I have confirmed that the data I extracted to a PC file from cylinder 0, head 0 and sector 0 of the real disk cartridge exactly matches the data on the disk since it matches the archive file of that disk that exists on bitsavers.org
My data is stored in disk order - where the data is stored with the last word of a record first, reversed so that the last word to come off disk is the first word of the record. The Alto loads the data into memory in reverse order, starting at the highest address in the buffer for the first word received and ending with the last word from disk placed at the lowest address, what we think of as the first word of that buffer.
The Alto uses that fact cleverly during boot. The boot firmware puts a spin instruction at location 0 which just loops to itself, then initiates a read from disk of cyl 0, head 0, sector 0 to place the 256 word data record of that sector in memory starting at location 0000.
The disk contents are stored in memory, starting with the first word from the disk at address 255 decimal, and proceeding down to lower addresses. As the disk read proceeds, location 0 is still a jump to itself keeping the processor in a tight loop. When the final word from disk is stored in memory, at location 0000, it overwrites the jump instruction and thus begins executing instructions from the disk sector from 0 onwards.
I modified the operation of my ReadField and WriteField FSMs to match the memory ordering, reversing the storing of words from disk. This should produce an exact match for the 266 words of each sector between what is on a disk archive file and what I produce.
Testing with my disk cartridge, I was able to match it up byte for byte with the bitsavers disk archive named xmsmall.dsk which does match the label on the physical cartridge. Other than the extraneous word at the front, it is now a match for the content of the sectors.
I had also instrumented the LEDs to show me any FSM that was not at its idle position, so that when the disk tool stalls again I can immediately spot which FSM(s) are confused. I set up for a test this morning with the new bitstream.
It never stalled - evoking the old adage that a watched pot never boils - but it did give me the data as I wished, in reversed word order, to match online disk archives and what the programmer would see in memory after issuing a read.
I do see that the online disk archive files have an extraneous word in front of the sector contents, which needs explanation before I can transform my output files into an acceptable archive file. The Contralto simulator uses the files and it simply ignores the first word from the file.
I moved on to test out my transaction to read an entire cartridge into RAM. I discovered two problems with this - first, it halts as soon as the finger is off the btn to trigger the transaction, and second it is not setting up the memory address properly so that I see the last cylinder's contents written in the position for cylinder 0.
I did a test to see whether the read field logic is not properly addressing cylinders above 0, or whether this is restricted to the read cartridge transaction. I saw that data was stored in the appropriate locations in RAM, so this was an artifact induced in the 'read entire cartridge' function.
I found the cause of the FSM needing button 1 to be depressed for it to continue up to cylinder 202, corrected the problem, and made a change to add an additional cycle for the bump of cylinder, head and sector numbers before triggering the read of the next sector. Half an hour later, the bitstream was ready for a test.
Nothing was working properly, all out of proportion to the two small changes I had made, indicating this is one of those odd times when the toolchain produces useless dreck as a bitstream. I made some other changes and synthesized again, now approaching late afternoon.
I also decided to swap the fpga board from the 1200K gate version down to the 500K gate variant that will be used for the tool in production, both the one used with the Alto restoration and a second tool to be used by Al Kossow to archive the contents of various disk cartridges.
I had to turn off the video display,which used quite a few gates, in order to fit in the 500K capacity. Other changes were also necessary, all in all the rework burned up a few hours.
When I did my evening testing, all appeared to be back to where I expected. The ReadSector function works fine, the Seek function works fine, and the ReadEntireCartridge function now runs to completion (cylinder 202) without having to hold button1 down continuously.
I dumped the file and checked, but found that only the even numbered sectors were read, implying I have a flaw in the incrementing logic for the ReadEntireCartridge function. It seemed that the logic stepped through every single cylinder, but I couldn't see how it alternated the head and sectors.
I did think of a way to improve some of my logic. The way I wrote the VHDL, it uses a chain of two adders to calculate the starting memory address as S + C - 1 (S is high order bits from cyl, head and sector and C is the word count), but I can assemble this without using an adder.
I have a memory address that has a high part generated from cylinder, head and sector values. It has a low part that is 9 bits representing the word within a sector. The high part is assembled from 8 bits of cylinder, 1 bit of head and 4 bits of sector number. All together, 22 bits of address.
I realized that the low part of the memory address is one of three constant values, x0002 for the header record, x000A for the label record and x100A for the data record. There are no carries that will propagate to the high 13 bits of the address.
I will also change instrumentation to let me watch, with the logic analyzer, as the ReadEntireCartridge function advances through all the sectors. That way, when I test tomorrow, I can fix up this last problem and be ready to capture the contents of the four cartridges we have with the Alto and the two that I have at home.