I uploaded the data from the test of my newly crafted logic for recognizing incoming data bits and found that absolutely zero sectors encountered a checksum error while reading. That is a 0% error rate, all I could ask for.
The data appears to be a faithful copy of the disk cartridge, although it does not match word for word the archive on the internet which I assumed it was from. 135 of the 4782 sectors have differences between the two versions.
I repeated the run just to confirm that checksum processing is passing on all sectors. I had the slide switch set to stop immediately on the first checksum error while reading an entire cartridge, yet had no stops. The data was identical to that I uploaded on the first run.
In addition, with a method that appears to read perfectly, I will attempt to read some cartridges on the Diablo drive attached to our restored Alto on our next session this Friday.
When I tested the disk tool on the real machine's drive to write a known image to our erased cartridge, the resulting data did not boot properly on the Alto. I need to do more debugging to determine why my WriteSector and WriteEntireCartridge appears to be malfunctioning.
These are essential in order to take archived images and restore them to cartridges, opening up the restored Alto to all the saved software that is accessible, whether from Bitsavers, PARC itself, personal Alto cartridges owned by various former researchers, or from LCM in Seattle.
I will retest my writing method by loading the known image of the cartridge XMSMALL, which is what I think I have on hand, into the disk tool. Then, I will rewrite just the first 24 sectors since that first cylinder was accidentally erased some time ago. That done, I will again read the entire cartridge and do a comparison run. The first 24 sectors should be identical if I am writing correctly.
With all 24 sectors on cylinder 0 written from the backup archive image, I ran a ReadEntireCartridge transaction and uploaded the data I had read. Running the compare program of the archive image against what I read, those 24 sectors are an exact match.
I did see an anomaly where the data in the latter half of the cartridge, beginning with about cylinder 71 up to the end was massively different now. I don't know why this would be, unless it was some error in either the format conversion program or in the compare program, since I hadn't moved the arm from cylinder zero when I was doing all the writing. I also power cycled everything before doing the read of the whole cartridge.
I may be experiencing a flaw in the function which reads the contents of RAM up into a PC file. I can check that by doing another run to read the cartridge, then comparing it to what I just saw. The new run was about the same as earlier today, with cylinder 0 an exact match but the roughly 130 sectors with minor differences were still there.
I converted and mounted the disk image I had just extracted on the ContrAlto simulator and was able to boot it up successfully. I am feeling quite good about the state of the tool today. I anticipate a successful session on Friday where we can archive all the packs on hand as well as writing the games image onto our previously erased cartridge.
Just before dinner, I converted the online archive image for XMSMALL into my format, loaded it onto the disk tool and then extracted it again. This will test whether the Adept functions are reliable. When I compared the archived image I had downloaded to the extracted image I uploaded, they matched 100%.
After dinner, the archive image was loaded again and I did a WriteEntireCartridge operation. This should leave me with a disk that is an exact sector for sector equivalent to the archive image. To test that, I would take the pack, perform a ReadEntireCartridge operation and process the file for comparison.
The data I read from the cartridge was compared to what I wrote, which was the XMSMALL archive image, and matched perfectly.
Congratulations!
ReplyDelete