Adventures with the 6809 (and 6309)

Yesterday I started playing with a new single board computer, freshly fitted with a 6309, both board and chip courtesy of @Revaldinho:


You’ll notice the board design is by Jeff Tranter, who used Grant Searle’s one-chip glue circuit design as a starting point. And you’ll notice the BBC Basic label: Dominic Beesley wrote a 6809 port (and also a 6309 port) and @hoglet crammed a mini-MOS into the same 16k ROM, so the machine boots to BBC Basic. (Jeff’s original boots to Motorola’s minimal machine monitor ASSIST09, and includes an extended MS Basic.)

Here’s a short program running:

And here’s a longer one - @drogon’s ASCII Mandelbrot, which comes out in about 7 minutes in this case:

Here’s the evidence that it’s a 6309 inside - test program courtesy of @hoglet:

Unfortunately buying 6309 on ebay doesn’t always net a 6309 - sometimes it’s a 6809. @Revaldinho ended up with a mixed bag but I was lucky to get one of the genuines.

What’s a 6309? It’s a very compatible licensed copy of Moto’s 6809. No, wait, it’s got hidden modes and hidden registers and extra opcodes! The thing is a maze of undocumented but solidly useful extra features. If the 6809 is the best 8 bit micro - and clock speed apart it might well have been - then the 6309 is from the future.

And Dominic’s 6309 version of BBC Basic uses the extra opcodes for faster arithmetic… although I haven’t yet run it. (The 6309 being a bigger machine, the in-Basic assembler is bigger too, and there’s not room to squeeze that 6309 assembler in to the 16k Basic+MOS build, so the 6309 Basic I hope to run before long will only have a 6809 assembler. Hope that’s clear!)


How big would a 6309 computer be with built in video and a PS/2 keyboard?

About the same as any other 8 bit micro… much depends on how you’d choose to implement the video and the keyboard interface. If you use modern microcontrollers, that’s going to be quite compact, but if you use techniques from BITD, that’s going to be about the same size as the boards we used back in the day - pretty large, if you look at systems which didn’t use any ULAs or custom chips.

One of our project ideas is to use a Raspberry Pi Pico as a peripheral to hang off an 8-bit bus, providing relatively high level functions, with its own private frame buffer and VGA output. There’s a gain in not putting the frame buffer in the 8 bit micro address space, and there’s a loss in bandwidth should the 8 bit code want to read frame buffer contents - something which a lot of games do, but serious software might not need to.

Tastes vary as to which tactics appeal to each individual, and it’s not really interesting to debate the pros and cons. If there’s something you want to build, go ahead and build it, and enjoy your hobby.

1 Like

Oh good, maybe we can swap notes. I’ve started a build of Mike Cvetanovski’s similar 6809 Max board - - just waiting for some remaining components to arrive. Hope to start building on the 24th. (6809, not 6309 - although it looks like a great upgrade, I need a real 6809 to compare against the static binary translator for 6809 that I wrote - at Index of /vectrex/6809sbt )

1 Like

Ah, the DS1249 non-volatile SRAM is an interesting fit there - can do the job of both RAM and ROM, once you’ve managed to bootstrap.

Yeah, it’s an old trick. I used to do something similar with my 6809 second processor for the Beeb - I’d write the 1K of tube code into one of those battery-backed rams in a Beeb rom socket and transplant it into the 6809 to bootstrap it…

1 Like

Ohh, that 6809 BBC BASIC looks like another nice piece of software to port to my FPGA 6809 system… another autumn project.


1 Like

Bit of an update - the software adventures continue, see @hoglet’s thread over on Stardot:
6809/6309 SBC running BBC Basic

We’ve got discussions going on about flow control and the serial port - these are likely to feed into a successor single board computer design, less minimal but still retro, still 6309, and still running BBC Basic. Hopefully we’ll look at other operating systems too - several mentioned on Arto Salmi’s page of resources:
6809 Emulation Page.


(Our preferred USB to serial adapters use FTDI chips, which will send up to three further bytes after RTS has kindly asked them to stop, and at high baud rates this is resulting in overrun. A better UART might help, but there’s work to do on the software side too.)

1 Like

I have a 6809 based RC21014 setup. At the moment the boot ROM is Cubix, but supporting ROM BASIC as well might be interesting I guess.

Video on a 6809 btw can be pretty compact. At least on a 6809E. The SAM and 6809E combo plus a little bit of glue did your video, memory interfacing and some of the glue for everything else. There’s not a lot of chips on a Dragon32 main board when you factor out the keyboard, cartridge and I/O glue.

PS/2 keyboard bitbanged is less electronics than a matrix keyboard scanner, but a bit more interesting to code 8)

1 Like

I think the SAM chip can also be used with static ram, that would speed it up a tiny bit as you
don’t do refresh. I suspect a PS/2 keyboard would break lots 6809 software, as the 6809 was designed
for games rather than apps.
CP/M while a primitive OS, was a real OS that had ample memory 48Kb+ and good sized floppy disk and i/o for a printer. You did not have to hack together a system to support a DOS like many
8 bit machines of that era did.

I don’t t think It actually makes a difference if you use SRAM as the SAM video and refresh usually live on the other half of the bus cycle to the processor (akin to the 6845 and 680x/6502 pairing).

FLEX is a bit weird, although it did get some things right that CP/M messed up - like being able to move file systems between machines. Flex for 6809 even had heirarchical file system addons. OS/9 on the other hand was a serious RTOS and mini Unixish system way better than any of the usual off the shelf Z80 suspects.

On the keyboard side Flex, Cubix, OS/9 all have input interfaces much like CP/M did, so it’s easy to plug the PS/2 keyboard into the system. For old games machines there are some much cleverer microcontroller based interfaces that fake the Tandy COCO keyboard one side and have PS/2 the other.

1 Like

Another update - @hoglet has moved forward, with various mini-meetups to discuss ideas, and produced a schematic and board layout for a much more capable single board computer: the SBC09. It’s not quite final yet, but Dave has breadboarded the heart of it for testing:


The main leap forward is at the bottom right of that photo: four LS670 chips, which act as an MMU. Like all the other parts in the design, they are presently available and at reasonable prices.

The MMU can act in two ways, software switchable. (Edit: I previously thought it would need (re)programming of the two GALs, which you see at bottom left and top middle, with labels on.) One scheme is 8k pages, which needs all 4 '670s, and the other is 16k pages, which only needs two. In either case, the 64k address space seen by the processor is split into equal size slots, and any similarly sized aligned page from the ROM(s) or RAM can be mapped in. (That includes mapping the same thing in more than one slot.)

Whatever is paged into each slot, the 768 bytes from FC00 to FEFF are always I/O addresses, not RAM or ROM. That’s rather like a Beeb.

There are two ROM sockets in case the only ROMs available are low capacity.

There’s a bit of cleverness to ensure the system can boot, because the MMUs come up in an indeterminate state.

There are various ways to partially populate the board for a subset of the functionality. Here’s a not-latest iteration of the not-final board design, which physically fits a Eurocard slot:

The connector on the left is an expansion bus which should be rather generally useful, although it doesn’t expect external devices to drive the address bus. (We’d hope to use this bus to connect add-ons such as a VDU engine or Pi-based coprocessor.)

A subsequent revision has tidied up the right hand end, which has an SD Card interface and two serial ports:

Edit: the latest schematic can always be seen here.

Dave has benchmarked this breadboarded implementation: with a 6309E clocked at 2MHz, running Dominic’s port of BBC Basic, it performs about 30% faster than a BBC Micro (2MHz 6502). But Dave was able to clock up to 6MHz, which came out at about 8MHz equivalent - twice the performance of Acorn’s fastest 6502.



Where did you get the 670’s? Will it run OS/9 level 2. Looks good.

I’m hoping the machine will be suitable to run any of the '09 operating systems, and it should be fun to bring each one up.

Mouser, Digikey, and Farnell all have the SN74LS670N in stock - perhaps surprisingly, for quite an old and specialised part, it still seems to be current.

Checks digikey, oops I was thinking of the wrong part. 74ls610 … 74ls613 memory mapped units. Ben.

Rochester Electronics has a large stock of 74LS610N parts:

The only problem is you would need to buy a minimum of 50 pieces.

One 74LS610 ~= Twelve 74LS670 in terms of capacity

1 Like

Very nice development on the 74ls670 based MMU addition, and i see those register files are damn quick too, so a 6309 machine can run pretty fast potentially.

8k is the absolute maximum page size though for an os9 machine, and all the serious ones used 2 or 4k. Of course nitros9 is still 8k pages only because of its coco3 roots, but perhaps one day we’ll get a port back to 4 and 2k sizes.

I have a handful of mc6829s here, and there’s a vendor on ebay currently… that’s a viable alternative at the moment too…


Another option would be a FPGA build, that way you could use modern speeds with the system. Sadly I have never been able to get a version to work for myself.

What I think is most interesting is how the design would accomplish task switches - that’s where the nuts and bolts of these things tends to get entertaining.

Sounds like there’s no dedicated trampoline space, so you end up with an 8k ROM page mapped into every task to allow switches. Fuse and autoswitching on vector fetch are neat alternatives.

  • Hmm. Had a look in the repo. Seems Hoglet’s been doing a lot of updates since the 4x4 register file approach and now it’s a single small SRAM and a lot of CPLD (not quite fathomed how the map writes work, or OS->task returns). Interesting.
1 Like

Some how I suspect a ‘fuse’ type flag is set before RTI instruction, so that the new MMU
map at the finish of the RTI (task switch on timer irq or SWI) is the maping for the new task.