23 Sep
2023
23 Sep
'23
12:16 a.m.
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(a)classiccmp.org>
Cc: Mike Katz <bitwiz(a)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
>
>