Mike I shall focus a few specifics
I did 30+ years of software, with occasional hardware toys, before I added 20 years of Hw, FPGA & Sw : old dogs can learn. FPGA logic source has more in common with software than old school (SSI / MSI / LSI) hardware. With the bonus that it all happens in parallel. Essentially you instantiate lots of little processors / state machines, with some interconnect and some IO knitting. It has not got any better since the OmiBus data break spec, the AXI spec is sufficiently complex that testing DMA interfaces is done at a minimum with verification IP. Although AXI busses do at least have a "global" synchronous clock. Interface complexity / verification is just one of those little challenges. I appreciate that OmniBus is not a multiplexed bus, like Q-bus. I was suggesting that you could multiplex the bus signals to/fr your processing hardware to enable the use of cheaper/simpler hardware. Of course, YMMV. The data being on either memory or data bus would not defeat an FPGA, as it would know the state of RnW and make the appropriate comparison. And, in VHDL it would all read like "parallel" Ada. Down to 0.5 mm pitch gull wing legs can be readily hand soldered by a wireman. Surface mount double sided PCBs can be hand assembled (by me), in small quantities, by restricting the components to 0603 and 0.65 mm pitch using an under board heater and hot air. The fine pitch stuff goes on first. OTOH a good wireman can hand solder 0402 components. So, don't back off completely from SMD. You "only" need: a quartz heater, a hot air wand, and a solder paste dispenser (you spit it on by hand). Note that surface tension squares everything up and moves the solder onto the pads; which need to be (hand assembly) oversize. NB this approach is for very low volume / zero budget / assemble tonight work; for serious boards / volumes you send the kit to the assembler. BGAs are another story - dodge them; e.g. use https://digilent.com/shop/cmod-a7-35t-breadboardable-artix-7-fpga-module/ or similar to apply FPGAs in a 0.1" DIL form factor, at LVTTL levels. You could build an OmniBus interface with two of these, some bus interface chips 74LVC for Rx, something OD (and not too fast) for Tx, and a "host" processor. Best Regards Martin -----Original Message----- From: Mike Katz [mailto:bit...@12bitsbest.com] Sent: 23 September 2023 01:16 To: General Discussion: On-Topic and Off-Topic Posts <cctalk@classiccmp.org> Cc: Martin Bishop <mjd.bis...@emeritus-solutions.com> Subject: Re: [cctalk] Re: Good C to FPGA/PLA compiler Martin, Thank you for all of your suggestions. I am a software guy who has dabbled in hardware since I built my first Heathkit in 1972. I have designed simple 6809 single boards in my past professional life but the Omnibus is several orders of magnitude more complicated than a 6809. Just reading the Single Cycle Data Break documentation in the Omnibus spec is enough to give me a headache. I think in C much better than I think in logic gates. I can write parallel C to describe parallel circuits. The last time I programmed any programmable logic it was FPGA's of the 10L8/16V10 variety. Sometimes the data is on the memory bus, sometimes it is on the data bus, depending on whether you are reading or writing to memory, for example. There is no bus multplexing between address and data or data and memory busses. Here is the basic definition of the Omnibus: Memory Address: 15 Signals Memory Data: 12 Signals Memory Direction: 1 Signal Data Bus: 12 Signals I/O Control Signals: 10 Signals DMA Control Signals: 8 Signals Timing Signals: 9 Signals CPU State: 6 Signals Memory Timing: 5 Signals Misc Signals: 18 Signals (Mostly used by the front panel) One of my goals here is to use thru hole parts and sockets so the average person can assemble it. I realize this may be impossible bit I'm trying. I have a good surface mount contract manufacturer close to my home that I have a business relationship will so I can go to full surface mount if I have to but that will increase the cost of the boards. On 9/22/2023 6:53 PM, Martin Bishop via cctalk wrote: > 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:cctalk@classiccmp.org] > Sent: 23 September 2023 00:27 > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk@classiccmp.org> > Cc: Mike Katz <bit...@12bitsbest.com> > 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 >> >>