Another option for the register file is SRAM. Extra read ports are easy as you can just have a copy of the register file for each read port. The downside is it takes a dedicated cycle to write back. For a risc machine you can have the output of ALU/MEM feed into a write back register. Then use that to write the register file usually this can be done in parallel with the next instruction fetch.

Historically SRAM was the most common way to have multiple registers. D flip flops have always been too expensive, even today.

SRAM Has the problem that it is a latch, not edge triggered like a D-FF. This means a multi phase clock
or like a 6502 non overlapping clock phases. Everybody but T.I. seems to have had a some flavor of a multi-port ram.
FAIRCHILD 9338 is good example of a never heard of chip.

I'm going to keep looking at other DIY CPU projects to see how other people solved these problems. At some point prototyping will be required to better understand the challenges to know how to transition to actual hardware.

For example, I think the place to start is fetching an instruction from EEPROM, latching it into the instruction register, and decoding it into control signals. That also requires the program counter and its initialization to zero on reset. I'm also going to cheat with my initial sequencer/microcode and use a microcontroller, so that stays flexible until things firm up.

Reads are a single phase, writes are two. Conveniently, a single clock cycle has two phases. Assuming the positive edge of the clock is settling time for control signals the control logic is as simple as an OR gate. One input of the OR is connected to the clock the other to WE control line. When enabled this will generate a WE strobe when the clock goes low.

The gotya is the WE line has to back high before the clock to the rest of the system or bad things may happen.
One could delay the master clock with another OR so the WE goes high the same time as master clock.
With 74LSXX,74XX,74HXX you had predictable delay times now days it is luck of the draw.

Reading the RiSC sequential design and comparing it against the PISC raises issues/questions about actually building it.

* The PISC connects the register file outputs to the address and data bus. The ALU inputs are also connected to these buses. The ALU output is connected to the register file write port. This is simple and reduces additional IC's and data lines. Also, all register and ALU chips are on one board with reduced interconnection with the rest of the system. In terms of construction, it's probably eight IC's which is doable with hand wiring.

* The sequential RiSC design places a mux in front of the ALU inputs for the immediate operand from the instruction register or the outputs of the register file. The output of the ALU feeds into either the program counter, the register file (via another MUX), or the address bus. This means 64 data lines are feeding into the ALU! Putting all the register, mux, and ALU chips on a single board would likely be at least 16 IC and could be a hand wiring challenge. With control lines and data output lines it's likely more than the ECB bus connector I was thinking of using.

So, here's my question/thoughts:

Rather than use the MUX, why not use a bus like the PISC? Register file IC's have output enable/disable. As does a D Flip flop which holds the decoded immediate operand from the instruction. The control unit has to enable the output anyway, so the mux control line seems like an extra signal. It would also halve the input data lines to the register/ALU board.

Granted a bug in the microcode could have two IC's attempting to drive the bus simultaneously. Slight enable/disable race conditions could also produce this outcome which would be a struggle to debug.

I understand why the RiSC connects the ALU output to the address bus because LW and SW have an immediate operand which is added to the register contents before addressing memory, so that requires a trip through the ALU, and the results aren't written back to any register. While that requires a mux to the register file input, it's a much smaller problem than the input data line issue.

I also read Prof. Jacobs' pipelined version, and his sequential approach is reasonable because his implied design goal is setting up his students to improve performance by adding pipeline registers and stages.

More design idea's found here.
https://homepage.cs.uiowa.edu/~dwjones/arch/

@oldben, thanks! Prof Jacobs is a gold mine of interesting ideas. I wish I could take his class.

His ultimate CISC and ultimate RISC designs are neat. He also has a whole page on the PDP-8 which is good to see.

A circuit diagram of the PISC is here:-
https://bradrodriguez.com/papers/pisc.pdf

And a 2021 implementation by VK2SJA that addresses some of the PISC’s shortcomings (and circuit diagram errors) is here:-
https://www.vk2sja.org/piffle/category/pisc/

B.Bibby, thanks for the links.

Because the AM29705 is readily available on eBay I'm going to use that for the register file. Additionally, only four are required vs eight for the 74LS172, so the cost is fairly low. The one downside is that the AM2907 multiplexes the B port address lines to latch the B output and the write address. That will complicate the writeback slightly.

However, it has sixteen registers which opens up a lot of possibilities. For example, having eight available to the programmer, and using a hidden one as the PC rather than having another register.

I created a KiCad library for the AM29705 and worked it into the ALU design that matches the page 10 diagram. In all honestly it seems overly complicated, and the ISA is intruding into a board that could be more generic.

I like the PISC two bus style better. So, I'll create a second schematic for that approach.

I recommend having a look at the design of some historical computers. In particular the xerox alto might be up your alley it uses a single bus: http://bitsavers.informatik.uni-stuttga ... _Aug76.pdf


The 74'138 decoder or similar is a good idea when dealing with a bus. No matter how glitchy or buggy the microcode is, only one device will be turned on at a time. As a bonus less control ROM bits are needed.

Having a open collector bus while slow is another option. if you can do it active low control signals work best.
Single step clock is a good idea, faster you turn the crank, faster you go.
With hex displays like surplus til-311's displaying state logic is a snap.

@DockLazy, thanks for the link.

The following approach is based on Andrew Holme's Mk2 http://www.aholme.co.uk/Mk2/Schematics.htm which uses the AM29705 and 74HC181 like the PISC.

My thinking is that the Register/ALU board remains generic and doesn't have dependencies on the instruction set. The ISA could be PISC or RiSC-16. A RiSC-16 control unit is responsible for placing 0 for R0, SignExt7, and LeftShift6 on the respective address or data bus after decoding the instruction. The ALU performs the operation, and it's written back to the target register.

For LW and SW instructions the memory address is formed by adding imm with contents of regB and then written back to R14. The control unit then outputs R14 to the address bus and performs the desired memory access.

I thought about putting a mux on the address bus and picking up the address coming out of the ALU directly and skipping the write back. I still might add that.

Here's the full sixteen-bit register file and ALU based on Andrew Holme's schematic minus the bus drivers and programmable logic. With eight IC's and 53 signal lines it looks like a manageable build. My plan is to order five AM29705 IC from eBay and build a four-bit version on a bread board. I'll then use a microcontroller to get a feel for how to manage the control lines and fetch data from an EPROM.

For example, coming out of reset I plan to start execution at address zero and I think these are the sequence of steps:
* Assert ALO bar to force a zero on the address bus.
* Assert ENAs1.
* Sets the ALU to the pass-through A function
* Sets the SRC2 bus to 0xF.
* Assert WErf to set the PC to zero.

I think those can all be done concurrently, but I won't really know until I try it.