I had a Coco 1 and a Coco 3, with the OS-9 operating system you could run C and Pascal compilers as well as use BASIC09 which was like a modern bytecode interpreted language (Python). The 6809 stands out because it was designed to support compiled languages, shared libraries and such. It not only had the right addressing modes but it had just enough registers that code generation was straightforward.
When I replaced my Coco3 with a 286 machine I switched to hardware that was more than an order of magnitude faster but MS-DOS was a big step back from OS-9.
Lately I have been obsessed with the lost 24-bit generation of micros and was quite delighted to discover the eZ80, would be nice to see the 6809 follow the same route but Motorola was too committed to the ultimately doomed 68k.
I mean, was 68k really "doomed"? Millions of machines shipped with it, it went through like 6 generations (and then ColdFire), and it's still used in military hardware with new chips made for that industry, and its existence heavily influenced everything about the Unix environments & protocols we use today.
It was a great ISA (though clearly completely different from the 6809), and these days big endian looks like a serious anachronism.
Wasn't it the VAX that set the precedent for all the "32-bit" machines ever since?
Every company that invested in it, however, had to either go out of business or switch to another architecture, usually the first. Apple and Sun Microsystems survived. Fragmentation, with the Apple Macintosh, Amiga, Atari ST, Sinclair QL, etc. (all similar machines that struggled with cost-performance tradeoffs in different ways), didn't help.
The BBC Micro developers probably had more space to really think about how to make a home computer and looked at many architectures and came to the conclusion that the 68k line punched below its weight. People in the early 1980s didn't see that one of the greatest rugpulls in computing was coming and were blindsided by IBM "doing it again" by maintaining long-term software compatibility with the 8088 and derivatives the way they did for the old 360... Companies that invested in the x86 didn't regret it, though many of them were crushed by an increasingly competitive market.
I absolutely agree that Motorola fucked up bigtime with the 68k->88k->PPC transition. They listened to the pundits who said the CISC ISA couldn't scale, and then Intel proved that (mostly) wrong but it was too late for 68k/ColdFire then. The rug-pulling actually is probably in large part responsible for both Atari and Commodore just packing it in, and led to Apple being in the wilderness for a decade as they did the first of 3 ISA transitions for the Mac.
Also yes the 68k was clearly a dog when it came to interrupt responsiveness and made no sense in home computers or video games, at least not until the '020.
It was meant to be a bargain VAX. And that's why I say it was influential. A whole generation (X) of us grew up who could never hope (or care) to touch a VAX, but we had Atari STs, Amigas, etc at home, and were shelling into SunOS 68k boxes for fun or school etc. It lasted quite a while after VAX was a done deal, too.
To me 68k was the Unix workstation and hobbyist market and defined 32-bit ISAs as well. I never touched an x86 until I could run Linux on it. I've never learned or written x86 assembly seriously in my entire career despite writing (and enjoying) 6502 68k, ARM, MIPS, RISC-V, others
Outside of the UK, ARM didn't play a role except for in some embedded stuff. Obviously that changed :-)
We need to remember that everyone -- not just Motorola -- thought CISC was a dead-end by the late 1980's. Even Intel!
And we also need to acknowledge that everyone was RIGHT! Intel ultimately threw billions into keeping x86 competitive, and they seem to have finally hit the wall now with performance per watt measures, which is what cost them Apple's business and is now driving Microsoft to ARM.
>Also yes the 68k was clearly a dog when it came to interrupt responsiveness and made no sense in home computers or video games, at least not until the '020.
In what world? The interrupts were very fast, taking just a few cycles, and the behavior was deterministic.
This is why they were popular in realtime applications, and remained so for decades.
Back in the day, they were famously used in e.g. the Eurofighter Typhoon.
The worst case interrupt latency on the original 68000 is pretty terrible? The instructions take ages and the interrupt handling mechanism adds additional delays.
>The worst case interrupt latency on the original 68000 is pretty terrible?
It has a fixed cost of 44 cycles. Is this somehow bad?
I would call it extremely tight.
edit: 44 cycles... after the previous instruction finishes. Some instructions (infamously slow division, and many-reg movem) can be slow. Worst case is what matters for realtime, but it is still under 400 cycles.
In home computers and video games? Holy crap ... compare that to the 6502. Maximum 13 cycles, including the execution of the instruction that initiated it, and the return from the interrupt...
And yes, obviously that's easy when you only have 3 registers ... But this has a serious real world effect for things like video games.
Atari ST (68k at 8MHz) had other issues that made it sluggish. It is no Amiga.
In most scenarios, most interrupts aren't going to interrupt divisions, as most instructions aren't over 16 cycles[0], thus most interrupts will not be much longer than 44 cycles. In microseconds, a non-issue for a microcomputer.
Realtime programmers of the time had predictable behavior, and could simply avoid using the specially long instructions (movem and div) altogether if they needed to bound latency below the upper limit. Performance isn't as important as meeting hard deadlines.
It was simply phased out at some point, like so many other processors. I think it's wrong to say it was "doomed".
For one of the minicomputer systems I worked with until around 1995 all the interface boards used m68k CPUs and were running their own little operating systems. This made the whole mini quite efficient - all the intelligence in the peripherals meant that a lot of data transfers could be performed independently of the main CPU.
Funny fact: Motorola didn't ship 68040 CPUs over 40Mhz because they didn't think customers would tolerate even a small heat sink and fan combination being required for the chip.
*looks at massive heat sink and fan on my desktop system...
About 35 years ago, I did some embedded development on a 68k platform running OS-9 (ported to 68k from 6809). I was really impressed with the POSIX-like environment, but thoroughly disgusted with the very poor documentation. I found that I had to write a lot of stub code to fully determine and understand the behavior of the system calls.
This was after I had purchased and fully digested the only documentation I could find: "OS-9 Insights"
Me too! I remember laboriously typing in the demo program from "TRS-80 Color Computer Assembly Language Programming" and watching it bubble sort the text on screen by directly accessing video memory.
So AIUI this is explicitly trying to be smaller than 32-bit RISC-V. And I can see that in the abstract, but I gotta ask: How much does it matter? My very uninformed impression was that with current fabrication, RISC-V is already more than small enough (on-chip surface area) and cheap enough ($) that there's not a lot of market for anything underneath it. Am I mistaken?
(To be clear, I'd like it to work, just questioning the economics.)
I find it pretty scary that C compilers target the 8051 but I also think C is a terrible waste of the AVR-8 (who needs to move the stack pointer around meaninglessly in a simple program where recursion is a problem and not a solution? Probably the best thing that happened in the 1970s was that Microsoft BASIC beat Lisp and Logo, otherwise a generation of people learning to code would have been victimized even more by bad Fibonacci implementations) which I only indulge in because I can port C code to a bigger microcontroller.
Have you ever played with the Parallax Propeller MCUs? (I and II). 32-bit, but very "retro" feel to them. And an odd and interesting multicore architecture.
Unfortunately they've had a bad streak in terms of getting a proper GCC or Clang toolchain targeted towards them. The developers of the chip are focused on their own weird structured BASIC-Assembly fusion ("SPIN").
They state this as their reasoning so there must be merit in pursuing a smaller footprint:
> Current industry trends are to adapt 32-bit RISC IP for microcontroller use, however their large 32x32 register files and loosely encoded instructions limit their absolute minimum footprint. So with the goal of a creating a performance and compact microprocessor IP, we need an 16-bit instruction set architecture (ISA).
Not every application requires 32 bits and as you can see from some of the use cases, there might be a dozen of these in a design so minimal footprint is important.
Some 8-bit cpus allow combining some registers in pairs. Giving 16-bit values from otherwise 8-bit registers. Or have a few dedicated 16-bit registers.
Couldn't the same be done in a 16-bit architecture? And cut the # of registers. Like 16x 16-bit registers, optionally used as 32-bit pairs (8 of those).
None of this says anything about external memory sizes or such.
Btw: RISC-V has an "-E" flavour which cuts the # of registers in half from 32 to 16, but is otherwise identical. There's even some (unofficial) RV16 candidates out there.
I think part of the goal for Turbo9 is to be used in the real world. By using an established ISA and maintaining binary compatibility, their CPU can be targeted by any tooling built for it over the past 40 years. Think of it: all existing documentation, code, compilers, assemblers, know-how, even existing compiled binaries!
As soon as you create your own architecture, you're essentially a toy. Nobody will want to rely on your half finished C compiler for it, or your unmaintained patchset for LLVM, or be willing to learn verilog just to fill gaps in documentation.
Even something as "simple" as changing registers on RISC-V will break most tooling and make most existing documentation impossible to rely on. Resulting in essentially a new architecture with a confusing name.
Being a toy isn't a bad thing, it just wasn't their goal here.
that there's not a lot of market for anything underneath it.
You'd be very mistaken. 4-bit MCUs are still found in places where you wouldn't even expect an MCU, and the 8-bit ones are numerous in ultra-high-volume highly cost-sensitive applications. Products that use COB-mounted sub-$0.01 die.
Kinda awful because it doesn’t have 24 bit index registers so writing programs that use the whole memory is a hassle. I remember people complaining a lot about messing with the segment registers in the 8086|8088 which was worse than having a flat memory space but really wasn’t that bad, you could always find a memory model that worked for your application and I really enjoyed writing 80286 assembly.
8086 doesn't support longer pointers either. You always had to load a segment and then an offset as two operations, no different from loading the DB (data bank register) in the '816.
The DB was not as flexible as segment registers, and there was only one of them, but you could easily load them both and then get a 16 bit value into the accumulator. Index registers also crossed bank boundaries. In contrast to the 8086, where the segments were a bit of a jail.
Mind, that's a feature in that you could write a multiprocessing system without memory protection, and have code reasonably safe from accidentally stomping on other areas (for example, if your C compiler compiled to the Tiny model, a rogue C ptr shouldn't be able to break out, obviously assembly could do anything).
Regarding the 68K and larger address space, on the original Macintosh, you were unable to request a single block of memory larger than 32K. So, like the Genie, unlimited power -- itty bitty living space. Sure, pointers could access anything, but at a system level, you weren't going to get a large enough chunk of memory, all at once, to warrant a larger pointer, so you were working with almost "virtually" segmented memory anyway.
On the IIGS, based on the 816, they used a similar memory manager. The segment manager on IIGS is really pretty cool. It's 2.0 of what the Macintosh had.
Wow I didn't know Hitachi made anything outside of their superh/sh CPUs (which also do a mixed encoding scheme) I'm guessing they derived it from these guys and appeased the risc crowds. Off topic but I wonder what ever happened to that j-core project. I have a feeling understanding/learning both the turbo9/6809 along with the j2/sh2 would make for a great comparison.
Interesting that there is no cache (instead it's using a prefetch queue).. "Implement multi-cycle to reduce area / power", I guess it's not one-cycle per instruction, so maybe not needed.
Well, where is the superscalar variant? :-) At least on an FPGA, there would be very diminishing returns for doing it. Even bypassing has bad effects on fMAX.
that convinced me I could build a useful custom processor but it also got me to see how complex things get when you go pipelined, superscalar, depending on a cache, etc.
The CoCo 3 had a custom chip which provided an MMU and a few other features, but the maximum amount of memory it supported was 512KB. Page size was fixed at 8KB.
Yes, you are right. I am confusing that with some other system. Sadly, I do not currently have a Coco 3. The details fade with lack of use...
I do recall, I used 2 pages, 16Kb RAM for my projects.
Page one, run main code and page in subroutines as needed. I could put graphics data under the main code too. The draw routines got called in page 2, meaning page 1 could go away for a while.
It worked well. Maybe it was the Atari featuring different page sizes.
How are people putting 2 Megabytes into the machine? I never did one of those upgrades, though I did add a 6309.
The target applications are SoC sub-blocks or small mixed-signal ASICs that require a compact and efficient microprocessor for programmable high-level control. There are many 32 or 64-bit RISC-V or ARM cores that try to fill this niche, but prove to be inefficient solutions given many of these applications only require 16-bit precision.
Unfortunately 6502, 8051, Z80, and various other architectures from a similar era already fill that niche.
The 6809 is one of the architectures from the era of the 6502, 8051, and Z80. Specifically, it's Motorola's response to the 6502 eating the 6800's lunch, the same way the 8086 was Intel's response to the Z80 eating the 8080's lunch.
I'm guessing they picked the 6809 because it's a lot more friendly to C than those other architectures.
You're probably right. There's a lot of code for those processors that's not going away.
Too bad though, the 6809 is the pinnacle of 8-bit CPU architecture. It's the result of analyzing the practical shortcomings of the 6800 and other CPUs and redesigning the ISA. It has 16-bit index registers and 16-bit arithmetic, addressing two of the 6502s most annoying drawbacks. Additionally, it has support for stack based locals, position independent code and a LEA instruction. All those make building a high level language compiler much easier than other 8-bits.
I used OS-9 on a 68K system when I worked for a telecom company. It was a great OS. The one thing I remember loving was typing `cd ...` to go up to the parent's parent directory. I still find myself typing it in bash and being disappointed it doesn't work.
48 comments
[ 3.9 ms ] story [ 110 ms ] threadI had a Coco 1 and a Coco 3, with the OS-9 operating system you could run C and Pascal compilers as well as use BASIC09 which was like a modern bytecode interpreted language (Python). The 6809 stands out because it was designed to support compiled languages, shared libraries and such. It not only had the right addressing modes but it had just enough registers that code generation was straightforward.
When I replaced my Coco3 with a 286 machine I switched to hardware that was more than an order of magnitude faster but MS-DOS was a big step back from OS-9.
Lately I have been obsessed with the lost 24-bit generation of micros and was quite delighted to discover the eZ80, would be nice to see the 6809 follow the same route but Motorola was too committed to the ultimately doomed 68k.
It was a great ISA (though clearly completely different from the 6809), and these days big endian looks like a serious anachronism.
Every company that invested in it, however, had to either go out of business or switch to another architecture, usually the first. Apple and Sun Microsystems survived. Fragmentation, with the Apple Macintosh, Amiga, Atari ST, Sinclair QL, etc. (all similar machines that struggled with cost-performance tradeoffs in different ways), didn't help.
The BBC Micro developers probably had more space to really think about how to make a home computer and looked at many architectures and came to the conclusion that the 68k line punched below its weight. People in the early 1980s didn't see that one of the greatest rugpulls in computing was coming and were blindsided by IBM "doing it again" by maintaining long-term software compatibility with the 8088 and derivatives the way they did for the old 360... Companies that invested in the x86 didn't regret it, though many of them were crushed by an increasingly competitive market.
Also yes the 68k was clearly a dog when it came to interrupt responsiveness and made no sense in home computers or video games, at least not until the '020.
It was meant to be a bargain VAX. And that's why I say it was influential. A whole generation (X) of us grew up who could never hope (or care) to touch a VAX, but we had Atari STs, Amigas, etc at home, and were shelling into SunOS 68k boxes for fun or school etc. It lasted quite a while after VAX was a done deal, too.
To me 68k was the Unix workstation and hobbyist market and defined 32-bit ISAs as well. I never touched an x86 until I could run Linux on it. I've never learned or written x86 assembly seriously in my entire career despite writing (and enjoying) 6502 68k, ARM, MIPS, RISC-V, others
Outside of the UK, ARM didn't play a role except for in some embedded stuff. Obviously that changed :-)
And we also need to acknowledge that everyone was RIGHT! Intel ultimately threw billions into keeping x86 competitive, and they seem to have finally hit the wall now with performance per watt measures, which is what cost them Apple's business and is now driving Microsoft to ARM.
And x86 will, too, be replaced.
In what world? The interrupts were very fast, taking just a few cycles, and the behavior was deterministic.
This is why they were popular in realtime applications, and remained so for decades.
Back in the day, they were famously used in e.g. the Eurofighter Typhoon.
I'm sure the 68020 was better.
It has a fixed cost of 44 cycles. Is this somehow bad?
I would call it extremely tight.
edit: 44 cycles... after the previous instruction finishes. Some instructions (infamously slow division, and many-reg movem) can be slow. Worst case is what matters for realtime, but it is still under 400 cycles.
And yes, obviously that's easy when you only have 3 registers ... But this has a serious real world effect for things like video games.
At 1MHz, sure.
Obviously in throughput, a different story
In most scenarios, most interrupts aren't going to interrupt divisions, as most instructions aren't over 16 cycles[0], thus most interrupts will not be much longer than 44 cycles. In microseconds, a non-issue for a microcomputer.
Realtime programmers of the time had predictable behavior, and could simply avoid using the specially long instructions (movem and div) altogether if they needed to bound latency below the upper limit. Performance isn't as important as meeting hard deadlines.
0. https://wiki.neogeodev.org/index.php?title=68k_instructions_...
*looks at massive heat sink and fan on my desktop system...
This was after I had purchased and fully digested the only documentation I could find: "OS-9 Insights"
https://www.amazon.com/OS-9-insights-advanced-programmers-gu...
(To be clear, I'd like it to work, just questioning the economics.)
I think there's value in an open and modernized 8-bit MCU/MPU that isn't PIC or whatever.
Unfortunately they've had a bad streak in terms of getting a proper GCC or Clang toolchain targeted towards them. The developers of the chip are focused on their own weird structured BASIC-Assembly fusion ("SPIN").
> Current industry trends are to adapt 32-bit RISC IP for microcontroller use, however their large 32x32 register files and loosely encoded instructions limit their absolute minimum footprint. So with the goal of a creating a performance and compact microprocessor IP, we need an 16-bit instruction set architecture (ISA).
Not every application requires 32 bits and as you can see from some of the use cases, there might be a dozen of these in a design so minimal footprint is important.
Couldn't the same be done in a 16-bit architecture? And cut the # of registers. Like 16x 16-bit registers, optionally used as 32-bit pairs (8 of those).
None of this says anything about external memory sizes or such.
Btw: RISC-V has an "-E" flavour which cuts the # of registers in half from 32 to 16, but is otherwise identical. There's even some (unofficial) RV16 candidates out there.
As soon as you create your own architecture, you're essentially a toy. Nobody will want to rely on your half finished C compiler for it, or your unmaintained patchset for LLVM, or be willing to learn verilog just to fill gaps in documentation.
Even something as "simple" as changing registers on RISC-V will break most tooling and make most existing documentation impossible to rely on. Resulting in essentially a new architecture with a confusing name.
Being a toy isn't a bad thing, it just wasn't their goal here.
You'd be very mistaken. 4-bit MCUs are still found in places where you wouldn't even expect an MCU, and the 8-bit ones are numerous in ultra-high-volume highly cost-sensitive applications. Products that use COB-mounted sub-$0.01 die.
'816 was a gross hack, but it at least let you get more memory on there without resorting to bankswitching
that and the stupid mode switching
oh, and stack and zero page not being able move out of first bank
not a compelling chip.
The DB was not as flexible as segment registers, and there was only one of them, but you could easily load them both and then get a 16 bit value into the accumulator. Index registers also crossed bank boundaries. In contrast to the 8086, where the segments were a bit of a jail.
Mind, that's a feature in that you could write a multiprocessing system without memory protection, and have code reasonably safe from accidentally stomping on other areas (for example, if your C compiler compiled to the Tiny model, a rogue C ptr shouldn't be able to break out, obviously assembly could do anything).
Regarding the 68K and larger address space, on the original Macintosh, you were unable to request a single block of memory larger than 32K. So, like the Genie, unlimited power -- itty bitty living space. Sure, pointers could access anything, but at a system level, you weren't going to get a large enough chunk of memory, all at once, to warrant a larger pointer, so you were working with almost "virtually" segmented memory anyway.
On the IIGS, based on the 816, they used a similar memory manager. The segment manager on IIGS is really pretty cool. It's 2.0 of what the Macintosh had.
That is, it has a 32-bit accumulator (made up of four 8-bit accumulators) but apparently no address extensions.
Well, where is the superscalar variant? :-) At least on an FPGA, there would be very diminishing returns for doing it. Even bypassing has bad effects on fMAX.
https://en.wikipedia.org/wiki/Transport_triggered_architectu...
that convinced me I could build a useful custom processor but it also got me to see how complex things get when you go pipelined, superscalar, depending on a cache, etc.
http://www.bitsavers.org/components/motorola/_dataSheets/682...
Basically, it can page a couple of megabytes (maybe 4 I can't remember off hand) into and out of the 16 bit address space as 2, 4, 8Kb pages.
The really nice thing is how well the 6809 can do relocatable code. Made paging things in to and out of RAM flexible.
I do recall, I used 2 pages, 16Kb RAM for my projects.
Page one, run main code and page in subroutines as needed. I could put graphics data under the main code too. The draw routines got called in page 2, meaning page 1 could go away for a while.
It worked well. Maybe it was the Atari featuring different page sizes.
How are people putting 2 Megabytes into the machine? I never did one of those upgrades, though I did add a 6309.
Unfortunately 6502, 8051, Z80, and various other architectures from a similar era already fill that niche.
I'm guessing they picked the 6809 because it's a lot more friendly to C than those other architectures.
Too bad though, the 6809 is the pinnacle of 8-bit CPU architecture. It's the result of analyzing the practical shortcomings of the 6800 and other CPUs and redesigning the ISA. It has 16-bit index registers and 16-bit arithmetic, addressing two of the 6502s most annoying drawbacks. Additionally, it has support for stack based locals, position independent code and a LEA instruction. All those make building a high level language compiler much easier than other 8-bits.