10 Dec
2021
10 Dec
'21
6:21 a.m.
On 12/9/2021 11:06 PM, Guy Sotomayor via cctalk wrote:
On 12/9/21 8:15 PM, Jay Jaeger via cctalk wrote:
1) Because not everyone has that kind of design experience and
capability (I do, but that is beside the point). In such a case,
suggesting a FPGA might cause those readers to just skip it without
further thought, whereas suggesting a micro is less likely to have that
effect on someone who *does* have the design experience.
2) Because the tooling on FPGAs is sometimes a pain and the parts
themselves are always in flux, and the updated tools often don't support
the older parts. Over the last 20 years I have gone through at least 3
different FPGA development boards and toolsets, where as my original
Arduino is just as useful as ever.
3) Because a highly flexible FPGA development board costs a lot more
than a micro, and micros would be a lot cheaper on a stand-alone PCB
than an FPGA part (or an FPGA through-hold carrier for those who are not
up to doing something like an FPGA part on a PCB.)
4) Because a micro form factor is smaller than an FPGA development board.
5) For someone well versed in software but not as well versed in design
(though enough that they could still do what you suggest), doing the
software might only take a couple of days for something like a 64Kw disk
(if it isn't too fast), and easier to debug/fix/enhance as well.
6) Because it was just a *suggestion* that one might emulate the disk
itself in hardware (see also point 1).
On the other hand, speed kills, and some disks are just too fast for a
micro alone to do.
One could perhaps emulate the RS64 data stream using a fast-enough
micro, ala the MFM emulator.
Why does everyone seem to want to emulate HW like this with a micro when
a reasonable FPGA implementation with some external FRAM would do the job?
The SMD/ESDI emulator that I've been working on
has to "brute force" the
emulation because of BW concerns.? That is, it has to read the entire
emulated disk image into DRAM because:
1. You need at least a track's worth of buffering to send/receive the
?? data though the data interface (serial)
2. You don't have enough time to transfer tracks in/out of the track
?? buffer to flash (or what ever) to meet the head switch times
3. You don't have enough time to transfer whole cylinders in/out of the
?? cylinder buffer to flash (or what ever) to have reasonable
?? track-to-track seek times
So it will require a micro, but that's mainly to manage what's going
in/out of the (large) DRAM back to flash (it reads the entire emulated
disk image into DRAM during boot).? All of the actual commands and data
movement across the interface are all done by an FPGA.
Cool. Would love an ESDI emulator for my Apollo DN3000 and SMD
emulation for my VAXen and PDP-11/24.