Finally feeling halfway human again, so spent the morning working on a complete redesign of the memory link logic, as the reference code from Digilent is untenable and too convoluted to attempt to modify.
As a utility function with many uses and options, it is fairly complicated. It has options to read and write to onboard flash, which I don't need. It can address memory at a low level, directly toggling control lines, which I don't need. It can read the RAM in either byte wide or full 16 bit word mode.
Since this is accessed from the Digilent Adept utility program on the PC, I am not certain that it always uses the word mode, so I must implement both byte and word mode functionality. This will take a bit of time to get working properly, but at least I have my memory access working to write those data words into RAM.
The utility works fine to read and write all registers except for the 'autoread/autowrite' register 14 which I need to move data between RAM and PC. I will continue finishing the design while working on the Alto this afternoon.
I saw signs of unreliability between the Xilinx toolchain and the Digilent Nexys2 board, something I have experienced in the past too. Some days back, switch 6 was not recognized at all, but it began to work after a few days. This morning, my memory request signal output on a PMOD pin was not working, but when I made changes to deliver this signal on a few extra pins as well, suddenly the original pin was functional
It seems that the bitstream going to program the fpga is corrupted, or some paths inside the FPGA don't work, which the vagaries of placement and routing choices will mean that one bitstream will expose defects while wholly unrelated changes produce a new bitstream where the defect is avoided.
In the afternoon, the restoration members met to test a few things with the Alto. I want to use the logic analyzer to capture the data words being read from the Diablo. Ken likely wants to test some Ethernet tool functions. We have a boot disk given to us by the LCM which we will attempt to boot up too.
We hadn't gotten a good trace from the logic analyzer, mostly due to attempts to create overly clever triggers for the capture of data, but decided to move on to testing the disk cartridge that LCM made for us.
We attempted the boot but it didn't complete. As we looked at the data words coming in, Ken noticed that the header showed us at cylinder 8, sector 0, not the boot location. Removing the disk drive cover allowed us to look at the rotary indicator dial. Indeed, as soon as we tried to boot we saw it seek out to cylinder 8.
Examining the cable carefully showed no problems, so we decided to put the scope on the disk signal that must be active (at ground level) to cause a seek. We didn't see it. The problem, whatever it was, went away from all the cable manipulation.
Of course, no boot because we had the erased cartridge in the drive. Next up, we put our new boot cartridge in place, hit the reset button and had a successful boot! The system consistently boots but we judge that we have a few relatively minor issues to fix before everything is 100%
The mouse does not appear to work, possibly due to a burned out incandescent bulb inside. When we run the microcode validation diagnostic (MADTEST), it suffers a failure and exits to the debugger (SWAT).
Some other applications fail in exactly the same way, such as Bravo, the editor, and Draw, the graphics program. Others, such a the CRT test or the KB test, work just fine. The SWAT screen and reported address is always the same, regardless of which application fails.
As we devoted only an afternoon to this session, we ran out of time to do much more than collect plenty of data which will be poured over in the coming days.
No comments:
Post a Comment