PDA

View Full Version : How to play originals that are in drive b looking for drive a?



Thraka
March 17th, 2014, 09:56 PM
I'm trying to play Star Trek Promethean Prophecy in drive b, my 5 1/4 drive. However, I think it keeps looking for drive A to do things. The instructions are calling for DOS 2.0 and I think it's similar to what some of the Infocom games do. Any idea on how to get these to work?

I was hoping to find some sort of redirect TSR I could load, or a way to just copy the disk to the hard drive and use a redirect a floppy drive to a folder or something, but I couldn't find anything.

MikeModifed
March 17th, 2014, 10:02 PM
"set command=drive b:" ??? or a variation thereof?

Mike

Thraka
March 17th, 2014, 10:08 PM
Thanks Mike.

However, I just found out the ASSIGN command on the Dos 6 supplemental disk will do drive swapping, I'll have to try this and find out.

Though, I would still love a way to install the game...

Thraka
March 17th, 2014, 10:24 PM
Ok.. well assign worked, I was able to map A to B.

However the game still gives me an error so I'm unsure. Maybe the disk is bad? It only reads as if it was a 200k disk, with a single 50k file on it, st.com. Does that sound right to anyone? Anyone own the game and confirm?

VileR
March 18th, 2014, 01:46 AM
Sounds like a nasty case of disk-based copy protection to me.

If that's what it is, there's usually little to do other than (a) using the 5.25" drive as A:, or (b) getting around the protection using less-than-legitimate means. I'd say you're looking at the reason why disk-based protection schemes started to disappear when multiple floppy formats (and hard drives) were becoming commonplace. :)

SomeGuy
March 18th, 2014, 05:36 AM
Copy protection schemes usually bypass DOS and talk directly to the BIOS. Sometimes they even bypass the BIOS and talk directly to the FDC chip. More often than not, they were hard coded to look for the disk only in the A: drive.

Disks meant to be used as booters often had a single small loader stub readable by DOS, with the rest of the program hidden outside of any recognizable file system. I think the reason for the DOS loader was that some computers might need special device drivers loaded first.

I assume you have a 3.5" drive as A: ? You could try using CopyIIPC to copy the disk to a 720k floppy. Not being familiar with the specific copy protection scheme, I would say there is perhaps a 50/50 chance that would create a usable disk.

Stone
March 18th, 2014, 06:01 AM
Switch the cable positions on the floppy drives.

hargle
March 18th, 2014, 06:06 AM
you should try this piece of software too:
http://www.coleskingdom.com/files/BOOTB.ZIP

It's a passthru boot sector that redirects accesses to A: to B:

Install the above onto a dedicated floppy that fits in your A: drive. then, whenever you want to boot to your B: drive, just insert that disk and boot your machine. You'll see the A: drive light up for just a second or two and then transfer to the B: drive and continue booting, assuming the disk in B: is bootable. It's a neat trick and quite handy.

Thraka
March 18th, 2014, 03:51 PM
That got me booting to B, however, B isn't a bootable disk.. odd eh? I'll have to just change the floppy cable to reverse assignments and see if that fixes it..

hargle
March 19th, 2014, 05:53 AM
That makes sense- you need to make a DOS bootable disk for your B: drive.
Then put the bootthru disk in A:, the DOS disk in B: and you should boot to a command prompt that says A:\>
Switch to your star trek disk in B: and the game should run.

Ok, there's a lot of shoulds there, but in theory this is how it is supposed to work!

SomeGuy
March 19th, 2014, 07:09 AM
Does BOOTB hook the Int 13 vector and switch the drive numbers around for the BIOS? Or is it just that DOS could boot from B: (BIOS drive 01h) if a BIOS happened to support it? BOOTB says it is not a TSR, so I would suspect the latter. (After all, DOS can boot from HDs).

A copy protection scheme would most likely talk directly to BIOS asking for drive 00h, so it would need something to alter the BIOS calls.

krebizfan
March 19th, 2014, 07:50 AM
You could try creating virtual machines that can only access the B: drive. Inside the VM, the B: will be treated as the A: for all purposes. OS/2 Warp has a bundled in option to boot a Virtual DOS Session off a floppy which worked with many tricky floppy only software.

Trixter
March 19th, 2014, 11:21 AM
Does BOOTB hook the Int 13 vector and switch the drive numbers around for the BIOS?

Yes. It intercepts all int 13 calls and switches the drive numbers (1 for 0, 0 for 1) then passes the request through to the original int 13. I haven't looked at it too closely, but I'm assuming it installs itself at the top of RAM and then reduces the amount of free RAM in the BIOS data area to hide/protect itself.

I've booted non-DOS non-copy-protected games using BOOTB.

Thraka
March 19th, 2014, 06:03 PM
Ok, the disk isn't bootable, even when the drive is connected and assigned in the BIOS as A. Booting into DOS and running on A the game works fine, so no disk issues, yah!! :)

Formatting a boot disk on drive B then using BOOTB to get to it, and running the game after booted worked perfectly, thanks!!

Agent Orange
March 19th, 2014, 07:52 PM
Ok, the disk isn't bootable, even when the drive is connected and assigned in the BIOS as A. Booting into DOS and running on A the game works fine, so no disk issues, yah!! :)

Formatting a boot disk on drive B then using BOOTB to get to it, and running the game after booted worked perfectly, thanks!!

Do a DIR on the subject disk and see if it has an assigned name. There have been instances where the program is looking for certain disk name. Shot in the dark.