Mike An M0 will require an FPGA below it to interact with the OmniBus
A BeagleBone, using the PRUs - which are ~microcoded, would be in with more of a chance Industrial grade SoCs / FPGAs should have no difficulty Martin -----Original Message----- From: Mike Katz via cctalk [mailto:[email protected]] Sent: 23 September 2023 00:27 To: General Discussion: On-Topic and Off-Topic Posts <[email protected]> Cc: Mike Katz <[email protected]> Subject: [cctalk] Re: Good C to FPGA/PLA compiler I plan on controlling the gate array with an RP2040 dual core cortex M0 running at 133 MHz and 8 PIO processors. However, the Data Break (DMA) timings on the Omnibus are in the 100nS range. The bus runs 6 different timing signals plus manipulating all of the other signals to implement Data Break. I just don't think a micro would be fast enough. That same holds for the break point. In order to be able to respond to address, data, r/w and count for 4 breakpoints in the <1uS window to stop the CPU before the start of the next cycle would stress most embedded micros (sub $10 micros anyway). The PDP-8/E main clocks are derived from a 20MHz crystal (That's a 50nS minimum timing). Quoting the DEC Omnibus Standard Document Memory, Address and Data must be settled within 50nS minimum and no more than 250nS depending on what is going on on the bus. There is a boot strap board that emulates the front panel with an Arduino and an I/O expander. But to implement Data Break requires much more tight timing. This bus was designed to handle core memory which requires a write after read because the read is destructive. On 9/22/2023 5:52 PM, Chuck Guzis via cctalk wrote: > Stupid question, I know, but someone has to ask it. > > Is there some overwhelming reason that the FPGA and associated logic > couldn't be subsumed into an inexpensive 32-bit MCU running at, oh, > 200 MHz? I can't believe that a PDP8 is all that fast... > > --Chuck > >
