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

Jay Jaeger cube1 at charter.net
Fri Dec 10 08:21:11 CST 2021


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).

On the other hand, speed kills, and some disks are just too fast for a 
micro alone to do.

> 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.


More information about the cctalk mailing list