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

[Paul Koning]

> On Dec 10, 2021, at 12:57 PM, Guy Sotomayor via cctalk <cctalk at classiccmp.org> wrote:
> 
> 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've done some pretty large VHDL designs (though not structured in the most conventional manner).  It's definitely one option.  It's a good one for large designs, or ones with severe performance requirements.

FPGA (VHDL or Verilog) work requires learning not just a new language but a way of looking at design that's unfamiliar to software people.  It's interesting and rewarding but not a simple thing to do.  And even "simple CPLD" projects aren't necessarily simpler done that way, at least not for people like me.

To pick an example: I have a rudimentary software-defined radio I built around 1998 (using Harris SDR chips) which uses a Lattice CPLD to interface to an EPP mode parallel printer interface.  That's conceptually a simple task but it turned out to be surprisingly hairy.  At the time it was the best answer; if I were to attempt a similar project today I would most likely pick a Raspberry Pico to do the interfacing.

The Pico is in fact a good example to point to.  While a Pi is a full Linux system, a Pico is a deep-embedded device, tiny and dirt cheap even by Arduino standards.  I've seen low end FPGA boards but I don't know if you can beat $4 as the price tag.  And add to that the fact that FPGA development software often only runs on *gag* Windows, while embedded software boards such as RPico offer open IDE systems that run on real host operating systems.

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

I haven't run into that, it's rather puzzing why that would be so given that MFM does one drive at a time.  In any case, the original comment was about RC11, which is massively slower than MFM disks.

	paul