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".
Software.
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.
OS9
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.
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.
Here are the design files: the schematics
and Verilog source.
Features.
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 :)