Commodore were well known for using the cheapest and easiest to obtain hardware they could, and working around the resulting quirks in software. The Datasette was the budget alternative to the 1541 floppy drive, itself a decidedly limited device whose firmware had been hobbled for compatibility with bugs in the 6522 VIA used in earlier Commodore machines. So the tape transport was a bog-standard unit that was probably originally designed for a "shoebox" portable dictation machine; Commodore's replacement electronics were even simpler and cheaper than the basic audio-grade circuits such a device would have carried. The erase head applied only a DC field, there was no bias circuitry, and I don't think there was even any explicit regulation of motor speed.

In short, it was engineered for cost, not for performance. The standard recording format was legendarily slow and inefficient, too - it was supposedly designed to maximise reliability to compensate for the shortcomings of the Datasette itself - making fastloaders de rigeur for commercial releases. Often the opportunity was taken to include a loading screen and music in the fastloader's functionality. It seems these fastloaders were still acceptably reliable despite cramming much more data into a tape than Commodore's default format.

Obviously with a better-quality tape transport, it is possible to obtain better performance, possibly even while running at the original tape speed. Using the shorter tape lengths (C90 and above use a thinner and more fragile tape) doubtless improves reliability, too. And using the tape formulation that the tape deck is optimised for (probably ferric oxide for a cheap one, instead of chromium dioxide or the metallic coatings which require more effort to magnetise) would improve reliability of recording too. I wonder how many reports of bad tape reliability come from inappropriate use of "high quality" CrO2 tapes in a deck not designed for them?

The timing accuracy I need to achieve the equivalent of 7500 baud with EFM is very close to what the "Fast Evil" C64 fastloader requires to achieve 4400 baud with a basic pulse-length modulation. That is, the latter has an average pulse rate of about 4400Hz, but the difference in the pulse lengths for a 1 and a 0 bit is roughly 1/12000 sec.

And now I realise there was an error in my arithmetic earlier - for these specs, I actually need an extra frequency division of 128 times, not 64. But this still works out faster than a stock 1541 floppy. Awkward.

Subject:

I am greatly enthused that other people also had the idea to backport features from Compact Disc to floppy disk. I had not seriously considered the further application to magnetic tape but it is a logical continuation.

I am not working in this field specifically but I am working in the analogous field of networking. There are obvious overlaps. As noted by Steve Wozniak, floppy disk interfaces may be used for networking. Indeed, the major difference is the clock speed and bit stuffing required for each medium.

I have an outline for a 256 bit cell network interface which may also be used for track-at-once floppy disk storage and/or tape storage. It is intended to be used with 8/9 bit stuffing, Hamming code on 80 bit blocks and a higher tier of FEC and CRC32. This could be modulated with the typical 1200/2400Hz frequencies for tape. Indeed, this may be compatible with vintage hardware from one or more manufacturers. For floppy disk, it is probably easier to start again. This is particularly true if track length varies with track number.

For magnetic storage, it may be possible and desirable to skew into a corner case which does not apply to networking. Specifically, with full control of floppy drive motor and possible servo control of tape, it is possible to record at 95% speed and read at 90-100% speed. This allows, for example, use of a floppy drive which is out of tolerance. It can also be applied in a manner which keeps bit slip small and favorable. For example, it might an advantage to ensure that bit insertions - and only bit insertions - have a specific frequency. This demonstrates that playback is occurring at a slightly slower speed than the recording. An adaptive estimate can be maintained for each device. In the case of floppy disk, an estimate can be maintained for each track.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

I only skimmed the thread, so sorry if that has already been mentioned.

Commodore and Apple both built their own schematics on top of almost bare-bones mechanical drives, using shift register etc to send/receive bits from the drive.
I have written an article here https://extrapages.de/archives/20190102 ... notes.html
and also Michael Steil of pagetable fame has written very interesting articles, e.g. https://www.pagetable.com/?p=1070

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Your article is good fachat.

For really getting down into the details of how floppy drive systems work, I cannot highly enough recommend Chapter 9: The Disk Controller from Jim Sather's Understanding the Apple II (Quality Software, 1983). I have seen nothing else that goes so incredibly deep into the operation of floppy controllers and drives while still being highly accessible to those with only basic electronics knowledge.

_________________
Curt J. Sampson - github.com/0cjs