Category Archives: Electronics

My various electronics projects

Propeller Fun

As I mentioned in my previous post I am using a Parallax Propeller in my COLE-2 SBC project. The propeller is a neat little chip. I won’t go into a whole lot of details about it here, since that is well-covered elsewhere, but the basics are that it’s an 8-core (or “cog”) processor running at 80 MHz, and is very hobbyist-friendly. It’s a bit of an odd duck from a programming point of view, but once you get used to it you can do some amazing things with it. There are literally hundreds of open source modules available implementing all sorts of software-designed peripherals so you can do a lot while writing little to no code of you own, if you so choose.

What initially drew me to the propeller is its ability to generate video signals, both composite (NTSC or PAL) and analog VGA. It’s able to do this thanks to some custom hardware included in each cog that facilitates the generation of the proper timing and the shifting out of pixel data based on that timing. You can do this with as little as one cog, although multiple cogs working together will allow you to get higher resolutions and/or better color depth. The only limitations are that is is limited to 6-bit RRGGBB color, and there is only 32 KB of shared RAM (called “hub RAM”) available for holding your frame buffer and other shared data.

Once you have the propeller integrated into your design, however, you might as well put all eight cogs to use; the only cost incurred is adding the extra driver code and maybe some I/O pins (more on that later). With that in mind I decided to see how much I could pack into that single chip.

The Bus Interface

To start with I need a way to interface the propeller to the rest of the system. Many projects just do this over a serial link; the chip can bit-bang serial at modest bit rates, and I could easily have attached it to the second port of the UART. But serial can be a real bottleneck for graphics modes, so I wanted some sort of parallel interface. In an ideal world I would let the chip pretend to be a 32 KB RAM chip, but this would eat up every single available I/O pin and would probably be overkill for the modest graphics modes the chip is capable of producing. So, I decided to borrow from the 1970s-era TMS9918, which did all configuration and VRAM access through just two addressable registers. This means I only need 1 address input instead of 15.

To implement this I connected the propeller to 14 signals bus: D0-D7, Φ2, /IOSEL2 (from my address decoder GAL), RWB, RDY, and /IRQ. The RDY line would be held low to halt the CPU while the propeller responds to a bus request, since it’s not fast enough to keep up with the CPU at full speed. All of these signals would be fed through a pair of 74LVC245 buffers, because the propeller is a 3.3V part but the rest of my system is 5V. So far so good, or so I thought…

RDY and Waiting

As it turns out using RDY with the 65816 is not quite as straightforward as I had hoped, due to the way it multiplexes the bank address onto the data bus. The bank address is emitted during the first half of the CPU cycle, when Φ2 is low. The data bus is connected to a 74ACT573 latch, which is kept open (transparent) during Φ2 low, but which closes and captures the bank address when Φ2 goes high.

Normally this setup works fine, and in fact it’s the exact design recommended by WDC. The problem comes in when you start trying to use RDY. When RDY is pulled low, the CPU halts as soon as Φ2 transitions from high to low. The actual Φ2 clock, however, does not stop. If RDY is kept low long enough for Φ2 to go high again, the bank address latch will capture some random data bus data as the bank address, and when the CPU finally resumes it will likely access the wrong memory address.

For my test implementation I solved this by using some extra lines on a GAL to construct a latch enable signal that such that the latch remains closed as long as RDY is low. Unfortunately this seems to have made the system slightly unstable, even when the propeller is not being accessed (during which times it’s not even on the bus, as its data bus buffer is disabled until /IOSEL2 goes low while Φ2 is high.) My GALs are fast (7 ns parts), but it’s possible the extra delay is the causing the strange behavior.

For my next attempt I am going to try a different approach: halting the CPU’s Φ2 clock during the high phase using a circuit like this:

Clock generation circuit with wait stating, by BigDumbDinosaur (

My current clock generator is the top half of that circuit, which means I already have the second half of the flip-flop available to use to add the bottom half; I just need to do the wiring. Once that’s done the propeller will pull /STP low instead of RDY, and my bank address latch will go back to being directly qualified by Φ2. I am hoping this will result in a stable system.

As a bonus I am hoping this new setup will solve another issue I have so far ignored; when first powering on, the propeller takes a few seconds to boot, during which it is not properly asserting RDY. This causes boots to randomly fail. With the new setup /STP will be low during this time so the CPU will not even try to boot until the propeller is up and running.

The Software

Writing the PASM code to implement the 65xx bus interface turned out to be much easier than I was expecting; I was able to hack out a working proof-of-concept implementation in a few hours. It isn’t even a lot of code; the basic code forming the main loop is just this:

mainloop    waitpeq Pin_PHI2, Pin_CS_PHI2       'Wait for /CS to go low with PHI2 high
            andn    outa, Pin_RDY               'Pull RDY low
            mov     _in, ina                    'Capture the input port
            and     _in, Pin_RS WZ,NR           'Check RS bit (0 = vram, 1 = registers)
            and     _in, Pin_RWB                'Mask RWB bit for later
    if_e    jmp     #:vram
            tjz     _in, #write_register
            jmp     #read_register
:vram       tjz     _in, #write_vram
            jmp     #read_vram

'' Common code for all ops; unhalts the CPU, waits for /CS to go high and then loops

            or      outa, Pin_RDY               'Unpause the CPU
            waitpeq Pin_CS, Pin_CS              'Wait for /CS to go high again
            andn    dira, Pins_Data             'Set data bus pins to high-Z (input state)
            jmp     #mainloop                   'Rinse and repeat

In the end I had a working setup in which reading the propeller on either I/O port would return a constantly incrementing byte, which I could also change by writing to either port. This allowed me to verify that the bus interface was working properly.

With the test code working I’ve started adding useful functionality. So far I’ve gotten the VRAM read and write working, and I’ve been able to successfully fill the screen with characters using assembly code running on the main CPU.


At the moment the video output is being driven by the “80×25 C0DF” driver from the waitvid.2048 repository. It generates 80×25 text using a 9×16 font; each character has an attribute byte associated with it that points to a 256-entry color palette. Each color entry in turn consists of a foreground/background color pair and a blink bit. The driver also supports two independent hardware cursors that can be a block or an underline, with or without blinking. The video buffer, color palette, and the font are all in hub RAM, so in theory they could all be made changeable by the main CPU.

I would like to offer the ability to switch to an alternate video driver (either a limited resolution bitmap, or perhaps a tiled driver with sprites), but as of yet I have not worked out how to accomplish this.


Since I have video the most natural choice for another thing to add is audio. As it turns out someone has written a Propeller module called SIDcog that emulates the C64 SID chip. It takes only a single cog to run, uses very little hub RAM (just a couple dozen bytes for registers) and only two I/O pins.

The SIDcog module is very simple to use; you tell it what pins to use for left/right audio, and it returns a pointer to a block of emulated SID registers in hub memory. Reading or writing those locations will affect the emulated SID just like it would a real one. So, in theory, once I’ve finished implementing the write_register function in my bus interface I will be able to play sound.


An SPI cog is the last piece I plan to add, since at that point I will be almost out of I/O pins. The propeller will handle the actual SPI transfers and signal the main CPU via interrupt once the transfer is complete. To allow reading or writing of entire SDcard blocks I plan to implement a small 512-byte buffer. I am not yet sure how this will be implemented at the bus interface side but I have some ideas.

Future Work

At the moment I’m hard at work getting the bus interface fully implemented. My focus is on getting the video registers implemented enough that I can try redirecting the console output to VGA. Expect another post (with pictures) once that VGA boot screen is working!

COLE-2 is born

NOTE: I’m going to experiment with turning on commenting, starting with this post. We’ll see how it goes.

The nice thing about creating things as a hobby is that you can switch to a new thing whenever you get bored or frustrated with the current thing. That is exactly what happened to me a few months ago: I started getting frustrated with the limited features I had available on COLE-1, so I decided to just jump ahead and start the next iteration. The result is this:

That ugly mess of wires is actually a functional 2 MHz 65816-based SBC, called, not surprisingly, COLE-2.

Hardware Overview

COLE-2 will be a substantial upgrade from its predecessor:

  • 6 MHz 65C816 CPU (largely limited by EEPROM speeds)
  • 1 MB of RAM
  • 256 KB of ROM w/ full system monitor, OS, and 16-bit BASIC
  • Glue logic moved to two 22V10 GALs
  • 28L92 Dual UART providing two DB-9 serial ports
  • 80 MHz Parallax Propeller for analog VGA video, stereo audio, and SPI
  • ATmega328p for PS/2 keyboard/mouse and two NES-compatible game ports
  • Dual 65C22 Versatile Interface Adapters
  • SD card reader
  • A user port
  • A single expansion slot

When I started this project my goal was to produce another headless SBC similar to COLE-1, but with an expansion slot that would act as a platform for developing my custom CPLD-based video system. However it became apparent that I was trying to take too big of a leap there, and so I decided to add basic on-board video as an interim step.

My current prototype is scaled down from the final specs, since it’s implemented on solderless breadboards. It only runs at 2 MHz, and has only 512 KB of RAM, 32 KB of ROM, one VIA, and no ATmega. Much of this is just due to lack of space on the breadboard; as you can see I’m already spilling out onto additional boards, and all those long wire runs take their toll on stability, especially at higher speeds. My plan is to squeeze the ATmega in there somewhere to get a working keyboard port, and then move on to designing the PCB and building a full prototype.

In my next post I will dive into how I integrated the Propeller into my design.

COLE-1 updates

Yes, it’s been five months since my last post. As it turns out writing meaningful blog posts is not as easy as I thought!

Anyway, I’ve been pretty busy, not only with life and work, but also steadily making progress on COLE-1. Here’s a recap.

SPI Support

One of the first things I did once the board was operational was start hacking together support for SPI, which opens up the possibility of talking to a lot of interesting hardware. The 6522 VIA can almost, but not quite, do SPI in hardware, so I ended up bit-banging it myself. The protocol is fairly simple, and is very flexible on clock rate, so this was not hard to do. Owning a logic analyzer (a Saleae Logic 4) also helped immensely.

SD Card Support

Once the SPI was working my next task was to hook up one of those little $5 SD-to-SPI adapters that you can find just about anywhere on the net. The hardware hookup was easy; the driver software, not so much. It took me a week or so to finally get the driver to properly initialize the card and read blocks, despite having some official documentation and some sample code. Having a small bug in my SPI driver also did not help matters!

Operating System

With the low-level bits of the SD card driver working (at least for reading), I have begun to build a real operating system around that. Tentatively I’m calling it JR/OS (Josh’s Retro Operating System), at least until a better name comes to mind.

The plan is to embed the OS in ROM and allow booting applications from FAT-formatted SD cards. Some day I would like to be able to load the OS from disk at boot time, but COLE-1 only has 32K of RAM and a largely empty 32K ROM, so for now JR/OS will remain in ROM.

Video and Improved I/O

This is where I’ve spent most of my time lately and the part I’m most excited about. For the past few months I have been designing a custom video and I/O chip using a large CPLD (complex programmable logic device). The goal is to provide VGA output, PS/2 keyboard and mouse input, and possibly hardware SPI.  It’s slated to eventually be the core of my next SBC, but first I’m going to be hooking it up to COLE-1.

Here’s the early prototype hardware. The board on the left is a Max V CPLD development board; it’s hooked up via a ribbon cable to my breadboard which contains the support circuitry to interface to the VGA monitor.

The two chips at the bottom of the breadboard are the VRAM, which is not yet connected. This board will get much more full soon.

And here’s a 16-color test pattern. The board can actually do up to 64 colors at 320×240 but this pattern was easy to generate.

I’ll be making a separate post about this chip soon, because it’s pretty cool and it deserves a post of its own. Stay tuned!

Introducing COLE-1

In my last post I talked about breadboarding a 6809 single-board computer; well, in the last three months I’ve taken that one step further, and I am proud to say I have finally achieved my goal of building an SBC based on an original design. Allow me to present COLE-1:

This SBC is based on a WD 65C02 clocked at 4 MHz, with 32K of RAM, 32K of ROM (implemented with an EEPROM, for easy updates), a 6522 VIA driving two 8-bit expansion ports, and a 6850 ACIA providing a TTL-level serial port running at 115.2k bps.

Board Design

All of my design work (schematic and board layout) was done using KiCad, and the boards were manufactured by PCBWay. It’s a four-layer board (my first) with internal ground and power planes. Here are a couple of photos of the bare board; as you can see the manufacturing quality is quite good:

Careful observers will notice that there is solder mask over the pads for my surface-mount components; this is NOT the board house’s fault, because I see the same thing in the gerber file; somehow I goofed up my board layout in KiCad. Fortunately solder mask is pretty easy to remove with a sharp flat-head screwdriver, so I was able to correct this mistake.

The solder mask problem, however, was nothing compared to the other mistake in this layout: I accidentally picked the wrong footprint for the ACIA, which is the chip at the lower left corner of the board. What should have been a 24-pin, 15mm wide footprint ended up being a 10mm wide variant!

Rather than waste the boards I hacked together an ugly but functional adapter using a 24-pin socket, some perf board, and two strips of male headers. This turned out to be more of a pain than I had planned, due to the need to solder in some tight spaces, but I finally got it working and stable.

The moral here is always print your layout on paper and do a test fitting with your actual components before sending your layout to the fab house!


The firmware for this board is very much a work in progress.  The system currently boots into a customized version of Enhanced BASIC; from there, you can run the ‘SYS’ command to drop into my home-brew system monitor.

The monitor is loosely based on the Apple II system monitor (since I grew up using it), but currently has only minimal functionality. You can view (but not modify) memory, disassemble code, and do Xmodem transfers to and from memory. The upload function is very handy for rapid testing of new firmware; I can upload and run test code from RAM instead of having to pull the EEPROM and re-program it.

Future Upgrades

At the moment I am working on designing an add-on board that will provide VGA output and PS/2 keyboard input through one of the VIA ports, using a custom CPLD and an Atmega microcontroller. I’ll be blogging more about that project soon.

I have also been experimenting with a microSD card adapter that interfaces via SPI, with the intent of eventually implementing a full disk operating system (probably based on FAT-16). The problem is that my current hardware design doesn’t directly support SPI; I have written some code that bit-bangs it on a VIA port, but it’s not exactly fast, so  I am thinking about just tying one port to an atmega328p and using that as a parallel<=>SPI interface to get better throughput.

Eventually there will be a COLE-2, probably based on the 65816, and with more integrated peripherals. I had originally intended to start work on COLE-2 once COLE-1 was up and running, but I’ve decided to hold off for a bit and see how much I can add onto COLE-1 first.

Design Files

The schematics, board layout, and firmware source code are all available in my GitHub repository.

A Home-brew 6809 SBC

When I was a kid experimenting with electronics my big dream was always to build my own computer. Today, after thirty years, I finally realized that dream:

This is my breadboard implementation of Grant Searle’s 6809 SBC. His basic design is just six chips and a handful of miscellaneous components. If you use a USB to TTL serial cable like I did then you can cut that down to just five chips.

This SBC is powered by a 6809 with 32K of RAM, 16K of ROM, and a 68B50 ACIA for the serial I/O. The ROM contains a modified version of Microsoft Extended BASIC as used by the Tandy Color Computer 2. All I/O is via the serial port at 115200 bps. Here’s me running some really simple BASIC commands in Minicom:

I was able put this together in an afternoon over 2-3 hours, and surprisingly, it almost worked on the first try! The only reason it didn’t work right away was because I forgot to tie a couple of MPU pins to Vcc. Once the missing wires were added it booted right up.

Grant also has designs for basically the same SBC but with a Z-80 or a 6502 as the CPU, and i plan to build all three eventually. I had actually wanted to start with the Z-80 version, but it uses an 8k ROM (a 27C64) and my burner seems to be having problems burning those; more on that later.

Now that I’ve gotten my feet wet I’m to start designing my own SBC. I’d like to build something around a 65816 but I will probably start with a 6502 or 65802 to keep the first design simple. Whatever I do I’m sure I’ll have fun building it!