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?
1) No, when I was involved they were s/36 (on smaller sites) and s/38 (on large and/or central site). The S/38 was from the 70s. They were in the long process of replacing as I recall older System/3 (not 32) retail support machines.
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.
My first exposure to the innards, from a software perspective, of a computer was a 6809 based system. The first assembly language I learned and the first “real” operating system with multitasking (Microware’s OS-9). I suppose it made an impression— I stuck with Motorola CPUs on my personal computers up to the 68040. :-)
Same here for 6809 and OS-9. I remember talking to friends writing 6502 assembly and comparing notes and it made me pretty happy I was working on the 6809 due to various operations and addressing modes.
I got a 64k CoCo2 when I was 10 or so. The Apple II was the only other computer I had ever used, and so my worldview was that BASIC was how you interacted with a computer. My Radio Shack carried Rainbow magazine and had lots of back issues available, and they were just absolutely delicious to me as a kid with all the program listings and ads for new hardware.
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 :)
Nice. I had gotten started with a CoCo 1 with just 16KiB of RAM. That eventually got upgraded to 64KiB and Extended Color BASIC. That made it easier to copy ROM cartridges and save them to cassette tape. One trick there was to cover over or cut the trace to a pin on the cartridge that prevented it from automatically starting. That was handy for switching between BASIC and the EDTASM+ ROM.
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.
CoCo had a UK clone made called the Dragon 32, which under the hood actually shipped with 64K ram, some careful tweaking and copying of the ROM to it's own spot allowed you to switch that upper 32K on and suddenly your ROM was RAM which meant you could extend the basic interpreter. Oh and you could also double the clock with a single poke 65495,0 .
Yep, we did both of those back in the day. The bank switching was needed for ROM copies that didn't relocate as easily, or if you were modifying the BASIC interpreter itself.
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.
Oh wow that was a nice bit of kit for those days. For me the route was: TRS-80 at work -> TRS-80 pocket computer -> KIM-1 -> Dragon 32 -> BBC Model B -> Atari ST -> 286 -> 386
And a bunch of homebrew in between. But a 6809 with 512K RAM would have been very nice :)
The CoCo3 ran fairly well, though it did run hot. The higher speed variant of the 6809 in the CoCo3 was still fundamentally a 8/16-bit processor. The main upgrade compared to the older versions was a bank-switching chip. You could apparently map any 8KiB of the 512KiB to any of 8 positions in the 64KiB address space of the 6809. It was sort of like segment registers... except less flexible.
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.
I've never even seen a CoCo3 in the wild here in Europe, and that's in spite of having worked for Tandy/RS. Maybe that was after the pull-out? That Dragon had a fantastic keyboard compared to the CoCo by the way, and that was one of the main reasons why I picked it.
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.
The 6809 (and 6800) helped me pay for my computer habit back in the late 70s/early 80s. I wrote a program for those CPUs, "Dynamite Disassembler", which I originally wrote to reverse engineer a bunch of code in the Flex and OS-9 OSes. Cleaned it up and managed to sell enough copies, at something like $150 a pop, that I could afford to buy more computer gear while I was a mostly-broke college student.
Primarily cost. In 1975, the 6800 cost $175 (which was already a dramatic reduction from the initial price of $360); the 6502 launched that year at $25.
Motorola dropped prices on the 6800 in response, but they still couldn't match MOS's pricing.
Indeed, the mask correction process that MOS came up with was really their killer advancement w.r.t. keeping design cost down, even considering the dramatically simpler 6502 core.
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.
Williams Electronics used the 6809 in Defender, Robotron, Joust and Sinistar. It was more expensive. Tandy chose it for the TRS-80 Color Computer and sacrificed dedicated sound generation hardware for it to keep costs down.
Same year I faxed them a resume touting my 8-bit assembly experience. Dodged a bullet there, although I'm sure I could have picked up another architecture pretty quickly.
We switched to C++. Nobody had a problem with the switch, although multitheading became a sticky point with some of the developers so we had to write an API to simulate nonpreemptive tasking like the old assembly system.
Although the 6809 was assembly-source level compatible with most of the 6800 opcodes, it was not binary compatible, and was in fact a totally new (better) design.
> Tandy chose it for the TRS-80 Color Computer and sacrificed dedicated sound generation hardware for it to keep costs down.
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.
Just because it came second, doesn't mean it's better. It was cheaper, and you can see where they cut corners to be cheaper. For me, if nothing else, the 16-bit stack and index registers in the 6800 make it hands down a better chip to program. But the 6502 was cheaper, sure, and some people probably like to spend all day thinking about what stuff to cram into the first 256 bytes to be performant.
The "zero-page", the low 256 bytes, amounted to a big register bank; compilers for 6502 used it that way. The hardware stack was for return addresses only, and was plenty; a zero-page pair pointed to the stack for arguments and locals. The designer of the ARM noted that her programs ran faster on 6502 than when ported to early 8086, largely because the latter was relatively so inefficient.
6502 fanbois like to pretended the zero page was registers because they had no choice and every since have tried to convince people that a weakness is a virtue. Better architectures don't have to pretend. And no one was talking about the 8086; most people who try to drag in an irrelevant processor to 'prove' 6502 superiority go 'but Z80!', so cudos for some originality.
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.
I never programmed 6502. But Sophie Wilson, who designed the ARM, and coded Acorn's BASIC interpreter, and shipped Acorns that could operate different CPUs on the same bus running her interpreter (ported), was in a better position to know than anybody else I know of. It is easy to confuse a more convenient programming model with more efficient operation.
The # of clock cycles to access zero page on 6502 is still higher than from the register set. I forget the exact amount, but it's certainly not another register, from a pure efficiency POV. If I recall it's at least one more cycle. Adds up quite a bit if you're doing things like shuffling in and out of the (single) accumulator.
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.
Memory was one cycle, zero-page or not. Indirect through zero page was 3 cycles after the instruction fetch, the first two to collect the address, the third to use it. The other chips with 16-bit index registers should have had a huge advantage, but they spent lots of cycles doing nothing visible from the outside.
In an 8 bit environment, to shave off one cycle and a byte in the program ROM is a big enough advantage that the zero page concept made good sense just from that point of view. Motorola took further advantage of it by allowing the zeropage to be moved around which could be used to give the effect of a rather primitive context switch between tasks, and coupled with position independent code made multi tasking even more feasible.
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.
Register-register or immediate ops are 2 cycles (e.g. TXA, LDA #imm).
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.
In modern parlance I think the best way to think of the zero page is as a primitive form of 'nearby' memory, we'd do this transparently through a cache. Some processors extended this 'register file in RAM' concept considerably, for instance the https://en.wikipedia.org/wiki/TMS9900 TMS9900 with it's workspace register.
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.
I absolutely agree, I don't think I would contradict that in any way, I just think the above exchange I was replying to was silly on both fronts and dunno why it got heated but wanted to provide more tempered POV on the utility of the zero page as a set of registers. You can frame it that way, and compilers often do, but it's honestly stretching the "truth" a bit.
I don't disagree that there was significant malleability in nomenclature, but the idea that zero-pages or 9900-style workspaces were register equivalents was in the most charitable sense was never anything but marketing, and never by anyone who honestly did the math. Even the 9900 folks pretty quickly stopped trying to convince us they had 'registers' and moved to how quickly they could change contexts and mitigate the speed asymmetries between on and off chip memory.
Remember that the 6502 and its related chipset was not designed to compete with the 8080 or 6800 for general computer applications, but rather with the Intel 4004 for cheap, low-parts-count embedded applications! Keeping that in mind, a lot of the 6502 design decisions make a lot more sense.
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.
This isn't true. The 4004 was obsolete by the time the 6502 was designed and nobody really thought of the 4004 as a CPU -- it rose to prominence years later as part of the victors (Intel) getting to write history. The 6502 was explicitly designed to compete with the 6800, so much so that it was pin compatible until legal action resulted in it being changed.
I'm trying to dig up the Chuck Peddle interview where he talks about targeting the embedded 4004 and friends market, I'll post it when I finally find it. The interview mentions achieving functional parity with the MCS-4 chip family as the reason for e.g. the 6530 RRIOT.
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.
Interestingly, the 8080 and 6800 were also designed more for embedded applications than for general-purpose computing. As late as 1981, Intel was focused on the various products that microprocessors could be designed into, such as clothes dryers and sprinkler systems. It's hard to imagine from the modern perspective, but the selection of the 8088 for the IBM PC was just another application. Intel viewed the iAPX 432 as their processor for real computing. Take a look at the cover of Intel's 1981 annual report which lists some of the 10,000 products that used microprocessors, putting personal computers down on the list between cameras and solar energy system control: https://www.intel.com/content/dam/doc/report/history-1981-an...
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.
The comparison with 6502 is often made, for obvious reasons, but the 6800 is definitely more of a "real processor" feature-wise! The order of magnitude in price difference and radically different intended applications are of course why that is so.
I don't think the 6800 and 6502 had different intended applications. The 6502 is just a second pass at designing the same product for the same market but with "design for manufacturing" given priority so it was quite a bit cheaper to make.
It is very cut-down compared to other processors of the time. Part of that was cost reduction, but part was also intended applications. I'm struggling to find it now, but I've got a transcript of an interview with I believe Chuck Peddle (may have been Bill Mensch) where they discuss it.
How is a 6800 more of a "real processor" feature-wise? They seem pretty similar to me - in fact I seem to recall that the 6501, a sister chip to the 6502 was "pinout" compatible with the 6800. Are you thinking the 6809?
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.
For trivial examples, and especially when using modern toolchains, the 6502 isn't tremendously more difficult to program for; however, if you're using the tools and resources of the day and writing large, complex projects (e.g. disk operating systems, databases, etc.) it's another story.
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
Back in the day, I did quite a bit of programming, professionally, on 6800-family CPUs, mainly 6850 and kin. It was an absolute pleasure to work with. The 6502, by comparison, felt like an absolute nightmare.
How would you compare the 6502 to the 6800? I cut my assembly teeth on the 68000 in the Amiga but always heard plenty about the 6502 due to the C64, but would love more perspective on how it compares to other CPUs.
Not the OP, but I'll give that a shot since I cut my assembly teeth on both of these, the Z80 and the '09 afterwards (and then back the 6502 because of the BBC Micro).
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.
Thank you for such a well-rounded reply. After my initial question I did read down through all the comments, and read a lot more about 6502 vs. 6800. It was a fascinating read.
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.
Indeed it is, it may be GP has their numbers mixed up a bit. What's funny is that you say 6850 and I immediately have the pinout in my head and I haven't looked at that chip for a good 40 years :)
I was baffled by the PDP-10 assembler reference manual. For example, I didn't know what a stack was, what a register was, etc.
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 had a similar experience, read the Popular Electronics 8080 article but couldn't understand it. Got my hands on TI 7400 and Intel 8080 databooks and just kept reading them front to back, over and over, till all the little fragments I could glean started to make sense together. Then I wire wrapped an 8080 board of my own design. (well, two of them, the first was a wiring nightmare, didn't work, so I had to start over, but I was much more skilled at that point, and my wiring was clean, and it worked right off the bat)
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...
I was 15 almost 16 when the Altair 8800 article came out in Popular Electronics, and I knew how to build little circuits using a couple transistors or a 741 op amp or 555 timer. Like I said, I could not understand the 8080 construction article, or what programming it "meant", but I knew FORTRAN and I knew programmable calculators so I guess I was coming at it from both sides. My biggest obstacle was not having any clue where to get the information I was looking for, so it would be by chance that I found out I could get databooks from chip makers. Took me a couple years all-in to build my own, but most of that time was spent reading and rereading technical manuals that I didn't quite understand. In a certain sense I was coming at it like an archeologist :)
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.
Wow, super cool! Thank you for the backstory, always interesting to see how people landed in this field and what made it possible. If not for a few such chance encounters my own life would have turned out entirely different.
93 comments
[ 3.1 ms ] story [ 174 ms ] threadNot 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.
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.
[1] http://www.lcurtisboyle.com/nitros9/galacticattack.html
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.
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.
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
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.
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.
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.
I did. I'm not cherry picking things I found on Google to try and be right.
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
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
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.
(The patent office messed up and swapped drawings; there's a slush maker patent with a diagram showing instruction decoder, registers, and so forth.)
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.