Thursday, September 15, 2016

Tool ready for first test with Diablo 31 drive

XEROX ALTO - DIABLO DISK TOOL CREATION

My first task in the morning was to walk through the results in simulation of the read sector and write sector commands to make everything was correct.  Seek to cylinder had a flaw, it was not putting up the cylinder address so that every seek would be to cylinder 0.

With the seek logic updated, I had good operation of seeks and could 'sign off' on that function. Next up was to work on the read sector function. I went back to fundamentals, carefully studying the Diablo manual and Alto documentation to be certain I was handling the read and write precisely as would be done on the Alto.

Some timing recommendations from Diablo are ignored in the Alto implementation. The most significant is the recommendation by Diablo that the write gate for a new sector is not turned on until 25us after the sector and that writing of zeroes at the end of the data record continues through the next sector marker for 25us.

I continued to pore over the situation when doing an update - where we finish reading one record of a sector and switch over to write the subsequent record(s). The precise way this is done is essential to producing a readable sector for future read commands.

My detailed examination of the read sector command showed it to perform apparently perfectly,

  • finding the correct sector
  • waiting for the right delay
  • scanning preambles to find the sync word
  • extracting data words
  • calculating checksums
  • verifying the check word against the calculated sum. 
It did this for all three records in sequence, in a way that should work properly with a real disk. I hope to test tomorrow with the Diablo drive on the Alto, at least to examine the first sector and compare it to what we think is being read.

When I began to examine the write sector command in detail, I quickly found a flaw. It was not writing out the sync bit to start each field. That was corrected, but the next problem is a defect in my design approach for writing a sector.

I switch off the write gate and stop writing zeroes as soon as I am through with the checksum of the data record, but I should continue up until the sector mark, I think, or at least for a reasonable postamble duration.

Since I am not going to do any writing tomorrow, I will put this change on the back burner and work on readying the tool for reading from the disk.

Another task today was to use my Analog Discovery to inject signals into each input wire on the Diablo cable and verify the expected results on the fpga input pin. Too, I would inject signals on the fpga output pins and verify the results were correct on the disk cable. This was essential before hooking up to the fpga.

I was able to confirm all the signals, assignments and quality except for two signals whose outputs seem to be bridged or shorted together somewhere on the board. Once I found that and corrected it, this was ready to hook up.

I also found a problem with the substitution I made of the CD4050 chip, but this is delivering +5V signals not 3.3V signals. I did some rewiring and it now produces +3.3 output on the signals into the fpga.

With a working connection board and presumed good logic in the fpga, it was time to trigger some functions and watch them on the logic analyzer. I tried to use of the Analog Discovery to drive index marker, sector marker, address acknowledge, file ready and ready to seek/read/write signals, which I hoped would work in spite of being generated at 3.3V to an input expecting 5V TTL.

The documentation on the Analog Discovery is paltry, to say the least, so it took some time to figure out how I might produce the bare minimum to drive my tool. I need to emit Index and Sector markers, with steady levels on File Ready and Read to Seek/Read/Write. Too, it would be necessary to emit Read Clock and a button to intermittently emit a Read Data pulse.

At the end of the day, I decided that I didn't have the means to adequately drive it with this tool. It might be possible to loop some signals from the fpga back to the cable, but that is a lot of logic coding to try to do in one night.

No comments:

Post a Comment