Re: 5.25 drive emulator

[ctkwan@epsilon.csd.hku.hk (Doug Kwan ~{9XUq5B~})]

In article <1994May19.233320.15374@labtam.labtam.oz.au> philip@labtam.oz.au (Philip Stephens) writes:
   >For a real 5.25 emulator, you'd need to intercept and emulate all the
   >bizarre Disk ][ ports and try to do something meaningful with them.

     This wouldn't be impossible, but you would probably need to save your
   disk images as actual disk bytes so that you could emulate the raw reads
                         ^^^^^^^^^^ Depending on what disk bytes you're
                                    talking about.

   and writes that the controller card does; this would increase the size
   of your disk image by a fair margin (approx. 350-400 bytes per sector
   rather than 256).  But I don't think the emulation would be all that
   difficult as long as you knew what the disk I/O locations did (I used to
   but it's being a while... :-)
     The point is that just emulating a disk ][ controller and letting the
   original RWTS code (or whatever code is being used to access the disk ][
   controller) would be the most direct implementation, and it would in
   that case work for everything (or should, in theory).
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^I don't think so.

All nibbles on disks have their seventh bits set and the Disk II hardware
has the ability to insert one or two 0's between two nibbles. For
protected disks, it is important to preserve all 0's and 1's rather
that just the "bytes" which are read by RWTS or other similar programmes.
Also, there exist weird protection mechanisms like quarter tracks or
spiral tracks. So it is quite difficult to write a 5.25 disk emulator
for all kind of disks, especially games.

Since mosts disk are readable by RWTS, it would be a nice scheme to
"nibblize" a track on the fly. In this way you will not increase the
size of your disk image. I did this in my X window based Apple II+
emulator. Off course, you have to "denibblize" the raw tracks back
into sectors when you write to the disk image. Now, a problem exists
if a track is screwed up and you cannot convert it back to 16 sectors.
A work-around is to use a hybrid disk image format. Nice tracks are
stored as 16 sectors while bad one are stored raw. I haven't implemented
the writing mechanism though. Hope I can do this after I have finished
my thesis, which I have no idea of how it is.

my $0.02

						Doug