I was reminded of @RichardP’s thread when I saw this series of articles:
This fellow has put a BeagleBone Black on the UNIBUS of a PDP-11 as a standard peripheral device, and can emulate a variety of peripherals using the Linux machine. The PRUs (small, RISC embedded processors) attached to the GPIOs on the BBB enable him to get around some of the timing problems that @RichardP is experiencing putting an ESP32 on an Amiga memory bus.
The project is very interesting and very well documented, and includes a little bit of everything. The custom board, of course, but also some custom 3D-printed parts to keep the profile low enough to fit in a standard UNIBUS slot, as well as software to emulate UNIBUS memory expansion cards and hard disk controllers with attached hard disks – it even goes so far as to include a 3D printed case that mounts the original HDD lamps and buttons from the HDD device!
It looks like the project came about some time last year, and is still under active development; there is a Google Group with a number of messages this month.
Very interesting! Their goal is to do all intelligent handling in linux user processes, and to use the PRUs to handle the bus timing. The basic bus cycle is 1MHz, the signalling handshakes are on the order of 100s of nanoseconds, but as it’s an asynchronous bus which waits some 10 microseconds before timing out, this recipe turns out to be feasible. Tech details here:
Does the beagle bone not suffer the DRAM refresh stalls that (apparently) afflict the Raspberry Pi? Or is that simply not an issue here either, due to stretching of SSYN.
The PRUs do not have unpredictable RAM latency problems, as I understand it. I’m not super familiar with the architecture, I don’t know if they have local RAM or a cache or what, but they are capable for bit-banging some quite fast clocks, reliably. They are separate, entirely autonomous RISC cores, but they do share main memory with the ARM.
DRAM refresh stalls are a problem in general for DRAM, though, right? Does the Pi have a particular issue?
I’ve been exploring using an R Pi as a “Super I/O” processor as I call it. My protocol is asynchronous, clocked by the host, and handshake based, so it’s not really susceptible to stalls (on either end), but during the discussions @drogon mentioned the RPi stalls would make it particularly unsuitable to something that could monitor GPIO with enough resolution to where it wouldn’t potentially miss signals from the host CPU due to these stalls.
I don’t have many more details than that - the Pi is often called “a GPU with an ARM attached”… the GPU is king - it controls the DRAM (and video) refresh resulting in non-deterministic jitter on the ARM side of things.
the PiTube direct project runs code on the GPU - or at least one of it’s processors. It’s not an area I’ve really looked at, but AIUI, even then, it’s only just good enough to accurately sample a 2Mhz signal, so using a Pi as a cpu bus level peripheral is only just possible for a 2Mhz (6502) bus. It would be well worth looking at the PiTube direct project for more details.
My own 8/16 bit MCU to Pi project effectively has the Pi emulate one port of a 6522 VIA, so the Pi polls for the strobe, reads the 8-bits of data, sends the Ack… I can get about 1MB/sec between a (8Mhz) 6502 and the Pi that way and any stalls at the Pi end are not noticed.
Indeed, the story of PiTubeDirect is an interleaving of three stories: increasing performance, increasing reliability, and addition of more different CPU emulations. For the reliability, it was all about an unexplained long tail of the ARM’s interrupt response and interrupt handler performance. Even locking code in the cache and turning off everything we could find, it seemed something was still sometimes - rarely - getting in the way and pushing out latency and causing mishaps. We were soak testing for hours. This was a bare-metal single-core system so we were not even seeing any kind of kernel or task switching or concurrency effect. So, in the case of the Pi, the ARM gets a somewhat variable response from the rest of the SoC, and for reliable bitbanging on a 2MHz bus we needed to bring the CPU into play. (But recall that the ARM was up to the task on a 1MHz bus - the variability wasn’t so bad.)
