Done wiring the driver role extension board, digging into the design of the logic

XEROX ALTO - DIABLO DISK TOOL CREATION

I received my chip sockets today and finalized the wiring of the driver role extension board. By lunchtime I was just completing a thorough connectivity and short test of everything before installing chips and wiring in the disk cable.

Soldering the 9 input and 13 output lines onto the board was tedious, but eventually I got the wires all inserted. For some reason, one of the input lines is missing, but I had verified it was wired on the cable a few days ago, so I probably taped it into the unused bunch. That adds yet another time-sucking activity, probing all the pairs to find the one that is connected to pin A.

With pin A's wire discovered and soldered down, it was time to bond all the grounds together and tie them to the board. A final test to ensure that no adjacent signal lines are shorting where I soldered the cable on, then it was time to figure out how to anchor the disk cable to the board.

I inserted all the chip, triple checked the pin assignments, polarities and voltage levels of all the level shifting circuits. Everything looks good, This needs +5V, +3.3V and ground power lines attached. I plan to put my copper ground planes on the bottom and top of the assembly and secure everything to finalize this, as soon as the plates arrive.

Board almost complete, waiting for power wires and ground planes

Cable to hook to Diablo disk drive and board to attach to FPGA

I had to begin the VHDL coding,with the sector and cylinder buffer transactions and basic transactions the first steps. This is because I can fully test these with the Adept utility before I add in any Diablo oriented logic or even hook up the extension board to the fpga.

I am still staring at the code, functionality and limitations of the various USB communications methods - essentially a remote block ram access, a remote DRAM access and some 'register' access to figure out the best way to build the system to handle both emulation and driver roles.

I am currently leaning to using just the 16MB of DRAM because it allows me to hold an entire disk cartridge in a easy to address format. Each sector, 532 bytes of data, will sit in 1024 bytes on the DRAM, an even power of two address. I will use five bits to select the 12 sectors (ignoring the wasted 4 sectors that this addressing selects. One bit for head, which has zero waste, and then 8 bits to specify cylinders 0 to 203, so again some waste.

It lets me cleanly control the top 8 address lines for cylinder number, the next line for head number, the following five lines for sector number, and then the bottom 10 bits are the byte number in the sector. No address multiplication, so a straightforward implementation, even if it is wasteful.

The 2,604,672 actual bytes of the virtual disk cartridge are sparsely stored in the 16,777,216 bytes of RAM. More than 84% empty but I have no use for the wasted RAM and this way it is easy to implement.

I will set up a special flag for each sector to show if the contents are invalid. That is, when I first start up in disk driver mode, until I read a particular sector, I have no idea what the contents of the sector will be. This flag will let me distinguish between an all zero sector and an 'undefined content' sector. It will only take up 4, 896 bits of distributed RAM, a teeny sliver of the available capacity on the FPGA chip.