Thanks for the detailed description (and thanks to everyone else for their input!). That
all makes sense. The firmware for the SuperCard Pro is closed source (which is kind of a
bummer) so I can't look at it to see what it's doing. I've posted a message
on the CBMStuff Forum and we'll see what the creators say.
Thanks!
- Josh
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at
classiccmp.org] On Behalf Of Chuck Guzis
Sent: Tuesday, August 11, 2015 7:25 PM
To: General at
classiccmp.org; Discussion@
Subject: Re: Writing 8" floppies with SuperCard Pro
On 08/11/2015 05:53 PM, Josh Dersch wrote:
Absolutely no idea -- the manual isn't
particularly technical and the
SDK mentions nothing. I'll see if there's anything to be dug up in
this regard. (Thanks also to Eric for suggesting this
problem...)
There should certainly be enough horsepower there to do just about anything. The cheap
Chinese emulators use a little STM32F0 ARM Cortex
M0 family MCU--dirt-cheap. There's a bit of logic to perform level shifting and OC
interface, but that's about it. If you encode/decode MFM data on the fly, 32K is more
than enough for track storage at 500Khz and a little buffering. Some years back, I did an
emulator using a
ATMega162 DIP and some external SRAMm running at 8MHz. Still more than enough, but a
little tighter in coding. The Chinese ones get away cheap because the format and encoding
is predetermined.
But back to write precompensation. The general theory is this.
Outer tracks have lower linear bit densities than inner ones because they're longer
from index to index. (Would you rather run a race on the inside or the outside track?)
Thus, bits (or rather changes in direction of magnetization) are closer together.
Depending on head construction and track width, adjacent bits can be shifted via
interference from the nominal bit timing window (yes, that means a bit already written can
be shifted away from its nominal window timing center even though you put it there
originally).
So, the scheme is to "write with history". That is, a shift register is used to
remember what was last written, what you're currently writing and then what's
about to be written--and the write signal shifted a few hundred nanoseconds
"early" or "late" (or not at all) according to current, past and
future data, which produces a train that's closer to optimal.
All of which explains why the results with no precompensation get worse the shorter the
track gets.
Another approach is to use "zoned" recording, where the disk is divided into
zones of varying bit density, according to how close to the hub they are. You may be
familiar with this with the Victor 9000 or early Mac floppy drives, but the technique is
much older than floppies.
Hope this helps,
Chuck