23 Nov
2015
23 Nov
'15
2:38 p.m.
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.
23 Nov
23 Nov
7:05 p.m.
On Nov 23, 2015, at 2:38 PM, David Bridgham <dab at
froghouse.org> wrote:
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
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.
7:45 p.m.
On 11/23/2015 07:05 PM, Paul Koning wrote:
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.
That's why that's my first choice. I just don't think it will be a problem.
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.
The original reason for the microcontroller is to implement the USB
protocol. I didn't feel up to that in Verilog.
7:51 p.m.
On Nov 23, 2015, at 7:45 PM, David Bridgham <dab at
froghouse.org> wrote:
On 11/23/2015 07:05 PM, Paul Koning wrote:
...
I can understand that, but surely that's an off the shelf item?
paul
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.
The original reason for the microcontroller is to implement the USB
protocol. I didn't feel up to that in Verilog.
8:34 p.m.
On 11/23/15 19:51, Paul Koning wrote:
I can understand that, but surely that's an off
the shelf item?
An implementation of the host side of the USB mass storage protocol? In
what form: an IC, IP for the FPGA, software? I'm sure the last one
exists but if either of the first do, I don't know about them (not that
I know a lot about what's available).
3158
days inactive
3159
days old
4 comments
2 participants
participants (2)
-
dab＠froghouse.org -
paulkoning＠comcast.net