On Fri, Dec 28, 2012 at 07:59:42PM -0800, Chuck Guzis wrote:
I've never run into a program that actually used
the SCAN commands.
They'd be the first thing that I'd throw overboard.
I was kind of thinking that. I'm inclined to do them just for completeness,
but how will I know if I've succeeded if there's no code that uses them?
Whatever tests I write myself will only verify the parts I understand...
Well, since a "306K" floppy has 6250
"raw" bytes per track, try
issuing a "Read Track" with a sector length of 8192 bytes for just a
single sector.
Now I'm with you. Cute!!!
Note that if you format a track substituting very large
sector sizes
(say, 8192 bytes) in the headers, then write one of them, the write
will wrap around the index and "eat its tail", leaving a track with
no address marks. Very useful for faking a blank track.
Also cute! And also easy to emulate -- it'd be hard not to.
Most systems made after about 2004 or so have an option
to boot from
a USB floppy, so emulating that for starters would be an option.
Even running DOS 6.22 with a USB floppy still allows for read/writing
and formatting--the more esoteric operations, of course, aren't
there.
Yeah I was thinking about that as one option. So it's just a raw disk for
this case, and then there's some way to switch it to being a .DSK file inside
a flash drive, for when you're reading a stack of old disks into image files.
As far as the Catweasel, I use both the ISA and PCI
variety--and my
code works with both--it's just a matter of figuring out which you
have and setting up some tables.
Sure, if it's that simple. I wrote a driver for the ISA and the PCI
version too (the first one -- doesn't the later PCI board need to have FPGA
code fed to it at runtime?) and *never* got them working reliably, because
junk bytes appeared in the buffer often enough to make reading impossible.
Obviously it may be I just wrote horribly buggy code (that's how I've spent
my whole life!) but the track data really seemed to be already munged when
it was coming out of the SRAM buffer. So my guess is that I was violating
some unwritten rule about not touching the registers at certain times, or
something. I'd look it up in the manual ... if there were one!
That's really what started this project -- I've spent *way* too much time
hacking on driver code for Catweasels I spent *way* too much money on (I
think I have four), for no results at all.
THe CW is useful for a lot of oddball formats. Right
now, I've got a
batch of hard-sectored floppies to retrieve data from that were
written using a Zilog MCZ. Care for 132-byte sectors?
Kinky! I wish I knew more about hard-sectored disks. I recently totally
failed a customer who wanted some closed-captioning data read but had no
idea what system the disk came from.
But then, I can emulate a Catweasel just fine--and get
a USB
interface using just about any modern MCU. I prefer the PIC32 chips
but an ARM would do just fine also.
I'm sure almost anything would work. I'm having a blast with the XMOS
XS1. The instruction set is vile -- the usual RISC mishmash that's
designed to make simple-minded C compilers look good -- but the way it
handles events and hardware multi-threading is beyond awesome. You enable
the events you care about (timers, GPIO changes, data in a channel) and
then wait for the next one. Each hyperthread has all its own events.
I have yet to need interrupts for anything...
John Wilson
D Bit