Hacker News Reader

Comment by trzy | Hacker News Reader

Why wasn’t this chip more common in arcade and game consoles vs. 6502 and Z80? Cost?

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.

Just to save anyone else the effort, inflation adjusted those numbers are: $1,031.36, $2,121.66, and $442.01.

Based on what? The data sources I can find put inflation since 1975 at ~470%, which sounds high, but even then $25 is only ~$140, not $442.01

I used this: https://www.bls.gov/data/inflation_calculator.htm

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.

> 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.

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.

The 6809 is not the same things as the 6800. Related, but quite different.

It also ran Williams' line of pinball machines all the way until 1999.

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.

The 6502 was a better chip (designed with hindsight on the 6800), and also cheaper. Z80 could run 8080 code.

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.

Can we please talk about something as settled as decades old CPUs without resorting to name calling?

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.

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.

They are super fast, but they are a load, modify, store operation, hence the large number of cycles.

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 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.

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.

And for that I got downvoted. Huh.

The zero page was faster than regular RAM access though, it's gotta count for something.

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.

I never programmed 6502.

I did. I'm not cherry picking things I found on Google to try and be right.

If I had to pick one over the other to write serious software in forever, it'd definitely be the 6800.

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

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.

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...

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.

Found it! Bill Mensch, not Chuck Peddle, and it's an IEEE Spectrum interview:

https://spectrum.ieee.org/q-a-with-co-creator-of-the-6502-pr...

SOURCE: 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.

The Z80 was a generation later, so its appropriate comparison is the 6809, used in the Dragon and Tandy Color Computer.

It's not so clear. Z80 is two years after the 6800 but the 6809 is two years after the Z80.

1974 - 6800 / 8080

1975 - 6502

1976 - Z80

1977 - 8085

1978 - 6809 / 8086

1979 - 68000 / 8088 / Z8000

Reply on news.ycombinator.com