On Nov 23, 2015, at 2:38 PM, David Bridgham <dab at
froghouse.org> wrote:
Otherwise it's the RM05 at 256 Meg, if I
remember right. But all those
disks are also expected to expose the actual geometry of the disk. While
fairly straight forward, it do expose you to a rather low level
interface, where you need to do a lot of calculations all the time.
All those old disk controllers expose the disk geometry. I've looked at
it for the specific case of the RK11 and it doesn't look too bad. If it
does turn into a problem, then we'll have a microcontroller on the board
too and I'll punt the calculations to it rather than doing them in the
FPGA. And my third option is to just do the trivial mapping of the
sector/surface/cylinder numbers to LBA and waste space on the flash
device. It's not we're so short of storage space in emulating any
number of RK, RP, or RM class disk packs.
You can certainly do a mapping with holes in it. That does mean you'd want to create
a utility that knows how to convert between your holy format and a standard packed disk
container file.
Then again, multiplying by a constant is trivial, and in a modern HDL you just write the
expression you need. The synthesis will construct some adds and shifts out of that. In
fact, even if you want to supply the geometry values from a table (so you're
multiplying by variable values) that's no big deal; two multipliers won't make a
dent in any modern FPGA.
Sure, you can throw in a microcontroller, but interfacing that is likely to take far more
gates than doing the mapping in the device directly.
paul