Modules

Introduction

I’ve spent so much time in theoretical simulation land, I think it’s time starting to put some practical ideas down to paper (well, screen). Given that I have more or less all the pieces figured out now, how would I go about actually building this monster of a machine? Or, for that matter, how did people in the ’60s build transistorized computers? Surely they didn’t just make a massive schematic with 10,000 transistors and set their layout team down to make a PCB. By hand. Neither will I.

So, if this is something you’re interested in, join me on this journey of practical computer design a’la 1960!

Modules

Well, this is obvious: we need to partition the design into smaller pieces. Ideally, these peaces should be fairly universal and reusable, such that I have as few different kinds as possible. They should be flexible enough that I can use them to build all the circuitry I need from them.

If you think about it, it’s not all that different from how you would think about building a computer from discrete 74xx logic: you have a family of building blocks, and you make more complex elements out of them. In some sense, I intend to build my own, custom 74xx logic series. That and a few analog(ish) blocks to deal with the more esoteric parts of the machine. The only difference is that I will do that on PCBs with individual transistors as opposed to small pieces of crystals and nasty chemicals.

In fact, this is exactly how transistorized computers were built as well. In fact, in fact, DEC, the producer of the PDP-11 that my core memory is from was started as a company making such modules for 3rd parties. Here’s one of their (hex inverter) module:

Others used different form factors, but the technique was rather universal. What these companies used to do was to stick these modules (in large quantities, as you can imagine) into a back-plane and wire-wrap them into the final circuit. This is the back-side of a PDP-8 for instance:

Yeah, thank you, but no, thank you. I’m not going to do that. I’m going to have a set of modules, but my ‘back plane’ is going to still be a PCB. Or multiple, if needed. I’m also going to go to some length to miniaturizing my modules. This saves on cost (smaller PCBs are cheaper), but also make the overall size more manageable. I’m going to rely on surface-mount components as opposed to through-hole. These are easier to assemble in mass and help with the previously mentioned miniaturization too. I’m not going to go crazy though. I’m thinking 0603 passives and SOT-23 or similar packages for transistors and diodes.

Digital modules

Here’s the list of modules I intend to build:

  • AOI gate (I’m a bit hesitant on the actual configuration, but something on the order of four OR branches, and three to four AND inputs each). I will provide both inverted and non-inverted outputs. By tying the unused inputs to GND or power, this can be configured into AND/NAND/OR/NOR gates as well so it can stand in for a number of roles.
  • NOT gate. Well, this is rather self explanatory.
  • 8-bit latch with care such that it can be configured as a 4-bit register as well. This probably means an inverter option on the clock and two clock inputs: one for the odd, and another for the even bits
  • 8-way one-hot decoder. This would more or less be the equivalent of a 74138. Maybe with a different number and configuration of enable signals.
  • ALU bit-plane. I think it makes a ton of sense to build this logic explicitly. This is replicated 16 times and is rather timing critical.

For all these modules, the final pull-up on the output stage will have a separate power connection. This way, it can be disconnected, if not needed. This is important to implement wired-and logic that is heavily used on the buses of the computer.

As I go through the design, I might find a need for a few other things, such as, maybe an 8-bit line-driver module if buses get really long. We shall see.

Analog modules

On the analog(ish) side of things, here’s the list I have in mind so far:

  • Differential amplifier. I will have to go through the detailed design, but it would be nice if a single module (with maybe different resistor values) would be configurable as either the ROM sense amp, the tape sense amp or the core memory sense amp. The needs and construction is slightly different in all cases, so I’m not convinced it’s possible at this point, but I’ll try to hold on to this ideal as long as I can.
  • Half-bridge drivers. These will be used for the X/Y drivers in the core memory. They will include not only the drivers them selves, but the needed control signal conditioning and level-shifting as well.
  • Current load switch. These are used for the sense/inhibit line drivers. They can be used for the ROM LED drivers as well, but if so, I need two variants: a high-side and a low-side switch. It’s also possible to use half-bridges in these roles with one half (top- or bottom) unused and potentially depopulated.
  • Current source. I’m debating this one. It’s possible to create a module for it, but it might be specialized to the point where only a single instance would be used. If that’s the case, maybe it’s better to include this circuit on the base board instead of relegating it to its own module. At the same time, its quite possible that this circuit needs a spin as I learn more about how core memory works (or how much current I need for the ROM), and re-releasing a small module as opposed to the large base board is certainly cheaper.
  • Power supplies. This, I’m not sure about. I might go down the path of designing something, I might just use something off-the-selves. Or both. It’s quite possible that I need a clean power supply for the sense amplifiers, which I would rather generate myself, whereas I might not want to bother with the high-current digital rail.
  • Clock generator. You can argue if this is analog or digital. No matter, I’ll need one. Eventually. I can get rather good mileage out my signal generator as a clock source and only swapping in a real clock source, once I know what I’m doing.

Creature comforts

I don’t think I can count on things going well the first time. Even if I completely simulate and validate everything prior to the build (which I won’t, I don’t think simulating 3,000+ transistors is reasonable), build mistakes can creep in that need debugging. So, I plan on having some aids built to help with this process. These modules won’t need to comply with my rigid ‘no ICs’ mantra, as they are not part of the final system. Here’s the list at the moment:

  • 8-bit hex display. Take 8 inputs and display it as a two-digit hex number.
  • Differential input amplifier. It seems I have a lot of hard-to-probe, low-level differential signals in the system. Having a way to ease the probing is probably worth the effort. A relatively wide-band, differential amplifier is probably a good investment in the long run.
  • Current probe. This is a corollary of the previous idea: by putting a current sense resistor across the inputs of the differential amplifier, I can get a crude current probe going. There are many many magnetics in this system and those are primary current-based circuits. Probing them is going to be important.
  • De-bounce circuit. I will probably want buttons and switches. Reset, single-step, interrupt generation, you name it. I will want to be able to generate well-defined events by pushing things. Buttons and switches however have the nasty tendency of producing multiple edges due to something called bounce. Pre-building a circuit that can create clean edges (falling or rising) is probably going to pay dividends.
  • LED with pulse-stretcher. This is more or less what a logic probe is doing. I have even built one myself. I think I will need something simpler than that, but something that I can replicate a few times and stick on various signals for monitoring purposes.

Connectors

I’ve spent some time thinking about connectors. These are potentially expensive and I will need a lot of them. I also want them to be surface mount; there will be thousands of pins and I’m not looking forward to individually solder them in. So, what options do I have?

There are the ubiquitous rectangular pin headers:

These are available in surface-mount variants, but not all that cheap. About $0.8 for each end. There are card edge connectors:

These are very cheap ($0.2) in through-hole and about $1.00 in surface mount variants. But, the other side, the module side is essentially free: it’s just the bare PCB with some fingers. I should clarify: they are free as long as I don’t want gold plating. With that, they are very much not free.

There are IC sockets, DIP sockets, which are available in surface-mount format:

These are expensive though and they also need a counter-part, which are even more expensive.

There are many many board-to-bard connectors, mostly through-hole (designed for back-planes and such) or tiny (mostly designed for FPCs). There is very little standardization here and the prices are rather high: close to a dollar for anything decent and it needs to come in pairs.

Overall, I think I will go with PCIe and try to forego the gold plating: after all, this is not a shipping product, so oxidation should be manageable. I just have to hope that it won’t turn into reliability nightmare.

From modules to computer

Once these modules are ready, I need to decide on the larger partitioning of the system. Currently, I’m thinking I would have one base board for the CPU, one for the core memory, one for ROM and a fourth one for the peripherals. These would be connected by some sort of bus, probably over ribbon cables, if I have to make a guess right now. One possibility is to make the boards connect to each other in a daisy-chain fashion. That would be a “best of both worlds” situation, where cables can be used to separate blocks for debugging, development reasons while keep the whole build relatively self-contained when finished.

Parting words

Overall, it seems I need somewhere around a dozen or so modules for the actual computer and another handful to help with the debug. I will start working on these one by one, individually testing each one out before moving to the full system build. During the process, I will have to lock down many of the loose ends of number of inputs, pinouts, form-factors etc. It should be fun.

This is where the rubber starts to hit the road. The project is finally moving out of the (virtual) lab to the … well, to the actual lab. I’m excited!