User interface test verification part 16

BOOTING AND SEEMS TO BE OPERATING PROPERLY

I chose to do some verification that my functions were still working before I dove into more general debugging.

DO THE KEY BRIDGES WORK? 

Indeed I appear to be successfully reading and writing over the H2FLW and F2SDRAM bridges. Response are reasonable and I do see the telltale LED turn off when my loop code in the FPGA advances after having completed a write to RAM of the block sent down. 

I starting walking through the code of a load with pauses to verify I had reasonable responses. If I have a problem with holding off the next block coming from Linux to FPGA while I am busy writing to RAM, I won't see it at this slow pace but that is easily checked by removing the pause statements later.

FIRST ISSUES DETECTED AND BEING HANDLED

I knew that the ARM and x86 systems were little-endian, which means that a 16 bit word that is a single long integer x01F6 will be stored as xF601 in memory. I didn't realize that it also flipped the two 16 bit words returned from a file access. In other words, the first two 1130 words in the virtual cartridge image file are x0000 and x0658 but when I fetch a block of 32 bits from the file I see them in memory as 0x5806 0x0000 meaning that both the bytes in a word and the words themselves are flipped. I had hoped that the two words in a block would be N and N+1 from left to right, not the N+1 and N I encountered.

I can easily fix this in the getdata module that reads and writes blocks from the Linux application over the bridge. I reshuffle the bytes so that the disk contents make sense from an IBM 1130, 16 bit big endian perspective. 

Next I discovered that my understanding of how to address the H2F LW bridge was flawed. Initially I intended that I would only send one 32 bit command word and retrieve one 32 bit status word, thus could ignore addresses. Lately I expanded it to allow me to interrogate up to three 32 bit values from the FPGA in addition to the status word, simply by using the associated address for my fetch or store in the Linux application. 

The addressing can be either symbol or word oriented, plus a given number of bits of address which constrains the maximum range of addressability. For the command/status channel of H2F LW bridge, I wasn't using the correct addresses thus when I tried to fetch my current RAM address from the second word of the channel I didn't get the intended value returned.

Once I got to full speed on this, I chose 4 address bits (1 of 16 addresses) with the address specifying the byte. My bridge channel transfers 32 bits (four bytes) at a time thus the relevant addresses for my intended data are b0000 to b0011 for the status word, b0100 to b0111 for the RAM address word, b1000 to b1011 for the cylinder address of the drive emulation, and b1100 to b1111 reserved for a future fourth word. 

I chose the Cylinder value based on a reader's suggestion that I consider showing the arm movement graphically while the drive is in operation. I am still not convinced this will be worth the effort, considering that the box will be hidden on the side of the machine inside its covers, but if I have spare time and can implement it economically, I will have the relevant data at hand in the Linux application.