Hacker News Reader

Comment by spc476 | Hacker News Reader

The 8086 wasn't binary compatible, but it was (more or less) software compatible---you could mechanically translate 8080 assembly to 8086 assembly and get about 95% converted without issue.

Motorola broke compatibility completely when they transitioned from 8-bits (6800, 6809) to 16/32 bits (68000) [1].

[1] From a hardware perspective, the 68000 is a 16-bit system; from a software perspective, it's a 32-bit system.

View on HN

I think he's talking about Zilog's 16 bit processor, which was completely incompatible with everything and is more or less forgotten now. (Literally in my case, I can't even recall its name).

Z8000 https://en.wikipedia.org/wiki/Zilog_Z8000

Yes, of course, that's the one. In the embedded shop I worked it I'm sure we looked at it briefly - it was overkill for our applications and also didn't have the natural advantage of being in any way compatible with the desktop computers we used for embedded software development.

Yes, I was talking about Z8000. Amazing processors (Z8001 and Z8002), but Zilog took too long to clean the bugs. That, and the lack of retrocompatibilty sealed its fate and Motorola 68k took over. Zilog tried again and again (Z80000, Z180 with Hitachi, Z280, Z380...) but never recovered. I have two Z380 waiting for the completion of its motherboards... :-)

I think an even bigger issue was the internal incompatibilities between 68000 variants, while Intel kept on maintaining compatibility all the way to the present day.

It's pretty amazing how well Intel has achieved that goal. Modern Intel CPUs can still natively run MS-DOS and applications for it. There are obviously problems with some games running too fast, and I seem to remember some issue in a common runtime (Turbo Pascal?) where a timing calibration loop would divide by zero because it took zero timer ticks to run a busywait loop. Those were already issues 20+ years ago, though.

Reply on news.ycombinator.com