> On Nov 23, 2015, at 2:38 PM, David Bridgham <d...@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
