[cctalk] Re: DEC Unibus variants

Hi shadoooo / Andrea Thank you for the exposition of the merits of FPGA implementations for Unibus and Qbus machines; it was cheeky of me to pose the question. Regarding cost savings from reusing the main module I suspect the cost of a Zynq module would be much less than that of the bus adapter. However, there are of course infrastructure and programming savings from commonality. Additionally, obtaining sufficient 3v3 IO may be a constraint and there remains the 3v3/5v interfacing issue. However, fairly cheap Zynq 20 boards with lots of 3v3 IO are available, see eg https://www.aliexpress.com/item/1005005779045608.html - the date codes etc are (of course) obscured on the delivered boards. A PDP-11 will fit on a Zynq 10 SoC, at least my 11/45 -MUL/DIV/ASH(C) -MMU -FPU does; I use it as an embedded processor, for things below the dignity of the SoCs PS. 28 kiWd of main memory can be provided by BRAM (a memory cycle time of 10 ns is practical), and as it is double ported its very easy to peek over Axi from the PS. Also, you can hook up a Zynq logic analyser for tracing execution. For the generality you propose, I should think a microcoded platform would be appropriate, a 16 bit mill with a suitable sequencer would probably emulate any 1970's 16 bit mini or peripheral. IIRC numerous PDP-11 implementations used microcode : eg 11/20, 11/40, T-11, etc. However, microcode is of course software (which you deprecate) but so one could argue are the state machines which populate the bulk of contemporary FPGA logic. You mention the difficulty of handling externally clocked data streams. I shall agree that this is a hardware task. In FPGA / SoC work it is invariably addressed by synchronising external signals with internal processing clocks; perhaps at the edge, perhaps at shift reqister read out. But it has to be done or metastability will have its way. A very interesting question is how well "features" like the BBB PRU implement this necessary logic. You are quite correct that the Am26S10 devices are probably the best "off the shelf" driver option. However, given their transition times, they possibly require quite a bit of house training for U&Qbus use. Fortunately, not ground I need to tread. And, yes it is certainly worth a try. One plea, don't do a DG Nova 2; never have I been provided with a worse mini ... Best Regards Martin -----Original Message----- From: shadoooo via cctalk [mailto:cctalk@classiccmp.org] Sent: 30 March 2025 10:16 To: General Discussion: On-Topic and Off-Topic Posts <cctalk(a)classiccmp.org> Cc: shadoooo <shadoooo(a)gmail.com> Subject: [cctalk] Re: DEC Unibus variants The why not use a UniBone comment has merit, what will your (FPGA) Well, I know the Unibone! Surely is a very capable system for emulation of older hardware and interfaces. Also performances are good as far as I understand (I don't have one). I have the idea of extending the concept of Unibone. The new design shall be modular, composed by: - a main board hosting the SoM and common interfaces (Ethernet, SD, USB, console) - a bus module for specific bus / machine: support could be added for DEC / Data General / other? - an interchangeable interface module for an hardware device (SMD, Pertec, floppy, RX1/2, RL01/02, other). Any kind of interface could be supported, also for example ADC, DAC, maybe video to some limits...) If you have main module and bus module, you have a similar solution to Unibone / Qbone. However if you need to change bus type, you need to swap only the bus adapter (cheaper). If you have main and interfaces modules, you can control physical devices directly, and do anything with it. For example, you can dump / restore the content of a SMD disk at bit level, no need to know the controller format, etc. Similar to Kyroflux for floppy, but MUCH faster! Alternatively, you could also emulate the device at low level (for example a generic SMD disk). If you have a set of main, bus and interface modules, you can do anything as above, plus you can emulate a controller for a specific machine for a specific device. That said, implementing "anything" would be an infinite effort, but the platform is flexible, so support could be added step-by-step. So why an FPGA? A programmable logic can implement a true digital circuit, where the PRUs in the BeagleBone are processors. This means that in an FPGA the time is always precisely determined by a clock, in PRUs it is affected by the software execution. This means that a PRU can work quite well on an asynchronous bus, provided that sample rate is sufficient, even if not constant. But for a fast synchronous interface, i.e. when time is determined by an external clock, often embedded with data, no software approach can work steadily in my opinion. One thing is true: programming an FPGA is designing a netlist, not developing a software. It can be very hard to debug sometimes, because the approach is more similar to repairing an old board with a Logic Analyzer than perform debugging in software: it's a circuit in a chip, there no step-by-step execution! Nevertheless: I'm a quite good electronic engineer, highly experienced with digital logic and FPGA, so the hardware design wouldn't be a problem. Just a matter of time. Nowadays a SoM with a smaller AMD Zynq7010/7020 (a system-on-chip including an FPGA, plus dual core CPU, lot of peripherals) doesn't cost a lot, and have a great usage flexibility. Also brute computing power is superior to older BB. Why not try? I'm open to your comments. As for the UNIBUS unobtainable transceivers: I think the best solution is to use AM26S10 for drivers, and an LVC logic powered at 3.3v for receivers. Both are active parts costing nuts. I would try this approach. Andrea