The 6809 board for Apple 2

I never had a 6809 anything in my life. Frankly I didn't even know that the TRS80 Color Computer was using it.  But I heard good thing about it lately. Some even claim it's the best 8 bit CPU ever. The "best" part is a matter of opinion and from what I've learned it is more 16 bit than 8 bit. I also could never understand why 68000 was considered 16 bit. IMHO it the registers width that matters, not the external bus, but I'm getting off topic.
So I decided to make a clone of the Stellation Two "Mill" card. I don't own a real one and only have a manual with schematics. The original plan was to build an exact replica: all the 74LSxx parts are still available, but then it was suggested to include the memory remapping for OS9 which was originally done by a daughterboard with a TTL prom. These are rare, expensive, slow, power hungry and hard to program. A GAL is an obvious choice, but a CPLD - a GAL on steroids - is even better. Apart from the memory translation it can replace some glue logic to minimize the chips count.  So the result is smaller than the "real thing".

board photo


The first thing to try was the demo from the floppy that was supplied with the board and the DSK image of which is available in all the usual places. That didn't work in my 2e enhanced for a simple reason. The 6809 fetches the reset vector from the last 2 bytes in memory ($FFFE-FFFF) just like the 6502, but interprets them in a "big endian" way. The "normal" autostart ROM has $40, $FA there which means "go to $FA40 at reset" to 6502, but it becomes $40FA to the 6809.  So the demo patches the RAM at $40FA and everything is good. The enhanced 2e unfortunately has a different reset vector that still points to ROM if read "backwards". Hard to patch. Sure one can switch to the "language card" RAM, but the demo came on a ProDOS floppy (image) so it was not trivial.
Fortunately I did implement the memory remapping that was allegedly used in the OS9 version. The same as used on a z80 SoftCard. So I moved a jumper to select memory translation and changed a couple of lines in the BASIC program that starts the demo. Now it was happy.
Ideally I wanted to be able to boot OS9 but unfortunately the image floating around is broken. The 6809 is started with a reset vector pointing to uninitialized memory with an obvious result.
Still I wanted to make something work beyond the simple counter demo. I assembled a tiny 6502 program to handle i/o and communicate with the 6809 via 2 locations in the shared memory.

The 6502 interface is built with the ACME assembler just because it was handy.

The 6809 Tiny BASIC is assembled with the A09 AKA "sbc09" and came as an example source with the assembler.

 I BLOADed the BASIC to $1400 in Apple space which is $400 to the 6809 with remapping enabled. I then BRUN the 6502 interface. It load to $F00 and also sets the reset vector for the 6809. With remapping $FFE becomes $FFFE to the 6809.

The Technical Brief  from the Stellation Two "Mill" dating back to 1980.


The Tiny BASIC is great to make sure the 6809 works at all, but the practical value is dubious. A much more interesting thing would be to run OS9 - a rather advanced OS for its time as I understand. The information was not easy to find at first. I knew that a daughterboard with a ROM was used to remap memory for OS9. The only source I could find claimed that the memory map was the same as used on z80 SoftCard. That made some sense - 6809's space starts at $1000, above 6502's zero page, stack and screen memory. And the 4K of I/O at $C000 is cut out. Unfortunately not everything that makes sense is true.  The real remapping for Mill OS9 is different.
The first 32K of 6809 logical address space indeed maps to $1000 up to $8FFF of physical memory.
But then the top 12K of 6809 logical address space maps to $9000 up to $BFFF - that's where the boot loader places the OS9 image. The 12K of top Apple's RAM - "language card" maps to $8000 to $AFFF, as the 6809 sees it. The I/O space becomes $Bxxx and zero page becomes $Cxxx.

Changing the Verilog to reflect this correct memory map made all the difference. Instead of going to the never-never land the 6809 now boots OS9. Listens to the Apple's keyboard with a little help from the 6502 that keeps running. And reads the directory of the OS9 floppy when asked nicely.

booting OS9

Potential hardware issues.

 While searching for any info on the Mill card and OS9 I came across a few reports that the board worked in A2+ but not in A2e. This prompted me to look for the probable cause. 
There is an interesting    how to do DMA on Apple 2e.
Looks like the Mill violates two constrains:

1. Address should be applied to the bus 30 ns after the DMA request goes active.
This is clearly not the case in the real Mill card - the /DMA and addresses are driven by the same chips, at the same time. It can cause bus contention problems.
Things a little better on my board - the /DMA signal is driven by a fast CPLD so it appears a little earlier than the addresses, but not by 30 ns. If it becomes a problem, a little delay could be added to the address buffers /EN lines. But again, if it works on the real Mill, my clone should be even less problematic.
2. The second issue is that according to the document the data should be only driven after 130 ns after PH0 goes high on the 2e while it's OK to drive it at any time on the 2+. Nothing is done about it on the real Mill. My board has space for 2 extra chips. Very easy to add one 74LS00 to follow the guidelines. If it becomes a problem.

extra logic

Here are the design files: the schematics and Verilog source.


As the saying goes once you document a bug, it becomes a "feature". So here are some features of my board.

The original Mill board has the bit 0 of the control register wired to the Apple's IRQ line so that a 6809 program or even a 6502 program can set this bit and cause an interrupt.  I didn't understand why this was needed and didn't implement it. I still don't understand. Clearly the  OS9 doesn't use this interrupt. Neither does the simple test that came with the Mill. There is a lot of unused logic in the CPLD - the limiting factor was the available pins. Once it became clear that the Q3 signal from the APple buf is not needed, I cut the trace to pin 6 of the CPLD and programmed it to assert IRQ on this pin when the control bit 0 is set. So one can use a wire to connect this pin to the slot connector but I didn't try it for a simple reason that there was no need.

One hicup that is not exactly a "feature" - often OS9 does't boot after a power up reset. A CTRL-reset and "6 CTRL-P" boots fine. So probably not a big deal.

There are 4 total memory maps. With a jumper to the right it is either no memory translation or inverted A15, just as the original Mill. With a jumper to the left it is the OS9 mapping. And if you reset bit 7 of the control register the A15 bit will be inverted and then OS9 remapping will be applied. Definitely to be avoided. Would be easy to reprogram the CPLD to eliminate this crazy setting, but why bother if the original board must do the same.

What is it good for?
Good question. All I know is that it does run 6809 code from the Apple's memory. There are other ways to run 6809 code on actual hardware: for example a Color Computer on e-bay won't be any more expensive.  I made this card mostly because a few people asked for it. If I were to design a 6809 co-processor board with no need to be compatible it would be more like the PCPI - running faster than the Apple's 1 MHz with it's own memory. Maybe even use an MMC/SD card as a "hard disk".
With only 10 boards built one can only imagine the price on some future auction :)