Sinclair's machines were Z80 based - was there another major brand using it? All the ones in the UK I can think of were 6502 based...?
back
5 comments
Amstrad. Their CPC range sold well enough that they ended up buying most of Sinclair Research and releasing a few models of Spectrum variants based on Amstrad industrial design.
One model post-purchase Spectrum even included the same kind of oddball 3 inch floppy drive that Amstrad had been using (another had a built in cassette player, similar to what the first Amstrad CPC had).
The Spectrum +3 . Also, was my first computer.
Andreas bought Sinclair, because Sinclair lost a lot of money, trying to get his "electric car"
I had the +2, the one with the cassette player.
Amstrad CPC464 and CPC6128 were UK based Z80 machines. Not too bad. Mine had a little drive inbuilt and ran CPM. My first computer was a Sinclair ZX80 so anything was better than that.
Amstrad programming is still a thing :)
I just added a CPC6128 to my retro collection, and promptly blew it up. :(
I'm going to repair it though, even if I have to replace every single chip. :)
Oh no! What happened?
Mine is happily running; it's a 464 w/ green phosphor monitor. I'm on the lookout for a reasonably priced colour monitor but they're rare as hen's teeth in Australia.
Not 'major brands', but all the East German 8-bit computers were Z80-based, and by far most of the other Eastern European machines (AFAIK only the Bulgarian Pravetz used 6502 clones).
I wrote an emulator which covers most of the East German 8-bit machines, some had quite interesting ideas implemented: http://floooh.github.io/virtualkc/ (needs WebAssembly)
The TRS-80 line. In hindsight it seems kind of shocking more computers didn't use them. The machine language was far bettr than the 6502 (IMHO), and they were typically clocked twice as fast.
They were clocked twice as fast because they worked less efficiently internally. The 6502 will read or write exactly one byte per machine cycle; the Z80 equivalent of the machine cycle is the T-state, of which it will spend 4 per instruction byte, 3 per operand or data byte, and 8 (I think?) per data byte read due to an instruction with a prefix. As today, though for different reasons, throughput of CPUs of the time was limited by memory bandwidth, and the Z80 has at least a 3-4x disadvantage here.
This does make the Z80 sound much worse than it is. A 6502 instruction takes at least 2 cycles, which for certain types of instruction means a cycle wasted. TXA and ASL A take 2 cycles, for example, even though both are one byte. It's 1 cycle to read the byte for the instruction, and then 1 cycle effectively wasted. The equivalent Z80 operations take 4 T-states, on the other hand: just the cost of reading the byte for that instruction.
The Z80 also has the upper hand with some more general instructions. LDIR is 21 T-states per byte for the equivalent of a memcpy, where the equivalent 6502 loop might approach 9 cycles per byte only with multiple unrolls, while being far less general. The Z80 also has 16-bit operations, which the 6502 lacks entirely. It's 11 T-states to add one register pair to HL, which is the sort of thing the 6502 will take 15-18 cycles over, and that only in the best case.
But it's not entirely a wash - in fact, quite the opposite. The Z80 has no analogue of the 6502's X-/Y-indexed addressing modes, and with only 3 register pairs (IX and IY being uselessly slow) you'll struggle to keep the necessary addresses live - a pain for anything that's table-driven. (It's 10 T-states to load the address, then 4 to replace the low byte with the index, then 7 to fetch the value there. The 6502 can do that whole lot in 4 cycles. You can also load the other index register this way, then use that to load the accumulator: 8 cycles for a table-indexed table lookup.) The 16-bit operations are annoyingly specific, and for many types of operation you need to shuffle data through the accumulator and back again. In practice this stuff typically negates the Z80's apparent register count advantage.
When I first read through the Z80 data sheet, the thing seemed basically magical by comparison to the 6502! But once I tried to actually write any code, I found there'd typically turn out to be this fairly consistent 4:1 T-state:cycle ratio. You can engineer situations where the Z80 is hilariously better... but they'd be engineered. For typical code, you can expect 4:1. You'll need a lot better than double the clock rate for the Z80 to win.
(Interesting and possibly relevant interview with Sophie Wilson, ARM designer and formerly with UK's Acorn, that touches on how memory bandwidth can influence CPU effectivness: http://www.computerhistory.org/collections/catalog/102746190)
You sound like an expert! How long would code take, for 32 bit floating point multiply, on Z80 vs 6502?
I'm curious, as a way to compare progress with todays 500 GFLOPS phone GPUs, and 10 TFLOPS PC GPU cards.
But neither Z80 nor 6502 have native 32 bit, nor fp, nor multiply, so a program is needed... this must have been done, for some applications.
http://www.andreadrian.de/oldcpu/Z80_number_cruncher.html#mo...
You’d be lucky to get KFLOPs on an 8-bit processor.
A 4MZ Z80 (or 8080) is about as fast as a 1MHz 6502, because of that.
Arguably the biggest "brand" connected to the Z80 was CP/M[1].