Simplest possible I/O for Homebrew 8-bit CPU

Question

I am working on designing an 8 bit cpu as a personal project for no real reason. I am using mostly 74HC series chips and am generally focusing on ease of programming over performance.

I am using various projects on the internet as inspiration, and I feel I have a pretty good grasp on how the basics will work, including the alu, registers, and the basic memory path.

The one thing I don't have a clue about is Input and output. I am not really interested in anything super fancy, like tcp/ip or uarts, but I would like to have a keyboard and a basic text output to a monitor of some kind. I really have no idea what hardware to use, or what instructions to make to use it.

I could squeeze a few more specialized instructions out of my ISA to access specialized hardware, but if I could do it all with some kind of memory mapping scheme that could be even better. I am planning on using a 64K ram chip, but maybe certain addresses could get diverted to other hardware or something.

I don't really want to implement interrupts, but I don't want to lose keyboard data either. Does that means I need some kind of queuing buffer chip for my keyboard? I don't even know where to start looking for a video chip, or how I would interface with it.

Any tips would be greatly appreciated. Again, I don't need anything fancy, a simple getChar and putChar would suffice. Pixel level control of graphics could be cool, but not absolutely required. I think I just need to be pointed in the right direction.

Answer 1

The "simplest possible I/O" depends on what your I/O requirements are. It would be very simple, if you're in control of the CPU design, to implement a couple of special instructions to input and output a few bits of parallel I/O.

But since you mention keyboard and video, it seems that your requirement is to be able to interact with your system that way - and the dead simplest way to do that is to incorporate a fixed baud-rate serial port, and use a PC & terminal program to supply the keyboard and video. Using 9600 bps is fine for human console purposes, or if you expect to transfer binary, 115200 could handle 64K bytes in around 6 seconds.

An off-the-shelf UART chip like the 6850 or 8250 (well, out of the junk-box anyway) will need only 2 to 8 registers for a complete stdin/stdout solution. This is a tiny footprint compared to trying to implement a keyboard and video interface directly. You can probably drive a keyboard matrix with just a single 8-bit output port and a single 8-bit input port, but video will need 2K addresses just to supply the frame buffer for an 80x25 character display. If you consider so-called LSI solutions like the 8250 to be cheating, I would counter that constructing a UART from 74xx would probably be easier than constructing a video generator from the same technology.

That said, the down-side of the UART is that you are likely to lose input unless you either (a) poll it frequently enough, or (b) implement interrupts. For a simple proof-of-concept for your CPU, just polling should suffice - unless you're also trying to prove out interrupt capabilities of your CPU (if/when it has them), in which case, keeping up with serial input by using UART interrupts would be a fine test case.

Answer 2

Apart from standard parallel I/O ports you'll definitely want serial I/O, like U(S)ART, as well. We'll need it in a minute.

Input
For the input I would build an interface for a common PC keyboard (the so called PS/2). This uses a synchronous serial protocol; that's what you'll need the serial interface for. That means SIPO (Serial In/Parallel Out) and PISO (Parallel In/Serial Out). A synchronous protocol like the PS/2 keyboard's has the advantage that there's also a clock signal, which makes the conversion easier than for instance a UART. (You'll soon want a UART too)

Display
Most of the TRS-80 home computer was, apart from CPU (Z80) and memory, built with TTL ICs, including the 16 lines x 64 characters video, so the schematics may help you to get started.
But this may already be a big step, and I would start with something simpler, so that you can focus on the CPU, which most likely will need some debugging before it works properly. And it would be nice to have something of a display for that. (You don't want to debug the CPU and the video logic at the same time. Take one step at a time.)
I would suggest to use a common 4x20 character LCD (bigger is OK too). This is easy to interface and can display already a lot of (debug) information.
Another option is that you create a UART interface. It's standard on most microcontrollers and you'll need it sooner or later anyway. The UART will allow you to connect to a PC, and with a simple protocol you can use the PC's display to show a virtual display of your own computer in a window.

Interrupts
Mike comments that interrupts aren't that hard to implement, but I think it's a good idea to leave them out for the moment. They do add a level of complexity, and a risk of instability (more on a software than a hardware level); safety-critical microprocessors usually don't have interrupts. I recall the old Viper, which was used in fighter planes.
To make sure you don't lose incoming data you'll have to buffer it. The usual solution is a FIFO. This one is a building block from the 74HC series, so you can simply use that, or you can roll your own. (I don't know what your make or buy criteria are.)

---

Further reading
TRS-80 Technical Manual

Answer 3

I/O mapping

"Some memory mapping scheme" is pretty much the definition of memory-mapped I/O.

Try the Commodore 64 trick: peripherals share memory space with RAM, and any address not taken by a peripheral goes to RAM.

Or the Intel x86 trick: I/O gets its own address space separate from RAM. This makes using pointers with peripherals much more difficult.

Peripherals in general have just enough address pins to address their registers, a chip select (CS) pin that says when it is selected, and either a Read/Write pin or a pair of Read Enable and Write Enable pins.

Framebuffer

The simplest way to generate a video signal is to make a circuit that reads consecutive addresses from RAM and converts them into a video signal. Just how you generate the signal depends on what signal you want to generate (NTSC, CGA, VGA, LVDS, etc.) If you run the CPU slow enough, you could have the CPU access RAM on one half of a clock cycle and then let the framebuffer read RAM on the other half cycle (the Commodore 64 did this). Alternatively, if your memory bus handles wait states, you could give the framebuffer priority access to RAM.

The upside of this framebuffer is that it's easy to implement and easy to write for. The downside is that it takes a lot of RAM and pushes text generation onto the CPU (but it lets you do variable width and height fonts, too).

The sad thing is that you'll be pretty much on your own here; the market for this kind of low-level video chip is pretty much nonexistent these days. Remember, though, that the Apple II did its video generation in discrete components without a dedicated chip, so you can too. ^_-

Interrupts

Interrupts shouldn't be that hard to implement: If an interrupt line is driven, and interrupts are globally enabled, and that particular interrupt is not disabled, then push the PC onto the stack (just like for a subroutine call), and finally either load a new PC value from an address depending on interrupt number (the vector table method), or just set the PC to a fixed value depending on the interrupt number, expecting a GOTO at that address to get the processor where it needs to go (the jump table method).

Keyboard Interface

Stevenvh posted his answer when I was about half done with mine, so I'll second the recommendation to use the PS/2 interface. One interesting thing to note is that the PS/2 interface can be made hot-swap, and can autodetect whether a keyboard or mouse is plugged in. These features never made it onto motherboards because nobody wanted to pay the extra $$$ or rewrite their drivers to support it, but I've done it in an FPGA, so you can, too.

The trick is, though, that the PS/2 interface is two-way, so you'll probably want to use an interrupt-based serial port design to interface to it. You could use chips called FIFOs (Cypress makes a lot of them) to loosen latency requirements; you'll need one going each way.

Answer 4

If you have a reasonably fast CPU, the circuitry will be simplest if you let the CPU do a significant portion of the work generating it. As a simplest case, suppose that your objective is 40-column video, your processor runs one million 16-bit instructions per second from RAM, using timings derived from an 8MHz clock, and you don't mind being unable to do anything else while generating video. In that case, you could have an I/O bit serve as a master video enable, and three more as a sub-row select, and then arrange things so that whenever an instruction is fetched from an address where bit 6 is high, the bottom 8 bits of the fetched instruction will be fed into a 2Kx8 ROM along with the three bits of sub-row select; the output of that will feed a 74HC165 to clock out pixels. To display video, arrange to fetch groups of 40 instructions where the LSB of each instruction is a byte of display data. Such an approach would totally hog the CPU, but require extremely little hardware.

A slightly nicer approach would be to add a couple counters, triggering an interrupt either once per line or frame. The CPU would be unable to do anything during the visible part of the frame, but wouldn't have to lose sync every time it decided to do something other than show video.

Incidentally, it may be easier to use LCD than video. An LCD that has a controller built in will probably be most convenient, but even one that only has drivers may be somewhat easier than video, since timings are apt to be a bit more forgiving.

Answer 5

I'll make this an answer rather than a comment as material presents better.

Brain fade - I meant Sinclair ZX80 ! :-(. Video in hardware using Z80 cpu DMA I think

Sinclair ZX80 circuit diagram here

Build your own ZX80 here

Annotated circuit diagram showing functional blocks

More ZX80 {good}

---

Electronics Australia described the DREAM 6800 computer in xxx. This had a memory mapped very low resolution pure hardware video display. No character generator - graphics only with text being produced in software.

Here: says

The DREAM 6800 Video Computer: the project was published in the May, June and July 1979 editions of Electronics Australia magazine. EA ran a series of projects based in it, including "DREAM 6800 tape system in May 1981, DREAM 6800 RTTY display, Jan 1981 and 4K RAM expansion December 1980

Answer 6

Start with a simple uart/serial port. No need for features, 8 bits no parity 1 stop bit is all you need.