On 12/28/2012 06:30 PM, John Wilson wrote:
Eww! I don't even understand why they would
purposely do that. The PLL
either needs a handout or it doesn't. At the moment, my code ignores index
pulses other than to count them so it knows when to give up (even that
bothers me -- I'd rather use a timer than have the FDC totally wedge up
just because the disk's in backwards or whatever). My only plan for using
index pulses was for the "format" cmd.
The original 8272/765 non-A parts were worse--the darned FDC was blind
for a full millisecond after the index. This created problems with
reading some 9 sector media on very early IBM 5150s.
Other than data recovery, I never got how that's
useful. I'm never so
desperate for data that I don't care which sector it came from! Although,
the very weird SCAN commands show that they imagined just such a use.
I've never run into a program that actually used the SCAN commands.
They'd be the first thing that I'd throw overboard.
You also can
feed the 765 a "Read Track" with a phony datalength
specified. The 765 will suck up all of the data after the first DAM
after the index until the transfer count is exhausted. Thus, you get
gaps, AMs, headers, all "in the raw", meaning that the 765 does not
resync during the transfer.
Where was I for this?!?! That sounds very very useful, almost. What value
constitutes "phony"?
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.
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, consider
implementing some of the 82078 added commands,
particularly "Format and Write" (can make copying go very fast) as
well as the PM functions.
Very nice! I hadn't noticed that one (I've been using the PC8477B data sheet
since that was the chip I used in Rev A).
Personally, I'd do the board as a USB card,
given the difficulty of
finding ISA-equipped motherboards or dealing with the nuances of
PCI/PCIE, etc.
Absolutely. I'm working on that right now (so I'll have a PCB already
whenever XMOS finally releases the XS1-SU01A to mere mortals, which is
supposedly imminent). I just like to be compatible with everything.
There's plenty of software that wants a uPD765, especially if it's for
booting. I never got the point of the PCI Catweasels -- they aren't
compatible with anything (not even each other, or ISA Catweasels) AND they
use expensive hardware to use up a slot whose bandwidth they don't even
need. But then again, at least the cabling stays out of the way.
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.
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.
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?
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.
--Chuck