search

JMarlin / nesii

0 stars 0 forks source link

[NES II] Read a sector #3

Closed JMarlin closed 3 months ago

JMarlin commented 3 months ago

Description

Turns out, per nesii#2, I can totally read a valid sector signature as long as I insert the proper number of NOPs to account for the faster CPU. To that end, it should be possible to do this same NOP adjustment to all the areas in the Woz ROM that do data reads and achieve complete basic sector reading.

Acceptance Criteria

JMarlin commented 3 months ago

Added Woz ROM track/sector address read code and added some NOPs, and I'm getting sector numbers that change but stay under 16 (stored in bits at $003c) and a track number that stays the same unless I manually push the head carriage (in found_track at $0040)

JMarlin commented 3 months ago

Have been wrestling all day trying to get anything over about four bytes to reliably sync, and unfortunately it definitely is coming down to hardware issues.

I decided to use the old debug output port as an interface for performing debug triggering at a certain point in the code, and configured it so that such a trigger would happen just before entering the Woz ROM read-twos-data-code.

I attached the logic analyzer to the two 74194 chips on my disk controller because they seemed like a good candidate for shifting in the floppy data. And they were -- it would appear that the board is doing something like shifting in a 1 on any read pulses and a zero if a certain number of clocks have elapsed, then copying the shift registers to another register and clearing them whenever the MSB becomes a 1. This is borne out by looking at the shift register values right before they're cleared, at which time just before and after the software trigger they show values corresponding to the data header and the first bytes of data that I had been reading in software on test runs.

I thought it would be very useful to use this data to confirm my software results, assuming that the analyzer would show all valid values and that I could use this to figure out what the correct delay for the software loops needed to be in order to match that data.

Except that the data changed on the analyzer in a very similar fashion to what I had been seeing in my software testing across multiple trigger runs. So it looks like the hardware itself is having trouble staying in sync for more than a few bytes.

There are a couple of things I can think to check immediately next:

  1. Scope the raw read pulses (timing mode, not state mode) along with all of the quantized signals to get an idea of their relationship and whether the source is bad quantization
  2. Run a halt loop immediately after triggering to see if the software reading from the card is actually the thing that causes the shift register to clear (which would be good news because if that's the case then it's still possible to correct in software)

If number 2 doesn't show any promise, then it looks like I might have to slow down the drive. I still feel kind of surprised, though, that it's a hardware issue since the NES clock is only about 11-12% slower than the Apple II's actual Q3 signal so I would expect desync to take more than a couple of bytes.

JMarlin commented 3 months ago

Did the check with the wait loop to see if the clearing of the shift register is caused by the software. It is not. No major surprise, but still. Now we know.

Time now to check the raw read pulses against the card signals and maybe, if we're really lucky, slow the drive down juuuuust enough that it can handle disks written on a normal Apple II

JMarlin commented 3 months ago

Final update so that I'm not going crazy later: EVERYTHING WAS WORKING FINE

I mean, there probably WAS some inconsistency in the data I was looking at on the logic analyzer and the monitor dumps, but almost certainly those were often just not-quite-in-sync bad first try reads of the sector.

The way I cracked it was by hexdumping the boot sector of the ADT 1.33 disk and using my copy of that disk to confirm. The data wasn't even close to looking right -- which was not surprising me all that much, of course. But then it dawned on me.

I wasn't continuing on to the actual decoding section of the Woz ROM code. I had only been getting as far as the checksum check and then immediately jumping out to the monitor. Except that the checksum check comes before the block that takes the twos data and the fours data and combines them to reconstruct the final data.

Once I called that, it basically started working fine. It should be noted that I DID end up bringing the drive motor speed down a little bit, but after doing that I brought it back up until sector reads on the NES stopped working and then back down until it was working again so that I could operate it at the top possible margin. And, beautiful thing, that's also within margin for the Apple II to use the same drive (I checked a couple of times back and forth)

One final note is that I wasted a BUNCH of time after doing my first swap-the-drive-between-machines test when the NES just seemingly stopped working entirely when I swapped back to it. Of course what was actually going on was that since I wasn't using the initial seek code, the drive was up at an incorrect track. Everything started going right as rain once I enabled the initial seek code. And as a bonus, it let me use that for the spin-up wait time and I was able to remove my big drive wait loop.

Whoop. Next stop: Update the boot ROM to jump into the boot sector and test sending disk images through ADT on the IIgs and seeing if I can boot 'em on the NES.