6809 Single Board Computer project

[DDunfield]

I too had a long love affair with the 6809 which culminated in the creation of my "D6809 Portable" which can be seen at:

  www.classiccmp.org/dunfield  (or google "Daves Old Computers")

Scroll down to the "Homebuilts" section and check out "D6809 portable".

I wrote a *LOT* of code for the 09 and have made a number of resources available which might be useful to anyone playing with this part:
NOTE: Any tools mentioned run under DOS, but work fine under DOSBOX for those systems which cannot naively run 16-bit DOS executables.

D6809 simulator (available under "D6809 portable" page)
  Includes MC6809 (obviously), system ROM, video display, keyboard, disk controller/drives, serial ports.
  Default ROM is my CUBIX OS, but you can substitute your own.
  Simulator includes a debugger with disassembler, breakpoints, single-step, traceback, memory/register editors etc.
  NOTE: To experience running the actual D6809 system, the simulator emulates the delays inherent in starting/stepping/reading floppy drives.
            If you get tired of waiting for it, use the '/D' command line option to disable drive speed emulation which speeds things up greatly!

CUBIX source code and porting package (available under "D6809 portable" page)
  Everything you need to port CUBIX to your own 6809 system.
  CUBIX is a simple command OS (DOS for the 6809!), but does have some nice features, over 100 system calls implemented via SWI.
  It includes a few applications:
  - Couple of editors
  - C compiler
  - Assembler
  - BASIC interpreter
  - Micro-APL interpreter
  - Micro-FORTH (unique native-compiled implementation)
  - 8080 simulator
  - A number of other utilities
  You can try it out using the D6809 simulator above.

Micro-C cross compiler for 6809 (Available in "DOS widgets" section of main page - "Embedded development tools" section)
  This is a PC hosted cross compiler for 6809 embedded systems. Reasonably complete, has a decent library.
  Not tied to any system/hardware, easy to get code up and running on "bare metal".
  NOTE: the 6809 was the first/original target for my Micro-C toolset.

ASM09 cross assembler for 6809 (included in Micro-C/09 or in "XTOOLS" package)
  Simple and straightforward cross assembler. Outputs Motorola (S18) or Intel download records.
  Has a useful macro preprocessor etc.

MON09 software development monitor (same place as compiler, "XTOOLS" package)
  This is a ROM monitor for the 6809 which includes memory dump, memory/register editors, disassembly, breakpoints, single-step etc.

HDM09 hardware development monitor  (Available in "DOS widgets" section of main page - "XTOOLS" package)
  A very simple monitor  (memory read/write, loop read/write etc.) which requires NO RAM.
  All you need working in a ROM and UART (and you can use UART polling to debug that).

DOSBOX DOS emulator (Available in "DOS widgets" section "Third party files section" near bottom)
  My customized version of HAL9000 Megabuild DOSBOX which I use to run DOS code under Win7/64.

Enjoy,
Dave

[grantb5]

Hi Dave.  Great to have a legend around here.  I'm pretty sure I still have a compiler of yours around here someplace.

[cjs]

Much like the Z80 was an improved 8080, the 6502 was an improved 6800. The 6809 is largely an improved 6502, adopting the 6502 improvements and adding more on top.

Not in the slightest. As others have pointed out, the primary feature of the 6502 was immensely lower cost: the 6502 was released at $25 when at that time the 6800 was selling for $175. (The 6800 was quickly reduced to $69, and eventually to $39, but by that point the high-volume users of home computer microprocessors had already settled on the 6502.)

The way to reduce cost was, of course, to remove things to get a smaller die, and the 6502 was generally a deficient processor compared to the 6800. Major reductions in functionality included:

• The second accumulator ('B' register) was removed.
• The stack pointer was reduced from 16 bits to 8 bits, leaving the stack to live in page 1 (0x100-0x1ff) only. That particularly hurt if you wanted to do multiprocessing.
• The 16-bit index register was replaced with a pair of 8-bit index registers, making life difficult if you wanted to, e.g., copy and/or transform more than a 256-byte chunk of memory.
• Interesting bugs were introduced, such as a broken ROR (rotate right instruction), which was rapidly fixed, and reading the wrong high address byte for JMP if the JMP address crossed a page boundary (eventually fixed in the 80s with the 65C02).

The 6502 did have two improvements over the 6800, though. One was the ability to index based on an 16-bit address in the zero page with the Y register added to that, making memory-to-memory block transfer/modify operations easier (so long as they were less than 256 byte blocks!). This was done with the 16-bit index register in the 6800 but, in what in retrospect was a major design deficiency, there was only one index register so you had to save the source address after every load of a data byte in order to load the destination address, and then do the reverse to get the next source byte. The other 6502 improvement was much faster interrupt processing, perhaps the fastest of any 8-bit CPU. Much of that was due simply to saving a lot less on the stack when an interrupt occurred.

The 6809 was a great improvement over both the 6800 and the 6502, but was based almost purely on improving the 6800, taking almost nothing from the 6502. For example, the block copy inconvenience described above was fixed in the obvious way: add a second 16-bit index register, thus also making this operation faster than the 6502 because it now took fewer memory loads and stores rather than more. They also added a "fast" interrupt which greatly reduced interrupt processing time by saving fewer registers, though it still wasn't as fast as the 6502. And multiprocessing became even easier and better with the careful attention they paid to supporting position-independent code, though that wasn't actually the intent of that feature. But all this made it a great platform for OS-9, probably the most sophisticated 8-bit operating system ever.

Though the 6502 won the battle as far as quantity, the 6809 was still heavily used in areas where the volume was lower and the extra hardware cost was made up for by easier software development, such as arcade video games and embedded systems. It's without question one of the best if not the best 8-bit CPUs of the 1970s and early 80s, and unless you need 6502 compatibility for some reason you'd generally be happier today using a 6809 in your retrocomputing projects.

I've not programmed a 6809 since the early 80s, when I had busied myself putting together an OS-9 system based around a Radio Shack Color Computer 3. Unfortunately, events precepitated by the untimely death of my father put paid to all my 1980s computing plans and the CoCo and its peripherals were lost along the way. But I'm getting interested in this again, and I too have started to make plans to build a 6809 system, though not with hardware as sophisticated as the rather nice SBC that started this thread. My intent is to explore what might have happened in an alternate reality where LISP instead of BASIC had become the common high-level language of microcomputers in the 70s.

[grantb5]

I find it interesting that so many people are building up "PC's" using these 8-bitters. I come from the opposite angle where they were used in embedded systems such as synthesizers and other music gear. I don't know of any that used the 6502 , and in fact I can't recollect any 6800 based synth's either, but I'm sure they are out there.

The 8-bit CPU's I see a lot of are Z80 (which I know little about), the 6809 was widely used, the 8051 family even more so (being a micro-controller and all) and the Hitachi 6303. I guess it could be argued that the 6303 is a descendant of the 6800, but as a microcontroller.

I wish the synths I was working on now (for the purpose of changing features) were 6809-based, but most of them seem to be 6303. I certainly enjoy working on both the 8051 and 6303 synths, but find myself cursing at all the code it takes to do something that would be so natural and compact in the 6809.

[cjs]

I come from the opposite angle where they were used in embedded systems such as synthesizers and other music gear.

Yes, right! That was the other major application for the 6809 that I was thinking of but forgot to put in my post. It was used in a very wide range of instruments, from the various Ensoniq synthesizers and samplers (cheap but very featureful—I loved my ESQ-1) to the midrange (Oberheim) to the high end (PPG Wave) to the super-high-end (Fairlight CMI Series II).

...and the Hitachi 6303. I guess it could be argued that the 6303 is a descendant of the 6800, but as a microcontroller.

Well, I'd say it is a 6800. It differs from what I typically think of when I think of a "microcontroller" in that it's designed around having a large (for the time) address space and the capability to easily add a lot of external peripheral logic; unlike most microcontrollers it's perfectly suited for a "real" computer. There were various other "microprocessors in microcontroller garb" as well, such as the 6508; typically these just added a bit of RAM and a few I/O pins (though the 6303X and 6303Y really went all out, expanding to 64-pin packages with serial ports, PLLs, the whole bit). But except for those where they removed pins for the sake of a smaller package (6507), these were all perfectly usable as the CPU of a "real" computer, weren't they?

And for something like an arcade game or a digital synth with a sequencer, you'd need that address space and ability to integrate with a lot of external hardware.

I wish the synths I was working on now (for the purpose of changing features) were 6809-based, but most of them seem to be 6303. I certainly enjoy working on both the 8051 and 6303 synths, but find myself cursing at all the code it takes to do something that would be so natural and compact in the 6809.

Ya. The 6800 was pretty great for 1974, but there were a few mistakes they made with it (lack of a second index register!) that really hurt. But until the late 70s there weren't really any microprocessors that I can think of that didn't have those problems. The early microprocessor manufacturers did have the example of the PDP-11, which they gleefully used in the late '70s, so I can only assume that it was just lack of enough transistors that caused them to scrimp so much on registers and addressing modes in earlier days. (Though maybe the 8080 guys were just perverse. They stuck in a more reasonable number of registers but then made everything a pain to use.)

[grantb5]

I have a "handheld" Yamaha RCX1 remote control unit that has a 64-pin shrink DIP HD6303YP. I was kind of surprised to see such a large device in such a small, simple unit. Especially since the DX7 family uses a more basic 6303. 

But to bring it more on-topic, my Yamaha MEP4 has a 6809 in it.  Ensoniq used the 68HC11 in some keyboard controller applications. I was heartbroken when the HC11 was released and it wasn't based on the 6809. Then the HC12 was the final blow for me and I was done with Motorola. 

[guenthert]

[..]
My intent is to explore what might have happened in an alternate reality where LISP instead of BASIC had become the common high-level language of microcomputers in the 70s.

I can somewhat relate, but think that LISP might be a bridge too far for 8 bitters (even though I know that some implementations did exists, e.g. Inter-LISP, but I can't help wondering, what you could do with them).  Much later, in the early nineties, the CLISP project managed to implement a pretty good Common Lisp compiler on various hosts, starting with Atari ST (might have been the late 4MiB version).  Now Common Lisp is much more demanding than earlier, simpler members of the LISP family, but still, I fear a 64KiB address space is no good match for a language with automatic memory management.  FORTH might be the more natural choice for 8 bitters and certainly easier to implement.

[cjs]

[..]
My intent is to explore what might have happened in an alternate reality where LISP instead of BASIC had become the common high-level language of microcomputers in the 70s.

I can somewhat relate, but think that LISP might be a bridge too far for 8 bitters....

But we have evidence otherwise: Logo is a very LISP-y language (don't be fooled by the surface syntax changes, which actually made it harder rather than easier to learn after the first few baby steps) and was released and used on a broad range of machines.

...but still, I fear a 64KiB address space is no good match for a language with automatic memory management.  FORTH might be the more natural choice for 8 bitters and certainly easier to implement.

Well, almost every BASIC had automatic memory management, and certainly all the popular ones did, so I don't think that's an issue.

Also, 64 KiB is sheer luxury; ideally I'd like to have a minimal version that runs on a system with 4 KiB of RAM and no ROM, just like the original 4K Micro Soft BASIC.

[intabits]

Someone who saw my post (#53) on the Compacta Uniboard in this thread, contacted me regarding using my photos on a Uniboard web page that he is creating.

I had found and scanned the documentation by that time, and made it available to him, but forgot to also post links to it all here. Until now.

More images added to imgur:-
https://imgur.com/gallery/lgEpyMm

I've uploaded the docs  (the documentation contains some duplication) to:-

https://www.filehosting.org/file/details/829492/Manuals.rar

https://www.filehosting.org/file/details/829493/Page%20Scans.rar

https://www.filehosting.org/file/details/829494/Schematics.rar

https://www.filehosting.org/file/details/829495/ROMs%20n%20stuff.rar

The web page he created for the UNIBOARD is:- (not sure how complete/ready it is)
http://www.sardis-technologies.com/oth6809/uniboard.htm

[ned_head]

I have seen a reference to the earliest Fairlight CMI (the "Quasar") that claimed to have two 6800's running in tandem but I'm not really sure if it did. (I thought it too was 6809-based but I could be wrong as it's design was started back in 1976). Certainly, all the subsequent models had pairs of 6809's as the main board (running OS-9 Level II) as well as a 6809 for every channel (known as "Channel cards"). The Series III had in addition, a 68000-based card called the "Waveform Supervisor" as well as the 6809-based main CPU and the many channel cards.

[grantb5]

Are the Fairlight schematics or service notes available online at all. I'm guessing if it's anything like the Rhodes Chroma (also 6809 I think), the docs are a binder full.

[oPossum]

There is a service manual with schematics excluding the voice board.

[oPossum]

http://www.synthzone.com/midi/fairlight/CMI_IIx_Service_Manual.pdf

[ned_head]

The IIx was a great machine. The Series III had the winchester hard drive which sort of stung its "road quality" attribute but made it a far more useful studio machine..
https://www.manualslib.com/download/1192332/Fairlight-Cmi-Series-Iii.html

[schofiel]

Ron,

I've also come across your SBC for the 6809P - it's quite superb, a really nice design.

Are you using Eagle?

Are you considering releasing the project on Github/Lab?

Have you made any progress on your layout?

Finally, (sorry for all the questions), are you going to release your GAL equations?

I am very impressed with this work - thanks!

Sincerely,

Rob Schofield