>I have a couple as well, and I thought it was quite descriptive of the
>processor's capabilities. I wonder what kind of neat logo we could come up
>with for the Hitachi 63C09... ;-)
You could make the circles '?'marks - for all the undocumented opcodes!
>>In hindsight, the 6809 while the best 8 processer it only has 64k of
>>memory space.
>
>So? Most (all?) 8-bit CPUs have that "limitation" -> which can be easily
>overcome with bankswitching and other techniques...
I agree that standard 16 bit 64k addressing should not have kept the processor
from becoming more widespread than it did - look at the Z80 and 6502 - both
less capable processors, both with "only" 64k and both received much more
acceptance than the 6809.
I do think that a natural progression in the 6809 family (had it continued)
would have been an integrated segmented or bank switched memory manager -
this could have been worked quite nicely into the 09 architecture.
>> Also since the only
>>common 6809 system was by Radio Shack as games machine you never got the
>>good I/O like lower case letters and a real serial and floppy drives.
>>Ben.
>
>Game machine? Hardly... the Commodore & Atari were *much* better with games
>than the CoCo ever was. Floppy drives? RS drives were the best available
>for that class of market at the time.
I 1/2 agree (with each of you) - the original CoCo (and even the CoCo2) were
somewhat limited, and more importantly packaged (CoCo1) and marketed as a cheap
home console computer. Not so much a game console (although the cartridge slot
does suggest this), but as a cheap "toy" computer (that happened to play a bunch
of cartridge games). The CoCo3 was a marked improvement, however it was too
little/too late, and as no one else had really picked up the CPU, it got the
reputation as an "oddball".
I do agree on the RS drive - the drive cartridge used a standard floppy controller
chip (and you could use standard off-the-shelf drives) and interfaced directly to
the 09 bus through the cartridge slot - much better/faster then the custom serial
drive offerings by the "other guys". But, I also think that having to use a
cartridge for the drive seems a bit goofy - why not have implemented a drive
interface native to the machine?
I designed and built my own 6809 based workstations - both the homebrew ones shown
on my web page, and a couple of custom bus/racked limited production designs for a
couple of "big" companies as in-house test platforms - These "serious" systems were
remarkably powerful for their time, and gave a truer impression of the 6809's
potential than the CoCo which hid that power beneath a flimsy and toyish looking
case, an inadaquate keyboard (CoCo1) and artifically limiting system software (for
example, the CoCo ROM's required DP to be "Page Zero" - and hogged most of it).
>How does [[ Crappy graphics, crappy sound, great I/O speeds & Unix-class
>multitasking OSs ]] == "Game Machine"???
Speaking of multitasking, there's a really nice feature of the 6809 that is
often ignored, however I used this in a number of 6809 based products that
I designed to implement very fast simple multitasking.
This feature is the "Direct Page" register! - Unlike other CPU's which use
"zero page", the 6809 has DP which means that you can place your "zero page"
at any 256 byte boundary. This register is also saved and restored during a
full interrupt, meaning that in a multitasking system, each task can have it
own "zero page". This makes for compact code (many tasks never need to use
extended addressing for memory references).
Here's an example of a ultra simple task swapper in only 5 instruction, in
which each task runs in round-robin fashion, requiring only 3 bytes in each
tasks "page" - there is no system task control blocks/tables:
; Interrupt saves all registers (can be SWI for volentary swap)
INTHND: STS <MYSP ; Save current task stack pointer
LDA <TLINK ; Get next tasks DP
TFR A,DP ; Switch to new DP :-( can't load DP directly)
LDS <MYSP ; Restore new task SP
RTI ; Load new task registers & launch
Ah - such memories!
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Vintage computing equipment collector.
http://www.parse.com/~ddunfield/museum/index.html
Received on Wed Apr 28 2004 - 14:21:02 BST