Given the disk crash we had on our spare drive, which we anticipate is repairable with sufficient cleaning of the heads, and a crash that another Alto owner suffered last week, I decided to move forward with the disk emulator version. This version will attach to an Alto disk controller card and respond as if a real Diablo drive and cartridge were present.
I had worked out some of the logic simply to test the disk driver version and thought through most of the functionality in the past. I will fork off a version of the tool and begin logic development. In addition to different logic loaded into the fpga, it needs an alternate plug-in board that routes signals through output drivers and input level shifters.
The emulator board will require a female connector to which the disk controller cable will attach, but will implement terminators on board rather than requiring a specific connector for an external one.
The difference in counts, otherwise symmetric, is due to the elimination of the Erase Gate input signal for the emulator. Since we know that an Alto ties Write Gate and Erase Gate together, whenever we see the Write Gate line we know the value of and needn't sense Erase Gate.
Before I did anything, I backed up the current state of the Disk Tool project. I then found a way to copy it to a new project, the disk emulator. Only when I knew that changes to the emulator won't impact the disk tool at all, was I ready to begin writing VHDL.
I built a couple of the emulator boards assigning fpga pins as input or output, using the level shifter or driver chips and routing it to the appropriate pin of the connector that will hook to the Alto disk controller cable.
The logic is interesting working this way. Essentially I will have a continuously running process that "spins" the disk producing SectorMark, another that runs continuously to produce the clock and data bits for each sector as it passes under the virtual disk head. The outputs ReadClock and ReadData are gated by the ReadGate signal but otherwise being continually generated by the reading process.
Only when the WriteGate signal is activated will I block the reading of words from memory, decode the WriteData&Clock signal to form words and stick them away. Not sure how to handle the writing side, likely another process synced with the continually reading process. This will be the only tricky part.
The Alto will be giving me padding words, sync words and other content while the WriteGate is on, thus I have to shadow the Alto to know which are data words for the header, label and data records in the sector.
Given the similarity of the disk packs, maybe a lot of that might be transferable to a DEC RK05 emulator as well...
ReplyDeleteYes it certainly could. The RK05 disk structure is easier but the key to easy adaption is how many input and output lines I need to accommodate for the RK05.
DeleteSounds fun. It looks like you already have the beginnings of an FPGA solution, but another approach is to use a generic microcontroller with a 5V-tolerant CPLD to help with the time-critical stuff. I used that method for a Mac/Lisa/Apple II disk emulator, and it's proven to be a powerful combination.
ReplyDeleteThe microcontroller loads one track's worth of data from an SD card into internal RAM, and then continuously spins the disk, just as you described. It passes one byte at a time to the CPLD, which shifts out the bits at the proper rate and preloads the next byte so there's never a data gap. The CPLD also handles things like output enable and others that require faster response than the mcu can provide through software. Although with cheap 32-bit mcus now reaching speeds of 100s of MHz, I've wondered if the whole thing could now be done entirely in software on the mcu.
For writing, I keep track of the last sector header that was read out, and assume any write operation is an attempt to update that sector. It doesn't attempt to do bit-level updating of the disk image during a write, such as overwriting half of one sector with a new one. In practice this works well and simplifies things greatly, but it does mean the hardware can't do a low-level format of the emulated disk.
What do you plan to use to store the disk image? How large is the disk? If it's not huge, you might be able to store it entirely in RAM on your board, which would probably make your job a lot easier.