> On Dec 10, 2021, at 12:57 PM, Guy Sotomayor via cctalk
> <cctalk@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
