On 12/10/21 6:21 AM, Jay Jaeger via cctalk wrote:
On 12/9/2021 11:06 PM, Guy Sotomayor via cctalk
On 12/9/21 8:15 PM, Jay Jaeger via cctalk wrote:
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?
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
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
6)? Because it was just a *suggestion* that one might emulate the disk
itself in hardware (see also point 1).
All valid points.? My frustration has been where I see projects that use
a RPi for something that a simple HW circuit/CPLD/FPGA could have done
it simpler and more efficiently.
I've lost count of the FPGA boards that I have.? I also typically don't
use eval boards for actual projects other than testing a few "flows".?
Everything gets done with a custom board because I typically need other
components and it gets too messy if I'm just using an "off the shelf"
eval board (and more than likely the eval board doesn't have enough I/Os).
I should also note that the Beagle Bone MFM emulator isn't actually fast
enough.? It works OK if you only have one drive but it's not fast enough
to handle the drive select signal when you have more than one.
On the other hand, speed kills, and some disks are just too fast for a
micro alone to do.
Project below.? ;-)
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.
Yes, it's on my project list...I have it mostly designed but other stuff
has pushed in front of it.? The big issue is the SW (HW is fairly
straightforward)..which is funny because I'm a system SW guy.? ;-)? I'm
using a Xilinx Zynq FPGA mainly because I need:
* A reasonably fast processor for handling the run-time management of
buffers (one version has 4 ARM Cortex-A9 CPUs running at 1+GHz and
the other has 4 ARM Cortex-A53 CPUs running at 1.5GHz).
* Lots of DRAM (has to contain the entire emulated disk image).
Smaller Zynq FPGA will support 1GB of DRAM and the larger one (at
least the one that I'm using) supports 4GB of DRAM.
* Lots of internal RAM (has to contain the maximum sized cylinder)
* A *fast* connection between the DRAM and internal RAM (this
determines the track-to-track latency).? Cylinders can be up to 1MB
(32KB/track, 32heads per cylinder) so when seeking, up to 2MB (1MB
in, 1MB out) has to be moved to/from DRAM.? I'm trying to keep the
seek times < 10ms (ideally ~4ms) so that means my data rate has to
be on the order of 200-500MB/s.
I'm doing this for my Symbolics machines (ESDI and SMD) and 11/70 (SMD).
TTFN - Guy