Remembering RAMAC

On 5/27/05, Tony Duell <ard at p850ug1.demon.co.uk> wrote: Yes... 4 bit rates - two bits from a TTL 'divide-by-N' counter chip can be written to by the 650x processor on the drive. The drive firmware looks at the track number and stuffs the two bits out an I/O port before reading/writing. ISTR one of the 4 available bit rates happens to match Apple II data rates, but I don't think anyone ever wrote a program for a 4040 or 1541 to attempt to decode Apple data. Not sure how the Apple detects sync marks, but Commodore drives have an 8-input-NAND attached to a shift register that will go 'true' when 8 bits of ones goes past the read head. The output of that NAND goes to the pin on the 650x that fiddles the overflow bit... one sees tight loops in the firmware where the CPU loops at the same address sampling the overflow bit, and what happens is things (other than IRQs) stop happening until the sync detector triggers, then the code flow resumes. I'm sure one could rig up another method of sync detection, but that one is quite efficient. One footnote about track densities on Commodore drives - the 2040 and 4040/1541 patterns are different, resulting in different numbers of blocks per diskette. Disks formatted on a 2040 have one track with more sectors on it than the same track on a 4040/1541 disk. I presume there were reliability issues with that particular track stuffing and cheap media. The 2040 and 4040 have identical hardware; only the firmware differs. All of my 2040s have been upgraded to 'v2' ROMs (turning it into a 4040 in all but the label), but I think I have one set of the old v1 stuff if I ever have to read an ancient PET floppy. All this code is available on funet, for the curious. It was not as catastrophic as the Apple 13 to 16-sector conversion, but for a brief time, there was some media chaos in the PET world. -ethan