• Please review our updated Terms and Rules here

Extended Arithmetic Element (EAE) re-implementation using current TTL ICs?

Other than being more authentic, is there a reason to stick with 7400-series rather than a 5V CPLD implementation that Vince and I have used in the past?

More chips mean more potential failures, it's more expensive, it takes up more real estate, forcing you to use two large PCBs instead of one, etc.
The reason is authenticity.
I somehow find a CPLD implementation of any Omnibus board hard to digest. I feel that it is a huge technological distortion. If you go down that path you might as well just implement the entire system on a single board using an FPGA ... or just run SIMH.
Of course I am a hypocrite because I happily run Roland's M847R boot loader board in both my LAB-8/e and PDP-8/e, even though I have a real M847 for RX01 boot. :)

Tom
 
I somehow find a CPLD implementation of any Omnibus board hard to digest. I feel that it is a huge technological distortion. If you go down that path you might as well just implement the entire system on a single board using an FPGA ... or just run SIMH.
I feel somewhat differently. I like the CPLD, but generally won't touch an FPGA. The CPLD is just logic inside -- essentially a large PAL. The constructs there quite closely mirror the original TTL, and I go out of my way to code my Verilog to reflect the way it was implemented in the TTL "equivalent circuit" in the datasheet of the chips I'm mimicing. (This tends to make folks used to FPGA Verilog cringe.)

The Verilog is a direct export of the TTL from the Eagle schematics on my site. (It is done with Perl scripts which read the schematic file, emitting Verilog for each chip.)

I do perform a layer of constant expression removal which greatly improves the readability of the result. OTOH, the code still reflects the original signal names and gates, so it's not as readable as something coded at a higher abstraction level.

Vince
 
There is this 4 years old Github repository (maybe from someone also here?) which tells it is a first step toward implementing PDP-8 in current TTL chips:

This is currently a work-in-progress, with the end goal of actually build one in real hardware some day. But right now I'm just aiming for a simulation which currently is very un-optimized both speed-wise and in regards of the chip count.

Step one is to get the simulation fully working with the built-in non-standard components. Then I'll convert the simulation design to use 74-series chips that still can be purchased - I expect some changes will be requred in regards of triggering at rising or falling edges and whether 3'rd-state outputs are available in the parts. Finally I'll spend some time optimizing the design, with a focus on the total chip count.
 
A PDP-8 utilising TTL chips was developed many, many years ago to support a digital logic course. Students had to design and build their own computer using TTL devices - sufficient to run DEC FOCAL. The machine was called an LD12 and had an instruction set and architecture that was the same as an unexpanded basic PDP-8 machine.

There are various threads on VCFED dedicated to recreating this and there is also a book you can purchase.

I have constructed a LOGISIM simulation for the machine and it successfully executes the MAINDECs and CHEKMO-II (the chess program). However, I did find (and fix) a bug (or rather, the MAINDECs found the bug).

See: https://retrobrewcomputers.org/n8vem-pbwiki-archive/0/35845334/38282303/96895548/.

I produced a PCB for the LD12 - but (unfortunately) real life has got in the way (yet again) from me completing the project. But I am hopeful when I retire...

Marty built one - and this was where I got involved, because it didn't work first time. We had to remotely debug the logic. This was why I constructed the LOGISIM simulation to see if it would ever work in reality (it did). We then made the hardware work accordingly...

Dave
 
> there is also a book you can purchase.

I may have this book somewhere, but this is not a project that I intend to pursue, I do not have the experience and knowledge, I was just curious.

> But I am hopeful when I retire...

I wish you will find the time! There are exceptional people on this forum!
 
Hi. This is a great discussion. Would someone be able to point to a resources that details how the EAE works? I have seen the circuit schematics, but would appreciate a higher level system level explanation. Thanks!
 
There are several directions to take this.
  1. An exact replacement for the M8340 and M8341 using the original components. An exact copy of the last revision.
  2. A replacement for the M8340 and M8341 interchangeable with factory versions using available thru hole TTL parts.
  3. A replacement for the M8340 and M8341 interchangeable with factory versions using CPLD's.
  4. A single card combining the M8340 and M8341 functionality. This should be doable with either surface mount TTL, CPLD's, or an FPGA and level shifters/bus drivers.
  5. A single card that replaces the M8330 in slot 1, M8340 in slot 2, M8341 in slot 3, M8310 in slot 4, and M8300 in slot 5. This will no doubt require an FPGA to attain sufficient logic density. The M8320 (bus termination) would still need to be a separate card at the other end of the omnibus.
#1 is hands down the easiest to accomplish but it really doesn't get you to your goal because , finding the parts to populate the cards, while not impossible is going to be very difficult.

#2 seems like it would be a good choice for a new project. It keeps the changes to the design compartmented to individual IC's. I suspect that
parts availability is only going to continue to decline which will make this the same as #1 in a few years.

#3 is probably the closest to done. Vince has already made hardware. He needs to find time and motivation to finish and debug it.

#4 would be my personal choice to add an EAE to an existing system. I believe this would cost the least to manufacture but also be the most work.

#5 is a project I discussed with Warren Stearns a couple of years before his passing. I wanted to also have the memory, console port, and RF01 or DF32 on this board as well. It is a multi year project all by itself and I came to realize that I probably would not be able to keep motivated to complete it. The chance of this one ever happening seems to be nearly zero.

I am sure others have thought of this as well but Warren and I did come up with an idea that makes fixing DEC boards and #1 more practical. And that is to make replacement IC's using a surface mount board with the outline of the IC it is replacing and substituting available logic to associated pins. This isolates the problem to something that can be dealt with in a couple of evenings. And when the parts used go away you can just redesign that one piece rather than have to redo a whole quad board. FPGA's have a much shorter life than old TTL. I only half joke about the FPGA of the month club.

I have two sets of EAE boards. I am pretty sure neither of them is functional. Too many hobbies and not enough time in retirement.
 
#4 would also be possible with Vincents cards, he wrote "You can populate either site, or both if you want an EAE on a single board."
 
A single card that replaces the M8330 in slot 1, M8340 in slot 2, M8341 in slot 3, M8310 in slot 4, and M8300 in slot 5. This will no doubt require an FPGA to attain sufficient logic density. The M8320 (bus termination) would still need to be a separate card at the other end of the omnibus.
It had occurred to me that (once the EAE card was working) to do the same with the core CPU set. A three CPLD thing that would reimplement the M8300, M8310, and M8330. There are top connector issues that might make it difficult to be compatible with the original boards, I think, so it might need to be a couple of boards, at least during debugging.

Anyway, once that was debugged, moving all the CPLD sites to a single board (and losing the top connectors) would be straight-forward. I'm also working on a CPLD for the memory extension, so one can envision a single card with the CPU, EAE, and memory extension. Whether there'd be enough room left to add the memory, boot loader, console interface, etc. is hard to say. (Well, surface mount would likely fit, but...)

Since these are essentially exports of the existing designs, the debug time is shorter (and the result is more compatible) than if the cards needed to be designed from scratch.

I think a complete Omnibus system in two connector blocks should be doable. Might not fit in a single slot, though.

Vince
 
There are several directions to take this.
  1. An exact replacement for the M8340 and M8341 using the original components. An exact copy of the last revision.
  2. A replacement for the M8340 and M8341 interchangeable with factory versions using available thru hole TTL parts.
From my perspective #2 is the most attractive (and a proven approach as Roland has made several of these boards), but #1 is doable as you wrote:

"make replacement IC's using a surface mount board with the outline of the IC it is replacing and substituting available logic to associated pins."

The harder to find ICs are the Signetics 8xxx series, so they would be prime candidates for small surface mount replacement boards emulating the original. JLCPCB can cheaply populate these surface mount TTL chips as part of the manufacturing run for the PCBs.

Tom
 
The M8341 (EAE multiplexers and timing generator) uses 5 DEC8235 (Signetics 8235). These are unusual and rare and there is no singe-chip substitute.

Kyle has previously designed a small PCB which can be used to substitute a DEC8235. It uses a hex inverter and 2 quad NAND gate with OC outputs. Kyle chose through hole components which make the PCB rather large.


There are SOIC parts that could be used to achieve a small PCB replacing each 8235 with one such PCB.
One could use 2 x SN7438D and one SN7404D.

Tom
 
An EAE for the 8/L never existed, so that's probably difficult if not impossible.

It *might* be possible to to a DMA thing similar to the FPP.
I completely agree. An EAE won't help me run some 4K languages on my 8/L that are dependent on such. It's much easier (and quite possible) to implement extended memory and then run a larger-footprint implementation of a given language. Not going to be a speed demon, but that's not the point. (It is somewhat for the 8/e ... :-}.)

I think that a CPLD implementation of the extended memory controller plus 28K-word of static RAM could be fit into a couple of empty slots in an 8/L, although some careful OTT additional signal cabling may be required as I'm not sure that there's a suitably large cluster of available slots that access all of the required signals; tying together modules in B/C/D 34, 35 and 36 is the logical group to consider. Alternative to a CPLD would be a fast small form-factor MCU-based emulation, which would open other surrogate-peripheral possibilities in the same space. At which point a surrogate EAE becomes conceivable.
 
I think that a CPLD implementation of the extended memory controller plus 28K-word of static RAM could be fit into a couple of empty slots in an 8/L, although some careful OTT additional signal cabling may be required as I'm not sure that there's a suitably large cluster of available slots that access all of the required signals; tying together modules in B/C/D 34, 35 and 36 is the logical group to consider.
There are cable slots in the 8/L which are intended for the memory expansion. The BM8L uses them. It's basically the Posibus, to get at the memory extension IOTs as they are performed, together with a version of the memory bus similar to the one used in the MM8i, but with a few more control signals so the memory extension can do it's thing.

I'm been working on the design (and am now working on the routing) for an implementation of the MM8i on 5 paddle cards, which fit into the 5 slots that are meant to hold the MM8i cables. The new design of course emulates as many MM8i as you are missing, up to 32K. (No CPLD needed to just provide memory.)

I think that would interface nicely to something that sat in the BM8L cabling slots and implemented the memory extension and exposed a BM8i compatible connection.

OTOH, the BM8L also isn't that hard to directly implement. (It's 20 slots of backplane connectors to wire it up in authentic vintage style, though.) Then you'd just need Omnibus memory.

Vince
 
It appears that the level of interest for an authentic clone of the EAE board set is minimal.
Only 3 people including Roland expressed interest.
I am a bit surprised.
I would be potentially interested in a couple of sets of EAE clones as well.
 
Back
Top