Over the past two years I architected, designed, and built YARC, a 16-bit computer. It looks like this:
As you can see, it's implemented using a sort of "wire wrap over solderless breadboard" style. The solderless breadboards are stuck down to a ground plane. Copper bars on bolts (insulated from the ground plane by plastic washers made of high-temperature PEEK plastic) carry +5 volts to each of the breadboard power strips through pairs of 30ga wires. The pictures below will help illustrate the construction process.
Unfortunately, images uploaded to Blogger have low resolution. The images in this posting, and a few more, in addition to all the design artifacts (hardware and software) are on Github: project root, latest images, PDF of KiCad schematic, documentation. The images on GH have much higher resolution (4032x3024).
We moved into our current home in January 2021, and it offered the most important thing of all: a place to work.
First experiments were with the clock ...
...and the physical packaging. I'm a nut about power and ground being solid. But soldering to the ground plane and copper bars is hard ... they carry away a lot of heat. You can see the PEEK plastic washers, which don't melt at soldering temperatures, isolating the tall (+5v) bolts from the ground plane. I also had to grind away a small amount of ground plane (copper cladding) under the washers to prevent small, side-to-side motion of the tall bolts from shorting to ground.
I had decided the YARC would be permanently tethered to the host computer and have microcode in RAM because I didn't like popping EPROMs in and out of sockets. I investigated various ways to do this, and finally concluded that a USB connection would get YARC on the air the soonest. An Arduino, equipped to read and write on the YARC's buses, seemed like the simplest way to achieve this.
Around this time I stumbled on to the "wire wrap over solderless breadboard" approach. In late 2021, I had this:
74HC574 bus interface registers at left and a couple of '138 decoders for pulse outputs above the Nano.
Next, I built out the clock and an 8-bit display register to the Nano's "north" and started on the YARC's 32k main memory subsystem:
The picture shows testing the memory controller with the 8k x 8 SRAMs not yet installed. There's still just one YARC "module" (1' x 1' copper-clad board).
Here, you can see the memory subsystem complete and a second YARC module. The instruction register lies to the "west" of the memory module, and the controls for the microcode RAM are being wired. The two YARC modules are still sitting side-by-side on an antistatic mat at this point, not attached to a base.
It came time to build out the additional two modules, buy some plywood, and attach all four modules. This was, I think, summer 2022.
With the microcode engine complete I began wiring the general registers and connecting the "real" (microcode) control signals to their various points - up to this time, everything had been controlled from the Nano. Control signals are mostly on white wires, external buses are green, internal buses (isolated by transceivers) are blue, and clocks are yellow.
There are an excessive number of isolated buses for such a simple machine because of my decision to implement microcode and even the ALU as RAM - making these spaces writable had serious consequences to complexity that I did not appreciate when I made the decision to go this way.
The results are still cool, though.
And finally, June 2023, the basic design is complete:
The image is rotated 90 degrees, with the Nano ("Downloader") at upper right. The clock circuit and the Nano's 8-bit display register are at top center. Proceeding down the right side of the image from the Nano are main memory, the instruction register, microcode controls, and the 8k x 32 bit microcode RAM. At center closest to the camera is the dual-banked array of four general registers, capable of two reads and one write per cycle, implemented with 74HC670s and multiplexers.
The three large RAM chips at lower left form the ALU, a carry-select adder implemented with lookup tables. The ALU is 8 bits wide and requires two cycles to do any operation. The flags logic and ALU controls are above them, adjacent to a small pair of pliers that volunteered for the photo.
The "completed" YARC is desperately short of address registers: only the four registers can drive the address bus, and two of them must serve as PC and SP. Fortunately, it will be simple to add a couple of transceivers from the non-architectural ALU output holding register to the address bus. This will at least allow for direct addressing and for (register indirect + immediate offset) against any of the four registers.
Now I need a lot of microcode. In yarc/yarc/pkg/asm there is a assembler program of a somewhat unique design, supporting a combination of microcode authorship for opcode definition with traditional assembler programming using the defined opcodes. Some code I've written is in yarc/yasm. Once I have enough of the instruction set defined, I hope to write a translator for a small subset of wasm to YARC assembler. This would allow C programming using any compiler than can produce wasm (e.g. Gnu C).
As you can see from the pictures, the basic 16-bit computer with writable control store and ALU functionality fit in 3/4 of the available hardware space. I'd like to implement a very basic VGA adapter, probably something more like Ben Eater's design than James Sharman's, and then implement a tile-like game that will remind observers of Tetris. I can't implement real Tetris because of intellectual property issues, but I'd like to be able to claim I got "YARC to Tetris" working, someday.
Looks amazing but must have been a lot of work. I wouldn't recommend a Ben Eater style VGA unless you want to loose 70pc of your CPU power. George Foot has done some great stuff with VGA, take a look at his stuff. I've also made a VGA card for my CPU which doesn't slow down the processor.
ReplyDelete