RC11 controller (Was: Reproduction DEC 144-lamp indicator panels)

[Guy Sotomayor]

On 12/10/21 6:21 AM, Jay Jaeger via cctalk wrote:
> On 12/9/2021 11:06 PM, Guy Sotomayor via cctalk wrote:
>>
>> 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 
> 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).

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