[NES II] Investigate and document current disk signal timing

[JMarlin]

Description

The hardware is built, the basic debugging firmware and development loop using the EEPROM emulator is working well enough. It is now time to get the disk and controller hooked back up and figure out what our current timing looks like and why it ain't working.

This story is just to re-document how timing is supposed to look, then instrument and document how the current execution does look.

Acceptance criteria

• [x] Re-read 'beneath apple DOS' low-level documentation, document in this issue what signals are important, where they are on the controller card, and what their timings should look like
• [x] Attach logic analyzer to the disk card's important signals, execute the woz boot code, and document what the signals during an attempt to read the disk look like

[JMarlin]

The book I was thinking of is 'Understanding the Apple II' Here's a link: https://archive.org/details/understanding_the_apple_ii

I'm going to mark off the items on this story, but mostly because after reading the documentation and messing around a bit, this story has become somewhat irrelevant.

I first confirmed that I was able to pull the basic 'search for sector signature' code from the original Woz ROM and running it detects a sector header just fine on an Apple IIe, which is a complete non-shocker. I then added the NOPs that it seemed would be required to match the period between DiskII data register loads on the ~1.79MHz NES to confirm that my understanding was correct and it would cause the signature detection to stop working -- which it did.

I then hooked everything up to the NES and went through the same process. Absolutely nothing worked with my custom Q3 generator in-circuit, but dropping back to the 'just use the main clock for Q3' approach the original Woz code hangs forever while the code with added NOPs reads the sector header perfectly fine. So, big win. I should be able to see if I can read a whole sector now as well.

For documentation purposes, the relevant thing to understand is that in read mode, the disk controller constantly shifts bits into its data register UNTIL the MSB has a 1 in it. At that time, it will cease shifting in data for the equivalent of 7 Apple II CPU cycles to give the Apple II time to read it and make sure it's the expected value. Therefore, if you don't wait long enough between reads, you're going to end up reading the same byte twice and therefore never get the data you expect (eg: if you're trying to read 'D5 AA', you'll read 'D5 D5' instead if you do it too fast) which is relevant to the NES because it's running almost twice as fast. Hence the need to add the NOPs.