18 Feb
2010
18 Feb
'10
4:30 p.m.
Chuck Guzis wrote:
The big problem that I see with this deviceside widget
is that it has
limited current drive capability. 8" drives use 150 ohm pullups in
their terminators and present a 1 TTL UL. That's asking a lot from
a little uC.
It seems a lot of folks are falling into the same bear-trap. The SPS
(www.softpres.org) "Kryoflux" analyser is based on an Atmel ARM micro,
but they're direct-driving the disc drive from the MCU I/Os. This sort
of "design" makes me cringe...
I'm using TI and Fairchild line driver chips -- 74LVX14 and 74LVC07.
24mA output drive, series-resistor overcurrent protection (and the
option of fitting transient suppressors as well). They're TSSOP, but the
PCB solder-mask makes them fairly easy to replace with a Stanley knife
and a cheap 25W soldering iron.
Also, what's the issue with "Flippy" disks? Why can't you just reverse
the data in the buffer to account for the reversed disc rotation?
I'm also not sure how well the device handles the
higher densities.
That would depend on what method it's using to acquire data, and what
the acquisition clock rate is.
Feed it a Copylock-protected floppy from an Amiga or an Atari ST and
it's just about guaranteed to fall over. That said, most Amiga and ST
discs were 3.5-inch...
I still prefer the simplicity of the CW MK 1 run under
DOS. Fully
documented and easy to program. Can be made to handle just about
anything.
Hm, as I understood it, you couldn't handle hard-sectored discs with the
Mk1?
Although IIRC it doesn't have any onboard memory either -- your sample
length is limited by how much base memory you can grab (which would be
somewhere in the region of 64k per segment for plain DOS, or a few
GBytes for DOS+DPMI).
The advantage to raw DOS is that (even in CWSDPMI or DOS4GW) you can
take over every part of the machine. "Write this value to port 0x378!"
"Yes sir!". You just don't have that level of control when you're
running a multitasking OS.
There's no reason that the CW couldn't handle
both reading and
writting Apple IIe floppies, but Jens comes right out and says that
he doesn't write software for these things.
"Look, it's a shiny box that doesn't do anything!"
This is the one situation I don't want to get into with the DiscFerret;
I'm holding back on the hardware because the software is utter cack.
That said, the access API (libdiscferret, aka DiscAPI) is stable and
could "in theory" be extended to permit use with the Catweasel, if one
were so inclined. All by design, too :)
So you're depending on
the kindness of strangers. The disk encoding format is well-
documented in "Understanding the Apple IIe". It's not rocket
science.
It would take some effort to write a "good" GCR encoder/decoder. I'm
having one hell of a time just getting my FM/MFM decoder to behave
itself. For some reason, old Acorn DFS format floppies (FM, 250kbps)
don't read very well in any drive.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/