• Please review our updated Terms and Rules here

Run MsDos Floppy on Windows (Help)

C

ccameronn

New Member
Joined
Aug 23, 2010
Messages
5
Hi there,

A little over a year ago, I spent 50+ hours trying to copy this program called RXPII. I have purchased the program, and they have gone out of business, so this shouldnt be a problem to talk about legally.

About a year ago, I had Techimo help me figure out how to duplicate this program (rxpii). The thread can be found here: http://www.techimo.com/forum/technical-support/228219-clone-floppy-disk-help-5.html

Details on disk:
Origional: 720 kb
Bad sector copy write protection
The program looks for the bad sectors in order to successfully run.

_________________________________________________________________

Now I have another project for us all


Objective: Get RXPII working on Windows xp or greater

I would like to get this RXPII working on a windows computer, instead of DOS. The only versions of windows I've sucessfully had it run on is windows 95 and 98 in the cmd.exe

With all the newer versions of windows (2000, xp, vista, 7) cmd.exe can still open the program on the floppy disk, but it cannot pass the bad sector check that is built into the program.

I have figured out that this RXPII program has bad sectors built into the floppy disk on purpose, as a copyright protection they used back in the day.

So my question is, how do i get this floppy disk workin on a newer version of windows. The program seems compatible itself as it displays and opens normally, but does not pass the activation check.

My guess is the newer versions of windows do not know how to read bad sectors, which in this case needs to be done or the program will have a fail safe and close when the bad sectors are not in the proper spot.

Ive tried images, but again I cant find a program that will recreate the bad sectors and run as an ISO.

Lets throw some ideas down, and maybe we can solve this

Thanks again, Cameron

*Note*
I have purchased this program, and own full rights to it. The company has gone out of business, and no legal issues arise by copying this backup.
 
The usual way this was done was to "hook" the INT 13 calls with a TSR that knows the location of the bad sectors and passes an error back to the program when they're hit. This should work with your game, so get writing!

Don't expect the floppy service on Win XP+ to emulate DOS access to floppies very well. The driver and accompanying software layers are very different from the very simplistic Win9x implementation.
 
This was suggested by another persons finally (I was thinking the same as I was reading along). If you set up a VM (vmware, virtual PC, qemu, or (maybe but probably not) dosbox)), create a blank virtual floppy disk, install dos 6.x on your VM and use your same copyiipc to copy the real disk to a virtual disk. See if it runs. If so you can keep that virtual disk/OS and it won't take much space to store.

You'll be in the same boat otherwise of running the program through a debugger or disassembler, looking for int 13 calls and changing the jump conditions around so it goes to the next code whether or not it finds the bad sectors.

Alternatively you could also try running the program in an emulated environment (the emulators above) and if it runs and only does the floppy check upon loading (not while it's running) you could snapshot the system/memory used and just resume it each time.

Those are some simplistic methods. Not sure if you've done much research to find out if someone else bought the rights to the product. If so perhaps they've spun out a newer version.
 
Find a disk imaging program that will copy things completely, including bad sectors. Rawwrite or Teledisk might, dunno.

Once you've done this, use DOSBox or a VM with the floppy image mounted - should work fine.
 
Caluser2000 said:
Try reading the disk again after updating the fd driver to a 3 mode one:
http://www.tech-archive.net/Archive/WinXP/microsoft.public.windowsxp.general/2006-12/msg10589.html
Click to expand...

How is that going to fix the issue of copy protection?

FWIW, the response that says to use "format a: /n:9 /t:80" works fine on my system (XP Pro, SP3). No special driver needed. AFAIK, the basic legacy floppy driver structure hasn't changed since 2K (when power management features were added and the driver was split into two parts), so the 2K floppy driver may well work--and give you 360K capabilities as well--but I haven't tried it yet.
 
barythrin said:
This was suggested by another persons finally (I was thinking the same as I was reading along). If you set up a VM (vmware, virtual PC, qemu, or (maybe but probably not) dosbox)), create a blank virtual floppy disk, install dos 6.x on your VM and use your same copyiipc to copy the real disk to a virtual disk. See if it runs. If so you can keep that virtual disk/OS and it won't take much space to store.

You'll be in the same boat otherwise of running the program through a debugger or disassembler, looking for int 13 calls and changing the jump conditions around so it goes to the next code whether or not it finds the bad sectors.

Alternatively you could also try running the program in an emulated environment (the emulators above) and if it runs and only does the floppy check upon loading (not while it's running) you could snapshot the system/memory used and just resume it each time.

Those are some simplistic methods. Not sure if you've done much research to find out if someone else bought the rights to the product. If so perhaps they've spun out a newer version.
Click to expand...

This sounds the most logical. The program only does a copy protection check at loading, because we are able to take out the floppy disk for days and have the program still running fully functional aslong as we keep the computer on.

Ive tried DosBox in the past, with no luck. Those Virtual pc options came to my mind, but the tricky part I guess will be creating a 100% fully identical image that when the program calls the code to find the specific bad sectors, it will work.

I'll try this on thursday, and post my results. Im in school right now for computer programming, but dont know enough to edit the code to skip the copy protection. Im guessing its not an easy process, otherwise I would ask you guys to help me out on that, as that is the best option :)

Until Thursday, wish me luck :)
 
Chuck(G) said:
How is that going to fix the issue of copy protection?

FWIW, the response that says to use "format a: /n:9 /t:80" works fine on my system (XP Pro, SP3). No special driver needed. AFAIK, the basic legacy floppy driver structure hasn't changed since 2K (when power management features were added and the driver was split into two parts), so the 2K floppy driver may well work--and give you 360K capabilities as well--but I haven't tried it yet.
Click to expand...

I'll try this too, as it does make sense. In order to trick DOS to copy the floppy disk (720kb) to a floppy disk (1.44 mb) I had to enter the bios and change the floppy from a 1.44 to a 720. Then i had to put tape over the high density hole so the 1.44 mb floppy drive couldnt stick its pin into it. Then was I only able to make a copy of the disk that worked.

If changing the drivers, and the bios to a 720kb mode 3, and having it work on windows XP or 7, this would be genious.

Thanks for the input guys, Greatly appreciated. Again, I'll post results thursday.
 
If you want to know what sectors are affected (and you have a legal copy of the game), then just write a little TSR that "hooks" INT 13H and records the AX, CX and DX contents going into the interrupt and the status (CY and AX) coming out of the interrupt in a small memory-resident buffer. You can peek at the buffer (and even write it to disk) using DEBUG after the game has terminated. You can then use the information to construct a TSR that, when loaded with the game, simulates the behavior of the floppy exactly.
 
Chuck(G) said:
If you want to know what sectors are affected (and you have a legal copy of the game), then just write a little TSR that "hooks" INT 13H and records the AX, CX and DX contents going into the interrupt and the status (CY and AX) coming out of the interrupt in a small memory-resident buffer. You can peek at the buffer (and even write it to disk) using DEBUG after the game has terminated. You can then use the information to construct a TSR that, when loaded with the game, simulates the behavior of the floppy exactly.
Click to expand...

haha wayy over my head, maybe I'll bring it into my programming teacher and see if he can help me out with that. If i could get the copy protection fooled, its a win win situation haha
 
I've never had trouble formatting 360K, 720K, 1.2MB, or 1.44MB floppies with the standard drivers in Windows 7, which I assume don't have more legacy support than XP. I think the 3-mode is only relevant if the person has a specific variety of FDD that supports those formats through hardware somehow differently than an ordinary FDD, from reading that link.
 
lol. What language are they teaching you? If it's something semi-advanced like C you might be able to pull it off as a project for class. Creating a VM won't be hard but yes dosbox is kind of a hack not really a true emulated computer so I wouldn't expect it to work with copyright protection. Virtual PC, QEMU, bochs (I think bochs became QEMU or something else), or VMWare are meant to emulate an Intel PC accurately so they might be able to emulate all the proper int 13 calls. Yeah let us know what your results are. If anything at least you can much around with a copy of the exe still. There are documents out there btw on cracking floppy protection. Although a lot of them are written specifically for the application/game mentioned most of the techniques are the same all around. Basically "int 13" is the call to access a disk drive (or dos it's int 21) heck wikipedia describes it probably better than I will.

So that's what folks are/were doing in your previous attempts. Actually there's a previous conversation about it here
 
You must log in or register to reply here.
Back
Top