ALTO DISK TOOL
I received a copy of some informal Python code from Ken Shirriff to transpose between my disk tool file format and the 'standard' archive format used with Alto simulators and for bitsavers.org storage. The code works in one direction, from my file format to the standard, but I need it work both ways.
The changed code was used to build my image file. I set up for a test, downloaded the file to RAM, then wrote the 24 sectors on Cylinder 0 using this file data as the content. I then uploaded RAM after having read a few of those rewritten sectors - all without any checksum errors on those read operations.
The uploaded file was transformed back to the standard format and compared to the archive file from which the recovered sectors were taken. There are some differences but these are all in areas where just running Contralto and booting the cartridge causes very similar changes, comparing the archive file before and after I booted it on the simulator.
I have now replaced the 24 sectors that were accidentally erased when I had the procedural error a month ago, although I may rewrite them with the pure archive version at some point.
This accident occurred when I loaded new firmware to the fpga while the disk was still spinning, apparently activating the WriteGate and EraseGate lines while the disk spun under the heads at cylinder 0. The fpga wasn't modulating the WriteData&Clock line, so the result was a fully erased track on both head 0 and 1, with no clock or data transitions at all.
I ran the ReadEntireCartridge transaction wishing to see what sectors have reported errors and where the sectors differ from the archived image. I plan to monitor the raw data coming from test point 1, compare it to the ReadData bits returned and see if I can spot why the record had a checksum error.
It will be easiest with Header or Label records, but most of the errors I captured this time were in the 256 word Data record. This will require looking at 4, 112 bit cells (one or two transitions per bit cell which should produce a 0 or 1 data value). That will cover a span of 2.467 milliseconds, the majority of the sector. Much better to find a Header or Label record, requiring 48 or 144 bit cells and only 23 or 86 microseconds time span.
With 256 words, I can't possibly hand calculate the checksum of the bits I receive. Fortunately, I can have the logic analyzer display the calculated checksum and all I have to do is compare it to the word read in. That may tell me which bit position(s) didn't checksum properly, but I will also look for unusual signals coming in anywhere in that record.
I have identified sectors that have a checksum error in the Label record:
- Cylinder 73, Head 0, Sector 5
- Cylinder 110 Head 1 Sector 11
- Cylinder 137 Head 1 Sector 0
- Cyl 141 Head 1 Sector 11
There are a few other sectors with Label record errors and plenty of sectors with only errors in the Data record but I can learn something from the first four above which might guide me to a compensatory strategy or perhaps require investigation of more sectors with errors.
I have been using some analysis and visualization tools built by Ken to compare my uploaded file with the archive and other versions of xmsmall.dsk. It found many differences in the index word of each sector in the archive, which is generated by the archiving tool but not actually read or written by an Alto.
I changed the code to ignore the index word as it is irrelevant to analyzing accuracy of disk reading. I then found that the number of sectors with differences between my uploaded file and the archive file from bitsavers was 374,
The number of sectors with checksum errors was over 200, meaning we had about 3.5% difference. That matches quite well with the 3.7% difference rate between the bitsavers archive before and after it was booted under Contralto.
My in depth study of the disk surface will take place tomorrow, as it is getting late now.
No comments:
Post a Comment