Live data from Hacker News

Motorola 6800

en.wikipedia.org

31–40 of 127 posts

Re: Motorola 6800

#31

With the optics of _compiled_ code, how do the various 8-bitters stack up? (6809/6811, 65C02, Z80, H8, ...)? One would have to account for the frequency allowed by the ISA at iso-technologies (which makes including AVR somewhat tricky). I only have experience with Z80 and 65C02 and I believe the consensus is that a 4 MHz Z80 beats a 2 MHz 65C02, but neither is a particularly nice compiler target.

The 6809 is ridiculously suitable for running Forth, because you've got two stacks, a 16-bit accumulator, and you can implement NEXT in two instructions taking about three clocks each.

Someone needs to write a WASM VM for it.

Re: Motorola 6800

#32

With the optics of _compiled_ code, how do the various 8-bitters stack up? (6809/6811, 65C02, Z80, H8, ...)? One would have to account for the frequency allowed by the ISA at iso-technologies (which makes including AVR somewhat tricky). I only have experience with Z80 and 65C02 and I believe the consensus is that a 4 MHz Z80 beats a 2 MHz 65C02, but neither is a particularly nice compiler target.

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.

These processors were designed for assembly programming, hence their very CISC-y ISA. Some 8-bitters designed for compiled languages would be the AVR family.

Re: Motorola 6800

#34

I just finished an undergraduate class on microcontroller applications that used a MC68HC12 dev board. We coded in Assembly and then later in C. I'm curious, is this a typical platform in other computer engineering programs in the US?

[deleted]

Re: Motorola 6800

#35
This was the first microprocessor I programmed.

My kit was for the school I was in. It was an STD Bus-based card, nailed onto a piece of wood, with a hex keypad/display.

The card had 256 whole bytes of RAM.

We programmed it in machine code.

Re: Motorola 6800

#36
post #25

Serious question, why is this on Hacker News? is it a classic of some sort?

The 6800 definitely is a classic, yes. The classics included at least 6800, 6502, 8080, and Z80. (To some extent 8085, but as an "expanded" 8080 the Z80 dominated.) The four of them powered the most iconic systems at the start of the microprocessor "takeover" at the end of the seventies (at the same time as I entered my electronics education). The 6800 was kind of left behind by the others eventually, but was used in e.g. the SWTPC 6800, and also in a lot of minicomputer (e.g. DEC) peripherals at the time (including variants like the 6802 with a little on-board RAM)

Re: Motorola 6800

#38

I just finished an undergraduate class on microcontroller applications that used a MC68HC12 dev board. We coded in Assembly and then later in C. I'm curious, is this a typical platform in other computer engineering programs in the US?

The university I'm attached to used 68HC11-family dev boards for their intro embedded course until the early/mid 2010s, with a smattering of other platforms like 8051 derivatives in advanced classes, and have switched to ARM (Small Cortex M ARMs, typically TI TM4C123 TivaC boards) for almost all our embedded content since. Plus a few little Arduino based activities with the freshmen, though the form of that has changed over the years.

The intro to embedded systems course used to be only taken by Computer Engineers around their Junior year, since ~2017 we do it a semester or so earlier and make the EEs take it too as part of a streamline; EEs no longer take the computer architecture course, and the new embedded course covers some basic architecture concepts.

We still do the beginning of the semester in Assembly (we really only show them ARM Thumb) and the later part in C.

Possibly the most revelatory thing about that course is that the low-level view means we find out and try to correct that most of our students (as second semester sophomores who have in theory passed at least two programming courses and a digital logic course) haven't the slightest idea what code actually means/does.

Example: Every semester I've been involved, when we transition from assembly to C, we give a simple assignment to sort some arrays of (well documented) structs by a specified field and order, given the address where first element starts and length in elements, in both C and assembly. They are handed a starter project with a lightly-obfuscated object file that sets up the arrays, calls two provided function headers for them to fill in, then tests if the sorts succeeded. Details get changed every semester because students cheat compulsively on programming assignments, but it's always set up to be easy, the structs they handle in ASM are always 16 or 32b in length, stored aligned, etc.

Many of them... struggle mightily for two weeks because they haven't actually retained anything about number representation, memory (size, layout, byte addressing), arguments, the difference between a value and a pointer, and so on. The course staff spend weeks doing patient remediation around that point in the semester. At least we get a chance to make another pass over that material and more of them get it after.

Re: Motorola 6800

#39
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 prepared me well. Flat, shared memory, von Neumann architecture. Very nice op codes and indexing, as I recall. Ill have to go back to my coursework and reminisce...

Re: Motorola 6800

#40
post #9

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.

Post reply on HN