Abandoning plan to use onboard flash as a disk drive

The original plan for this system was to make use of the onboard flash on the Nexys2 board, whose 128MB capacity seemed to offer room to place seven virtual disk cartridges and access them from the disk emulation hardware as needed. The speed of the 1130 disk is slow, with 28 microseconds between each word as the data is streaming in or out of the heads, which would appear at first glance to easily allow for use of flash to read or write the word as needed. The flash has an effective write time of 13.6 microseconds per word, but that is at best case which would require building and writing 32B buffers not individual words, with some kind of FIFO buffer between disk emulation and the flash access module.

A complication comes from the implementation on the Nexys2 board, where the address, data and most control lines are shared between RAM and flash. Only one is accessed at any given time, with RAM the clear priority to ensure the 1130 operates correctly and meets its realistic timing objective. Thus, access to flash would have to fit 'in between' the 1130 CPU and cycle steal accesses. The initial concept was to only allow flash access at phase A of a T7/X7 cycle, finishing up any flash access use of the signal lines before the 1130 itself begins RAM access.

The complexity of overlapping all this, with operations such as a write of a 32byte block taking well over 200 microseconds to complete, then needing to asynchronously empty a FIFO on that long timescale. Plus, the challenges of error recovery are thorny since the disk emulation module and 1130 program itself will have moved well past the IO by the time the last part of a sector is written. Any problem is detected long after we could have presented some meaningful status to the software running in the 1130.

At this point, I suspect that any flash or disk drive used to emulate the disk drive will be hung off a fast serial link of some sort, eliminating the shared signals that ultimately forced me to drop use of the onboard flash. More later as I redesign and implement a replacement mechanism.
\
It is also possible that I will figure out a method that safely exploits the onboard flash, which would have been the most natural approach, most efficient in space and energy use. .