Wednesday, June 28, 2017

Building up self-testing generator inside disk tool, working on 1130 lights


This morning I wired up the sector number input signals to the spare pins where I was generating sham sector numbers tied to the sham SectorMarks I produce. The remaining logic design task is to produce a steady stream of clock pulses on ReadClock and periodic one bits on ReadData, such that the ReadSector logic can complete (albeit with checksum validity errors on every field).

I introduced the code, a variant of the logic that builds the clock and data pulses for writing. Clocks are steady, 100 ns on every 600 ns. Data bits alternate a 1 every 96 clock times (6 words apart) with 0 for every other clock time. The wiring is set to loop these signals around to the ReadClock and ReadData inputs to the board.

First I tested the WriteEntireCartridge to verify that my sector number generator will allow the mechanism to drive up through all sectors writing from memory. Next, I tested a ReadSector to verify whether the stream of bits coming it would cause it to complete a read, albeit with checksum errors since the incoming bitstream is nonsense.

Results of the test were initially poor. I forgot that the inputs from the Diablo are inverted logic, thus SectorMark is always at 1 except for the brief interval when it turns on with a value of 0. Same with the sector numbering, but I forgot the inversion. Also, the clock and data pulses needed to be inverted.

With the inversion change done and another 30 minutes of toolchain time, I reran the tests. This time, things looked much better. The WriteEntireCartridge function advanced properly through all cylinders, heads and sectors writing different patterns that I believe correspond directly to the image file I downloaded into the FPGA.

The ReadSector completed with checksum errors, as expected and a ReadEntireCartridge transaction ran up through all 202 cylinders reads 12 sectors from each of two heads. Untested as yet is the evidence that the data being read was placed properly in FPGA memory and available for upload, but I should be able to look at an uploaded file and see the pattern of 16 words of zero, one word with x0001 repeated over and over throughout memory.

After lunch, I will think a bit about ways I might inject a more realistic bit pattern including causing a checksum match. This might get complex but it is worth a half hour of thinking. I came up with an array of words, 366 long, which represents all the words to be output during a sector.

Triggered by the gotsector signal that informs a WriteSector or ReadSector transaction that it has matched the desired sector number and is ready to read or write, this steps through 16 bit positions in a word each time I am ready to send the next sham bit cell of 600ns, resetting and bumping the word pointer at the end of the word, then shutting down when the word pointer reaches 365 and the last bit 15 is output.

The remaining task is to preload the 365 words of this array with the proper values. For example, 34 words of zero, a word of x0001 as the sync bit, two words of header data, a checksum value, and ten words of zero as the interrecord gap. I will try to do this with a long string of initialization constants if I can sort out the syntax and stand to type in all those binary word values.

Meanwhile, I checked over my watchdog timer function, which flags if the WriteSector transaction ever experiences a new SectorMark before it is done writing out the three records of the sector. It is working properly, writing every sector of data and stopping the write transaction before the next SM arrives.

With the first version of my sham data emitting logic, I did a ReadSector and looked at the checksum validity bits when it completed.  All bad, furthermore when I looked the first two words were inverted. This was the signal itself to define whether it is a 1 or a 0 bit.

Even with this, the result is checksum errors on all three records and the data in memory is nothing like it should be. Time to look over the logic for ReadSector and ReadField and ensure that it is properly storing the extracted data word. Besides that, I put the scope on the stream being sent in, just in case my sham data logic was malfunctioning.

I can see the proper data bit sequence right on the scope, delivered from my sham data generator to the ReadData line of the disk tool input. The logic is not reading properly yet, but I think I saw a flaw in my sector triggering and did a run to fix that up.

Since the Alto stores data in reverse order (last word of a record, then each lower word until one word comes at the end), setting up my sample sector is a bit messy. I started with a sector where the header, label and data records were all filled with zero words. That made the checksum calculation easy - 0x0151 - and I will get a proper match.

Later I can enter the label field in reverse word order and compute as best I can the checksum value for that field. With those set in the sham sector, I would have a good checksum validation for that sector.


I don't have my jig built yet but I did solder up a small number of lights onto headers, using the new tinier bulbs I received from China. I will work on small batches until I have all 160 done, hopefully with a jig to speed things up. 

No comments:

Post a Comment