HD6309 Singleboard Computer

Hitachi HD63C09 clocked at a blistering 3 MHz with a capacious 64K of RAM! Retroputing bliss...

Similar projects worth following
100mm x 160mm eurocard format SBC with Hitachi HD63C09E processor clocked at 3 MHz, with 16K of EEPROM and 64K of SRAM. An Altera MAX7128S CPLD is used for all of the 'glue logic' as well as implement a hardware SPI interface to a microSD card. One channel of a Zilog 85C30 Serial Communications Controller (dual UART) is connected to an FT230X UART-to-USB bridge. The USB B connector is the terminal interface to a USB host (e.g. PC) as well as a means to power the board. A battery-backed Epson RTC7301 Realtime Clock keeps time. A Zilog 8536 CIO and stacking PC-104 type 'expansion connector' provide I/O.

CPLD glue all written in VHDL and includes CPU clock generation, baud clock generation, address decoding, and SPI master.  A few "registers" were implemented in the CPLD to allow soft-configuration of the SBC.  The address decoder allows the uppermost 16K of EEPROM to be banked over the EEPROM. The Zilog SCC Ch A provides a 115.2kbps interface to the USB host via the FTDI bridge. A Zilog 8536 Complex Input Output (CIO) device provides 20 I/O pins as well as timers and a clever interrupt controller. The USB B connector is the host interface as well as a means to power the board.

  • 1 × Hitachi HD63C09E PLCC CPU
  • 1 × Altera EPM7128SLI-84 PLCC CPLD
  • 2 × 32K x 8 DIP SRAM
  • 1 × 28C256 32K x 8 DIP EEPROM
  • 1 × Epson RTC7301 DIP Realtime Clock

View all 9 components

  • Clock Frequency Clarification

    tomcircuit06/05/2018 at 17:50 0 comments

    There are two oscillators on the SBC, Y1 and Y2.  Unfortunately, the information on what these are is missing!

    Y1 is "XOSC" and is 24 MHz, from which the 3 MHz quadrature ECLK and QCLK signals for 63C09 U3 are derived inside of CPLD U7.

    Y2 is "WOSC" and is 14.745 MHz, which CPLD U7 divides by 8 and 4 to produce the signals that are applied to SCC U5 ACLK and BCLK, respectively.

    Below is a snippet from the HD6309_glue_top.vhd file documentation, which seems to be the only place I bothered to document this information :-/

    entity HD6309_glue_top is
    	port ( 
    		XOSC : in std_logic;			-- Oscillator input for CPU (nominally 24 MHz)
    		WOSC : in std_logic;			-- Oscillator input for ACLK/BCLK (nominally 14.745 MHz)
    		QCLK : out std_logic;		-- Q phase clock output (nom 3 MHz, XOSC divided by 8)
    		ECLK : out std_logic;		-- E phase clock output (nom 3 MHz, XOSC divided by 8)
    		BCLK : out std_logic;		-- SCC ch B baudrate (WOSC/4 for SCC BRG)
    		ACLK : out std_logic;		-- SCC ch A baudrate (WOSC/8 for 115.2kbps in SCC 16x mode)

    Possible source for Y1 (DigiKey):

    Possible source for Y2 (DigiKey):

  • C compiler...sort of

    tomcircuit02/25/2016 at 20:18 0 comments

    One thing that's high on my wish list for the 6309sbc is high level language support. After writing the SD card stuff in 6309 assembly language, for example, it was clear to me that C support would make using the 6309sbc a lot more fun (and easy).

    I did take a look at the bipom MicroC toolchain. It's a windows IDE coupled with the Dave Dunfield MicroC compiler. I've used Dave Dunfield's stuff before - the monitor package has very nice ROM monitors and cross assemblers for about a dozen different CPUs. The monitor on for my own sbc6309 board is a hacked version of his 6809 monitor. Micro C is a limited dialect of C. It didn't take too long to adapt the runtime files for the sbc6309 hardware. I was up and running in less than an hour. I'll put the runtime files up on GitHub soon, in case anyone wants to give it a try.'s not "real" C. There are a lot of limitations that have to be observed. Even then, stuff that should have worked, didn't. I can't really recommend springing $150 for this tool for the 6809 unless you're really, really curious. Don't get me wrong - I don't feel ripped off - I am just spoiled when it comes to embedded toolchains. I use Keil uVision for the 8051 for my day job, and that tool is rock solid. It is also about 20x the cost of the bipom offering. I get it.

    I see that there's a 6809 target for gcc, but really have no idea how to make it work with something like the sbc6309. Anyone want to take this on? If so, contact me and we'll see what we can work out (e.g. trade hardware for a working gcc6809 for the 6309sbc)

  • Hiatus

    tomcircuit07/10/2014 at 03:12 0 comments

    Nothing going on with the SBC for a while - it's summer, and instead of electronics, I've been 'hacking' on a cottage rehab: down to the floor joists and the wall studs, complete re-plumbing, and a sorely needed electrical upgrade. It's a ton of work, but it will be nice when it's done. In the meantime, I've been thinking about VGA text and graphics support and I think a way to improve the sound quality from the FPGA. Of course, I've also spawned a couple new project ideas, which I'll put up here when I'm more in a position to actually work on them! For the time being, emjoy the summertime!

  • YM2149 Sound Revisited

    tomcircuit06/16/2014 at 12:17 0 comments

    Fellow retroputing enthusiast Daniel Tufvesson found a nice set of tools to convert MIDI tunes into an intermediate format, very suitable for playing with a very simple program on the hd6303 and hd6309. What I think it reveals is that my lazy approach at sound interface from the emulated YM2149 to the audio CODEC is causing some rather unpleasant artifacts.

    The YM2149 core ticks along at approx 1.56 MHz. This is the rate at which the tone generators update and the final output output is made avaialable. The audio CODEC interface (shamelessly stolen from Steven Edwards FPGA Apple II project) hums along at 18.43 MHz, which is 192x the 48 kHz DAC rate. So the audio CODEC interface consumes the YM2149 output at a rate that is not related to the YM2149 output update rate. I suspect that this is where my problem is. The asynchronous nature of the sound source and the CODEC interface are causing audible uglies.

    I think I'll try to find some way to derive the YM2149 clock from the audio clock chain - I think that's the most straightforward way to do it. Otherwise, some sort of interpolation filter is required, which is really beyond my ability at this point - I'm no DSP guru; I just know enough to almost be dangerous.

    If anyone reading this (does anyone read these?) has any suggestions or advice, I'd welcome it!

  • CPLD 1.3 and ROM Basic on Github

    tomcircuit05/26/2014 at 20:05 0 comments

    Very short update - latest ROM BASIC (Microsoft Extended BASIC) and the Quartus VHDL project for the glue logic CPLD are up on Github now.

  • FLEX, IO page moves, VHDL

    tomcircuit05/25/2014 at 02:29 0 comments

    Since my hacking about with the hd6303 (the Hitachi version of the 6800) I've managed to keep in touch with a fellow hd6303 enthusiast, Daniel Tufvesson ( check out his blog at ). Daniel has been looking very deeply into the FLEX operating system for the hd6309, and he's come to the conclusion that there's really only one (big) roadblock that complicates porting FLEX to this hd6309 SBC: the I/O page is located at $C000. FLEX OS was mostly run on the SWTPC-09 ( read more about this vintage machine at ) and it has IO located at $E000. The SWTPC-09 has RAM all wrapped around the IO area, and the FLEX OS has program and data intermixed very freely. To untangle FLEX to work with a different memory map would be a LOT of work. Well, I think it'd be fun to have an OS, and I'm not about to write my own, so I guess I'll move the IO page to $E000. This involves no real hardware changes, thanks to the CPLD that handles all the glue logic.

    Speaking of which...the last released CPLD version (1.2) sports about as much utilization as the EPM7128 will stand - something around 100 macrocells. Sure, there's 28 more, but routing to them becomes really difficult and the Quartus fitter just cries uncle and gives up. As I put together CPLD version 1.3, still pushing around 98 macrocells, I took a real hard look at the circuit that resulted from my VHDL code. This is most easily done using the RTL viewer feature in Quartus. What I notices was that the address decoder was really "lazy" and the implementation was a bunch of n-bit comparators - not very efficient. So, on a whim, I re-wrote the address decoder using only plan-vanilla, hand-minimized logic equations. I was rewarded with the total design implemented in 73 macrocells - a 25% reduction! That allowed me to clean up some other things that bugged me in the CPLD, so version 1.3 preserves some room for growth/fixes in the future.

    So, coming soon is the CPLD 1.3 with ROM bank 1 from $C000-BFFF and bank 2 from $E200-FFFF. Each bank can be switched out for RAM. Writes to the ROM space will always write to RAM, so it's easy to copy ROM to RAM; just read and then write each byte back to its original location - no need for a page buffer elsewhere in RAM.  Of course, this means that I need to do some changes to the MS BASIC, and the monitor program, to accommodate the new I/O page location. Moving can be a pain!

  • More FPGA Fun - PS/2 keyboard

    tomcircuit05/11/2014 at 19:06 0 comments

    Spring has finally spring here in Southeastern Michigan, so I'm finding more non-electronic things to do lately. Still, I managed to continue experimenting with the DE1 Cyclone II eval board that I've bridged to the hd6309 SBC. I found several nice VHDL implementations of PS/2 keyboard interfaces. I settled on a GPL'd set of code I found at

    That not only does the (easy) job of receiving the PS/2 clock and data pulses, but also the (less easy) job of converting the PS/2 keyboard "scan codes" into simple ASCII values. So, in short order, I could use the hd6309 ROM monitor program to read keys from a PS/2 keyboard connected to the DE1. I implemented the read-only keyboard data port "Apple ][ style" where the MSB is high when new key data is available, and low if it's already been read. The ASCII value of the key pressed is contained the lower 7 bits. So, for example, if I hit the "A" key, the first time I read the port it will read $C1 ($80+$41) and on subsequent reads it will read $41. Simple. 

    Recall that the goal for the FPGA is to implement PS/2 keyboard, a sound chip (see previous log), a paged memory unit, and a VGA-compatible video interface. I'm convinced that the Cyclone II FPGA is capable of all of these things - much more, really.  For example, I did notice that opencores has VHDL for several IEEE-754 compliant Floating Point arithmetic units...hmmmm...

  • YM2149 Sound via FPGA

    tomcircuit05/06/2014 at 04:08 0 comments

    I recieved my hd6309 SBC bridge PCB right around Easter time. This is just a small PCB that interfaces to the expansion connector on the SBC. It brings the address, data, control lines through 5V to 3.3V level shifters (74LCX541 and 74LCX245 do the work here). A 40-pos ribbon cable interfaces these shifted signals to my Terrasic DE1 FPGA dev board. The DE1 is a fabulous board with an Altera Cyclone II FPGA and a very rich set of peripherals included (SDRAM, FLASH, SRAM, CODEC, LEDs, Switches, RS232, VGA...the list goes on).

    After a simple I/O port implemented in the FPGA as a test (read the DE1 switches, write to the DE1 LEDs) I tore into a very nicely done GPL VHDL model of a Yamaha YM2149 sound chip (courtesy of MikeJ at The YM2149 is essentially an AY-3-8910 at heart. I altered the bus interface section to provide a demultiplexed bus (A0-A3 inputs, RD strobe, WR strobe) and removed the YM2149's two 8-bit I/O ports. I implemented a very simple address decoder of the hd6309 CPU address lines, and routed the audio out via the DE1 onboard CODEC. Voila! The hd6309 SBC now can make cool beepy-boopy sounds via a synthesized YM2149 soundchip.

    This was a nice diversion that definitely proves out the idea that an FPGA can easily be interfaced to the vintage hd6309 CPU. As I wrote earlier, the intent is to eventually implement an FPGA-based VGA video controller, sound chip, PS/2 keyboard interface, and a paged MMU for RAM expansion. Sure, the FPGA could hold the CPU, also, but that's not what I'm after, here, so I'll stick to actual hardware for the CPU!

  • ROM BASIC up and running!

    tomcircuit04/23/2014 at 02:20 0 comments

    I admit I get sidetracked pretty easily. I was really trying to work on a nice, open-source monitor program for the hd6309. I was chugging away, making a bit of progress. Then, as I was casting about on the intarwebs, I was finally able to access the 6809 homebrew computer pages of Grant Searle. (note: I still have very spotty access to his pages - unreliable server?) Grant has done a wonderful job of taking the Microsoft's CoCo Extended BASIC interpreter and thrifting it down to a console version. Bravo! In a matter of a few hours, I was able to work with Grant's source file, adapt it to assemble with lwtools assembler, and do the relatively minor adaptations for my HD6309 SBC. Fire up the EPROM programmer...

    It works great! It brings back a lot of fond memories of working with a relatively naked ROM BASIC machine. In no time at all I had loaded in Hammurabi from the Ahl book (101 BASIC computer games) and my 8-year old son Ryan and I were (mis)managing the mythical city and starving villagers left and right. Fun stuff! That's one goal accomplished, then - a working BASIC interpreter. Again, all the credit goes to Grant Searle - check out his pages, especially his MultiComp reconfigurable computer project. Good stuff!

    OK, now, back to a monitor, that can now cohabitate with a fully functioning floating point BASIC interpreter.

  • Open Source 6309 Monitor?

    tomcircuit04/13/2014 at 21:39 0 comments

    I've been slowly chipping away at the edges of a dilemma. I've been very comfortable using Dave Dunfield's MON09 monitor program for this project. It's a really nice full-featured monitor that works great, and took almost no effort to port to my hardware (i.e. integrate SCC support). I added some stuff to support the realtime clock, and the CIO, and cleaned up the hex/srec loader a bit. But, other than that, it's pretty much the code I bought from DDS, many years ago. The only drawbacks are, as I see it: 1) it's closed-source, so I can't distribute the source code or even the binary ROM code; 2) it's really a 6809 monitor, and not a 6309 monitor - it doesn't know about the extra 6309 registers, nor all of the additional 6309 opcodes. 

    I've avoided the temptation to fix #2, because of #1 - any effort put into the monitor can't be shared, and I'm bummed out about that. I've looked for a 6309 ROM monitor, but don't find one. I've found other 6809 monitors, all quite ancient, but they are also not open source (they predate the concept, for the most part). Ugh. 

    I suppose I need to get writing, then. At some point, it'll be done....

    Other News

    I whipped up the design for a "breakout board" to interface the 6309 SBC expansion port to my trusty Altera DE1 Cyclone II FPGA eval board. It's just a bunch of 74LVC level shifters to bring the 5V TTL down to 3.3V CMOS suitable for input into the FPGA. The idea is that I can use the DE1 to develop the VGA and sound and keyboard interface stuff, before committing to a design.I've got a low-cost Cyclone I FPGA board, also, on hand, so there's another connector to interface with that board, too. I'm not decided between Cyclone I and Cyclone II. The II is more capable and larger, but the I comes in a nice TQFP 100 package that is about the limit of what I'll hand-solder.  Anyhow, this board should be helpful, I think. It's getting fabbed via OSHpark, hope to see the boards in about a week or two.

    The 4.10 release of William Astle's "lwtools" assembler/linker toolchain is out. lwasm now includes the ability to write intel hex and motorola srecord output files - courtesy of yours truly.  Get it at   

View all 16 project logs

  • 1
    Step 1

    Get the relevant docu from GitHub

  • 2
    Step 2

    Get a PCB from OSHpark

  • 3
    Step 3

    Component sources:

    Most items are commonly available, with the possible exceptions being the 63C09EP (be sure to get an 'E' type with external clock) and the Z8536 CIO. I obtained the CPU via eBay. The CIO might be a bit harder to find. It's not critical, and can be omitted if desired. Be careful with the EPM7128S CPLD, also - some surplus chips e.g. eBay are pre-programmed with the JTAG pins assigned to I/O - these cannot be re-flashed using JTAG! Ask me how I know this...

View all 3 instructions

Enjoy this project?



William wrote 04/01/2019 at 21:09 point

I know, according to your logs here you were looking at Flex for the OS, What about NitrOS-9.... written to take advantage of the 6309, flexible memory model iirc.... hardware treated as modules to the kernel... I believe it's open source as well.

  Are you sure? yes | no

tomcircuit wrote 04/05/2019 at 17:44 point

Many of the 6809/6309 OS, tools, etc. that I find are really targeted to a specific machine, and unfortunately I lack the skills to tailor them to work with the HD6309 SBC architecture. I never find "generic" targets to use as a starting point.

Similar for toolchains: I have lost count of how many times I've underwent the "install cygwin, (attempt to) build gcc for 6809, fail" loop. Without a C compiler, I'm really not interested in doing a lot of work with the 6309. Yep...I'm lazy!

  Are you sure? yes | no

mister35mm wrote 03/22/2018 at 05:05 point

ASSEMBLY LANGUAGE PROGRAMMING MOTOROLA 6809 / 6309, 6800 Microprocessors

This technical support page is for discussing programming and design with the Motorola 6809, a very powerful and sophisticated 8bit microprocessor.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 03/22/2018 at 11:52 point

I'm there too :-)

  Are you sure? yes | no

mister35mm wrote 03/22/2018 at 14:05 point

Good chap!

  Are you sure? yes | no

Deny Wilson wrote 02/13/2018 at 14:54 point

FYI, there is another "c-like" compiler out there for the 6809 (specifically, the Tandy Color Computer), called CMOC. It's being actively worked on and is open source. It's here:  

From the site: "The most significant differences between CMOC and a complete C compiler is the absence of the const keyword and bit fields. Versions 0.1.40 and .41 have introduced the float and long types. (Floats are only usable under Color Basic.)"

  Are you sure? yes | no

jaromir.sukuba wrote 02/07/2016 at 19:37 point

Any news about this one?

  Are you sure? yes | no

tomcircuit wrote 02/26/2016 at 01:05 point

I just posted a project log re: C compiler. Whether software is homebrew or borrowed, a real C compiler would be a really helpful item. Unfortunately, GCC and newlib and GDB and the like are really outside of my sphere of understanding and ability. Hoping that someone with better skills can educate me!

  Are you sure? yes | no

Hayden Kroepfl wrote 07/27/2016 at 23:08 point

You should be able to just use gcc with -ffreestanding and -nostdlib. At that point you don't need to worry about newlib or anything, you would just need to write an assembly stub _start which would copy data into ram, if needed, and clear out BSS, then call main, or whatever function. 

You'll also need a linker file which would specify where each of the .code .data and .bss sections reside in the address space. 

After that objdump can turn the elf file produced into a intel hex or motorola srec file which can be burned to a ROM.

  Are you sure? yes | no

Darryl N wrote 07/08/2017 at 20:34 point

A quick search turned up this 6809/6309 cross compiler, maybe it will work for you.  I haven't used it, can't say. However, I did write 6809 assembler on a TRS-80 Color Computer using an EDTASM ROM Pak, way back in 1984 when dinosaurs roamed the earth.  :-)

"LWTOOLS is a set of cross-development tools for the Motorola 6809 and Hitachi 6309 microprocessors. It supports assembling to raw binaries, CoCo LOADM binaries, and a proprietary object file format for later linking. It also supports macros and file inclusion among other things."

  Are you sure? yes | no

Darryl N wrote 07/08/2017 at 20:50 point

Also, there's this FreeWPC pinball machine framework, no idea if it will adapt easily for bare metal.

  Are you sure? yes | no

jaromir.sukuba wrote 05/25/2014 at 09:52 point
Nice project.
As usual for computers, hardware is only the first half of work. What about software and/or some kind of OS? Do you have any plans for reusing existing software, or are going to write your own?

  Are you sure? yes | no

tomcircuit wrote 05/25/2014 at 23:46 point
Thank you!

Yes, your comment is absolutely correct! Hardware is only half of the work - for me, it's the more enjoyable part. I'm much more comfortable with electronic design, PCB layout, VHDL, etc. I think I've lost a lot of the patience and focus that it takes to be a proficient embedded coder.

For software, I have managed to re-use several items from the past; read my blog entries above for more details. Key software items that are re-used and up and running right now: Dave Dunfield's 6809 Monitor program in ROM, and the very capable Microsoft Extended BASIC interpreter in ROM.

I'm excited that another person is interested in porting the FLEX operating system to this SBC, so a longer term project is to have that up and running. I've done the low-level drivers for the SD card in 6309 assembly language, so hopefully it's a matter of merging those into the old FLEX source code.

  Are you sure? yes | no

tomcircuit wrote 03/10/2014 at 14:17 point
I suppose I could make a video - it wouldn't be very exciting...just a screenshot of running the monitor program.

Also, I'm working on getting the project files in order and then I'll push them up to GitHub and publish the link.

  Are you sure? yes | no

tomcircuit wrote 03/22/2014 at 22:10 point
All the project files are here:

  Are you sure? yes | no

ernesto.villarreal wrote 03/10/2014 at 06:31 point

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates