[HN Gopher] GCR Decoding on the Fly
       ___________________________________________________________________
        
       GCR Decoding on the Fly
        
       Author : mmastrac
       Score  : 20 points
       Date   : 2022-11-29 23:08 UTC (23 hours ago)
        
 (HTM) web link (www.linusakesson.net)
 (TXT) w3m dump (www.linusakesson.net)
        
       | dmitrygr wrote:
       | Using glitch opcodes of the processor is a very nice touch!
       | 
       | For those who are not aware: 6502 was hand-designed. There are
       | many opcodes that are not documented (they were the "do not care"
       | squares in the karnaugh maps and PALs used to create various
       | internal control signals). This means that many still do
       | _something_. Over the years many were documented well, and this
       | code uses some of them, which is super cool! It does mean that
       | this code will not work on later 6502 variants like the 65c02
       | which act differently when faced with those opcode.
        
       | ajross wrote:
       | This is great, but requires a ton of background to understand
       | what the author is doing and why.
       | 
       | The Commodore 64 had a... somewhat unique floppy disk
       | architecture. The disk drive itself had its own 6502 processor
       | and some RAM, and so Commodore felt they didn't need to buy a WDC
       | or NEC floppy controller, they could do all the work of
       | interpreting the 250 kHz bit stream (which for physics reasons
       | can't be the raw bit pattern the user wants to store) from the
       | device in software. Woz had pioneered this technique four years
       | earlier, so they knew it could work even though they made a few
       | different and somewhat questionable choices in the hardware
       | design. That's the "GCR" encoding being discussed.
       | 
       | Also, having a separate CPU meant that all the filesystem[1]
       | duties were actually farmed off to the drive, the main CPU would
       | just speak what amounts to a system call (open/close/read/write)
       | interface over a 1 bit synchronous interface called IEC. But that
       | interface was slow. Hardware bugs with their interface chip meant
       | it needed to be bit-banged from the 1 MHz 6502's. Effectively it
       | was a 1 bit wide parallel port, and it was _awful_ (like,
       | literally 10x slower at disk I /O than an Apple II!).
       | 
       | BUT: the separate CPU had commands that would load and execute
       | code from the host, so its behavior could be arbitrarily changed.
       | So... a whole ecosystem of "fast loader" products grew up using
       | deep mysteries to work around this. Most of them were basically
       | two-bit clockless/async transfers written in extremely carefully
       | timed assembly.
       | 
       | But because of that crazy-accurate sub-cycle timing requirement,
       | you couldn't be doing stuff like "reading the disk" and "decoding
       | the flux patterns" at the same time. Fast loaders would load the
       | raw data out of the shift register and only when the full sector
       | was in RAM do the work of unpacking it into bytes to be sent over
       | the IEC wires. So even though the transfer was fast there was a
       | big latency cost.
       | 
       | So that's what the author is doing: reading bytes off the disk
       | and decoding them simultaneously. It's a pretty amazing trick.
       | 
       | [1] That's the word we use today. Commodore just called it "DOS",
       | which was ambiguous even then.
        
       ___________________________________________________________________
       (page generated 2022-11-30 23:02 UTC)