Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Captain Zilog Crushed: The Story of the Z8000

thechipletter.substack.com

Post reply on HN
Print view View original

51–60 of 70 posts

Re: Captain Zilog Crushed: The Story of the Z8000

#51

Post by jacquesm »

systems_glitch wrote: post #50
jacquesm wrote: post #46

Earlier quoted context omitted.

I used some pretty beefy boxes for industrial systems in the 80's and what struck me about them - and of the PCs of that era - is that they were all built to last for decades. Modern stuff is built to last for a couple of years at best in most cases, with some rare exceptions. Flimsy cases, plastic instead of steel. Unserviceable, non-standard and proprietary instead of standardized and repairable. Miniaturized as mu…

Yeah, add on top of that you usually got full schematics, and logic tables if there were programmable logic devices! That's how we're able to continue offering service on these systems. There's a pretty good hobbyist community around S-100, a fair number of folks are designing hobbyist-level new boards and such. A lot of that is centered around the following site: s100computers.com Some of their designs are...weird..…

There is a fair chance active use of the S-100 bus will outlast all of us :)

Re: Captain Zilog Crushed: The Story of the Z8000

#52

Post by monocasa »

FirmwareBurner wrote: post #20
thrtythreeforty wrote: post #3

Earlier quoted context omitted.

The latest round of STM32G0 is about $1 in quoted price before you start haggling. TI is launching a $0.40 (!) ARM micro soon. A modern toolchain, an ALU that doesn't suck, and a ton of ecosystem support are genuine improvements over z80. It's just the new default in the same way that z80 was a default (though less so, I grant). And I say this as someone who still knows z80 opcodes from high school programming TI cal…

>TI is launching a $0.40 (!) ARM micro soon. [...] It's just the new default in the same way that z80 was a default. And yet many cheap electronic devices will continue to be built and sold with 4-bit microcontrollers because 32 bit is overkill for those use cases and $0.40 is too expensive when 4-bit dies cost $0.05 or even $0.01, and $0.35 in savings is huge in high enough volume. You won't see any new products dev…

We're getting closer. There are riscv chips in the https://www.hackster.io/news/wch-launches-a-sub-10-risc-v-mi...

At some point you get to a weird place where the logic transistors are so small you get some gate count for free just fitting around the pad drivers and pin protection diodes. We're getting pretty rapidly to the ~10k gate count there where a stripped down classic RISC makes sense.

Re: Captain Zilog Crushed: The Story of the Z8000

#53

Post by MichaelZuo »

kens wrote: post #49
MichaelZuo wrote: post #34

> One key implementation decision was that the Z8000 would not make use of microcode. Microcode would have broken down the Z8000’s instructions into a series of simpler instructions, hidden from the outside world, which the processor would execute. Instead, all instructions would be ‘hard-wired’ into the logic of the CPU, a more challenging approach for the designer. Shima would later discuss how much more difficult…

The NEC V33 (1988) was a hardwired (not microcoded) version of the 286. The decision not to use microcode might be related to the long lawsuit between Intel and NEC over microcode. Also, as krylon points out, RISC chips generally don't use microcode.

Thanks Ken, that's pretty fascinating info. It makes me wonder if, with modern design software, a modern 64 bit CPU could be made without any microcode either.

Re: Captain Zilog Crushed: The Story of the Z8000

#56

Post by PaulHoule »

drpixie wrote: post #17
wk_end wrote: post #4

Earlier quoted context omitted.

I saw a tweet once that went something like, "Mankind strayed from god when we invented the IC", and some days I feel that. Economies of scale crush everything, including our nerdy fondness for particularly elegant ISAs.

You're right there. As transistors got cheaper, we've got into the habit of using them en-mass to prop up horrible architectures with weird (but effective) tricks like enormous look-ahead, stupendous pipelines, and gigantic caches. I recall with considerable fondness those ISAs that could be understood in ultimate detail by a simple human - the monolithic supercomputers like the Cray 1.

I dunno. There was that strange time in the 1980s where progress in microprocessors hung in the air, where Apple couldn't really find a sequel to the Apple ][, where the TRS-80 Model 4 wasn't much better than the Model 3 which wasn't better than the model 1, where Commodore came out with a new machine every year but only a few of them made any traction.

Coding assembly for the 8088 it was painfully obvious that instructions were competing on the bus with data, which is why the string instructions were so important

http://www.righto.com/2023/04/8086-microcode-string-operatio...

Today people would scoff at that sort of thing because a tight loop can sit in the I cache and be just as efficient as a microcoded string instruction.

I traded my Coco 3 (which unlike the PC had a real multitasking OS) for an 80286 machine and that was a massive jump in performance because the 80286 was starting to get those complex features that would start the "Moore's Law" period where computers got notably better on a year by year basis. The awful truth of memory latency really forces you do those "horrible" things if you want to get near the performance that is possible.

Today I am an AVR8 fan because it has separate buses for instructions and data and gets awesome performance for something very simple that doesn't use all the tricks that later processors use. It's the last 8-bit processor so it stands head and shoulders above the rest in terms of clean design and it's got a mainframe-sized register file. In assembly language you can frequently keep most of the variables you use all the time in registers, dedicate a few registers to the interrupt handler so you don't need to swap registers, etc.

As for the Cray and the IBM 3090's vector units it was nice that those things had vector instructions that weren't bound to a particular implementation length unlike the SIMD instructions that Intel has so often fumbled with that require you to rewrite your code every two year if you want to keep up, aren't available across the line (so people other than national labs and Apple don't use them) and are arguably a waste of power and die area at this point.

Re: Captain Zilog Crushed: The Story of the Z8000

#57

Post by Someone »

klelatti wrote: post #19
Someone wrote: post #16

FTA: “One cheaper version would fit into a 40-pin package. This version would have its memory address sizes limited to 16-bits and so would only be able to use 64 KB of memory. A more expensive 48-pin version would have access to a 23-bit or 8 MB address space. To support this approach, the architecture would be based on segmented addresses.” I don’t see how that follows, given the example of the 6507. https://en.wik…

I believe the Z8001 and Z8002 are different designs (can't find a die shot of the Z8001 but Z8002 die only has 40 pads). Zilog could have gone down the 6507 style route, I guess, but the Z8002 would have been more expensive to produce. So use of the word 'support' is really 'in support of a cheaper 16 bit address / 40 pin version' where savings are made not only on packaging but on the die.

Sorry, I wasn’t clear enough. The point was (and is) that I don’t see why limiting the address space to 64kB in one of the chips would require using segmented memory, not that they could have reused the same design between the two.

I mentioned the 6507 as an example where a CPU has a larger address space in the instruction set than the hardware allows.

I could also have mentioned the 68000 (32-bit addresses in the instruction set, but its address bus only had 24 bits, and it initially didn’t support virtual memory, so a byte was wasted (or, in some cases, put to creative use) in every pointer.

Re: Captain Zilog Crushed: The Story of the Z8000

#58

Post by canucker2016 »

jacquesm wrote: post #46
systems_glitch wrote: post #44

Earlier quoted context omitted.

Some of them! Some S-100 stuff is definitely cheese grade construction. We end up repairing a fair number of Altair 8800s of various models for hobbyists and collectors, and they are...not well-designed systems. It's pretty amazing how well S-100 progressed from the initial MITS design, given how slapdash it was.

I used some pretty beefy boxes for industrial systems in the 80's and what struck me about them - and of the PCs of that era - is that they were all built to last for decades. Modern stuff is built to last for a couple of years at best in most cases, with some rare exceptions. Flimsy cases, plastic instead of steel. Unserviceable, non-standard and proprietary instead of standardized and repairable. Miniaturized as mu…

One story I heard was about Compaq and how their early PCs were over-engineered.

The floppy drives of early Compaq PCs were rated/tested for a really high number of insertions/ejections. You'd have to be doing nothing BUT inserting/ejecting floppies 24/7 to even get close to the rated limit.

Some beancounter at Compaq realizes they're overpaying. They lower the rated limit of insertions/ejections by a couple orders of magnitude and let the savings flow through to the profit line with the customer none the wiser. Didn't help against Dell and the other cheaper PC manufacturers though.

Re: Captain Zilog Crushed: The Story of the Z8000

#59

Post by dfawcus »

kens wrote: post #49
MichaelZuo wrote: post #34

> One key implementation decision was that the Z8000 would not make use of microcode. Microcode would have broken down the Z8000’s instructions into a series of simpler instructions, hidden from the outside world, which the processor would execute. Instead, all instructions would be ‘hard-wired’ into the logic of the CPU, a more challenging approach for the designer. Shima would later discuss how much more difficult…

The NEC V33 (1988) was a hardwired (not microcoded) version of the 286. The decision not to use microcode might be related to the long lawsuit between Intel and NEC over microcode. Also, as krylon points out, RISC chips generally don't use microcode.

According to the datasheet, which I've just looked at, it was not a '286 equivalent. Rather it added a paging mechanism whereby a 20 bit 'linear' address was mapped to a 24 bit 'physical' address. Using 1024 16k pages, so a bit like an internal LIM 4.0 scheme, but limited to 16M total rather than 24M.

It has a pair of new instructions, to enter and exit the extended mapping mode, and the mappings are only changeable when not in the extended mapping mode. So a form of memory protection.

See pages 20 and 21 of the following:

https://datasheet.datasheetarchive.com/originals/scans/Scans...

Re: Captain Zilog Crushed: The Story of the Z8000

#60

Post by monocasa »

MichaelZuo wrote: post #53
kens wrote: post #49

Earlier quoted context omitted.

The NEC V33 (1988) was a hardwired (not microcoded) version of the 286. The decision not to use microcode might be related to the long lawsuit between Intel and NEC over microcode. Also, as krylon points out, RISC chips generally don't use microcode.

Thanks Ken, that's pretty fascinating info. It makes me wonder if, with modern design software, a modern 64 bit CPU could be made without any microcode either.

Depending on what you mean by modern, there are RISC-V cores that don't use microcode, including 64-bit OoOE cores like SonicBOOM and the T-Head C920.
Post reply on HN