91–100 of 127 posts
> It has 72 instructions with seven addressing modes for a total of 197 opcodes. noob question: why so many addressing modes?
I built a small multitasking kernel with a friend with a 68000 (m68000) in college. We implemented it on breadboards, I think with 30 or so feet of jumpers [0]. I had very little prior embedded experience, so it was trial by fire. It was a wonderful introduction to how kernels work (or at least concurrency and scheduling) at their most basic level, without having to deal with the complexity of virtual address spaces,…
Very cool! Do note that the Wikipedia page is about the 6800 (Sixty-Eight Hundred), though, not the 68K. A generation earlier, 8-bit, far less popular in end-user applications than the 68K. Still a good processor.
In fact, the 6501 (architecturally the same as a 6502) was pin compatible with the 6800 and was discontinued after a lawsuit.
I actually preferred aspects of the 6800 series, particularly the addressing options.
I built a small multitasking kernel with a friend with a 68000 (m68000) in college. We implemented it on breadboards, I think with 30 or so feet of jumpers [0]. I had very little prior embedded experience, so it was trial by fire. It was a wonderful introduction to how kernels work (or at least concurrency and scheduling) at their most basic level, without having to deal with the complexity of virtual address spaces,…
I think the x86_64 chips are fairly unique in terms of how hilariously awful the bring-up process is. I'd hate to be a microcode engineer on one of them. So much state. Then throw virtualization into the mix.
Earlier quoted context omitted.
Back then people wrote assembly language themselves. At 1-2Mhz, sometimes Khz, it was how one got performant code. Addressing flexibility makes assembly language programming practical for people to do. Check out the 6809 for a beautiful ISA and probably one of the most powerful 8 bit CPUs.
"You kids and your RISC! Back in my day we had seven addressing modes and we liked it!" Everyone nowadays takes it for granted that you can use software to write software. There are still lots of graybeard programmers around who had to make do with punch-cards when they were learning.
I never did punch cards, but I have used paper tape with one of these:
https://w140.com/tekwiki/wiki/4051
And here is a video of the storage CRT: (they are beautiful to watch in person, and the one I used had a 2048x2048 vector space to draw in.
On mine, I had a cassette like tape drive that had some CNC programming tools on it. Another tape had various utilities and some crude simulation programs.
User data was on paper tape, usually source code, or finalized G-code, or plots one might want to reproduce. Frankly, I love paper tape. And I have had to read it, patch instructions in with one of those little machines with all the hand push button punches and index gear to keep it lined up. Same for damaged tapes.
And my first machine language programs were hand assembled from blurry, photocopied data book pages mooched from the local university.
Sidenote: Moto was cool. I asked about documentation later for the 6809, and was able to have my parents take me to a local office where I got to chat with an engineer and left with a pile of docs, and reference databooks!
I did not get an assembler of my own until I mowed a lot of lawns and bought MAC/65 for my Atari. Prior to that, I was typing stuff into the mini-assembler on the Apple.
I was a kid, 14 for that stuff.
Later at 19 I ended up working in small shops using Tektronix hand me down gear while attending college. Super glad I fell into that experience frankly. Those Tek computers were odd, but well conceived and more powerful than one might think 8 bit stuff could be. The people in that shop made some impressive stuff essentially laid out and programmed on a 6800 CPU found in the Tek storage tube terminal / computers. They were interesting designs.
One could get one and just set it up for serial comms and use it as a weird but capable text display and or, graphics display like a paperless plotter. Xterm has Tektronix mode to support that even today.
Add some ROM and RAM, and peripherals, and then it was a powerful, technical computing micro computer. Disk drives, cartridge tape, paper tape read and punch, plotter, joystick, and off you go! Never did get to use a disk. But that fast cartridge tape drive and paper tape worked better than expected.
What I find interesting is younger people are checking this stuff out and or building their own gear. 8 bits is enough to really do stuff and understand the entire thing. While not practical given what we have today, it all is still educational in a way that appears to remain potent.
For my own fun reasons, and some product development, I have the luxury of...
I keep an Apple //e Platinum on my work bench. And I use it to do electronic projects the same way I did as a kid. Good for simple prototypes or to understand a sensor, do comms. When my current project slows, I plan on making a card with a Propeller chip on it to make a cool dev station that works like an Apple with command line, just type a line and go BASIC, as well as self hosted compiler and assembler... good times. And practical. People I work with and I have done a couple designs. It all works just fine and it is simple. No updates, no OS, just lean and mean.
Earlier quoted context omitted.
Well, it was the predecessor :)
There was the 6809 in between. I remember BYTE magazine's cover story, "A Microprocessor for the Revolution". Well, not quite, as it turned out! :)
Earlier quoted context omitted.
$200k sounds like such a small number, but it was the dropping of the offending chip that was the gotcha.
Well...200k in 1975 $'s. And MOS was a startup, basically. So not a trivial amount. But yeah, a big part of the initial pitch was "you can use your same hardware design but replace the $300 CPU with our $25 CPU".
The Heathkit/Zenith ET-3400 trainers with 6800s, and the accompanying Heath/Zenith coursework, were fantastic in 1982. 50+ of us completed it that year, the class final was bit-banging the tune of "Anchors Away" as the instructor was a Navy officer and educator, retired to civilian teaching. I later learned machine language on broken superscalar mainframes as bit-chaser, but the 6800 were simply fantastic devices and…
[1] https://www.youtube.com/watch?v=zBkNBP00wJE [2] https://github.com/lefticus/6502-cpp [3] https://github.com/CalPlug/Heathkit_ET-3400
There is something special to me about the idea of writing modern C++, and compiling it for such early microprocessors. The 512 bytes of RAM is a pretty big limitation though. I wanted to try and emulate an EEPROM using an Arduino or FPGA, but got stalled out on the project. From time to time I like to browse through the LLVM backend documentation, but I can't seem to commit to trying to build a backend.
> It has 72 instructions with seven addressing modes for a total of 197 opcodes. noob question: why so many addressing modes?
Back then people wrote assembly language themselves. At 1-2Mhz, sometimes Khz, it was how one got performant code. Addressing flexibility makes assembly language programming practical for people to do. Check out the 6809 for a beautiful ISA and probably one of the most powerful 8 bit CPUs.
Not only this. It made for more compact code, and memory was very expensive. So expensive that 64kB was practically unheard of. In 1980, 4kB would cost $100 or so. If I read it correctly, the original board with the 6800 was shipped with 128B.
Earlier quoted context omitted.
Back then people wrote assembly language themselves. At 1-2Mhz, sometimes Khz, it was how one got performant code. Addressing flexibility makes assembly language programming practical for people to do. Check out the 6809 for a beautiful ISA and probably one of the most powerful 8 bit CPUs.
> Back then people wrote assembly language themselves. Not only this. It made for more compact code, and memory was very expensive. So expensive that 64kB was practically unheard of. In 1980, 4kB would cost $100 or so. If I read it correctly, the original board with the 6800 was shipped with 128B.
128 bytes is a lot! Seems absolutely insane small now, but back then every bit mattered. And being so close to the hardware meant being able to do things super lean and mean.
On the KIM 1, the RIOT chip came with 128bytes of RAM, and Rockwell, MOS, and others also later packaged the CPU with small amounts of RAM, timers, and other handy things. Early origins of system on chip designs. And there was a jumper or solder pad one could use to sort out address decoding should more RAM be added.
128 bytes, probably split between zero page and the stack, can do a lot!
For perspective, the Atari 2600 had 128 bytes of RAM in its RIOT chip and that was the total system RAM!
Atari 2600 Space Invaders fit into 4K ROM and the 128 bytes of RAM.
No frame buffer, no tile engine!
Graphics were generated line by line, game logic happening during the screen blanking period!
Earlier quoted context omitted.
I just don't think any of the 8-bits made good compiler targets. At least not C compilers. Not enough registers, even in the 6809.
In theory, a smart compiler could make heavy use of the DP register (6809 feature) and then local variables within a compiled function could access these "fast" global variables instead. This was a common pattern when coding in assembly, and it's much faster than accessing variables off the stack. The function wouldn't be reentrant, but a compiler pragma could be used to enable/disable the DP mode. Declaring the loca…
Z80 had a faster clock, but instructions took loads of cycles. Nowadays that is OK, but Z80 did not pipeline. It had fancy looping instructions, but they ran slower than the loop would have.