• Please review our updated Terms and Rules here

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

thunter0512

Veteran Member
Joined
Sep 27, 2020
Messages
858
Location
Perth in Western Australia
As this subject has come up a few times in other threads I have created a new thread just for this.

What would be the interest for a new PDP-8/e/m/f "Extendend Arithmetic Element" (EAE aka KE8E) board set re-implemented using currently available TTL ICs?

Roland Huisman has done similar work for the VR-14 display controller VC8E board set (M885R and M869R), mains-RTC (M882R), Floppy Controller RX8E (M8357R), and TA8E cassette tape controller (M8331R).

Tom
 
Hi Tom,

I think I have done about 70% for the EAE set in kicad. The biggest problems are in the open collector ROM chips. I didn't have a solution for it and I have decided to wait for other ideas. The best idea I had was to use the original model ROM chips. But to be honest, spacewar was the only application I would use which was making use of the EAE. Now there are some spacewar versions which do not need the EAE.

What is your application for the EAE?

Regards, Roland
 
Could it be done on a single board?
A single board is not feasible using standard through-hole TTL ICs, but that is also not the idea. The idea is to clone the real thing using currently available TTL ICs maintaining the original design and most of the layout. For example SN7439N are not readily available, but the functionally identical SN7438N are readily available although the pin-out is different. So any SN7439N (or 8881) can easily be replaced by a SN7438N with a minor layout change.
 
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.
 
What is your application for the EAE?
Hi Roland,

I use the EAE for Spacewar and F4 in my LAB-8/e. Performance it noticeably better.
It would be nice to have the EAE for my PDP-8/e too. Even just a spare M8340 would be useful (I already have a spare M8341).

The IM5600 ROMs could be replaced with 82S23 or compatible (e.g. TI SN74188N).

Thanks
Tom
 
Here are the prototypes I mentioned over in the 4K languages thread:
IMG_20230322_090549630.jpg
The idea here is to re-implement the schematic of each board in the Verilog of the corresponding CPLD. You can populate either site, or both if you want an EAE on a single board. The board is laid out to support surface mount, or the larger through-hole sockets if you prefer.

I got the Verilog put together, and the boards, but I ended up sort of burying myself in projects, and have never gotten back to this one to do the test and debug.

Vince
 
I think I have done about 70% for the EAE set in kicad. The biggest problems are in the open collector ROM chips. I didn't have a solution for it and I have decided to wait for other ideas. The best idea I had was to use the original model ROM chips.
The contents of ROM1 and ROM2 look rather simple... many long strings of non-changing bits in consecutive addresses. It could probably be reduced to not-so-many minterms and fit in a GAL 16V8 or 20V8.
 
I feel like I'm missing something in the context here. Surely there aren't that many Omnibus machines with only 4K? Is the idea to faithfully replicate the 4K and paper tape experience?

Or are folks just generally wanting to trick out their 8/E/F/M with an EAE?

Vince
 
I feel like I'm missing something in the context here. Surely there aren't that many Omnibus machines with only 4K? Is the idea to faithfully replicate the 4K and paper tape experience?

Or are folks just generally wanting to trick out their 8/E/F/M with an EAE?

Vince
Fair call. My real 4K interest is an 8/L. WRT 8/e I'm in basically the same motivational camp as Tom Hunter.
 
Using EAE only for spacewar, hmmm.
There is a UWFOCAL that was compiled against EAE. You may even patch 4k FOCAL69 with some words by hand to use EAE or use the DECUS patch. And there are Basic or Fortran waiting to speed up your number cruncher....
There are 2 different designs (layout of some signals are different) of EAE boards, depending on the age of the CPU boards. Maybe this could be jumpered?

@Vince. is your approch not the way of a more general Omnibus-Adapter for many kind of cards? Maybe after Jörgs unibone/qbone some kind of omnibone? EAE needs the head connectors, a serial card would need some other things, but such a general card would be great.
 
@Vince. is your approch not the way of a more general Omnibus-Adapter for many kind of cards? Maybe after Jörgs unibone/qbone some kind of omnibone? EAE needs the head connectors, a serial card would need some other things, but such a general card would be great.
Yes and no.

The EAE card is quite different, as it sits in the middle of the CPU stack and has a pile of non-Omnibus signals. So it it kind of it's own thing.

The Memory extension also has a fair number of odd signals, which become an issue since they require pins, which are the scarce resource on the more solderable CPLDs.

However, a general I/O card is not beyond the pale. I already have work toward a combo TD8E/RX8E card, Basically, the idea is that you plunk down the CPLD and hook it up to the Omnibus signals that have to do with non-DMA I/O. Then you set up various transducer chunks that interface to the 40 pin right angle header. The user then populates the transducer block for their device (TD8E, RX8E, KL8E, etc.) and programs the CPLD to talk to the installed transducers.

A real-time clock (basically just a periodic interrupt) can piggyback on the CPLD logic of any I/O controller with a crystal in it, since very little logic is needed for it.

A DMA device like the RK8E is probably more difficult, as I suspect it exceeds the pin count of the easily solderable CPLDs. (There are flavors with more pins, though.) It may also exceed the gate count, which would complicate things further.

Vince
 
Fair call. My real 4K interest is an 8/L.
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.

Much easier (and on my mind lately) would be an MM8/I replacement, bringing the 32K memory card technology to older machines. The 8/L has an additional need for an implementation of the memory expansion, so perhaps another card in front of the MM8/I replacement.

Alternatively, there are the BM8L and BM8I interfaces, into which you should be able to insert the existing 32K card.

Vince
 
If we're 'reaching for the stars', why not consider including the KG8E (M884) logic? Charlie Lasner seemed confident it would substantially improve the reliability (robustness) of the TD8E DECtape handler. (ref: last page)
That's pretty out there. It is conceivable that a CPLD implementation of that could be done.

I don't know who would want to rework the TD8E handlers to require it. Are there other applications for it? Any existing software?

Vince
 
I feel like I'm missing something in the context here. Surely there aren't that many Omnibus machines with only 4K? Is the idea to faithfully replicate the 4K and paper tape experience?

Or are folks just generally wanting to trick out their 8/E/F/M with an EAE?

Vince
The idea is a faithful clone of the EAE to "trick out" a 8/e/f/m and gain a bit of speed for heavy maths in EAE enabled software. The secondary aim is to have a complete set of spares for my LAB-8/e. I currently don't have a spare for the M8340 in the LAB-8/e. My PDP-8/e has no EAE at all.

Tom
 
Back
Top