First result from the testing is that I have disabled the mechanism to read and write between the PC and the fpga memory. I stripped out something when I was removing all the combinatorial inputs to the state machines. I have a backup from about a month ago that I could look over and find the missing bits to restore the capability.
I did find what changed, but it was in an area with combinatorial logic creating signals that are inputs to FSMs, which I tried to remove as far as possible by replacing them with clocked processes that produce registered outputs.
A couple of signals weren't easily amenable to registering, without introducing a one cycle delay in responding to conditions, but they were slow changing fields that I thought worth taking a risk with. Meanwhile I will noodle on ways to move all to clocked processes.
The memory read/write logic is not working properly, thus I had to move on to the more challenging approach that removed all combinatorial logic from the mechanism. This changed the flow enough that testing will have to be focused heavily until we know it works.
By early evening it was writing and reading to memory properly, at least as far as the PC to fpga link is concerned and the contents of the archived image I downloaded to the fpga was reading properly. I then set up the scope to watch it write a sector, to see if it is still doing that properly.
My testbed doesn't provide all 12 sector values back to the logic, thus making it challenging to check out the full WriteEntireCartridge logic. Even more, it can't deliver a realistic input stream of disk data and clock pulses to check out the ReadSector function properly. I believe my ReadSector is hanging waiting for a sync pulse, but I need to route other signals to LEDs in order to test this out.
I now have the eight non-idle states of the ReadSector transaction displayed on my eight board LEDs. I also set up a counter to emit SectorMark signals once every 3.33ms just as the real disk does. This will allow me to try out a WriteSector and observe the pattern on the scope, in addition to determining where the ReadSector is stalling.
My sector signals are working properly and the WriteSector function seems to work perfectly. I still have the watchdog timer switched off - this should fire off if a sector is still being written when the next SectorMark arrives, but I have some flaw that triggers it falsely.
When I attempt a WriteEntire Cartridge, the logic writes the first sector and stalls waiting for a match on sector number 1, since my current testbed is continually reporting sector 0. However, I may be able to loop some more signals to drive the sector numbering appropriately.
I tested the ReadSector function, which should stall on the first field waiting perpetually for a sync bit, but instead it clocks through, issues a checksum error (appropriately for an all 0 field), then waits forever for the sync pulse that starts field 2. I can temporarily fix this up by wrapping signals that issues one bits periodically along with a steady stream of clock pulses.
The big question is why ReadSector thinks it got sync for the first field. Must be an error in the startup of my bit logic.
This will take some additional signal lines, jumper wires and a bit of fpga logic to produce the appropriate signal timings. By the time I retired for the night, the logic for producing 'rotating' sector numbers was complete but not yet wired in. Tomorrow I will need to work on the ReadData and ReadClock simulated signals.
DIGIBARN XEROX ALTO RESTORATION
Marc continued to battle the power supply, discovering a bad regulator and a failed power resistor (so far). I bought the replacement parts and will deliver them to him so he can fight on. We shall see what it takes to get this dual power supply (5V and 5V, interestingly) to work completely.
No comments:
Post a Comment