5 ms·

And, then, they thought: "hum... let's do our 16 bits microprocessor... and forgot the retro compatibility with our own 8bit chip!". What could go wrong?

spc476 8y ago
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.
- billforsternz 8y ago
  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).
  - klft 8y ago
    Z8000 https://en.wikipedia.org/wiki/Zilog_Z8000 https://en.wikipedia.org/wiki/Zilog_Z8000
    - billforsternz 8y ago
      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.
  - MarcPereira 8y ago
    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... :-)
- digi_owl 8y ago
  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.
  - 0xcde4c3db 8y ago
    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.

spc476 8y ago

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.

billforsternz 8y ago
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).
- klft 8y ago
  Z8000 https://en.wikipedia.org/wiki/Zilog_Z8000 https://en.wikipedia.org/wiki/Zilog_Z8000
  - billforsternz 8y ago
    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.
- MarcPereira 8y ago
  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... :-)
digi_owl 8y ago
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.
- 0xcde4c3db 8y ago
  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.