The Ultimate RISC Gets Hardware

(In a nasal, Andy-Rooneyish tone) “Have you ever noticed how some things just stay new?”

Well, Prof. Jones’ paper is like that.  It seems that every time I look at the paper, I see something new.  Take for instance figure 2, the block diagram: I have been going over that paper on-and-off for a few years.  Even so, I came up with the block diagram that I posted earlier.  Hmmm, it seems that when I took another look at figure 2, I just tried fitting some 74LS00 series chips in place; what do you know?  They fit!  I looked at the buffer (the triangle pointing up, on the right side of the diagram) and thought that it could be a simple tri-state buffer; perhaps a couple/few 74LS241 Octal 3-State Drivers?

Next, I looked to the left a bit and noticed that the rectangle right next to the driver was really a latch, such as the 74LS373 or ‘374 (now what is the difference between those again?  Oh yeah, one is edge triggered and the other is level triggered.)  Whoa, those latches in Prof. Jones’ figure 2 look mighty close to these chips.  In fact, with the exception of the triggers being inverted from Prof. Jones’ design, and the fact that the address latch is not buffered (just keep the output enabled for that one), those chips will work admirably.

After looking through my old, handy-dandy 7400 TTL list (, and doing a couple more replacements, I came up with this:

Notice that, as I’ve mentioned, the PC, ADDR and TEMP latches are inverted from Prof. Jones’ description.  This can be easily handled by simply inverting the bits in the sequencer for those signals.

Also, the address decoding for the PC Register is the small box in the lower-left corner.  It is simply a large AND gate looking for all the address bits to be high (the highest address) along with the write signal high.  This will latch the data on the data bus into the 74LS374 holding the PC Register.

The sequencer will be a simple 74LS188 ROM (or actually half of one) programmed with the data from figure 3 in Prof. Jones’ paper.  The address lines for this ROM will be tied to a 4-bit binary up counter (such as a 74LS161) clocked by the system clock.  The eight bits per address location will line up with the eight signals coming in on the left-side of figure 2.

Next up will be creating a schematic of each part of figure 2, and the 74LS188 ROM with the counter and clock.  I would like the clock to be variable, including down to single step, so that the operator can see each step as it is executed.

Also, January is the Winter Warmup for the Retrochallenge contest.  I will be entering again (didn’t do as well as I would have liked last summer), but am not sure what I will be doing for that.  Check out my RC blog at

Additionally, I recently purchased a few of the LaunchPads from Texas Instruments.  We will be going through an introduction to them in the next few weeks.





A Revelation!

Still working on getting the hang of this blogging stuff.  Just thought of something – guess what?  I don’t HAVE to stay on one project until it is completed.  (All right, you veteran bloggers, you can stop laughing now and get up off the floor; ok, so I can be slow on some things sometimes.)  As an engineer, you will rarely get the chance to work on a single project until completion, and so it will be with this blog too.

Anyway, I do have an update to the Ultimate RISC computer that Professor Jones described.  I started to write the emulation for the Parallax QuickStart board (,ProductName) .  I really love this little board, and when I add Bean’s Propeller Embedded BASIC (PE-BASIC, it feels kind of like the old small computers from the ’70s.

Well, back in the mid-70s, I wrote an emulator for Bell Labs’ CardIAC computer (   This cardboard computer taught the user how computers work on a very basic level.  Because of the CardIAC, I was light years ahead in understanding machine (and thus assembly) language.  Then, back in the early-90s, I dusted it off and morphed it into a visual CPU simulator for a microprocessor course that I was teaching.  Once more, I was starting to work on it to morph it into this Move computer.  I wanted it to be in “kinda” hardware (the Propeller would output an address and read/write to an external memory or I/O device.

After getting a good start, I decided that I was really doing a “proof of concept” project with this.  I really want to do a complete H/W Move Computer, not just a hardware emulation.  So, I am going to re-do this project:  the first implementation will be a purely software version (written in something with a little more horsepower than PE-BASIC, sorry Bean, but an integer-only language without any string handling or other things, while great for an embedded control system, leaves a bit to be desired for this Move Computer.)

My second implementation will then be a simple 4-bit proof of concept done in SSL (Small-Scale Logic) and MSL (Medium-Scale Logic) ICs, such as the 74LS00 or maybe the 4000 family chips.  This will be followed by an actually usable 16-bit or more computer, again done in SSL and MSL.

Here is the block diagram for my Move Computer:

The Control unit will need to generate 8 signals:

Internal to CPU:

  • MAR_WR (Memory Address Register Write or Load)
  • MDR_WR (Memory Data Register Write or Load)
  • MDR_RD (Memory Data Register Read)
  • PCRADDR_RD (Program Count Register Address – hardwired to all 1s, I.E. FFFF)
  • CTRL_RESET (Reset the binary counter to the micro-instruction step)

And external to CPU

  • WR (Write – for Memory or I/O)
  • RD (Read – for Memory or I/O)
  • PCR_INCR (PCR Increment)


All control signals go to 1
ACCU (Accumulator) = 0000
PCR (Program Count Register) = 0000

The microcode for the CPU will be pretty simple.  The processor will fetch the contents of the source location and then store it in the destination location.

Fetch the contents of the next Source memory location in the program into the MDR.

1)  PCRADDR_RD = 0 & MAR_WR = 0
2)  PCRADDR_RD = 1, MAR_WR = 1
3)  MAR_WR = 0
4)  MAR_WR = 1, PCR_INCR = 0
5)  PCR_INCR = 1, RD = 0
6)  MDR_WR = 0
7)  MDR_WR = 1
8)  RD = 1

Store the contents of the MDR into the next Destination memory location in the program.

1)  PCRADDR_RD = 0 & MAR_WR = 0
2)  PCRADDR_RD = 1, MAR_WR = 1
3)  MAR_WR = 0
4)  MAR_WR = 1, PCR_INCR = 0
5)  PCR_INCR = 1, MDR_RD = 0
6)  WR = 0
7)  WR = 1
8)  MDR_RD = 1

This looks like it will work, next I will test it in software.  If I stay with this microcode, you will notice that it takes exactly 16 steps.  I would not need the CTRL_Reset signal in that case, just running the sequencer clock beyond the 15(Decimal) or 1111b would start it over again without any need to reset the counter.

Well, that seems to be it for the initial design phase, I will implement it in software and present it in the next posting of this project (with other posts between these, of course.)

The Ultimate RISC

Having been working with computers since 1975, I have long wanted to build my own CPU.  In my playing research, I ran across a paper by Professor Douglas W. Jones of the University of Iowa (  This article really captured my imagination, and I have not been able to get it out of my mind.  This is, pretty much, the ultimate in simplified CPU design.

Professor Jones’ paper presents the design for a computer with only a single instruction.  At first, (having grown up watching the 8080 being trumped by the Z-80 and then Intel upping it’s own 8080 with the 8085 followed by the 8086 and so on…) my mind had a difficult time wrapping itself around a single instruction actually being useful.  Prof. Jones even discusses some real-world single-instruction computers at the end of his paper.

People who deal with logic know that any logic can be generated from only NAND gates.  Thus, a computer which can only perform a NAND operation should be able to emulate all other operations.  Likewise, it turns out, a computer which does nothing more than subtracting one number from another and then jumping to a new location can emulate all other operations.  Wikipedia discusses some of those computers in their article on One Instruction Set Computer (

Prof. Jones presents another type of single instruction computer, the MOVE computer.  The only instruction available to this CPU is the MOVE command.  This does bring up a few difficulties such as: how does the CPU modify it’s program flow… How do you do logic or arithmetic functions, etc.

His paper covers all that pretty well.  After reading his paper, it started to strike me as being an insanely simple architecture.  I think that this is a good way for people to get into the design of a CPU.  My next project will be an implementation of this MOVE computer in hardware (probably just an MPU emulating the CPU to begin with.)