Mike A key factor is that 60 years have passed:
- the PDP8/E (and its chums) were core store machines - the bus time slots are 300 + 250 + 350 + 300 ns = 1200 ns [T1 T2 T3 T4 phases of core access] - FPGA fabric can trivially run at 100 MHz, and talk to an AXI bus + Arm Core - SoCs have 32 / 64 bit “external” data busses - Arm cores run at 666 MHz and above - consequently the test hardware is ~3 orders of magnitude faster than the old iron, wider and capable of performing lots of (hardware) logic in 10 ns – a cascade of 10 LUT6’s is not unreasonable on a mid range FPGA. To cut to the chase, a clone of the UniBone should be possible and largely a software project – there is a large body of code and experience to build on and the Omni and Uni / Q Busses are similar. The 96 signals need not define the scale of the FPGA / SoC hardware. There is probably scope for multiplexing / serialising the lines to / from the OmniBus – I should think the RetroCmp designs use this technology – unfortunately I have not had the time to read them sufficiently carefully to say. Interfacing between the omnibus and an FPGA / SoC will require debouncing and a metastable hardened synchronisers (~3 stages of FFs) to bring the signals into the FPGA/SoC synchronous domain. Beyond a Schmidt trigger / equivalent front end this is a job for modern digits, in the input FPGA/CPLD(s). Re your specific requirements: 1) Was a hardware task 60 years ago, It would now be trivial to do it with an FPGA controlled by any reasonable processor 2) You should be able to this by bit banging over JTAG, maybe with a little hardware assist 3) Sequencer breakpoints in FPGAs are straightforward, provide the condition and it pulls the stop line; all that is required are condition register sets and comparison logic 4) see comment above re Mux/Serial 5) I should think avoiding stubs will be more important than the specific input devices I would restate your needs / the design as: a) bus interface b) FPGA interface c) bus receiving, driving, uC demand (e.g. DMA, FP emulation, breakpoint conditions) and reactive logic d) uC code HtH; Best Regards Martin From: Mike Katz [mailto:bit...@12bitsbest.com] Sent: 22 September 2023 22:17 To: General Discussion: On-Topic and Off-Topic Posts <cctalk@classiccmp.org<mailto:cctalk@classiccmp.org>> Cc: Martin Bishop <mjd.bis...@emeritus-solutions.com<mailto:mjd.bis...@emeritus-solutions.com>> Subject: Re: [cctalk] Re: Good C to FPGA/PLA compiler Martin, The debug board will need to have the following functionality: 1. Read and write to/from memory when the CPU is running using one cycle data break (DEC's version of DMA for the PDP-8). Single Cycle DMA requires some interesting signaling, including putting the priority on the data bus during part of the cycle. 2. Read and write to/from memory when the CPU is halted using front panel emulation (something totally different than one cycle data break unfortunately) 3. Handle 4 breakpoints (based on address, data, R/W and count) and signal the cpu to stop. I don't know, yet, if there will be enough time in the CPU's instruction cycle to top the CPU before the fetch of the next instruction. If this cannot be done in hardware than a much more crude break point system can be done in software. 4. There are 96 active signals on the PDP-8/E's Omnibus. I expect to need most or all of them for this project. 5. The Omnibus is an open drain, active low bus where +2.7V to +4.5V is a zero and -0.5 to +0.4V is a one. I don't necessarily need a 5V tolerant gate array but what ever I use to interface to the bus will need to be. A full description of the Omnibus can be found here: https://bitsavers.org/pdf/dec/standards/EL-00157_00_A_DEC_STD_157_OMNIBUS_Specification_Aug76.pdf Coding the break point system in some kind of parallel C like language seems way easier to me than to write this in gates. I don't have a clue how to design the count registers. I need to get #'s 1 and 2 working first and then I can dive into #3. Thanks.
