Motorola's pioneering 8-bit 6800: Origins and architecture
thechipletter.substack.com
thechipletter.substack.com
(The patent office messed up and swapped drawings; there's a slush maker patent with a diagram showing instruction decoder, registers, and so forth.)
What totally confused me at the time though were program listings in assembly (I couldn't figure out how you were meant to type those in) and especially the discussions of OS-9. I didn't know what it was, and even in some cases where I found a Radio Shack with the Tandy OS-9 distro, it was like 100$ and didn't have any games as near as I could tell, so I couldn't figure out why you would pay so much for it. Also I lived in a rural location where even the nearest 6809-oriented BBS would have meant expensive toll calls, so I missed the opportunity to learn that way.
Anyway skip forward, I started to college in 1993, immediately found Usenet, then Linux, and spent the next 30 years or so steeped in that world. Every so often I would go back and do a little reading on the 6809 world, but because I had never really understood most of what was going on, I didn't have a great deal of nostalgia.
Finally though, a few weeks ago I came across a link (maybe here?) to a release of the VCC emulator, and although I had played with a couple of 6809 emulators before, I hadn't really gone down the rathole of finding the MultiPak roms, or hard disk controller paks, etc. I found a couple of hard drive images, one from the NitrOS9 Ease of Use project, and another random NitrOS9 image packed with old software. What was particularly fascinating to me was the NitrOS9 source itself- since my introduction to Unix was in the 486-MMU-having-era, to see what people were able to do with a 6809 and an assembler was just a joy to read and understand.
I feel like probably everything that has ever needed doing on a 6809 has probably been done, and I've done enough 8 bit assembly stuff in school that I don't have a powerful urge to go back and make something myself, but boy what a feeling of having come full circle when I cd'd into the NitrOS9 source directory and found a makefile of all things! I feel so fortunate to have been able to live through a time of such explosive growth and change, and hope to get the chance to do a little OS-9 hacking when I retire some day :)
One use of all that was to fix the CoCo's clone of the arcade video game Galaxian, called Galactic Attack[1]. The CoCo had analog joysticks, and the writer of Galactic Attack thought it would be neat to have the ship you control track the X axis of the joystick. Except it would be unfair to whip the joystick from one side of the screen to the other while avoiding the enemy shots. So in the Galactic Attack game, the player ship lazily tracked the position of the joystick, moving slowly to the position of the stick. In practice this made the player ship hard (for me) to control and felt unresponsive. And it made it hard to hold still in the case an enemy bomb was close by.
I had already modified one of my Atari 2600 joysticks to work on the CoCo (probably a Rainbow magazine article). So what I did next was to modify the joystick routine to just create three zones (move left, dead zone, move right) for the X axis values. The game may or may not have been written with all relative branches (instead of absolute), so I might have had to fix that too.
Good times.
Towards the end of the 1980's I upgraded to a CoCo3, with 512KiB of RAM (wow! so much), a disk drive (156KiB) and OS-9 level 2. Also got the C compiler for OS-9 when it was on sale (discontinued).
My final setup would have the entire operating system loaded into RAM, with a RAM disk, upon which I'd copy in the C compiler. And display it via a glorious 80 columns on a monochrome monitor. It was with all that I started writing my own vi clone, but didn't get too far.
And a bunch of homebrew in between. But a 6809 with 512K RAM would have been very nice :)
I sorely wanted an Atari 520ST when they first came out, but it was more than I could afford at the time.
After graduating from university, I eventually got a Gateway 386 with a whopping 4MiB of RAM. In part to play Wing Commander and Castle Wolfstein. I've mostly been a PC guy since, though I've dabbled in RISC-V more recently. Not ready yet to make that my main desktop though.
The ST was my first 'serious' computer, with a massive amount of memory and an optional hard drive it really unlocked a whole bunch of capabilities, such as compiled languages and more RAM to work with, I used it for all kinds of commercial projects. In many ways X86 felt like a step back after working with the ST, especially after I figured out how to add more RAM to it. It also had a whole slew of useful ports including MIDI.
Today I use an old Thinkpad as my daily driver and it's funny, it's probably the oldest piece of hardware that I have here (a W540, 9 years old, $300 second hand including the 32G RAM in it), but it performs admirably and it uses very little power (everything on solar here so that matters a lot).
But I've been eyeing that RISC-V stuff as well and like you I'm still in hold mode. But it's getting closer.
Eventually, I got a hold of the 6800 instruction set manual. It had what, 40 instructions? Small enough for me to "get" it. All of a sudden, it all made sense.
So I have a soft spot for the good ole' 6800! I eventually designed, built, and programmed my own 6800 single board computer. I had a blast with that project.
I was most proud of noticing that on the 8080 there is some sort of halt signal pin, and a separate pause signal pin (might not have those names right, maybe it was memory ready?). Anyway, one of them detected the leading edge and the other detected the trailing edge of the clock, so I was able to rig up a pushbutton for single stepping the processor without having to figure out how to make a pushbutton debouncer circuit which I was having a lot of trouble with...
good times
How old were you if I may ask?
Just a few months when I got to wire wrapping. I was somewhat astonished when it worked, I thought I'd have more problems, but I did check and recheck all my work as I went because I was fearful.
I had an older relative who had a job testing components (beyond plugging them in and looking at the lights he didn't know much about them) and he showed me around the lab where he worked (they were doing components for the Fidelity chess challenger) and gave me a bunch of drop-out chips that had failed the tests, including 2114(?) static ram chips and a couple of 8080s. I don't know what tests they failed, but they worked for me.
http://zoom.interoscitor.com/PetersonEnterprises/Consulting/...
It's pretty tedious to program it since the I/O is all in binary and you have to use toggle switches to key in binary machine code.
Both are fine processors, the 6502 was technically not quite where the 6800 was but nothing that you couldn't solve using a couple of macros (and a Macro assembler was table stakes for anybody serious enough to go after this stuff and so you rolled your own because buying one was prohibitively expensive).
The 6502 had an edge in available software and books, especially once the Commodore took hold. Community mattered, even back then! The 6800 was laid out much more sensible from an instruction set perspective, the term used is 'orthogonality', if you know the rules you can predict the existence of a particular mnemonic and parameters easily, whereas with the 6502 it was mostly a matter of learning it all by heart. Easy to do because both were tiny in comparison with todays CPUs. I suspect that's where the GP's nightmare comment relates to, the fact that the 6502 always felt like it could have been so much better if they had spent a bit more time on this subject.
The 6800, it's more modern and upgraded brother, the 6809 and the much larger 68000 all were much more logical and predictable. The Z80 became widespread due to - amongst others - Sinclair with the ZX-80 and ZX-81, and Radio Shack using them in their line of TRS-80 micro computers, and a large number of people cut their teeth on those. I had access to them at work (I worked for Tandy on Saturdays, which was the European name for RS) and never found that chip much to my liking, but it was the engine behind the CP/M software environment.
Programming in assembler (or even directly in machine code) is an exercise in abstraction to the point that you have to have a very good memory and to be able to limit the scope of what you are doing to be able to make any progress at all. But it beat the pants of BASIC (the most common alternative on micro computers at the time) in terms of speed and control so if you wanted to do anything serious with those machines that's how you did it.
The 6502 had awesome hardware support in terms of peripherals and the machines you found it in (with the BBC Micro model 'B' as the pinnacle of home computing at the time) and the 6800/6809 had an edge if you wanted to roll your own system from scratch. Various bus based systems (S-100, Eurocards, VME) gave you the option to build systems and to swap out the CPU with something else. The BBC again led the way here by speccing a bus called 'the Tube' (a pun on the London underground) that allowed you to build specialist co-processors that used the original BBC as an I/O processor.
I completely agree with your comment about "community matters". You could really see this in the demo scene for the C64 (as well as the games programming world).
My friend's older brother had a ZX Spectrum, which I lusted after (mostly for the games). I was still too young to really "get" assembly, and it was only really when I got to the end of high school that I got into it.
BBCs were very rare here in Aus, but I did pore over a magazine column that featured them. I vaguely remember the Tube being mentioned.
https://spectrum.ieee.org/q-a-with-co-creator-of-the-6502-pr...
Oh I see you are talking about the 16 bit stack pointer and probably the 16 bit Index register. Fair enough on an 16 bit address bus those are fairly convenient but it's interesting that it just tends to mean if you use SOA or AOS for you data design. I don't think 6502 is really much harder to code than 6800 or 6809.
The 6800's larger register set (yes, 16-bit stack pointer and index registers, but also dual accumulators), richer instruction set, more consistent use of status flags, and hardware features like DMA support with no additional hardware/not a special version of the processor are what makes it more of a "real processor" to me.
I still hack on both, though, so I'm not trying to say the 6502 is some kinda turd no one should program :P
Not really, I think. Doesn’t it directly follow from (FTA)b“Motorola’s 700 page manual for the system even showed how to use the 6800 family to create a complete ‘Point-of-Sale’ terminal”?
In the 1970s, how would you connect that to a computer without a modem?
What shops would have a that in the (air-conditioned) back room?
2) $1000 a month is not much money for a retail store large enough to have multiple POS systems, even in 1983 dollars. And you could purchase them if you didn't want to lease.
3) I'm assuming by the 'air conditioning' comment, you're imagining some refrigerator sized minicomputer. You can look at that System/36 Wikipedia page and see pictures of 2 S/36 models that are large deskside cabinets (think of the giant PC AT tower cases of old), are air-cooled, and designed to go in the air-conditioned back room of the store, which all of the stores had.
Motorola dropped prices on the 6800 in response, but they still couldn't match MOS's pricing.
Checking again it looks like I'd used this calculator in the past for $250 so I got an extra zero in there by accident via autocomplete, sorry. I can no longer edit the original.
The result of that though is an excellent example of 'software eating the world' and allowed for a whole pile of other tricks to be pulled (in software!) that would have required more circuitry in other computers. For instance, the tape interface used it, as well as the joystick interface. If you were a bit more adventurous you could use it for analog in as well as analog out.
But it is now as it has always been: when you call someones pet processor ugly, you'll get all the specious arguments you can stomach.
The TMS9900 took this further, and had no onboard registers (other than PC & status register). Everything was in RAM.
That model only made sense until RAM became slower than the bus speed (late 80s).
The zero page in the 6800 and 6502 not being relocatable also sucked. Something fixed in the 6809 and 65816 respectively.
I suspect the lessons Sophie Wilson learned from the 6502 were... cycle efficiency and minimalism. The 6502 was super responsive to interrupts precisely because it was so sparse on features.
Register-ZP ops are 3 cycles.
Register-absolute (full 16-bit address) are 4 cycles.
Indirect lookups add a cycle, indexed adds a cycle.
There is some weirdness - e.g. pushing A to the stack is 3 cycles, but pulling it back is 4 cycles. And LSR/ASL start at 5 cycles for ZP access (6 for absolute) and you would think bit shifting would be super fast.
All of these concepts, register file, cache, context memory were quite fluid at the time and not yet settled in the way we see them today so it isn't surprising to see one party refer to the 6502 zero page (or the 6809 direct page) as an extension of the register file in the CPU and another to see it as a cache, a task context or more efficient bit of memory. All of these can be right, it's just a POV difference.
And for that I got downvoted. Huh.
The reason the 16 bit index register indirect fetches were so slow is that they did a useless 'add' of 0 to the index register prior to the fetch. They also had an offset option and I guess letting it do it's usual thing with an offset of 0 made the silicon a bit simpler at the expense of a bit of efficiency.
I did. I'm not cherry picking things I found on Google to try and be right.
Remember, you can also spend all day exploiting zero page mode in the 6800, but you'll never be able to move the 6502's stack :P
That folks turned out complex, feature-complete operating systems several times on 6502 is as impressive as those things being done on e.g. the DEC PDP-8, IMO. Doubly so when you consider that the 6502 hackers were often just that, hackers and hobbyists without an industrial-grade budget.
The 4004 was old by then, but not obsolete. It and the 4040 were still being integrated into embedded systems where cost was a major factor through the late 70s.
https://spectrum.ieee.org/q-a-with-co-creator-of-the-6502-pr...
Bill Mensch tells IEEE Spectrum directly that the 6502 was designed to compete with the Intel 4040, and specifically says not the 8080 or 6800. I don't know how much more "primary" a reference can get, folks.
1974 - 6800 / 8080
1975 - 6502
1976 - Z80
1977 - 8085
1978 - 6809 / 8086
1979 - 68000 / 8088 / Z8000