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:[email protected]] On Behalf Of Chuck Guzis Sent: Tuesday, August 11, 2015 7:25 PM To: [email protected]; 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
