@Hammer

Quote:

Commodore's in-house 16-bit Z8001 equipped C900 is trash i.e. it had no "killer business apps". I don't recall Coherent OS abstracting the CPU difference like LLVM or JavaVM. Z8000 is not backward compatible with Z80. Coherent + Z8000 needs re-compiled apps for this platform, hence a similar problem faced by non-X86 Windows NT. C900 doesn't have Steve Jobs to solve the "chicken vs egg" attracting business software on the platform. "The 16/32-bit 8 MHz Motorola 68000 came to market later the same year and turns in a time of 0.49 seconds on the same Sieve test, over twice as fast as the Z8000" C900 doesn't have Sun-3's ECC memory feature, hence it's not a "real" workstation.

All the issues regarding software apply to the Amiga 1000. That is the primary reason it failed on the market.

I am of the opinion that the C900 was the biggest missed opportunity in the CBM's history. It was a step in the right direction, IMO, and while it wasn't perfect, it was an product that would have been very popular - why? Because it had absolutely no competition at the time and there was a market for a cheap UNIX computer, especially in education.

Also, another point. Had C900 lived, Commodore would have bought Zilog. They were in discussions during the project, Zilog was financially in distress and Commodore would have bailed them out.

While the Z8000 wasn't anything special, the successor, the Z80000 was a fully pipelined 32 bit chip designed with on chip 256K cache and MMU, in 1986. Now, imagine a, let's call it, C9000 with the Z80000, out in 1987-1988, with a more up to date UNIX version and Commodore pricing(compared to the other UNIX vendors)... it would have been killer!.... While the C900 could have been the A500 of the UNIX world.

_________________

@WolfToTheMoon

I like that thought. I wonder if David and Dave will make that point in the book?

_________________
Amiga A1200, 3.1 ROMs, Blizzard 1230 MKIV 64MB & FPU, 4GB DoM SSD, Workbench 3.1

WolfToTheMoon Quote:

All the issues regarding software apply to the Amiga 1000. That is the primary reason it failed on the market. I am of the opinion that the C900 was the biggest missed opportunity in the CBM's history. It was a step in the right direction, IMO, and while it wasn't perfect, it was an product that would have been very popular - why? Because it had absolutely no competition at the time and there was a market for a cheap UNIX computer, especially in education.

The Amiga and C900 are different computers and markets. The Amiga 2500UX was an Amiga computer with Unix in the same case but at a much later date. I'm not so sure the C900 would have been successful due to a limited educational market, lack of a large flat address space, a cut down version of Unix and IBM quickly cornering the business market with the release of the IBM PC in 1981. Then there is the question of price which may have been able to compete with the IBM PC/XT/AT but likely not PC clones which followed. The Amiga integrated chipset is a much better way to compete but CBM did not continue to integrate and develop it.

WolfToTheMoon Quote:

Also, another point. Had C900 lived, Commodore would have bought Zilog. They were in discussions during the project, Zilog was financially in distress and Commodore would have bailed them out. While the Z8000 wasn't anything special, the successor, the Z80000 was a fully pipelined 32 bit chip designed with on chip 256K cache and MMU, in 1986. Now, imagine a, let's call it, C9000 with the Z80000, out in 1987-1988, with a more up to date UNIX version and Commodore pricing(compared to the other UNIX vendors)... it would have been killer!.... While the C900 could have been the A500 of the UNIX world.

The Z80000 finally had the 32 bit ISA in 1986 that the 68000 had in 1979. The more popular x86 architecture finally had the 32 bit ISA needed with the 80386 in 1985, beating the Z80000 to market. Both the x86 and Z80000 had baggage compared to the 68k. I'll comment below about the Z80000 datasheet.

https://www.datasheetarchive.com/datasheet?id=e100c073c2c967c20354c08a71ae01dfc32be5&type=O&term=Z80000%2520Zilog Quote:

In linear mode, addresses are 32 bits. Address calculations using linear addresses involve all 32 bits. In linear mode, the address space of 4G bytes is uniform and unstructured. Many applications benefit from the flexibility of linear addressing by allocating objects at arbitrary positions in the address space.

The 1979 68000 had a large flat/linear address space which the 80386 finally delivered in 1985 and the Z80000 in 1986. This is a huge advantage for the 68k over x86 and Z for half a decade. Furthermore, the x86 and Z architectures have compatibility baggage from mostly unused segment registers, outdated segmented MMU support, multiple operating/execution modes (Z has linear, segmented and compact modes while x86 has 6 modes) and segmented addressing modes may waste encoding space. The 68k ISA has one "linear" mode and a rich selection of addressing modes including more valuable PC relative address modes and addressing modes with variable sized displacements that scale across the whole 32 bit address range. There is a large advantage to designing an ISA to be 32 bit from the beginning as a 16 bit address space is so limited. The hardware cost of a 32 bit ISA CPU was high in 1979 but the popularity of the 68000 showed Motorola nailed the ISA while x86 was slow to follow but lucky do to the IBM PC poor choice of 8088. The 32 bit Z architecture was even later and was less lucky.

https://www.datasheetarchive.com/datasheet?id=e100c073c2c967c20354c08a71ae01dfc32be5&type=O&term=Z80000%2520Zilog Quote:

The pipeline allows single instructions, like register-to-register load and memory-to-register add, to execute at a rate of one per processor cycle. Thus, the peak performance of the CPU is 5 million instructions per second (MIPS) with a 10 MHz clock. In practice, the actual performance is reduced to approximately one-third of the peak because of delays due to the execution of multiple-cycle instructions, interference between instructions in the pipeline and main memory accesses for cache and TLB misses.

The Z80000 CPU is advanced with a 6-stage pipeline, most instructions are single cycle, there are 16 GP registers and it has a cache.

Hammer Quote:

Performance = IPC x clock speed

Even with the advanced CPU, "actual performance" (MIPS) is 1/3 of "peak performance". Lou would probably say the 6502 has better IPC and performance/MHz because it accesses memory faster and has fewer multiple-cycle instructions. In reality, the Z80000 is a powerful CPU design that surpassed 68k and x86 CPU designs in many ways.

RISC 32 bit architectures started appearing in about 1985 with a lot of hype which was bad timing and luck for the Z80000. Mentioned above is that the Z80000 "memory-to-register add" is single cycle. It is a CISC design with the "address calculations" stage 2 cycles before the "execution" stage thus avoiding the load-to-use stall of the classic RISC design that kills performance. RISC designs split the "memory-to-register add" into separate load and add instructions giving twice as many instructions to execute and bloated code (most CISC memory instructions are the equivalent of two RISC instructions). The relatively deep 6-stage pipeline allows more instruction level parallelism and should allow the Z80000 to be clocked up more than most CPUs back then including shallow pipeline RISC designs. The Z80000 was a promising design but performance potential alone does not guarantee market success as we found out with the WE32000/Bellmac-32A (which Zilog replaced the Z80000 with), 68060, Cyrix 6x86, SiFive U74, etc. These CPU/core designs are better than more popular so called great designs of the competition yet few people know about them.

https://www.datasheetarchive.com/datasheet?id=e100c073c2c967c20354c08a71ae01dfc32be5&type=O&term=Z80000%2520Zilog Quote:

The cache stores data in blocks of 16 bytes. Each data word in the cache has an associated validity bit to indicate whether or not the word is a valid copy of the corresponding main memory location. The cache contains 16 blocks, providing 256 bytes of storage.

The on-chip cache is a 256 bytes not "256K" bytes as you posted. It is a very flexible unified fully associate cache with write/store through and supports cache bursts. It is nicer than the 68020 256 byte direct mapped instruction cache although access timing may be better for the 68020. The 68030 added a separate 256 byte data cache and cache burst support. The 80386 had no caching other than the 16 byte code queue as x86 has more baggage to support.

year | CPU | GP regs | pipeline | caches | transistors
1984 68020 16 3-stage 256I 190,000
1985 80386 7 6-stage none 275,000
1986 Z80000 16 6-stage 256U ?
1987 68030 16 3-stage 256I+256D 273,000
1989 80486 7 5-stage 8192U 1,200,000
1990 68040 16 6-stage 4096I+4096D 1,170,000

The 68020/68030 needed more pipelining for performance. The 80386 could be clocked up but would be stalled waiting for memory a lot with few GP registers and without caches. The Z80000 looks good with plenty of GP registers, no load-to-use stalls, powerful addressing modes, a small but flexible fully associative unified cache, good pipeline depth with reasonable branch timing (1 cycle not taken, 4 cycle taken), etc. The Z80000 ISA uses a 16-bit VLE which is good and an improvement over the x86 8-bit VLE plus there is a 4 bit field in encodings for 16 GP registers. One issue is that most 32-bit sized accesses use a prefix which bloats the code. This is the same mistake the AC68080 ISA makes. Most datatypes likely were smaller sizes at first but maximizing performance and features requires using larger datatypes and the word size of the CPU. This minimizes partial register write stalls and forwarding of results may be simplified. The Z80000 may only have a 16-bit ALU judging by timings but a full 32-bit implementation would likely have had reduced performance compared to a full 32-bit 68k CPU design. The 68040 design is similar but the 68040 is a full 32-bit design and has more caches. The 68040 is still partially microcoded which the Z80000 may not have been if it followed the Z8000 path. No microcoding is higher performance and reduces the transistors but was more bug prone at that time which was a problem for the Z8000. I still prefer the 68k ISA which is simpler, more orthogonal, includes (An)+ and -(An) addressing modes and likely has better code density. It is a big advantage to start with a large flat address space which avoids much of the baggage.

Last edited by matthey on 21-Aug-2024 at 01:58 AM.
Last edited by matthey on 21-Aug-2024 at 01:57 AM.
Last edited by matthey on 20-Aug-2024 at 12:39 AM.

@WolfToTheMoon

Reminder, SUN-3 workstation has ECC memory support.

Commodore purchased MOS Technology, Inc when 65xx was rising. In late 1976, CBM, publicly traded on the NYSE with a market capitalization around US$60 million, purchased MOS (whose market cap was around US$12 million) in an all-stock merger deal.

C900 does not have "killer app" business software since Coherent on 16-bit Z8001 CPU doesn't have a CPU abstractions layer.

Commodore doesn't have Steve Jobs who courted major business software vendors for the MacOS platform.

Like Xenix, Coherent also runs on X86 PCs.

C900 is not business-ready desktop computer platform due to missing "killer app" business software.

Z80000's delays in the initial manufacturing pushed back its availability date to after that of the 80386, and the Z80000 saw little use in the market.

Coherent's Mark Williams Company closed in 1995.

Coherent is not Steve Jobs' NeXTSTEP.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

The 68020/68030 needed more pipelining for performance. The 80386 could be clocked up but would be stalled waiting for memory a lot with few GP registers and without caches.

Both 68030 and 80386 are not 1 IPC CPU design.

486 was released in April 1989 and 486-based PCs were released in late 1989.

https://archive.computerhistory.org/resources/access/text/2013/04/102723262-05-01-acc.pdf
Data Quest 1992's Estimated Long-Range Microprocessor and Peripheral Price Trends—North American Bookings

For 1992,
68030-25 CQFP, $108.75
68040-25, $418.52 (68040-40 release in May 1992)

68EC030 doesn't promote Unix use cases.
68EC040 doesn't promote Unix use cases. 68EC040 is brain-dead for desktop 68K computers with DMA.

386DX-25 PQFP, $103.00
80486SX-20, $157.75
80486DX-25, $376.75
80486DX-33, $376.75
80486DX-50, $553.25
80486DX2-50, $502.75

All 32-bit Intel X86 CPUs have Unix-capable MMU to run Xenix or IBM's multi-tasking/memory-protected OS/2 2.x.

AM386-40, $102.50, status quo disruptor. Unix capable with MMU.

MIPS R3000-25, $96.31, this is 68040 class, Unix capable with MMU.

SPARC-25, $71.00, this is 68040 class, Unix capable with MMU.


Quote:

The Z80000 looks good with plenty of GP registers, no load-to-use stalls, powerful addressing modes, a small but flexible fully associative unified cache, good pipeline depth with reasonable branch timing (1 cycle not taken, 4 cycle taken), etc.

Z80000 has 16 registers in 16-bit mode with two 16-bit registers that can combine as a 32-bit register.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

Even with the advanced CPU, "actual performance" (MIPS) is 1/3 of "peak performance". Lou would probably say the 6502 has better IPC and performance/MHz because it accesses memory faster and has fewer multiple-cycle instructions.

65CE02 has 1 IPC with 8 bit instructions, but the 16-bit memory segmentation model is "brain-dead" for complex data structures.

Without a 16-bit or 32-bit instruction microcode on a simple CPU core, 65CE02 would require several 8-bit instructions from the programmer's effort.

Quote:

In reality, the Z80000 is a powerful CPU design that surpassed 68k and x86 CPU designs in many ways.

For very low software library platforms, MIPS R2000 (released in January 1986) was attracting *nix workstation design wins.


Quote:

RISC 32 bit architectures started appearing in about 1985 with a lot of hype which was bad timing and luck for the Z80000. Mentioned above is that the Z80000 "memory-to-register add" is single cycle. It is a CISC design with the "address calculations" stage 2 cycles before the "execution" stage thus avoiding the load-to-use stall of the classic RISC design that kills performance. RISC designs split the "memory-to-register add" into separate load and add instructions giving twice as many instructions to execute and bloated code (most CISC memory instructions are the equivalent of two RISC instructions).

I'm already aware of RISC ideology's load/store operation being separated from math operations.

68030 and 80386 are not 1 IPC CPU designs.

Z80000 has a production delay into 1986 which runs into MIPS R2000's Jan 1986 release time frame. MIPS R3000 was released in June 1988.

Evans & Sutherland (for Vision workstation) and SGI (for multiple SKUs) selected the MIPS CPU family for the workstation 3D use case. Nintendo and Sony followed SGI's MIPS selection example.

Quote:

The relatively deep 6-stage pipeline allows more instruction level parallelism and should allow the Z80000 to be clocked up more than most CPUs back then including shallow pipeline RISC designs.

Z80000 has a production delay into 1986. The theory didn't match up with reality.

MIPS was able to iterate its CPU improvements quickly with R3000's released in June 1988.


Quote:

The Z80000 was a promising design but performance potential alone does not guarantee market success as we found out with the WE32000/Bellmac-32A (which Zilog replaced the Z80000 with), 68060, Cyrix 6x86, SiFive U74, etc. These CPU/core designs are better than more popular so called great designs of the competition yet few people know about them.

Z80000 has a production delay into 1986.

Steve Jobs courting major business software and MacOS's GUI user experience are major factors for MacOS's acceptance in the marketplace. Other platform vendors followed Apple's 68000 selection lead.

Hardware is meaningless without "killer app" software.

Your 68060's "8 pipeline stage" superiority argument doesn't factor in real-world overclocking attempts and it's subpar.

I have 68060 rev1 on qualified 100 Mhz SDR rated TF1260 which doesn't exist in 1994 and 1995 i.e. SDR PC100 memory for 100 Mhz 32bit bus doesn't exist in 1994 and 1995!

SysInfo has easily stepped on 68060's 4-byte per cycle fetch from L1 instruction cache limitation.

Cyrix 6x86 was killed by Quake, enough said.

For 1996, my selection for Pentium 150 Mhz / S3 trio 64 UV+ based PC over 68060-50Mhz via CyberStorm 060 /CyberGraphics 64 (S3 Trio 64V) upgrade for my A3000 is Quake for a similar amount of money. Many others followed the Quake benchmark.

The main reason why I purchased TF1260 is to investigate 68060 rev1's "8 stage pipeline" superiority for reaching higher clock speed. This is my "What IF" with 68060's upgrade path instead of Pentium 150 Mhz / S3 trio 64 UV+ based PC.

I didn't believe the hype with 68060's "8 stage pipeline". Without PiStorm32 with Emu68, I would have purchased AC68080 just to close the gap with my 1996-era Pentium 150 Mhz / S3 trio 64 UV+ based PC.


Quote:

The on-chip cache is a 256 bytes not "256K" bytes as you posted. It is a very flexible unified fully associate cache with write/store through and supports cache bursts. It is nicer than the 68020 256 byte direct mapped instruction cache although access timing may be better for the 68020. The 68030 added a separate 256 byte data cache and cache burst support. The 80386 had no caching other than the 16 byte code queue as x86 has more baggage to support.

I DID NOT claim "256K" cache for the Z80000. This is WolfToTheMoon's comment.

My "Performance = IPC x clock speed" comment is not on this topic thread. LOL

Last edited by Hammer on 20-Aug-2024 at 04:27 AM.
Last edited by Hammer on 20-Aug-2024 at 03:44 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

There would be no competition for C900 in 1985-1986 regarding UNIX workstation pricing. All other UNIX workstation vendors were charging several times more for their entry price workstations than the projected C900 pricing. Yes, those systems were faster and more advanced, but that doesn't change the fact that, for example, SUN wanted over 20 000 $ for their SUN-2/SUN-3 workstations or 15 000 $(in 1988) for the Sun 386i, IBM's 286 AT with Microsoft's Xenix was 5000$ in 1985, NeXT computer was 6500$(in 1988) while the C900 would retail at around 2500 $ in 1985.

The C900 had no competition, period. On top of that, Commodore would be selling their system through mass market chains, unlike other UNIX vendors.

With the arrival of the Z80000(in say 1987-1988), the C900 successor would be also capable of going toe-to-toe with 68K, x86 and RISC workstations in performance and features, for a lot less money.

It was a massive missed opportunity. Every source I've read tells that there was a massive interest for the C900 when it was shown. It was stupid of Commodore to cancel the C900 when most of the heavy lifting was done. However, it shouldn't be all that surprising since we all know C= management was not exactly stellar and did not truly understand what they were selling.

The Amiga and C64 gave Commodore a very successful second half of the 80s - but, neither of those computers was ready or easily adaptable for the demands and market trends that would appear in the 90s. C64 was too slow and old and Amiga was married to Motorola and it's custom chipset and OS which limited portabilty. With a UNIX based system it would have been easier to survive the eventual/probable C= demise in the 90s.


Also, I want to adress the issue that C900 would have no software at launch. So what???? What software did Macintosh, Amiga or Atari had in 1985? But, C900 had one advantage, with it being UNIX based, it would have been easier to port software on it.


Edit:Ah, yes.... I meant to swrite 256B(ytes), but for some reason(habit?) went with 256K. Sorry about that.

Last edited by WolfToTheMoon on 20-Aug-2024 at 10:02 AM.
Last edited by WolfToTheMoon on 20-Aug-2024 at 09:57 AM.

_________________

So it would have had at least 50 applications available at launch, probably ported along with Coherent - better suited as a business machine than the A1000, while costing a similar amount of money. The high resolution monochrome version might have been attractive to the digital publishing market.

_________________

@WolfToTheMoon

Was the HW anywhere near ready for public release?

Did C= have any potential costumers for such a machine?

Was there any upgrade path beyond that Z8000 (within a reasonable schedule)?

Sure the A1000 had similar issues (well the upgrade path existed) but thats not the issue.

C= was doomed the day the applied "for the masses not the classes" business tactics to their "pro" products.
The A500 gave them a few years of life extension but it wasn't profitable enough for proper longlife support and once PCs managed to intrude into the "can be had for cheap and will play good enough games I can get on the schoolyard" segment that market dried up.

Hence any "realistic" alt history fix for C= would have been applied at or even before the C64 launch.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

Was the HW anywhere near ready for public release?

yes.

Quote:

Did C= have any potential costumers for such a machine

If you look at how many UNIX workstation companies/vendors sprung out during the 80s, I'd say YES. The C900 would have been the cheapest way into a new UNIX box and I bet small businesses and academia would be the biggest C900 market.

Quote:

Was there any upgrade path beyond that Z8000 (within a reasonable schedule)?

Yes. If C900 proceeded to production, Commodore planned to buy Zilog. Zilog already had Z80000 in development and it was launched a year after C900 was planned to launch. The Z80000 was a fully pipelined 32 bit CPU with solid perfomance and possibility of further development(pending usual C= mismanagement). This could have given them parity with more upscale UNIX vendors of the late 80s, but probably at Commodore prices - meaning, much cheaper. Think something similar to NeXT computer, but probably at half the price or less.

_________________

@WolfToTheMoon

Maybe you wanna check up on the status of the prototype that surfaced a few years back.

C= wouldn't have started with a good reputation, not even with none at all so thats an issue.

As for being "the cheapest UNIX", well Coherent wasn't "UNIX" and it ran just fine on PCs of the time.

C= also didn't have the money to buy Zilog and neither the Z8000 nor the Z80000 were that compelling compared to x86 or 68k CPU available the same time for similar prices.

Now if C= had kept up good support for the PETs and replaced them with something leading to the C900 by 83 they may have had a shot.

With an optimistic 86 release and all the burnt bridges it would have been a non starter.

Last edited by Kronos on 20-Aug-2024 at 06:26 PM.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@matthey

Quote:

matthey wrote: There is a large advantage to designing an ISA to be 32 bit from the beginning as a 16 bit address space is so limited.

It depends on how the ISA is designed, but the problem with designing an architecture is that the architects tend to model it around the defined goal/target and using the opcode space as much as possible in this direction.

So, if you defined a 16 bit ISA, then very likely its opcode structure will be optimized for 16 bits (and 8 bits for a CISC), leaving little or no room for a further extension.

It also happened with the 68k: it was designed as a 32 bit ISA, and there was not much room left for a 64 bit extension.

Of course, there are much worse examples, like IA32/x86, which have exacerbated the concept.
Quote:

The Z80000 CPU is advanced with a 6-stage pipeline, most instructions are single cycle, there are 32 GP registers and it has a cache. [...] The Z80000 ISA uses a 16-bit VLE which is good and an improvement over the x86 8-bit VLE but there is only a 4 bit field in encodings for 16 GP registers. With a quick read through the manual I didn't figure out how 32 GP registers are accessed.

In fact, it has "only" (!) 16 x 32-bit registers.
Quote:

The other issue is that most 32-bit sized accesses use a prefix which bloats the code. This is the same mistake the AC68080 ISA makes. Most datatypes likely were smaller sizes at first but maximizing performance and features requires using larger datatypes and the word size of the CPU.

Exactly. I expect a poor code density, hence requiring larger caches to address it.

The Z8000 should have a good code density, but I don't think that it's a the same level of 68k.
Quote:

I still prefer the 68k ISA which is simpler, more orthogonal, includes (An)+ and -(An) addressing modes and likely has better code density. It is a big advantage to start with a large flat address space which avoids much of the baggage.

Right. And already the Z8000 was quite complex, with many instructions and several which are complicated. Z80000 is even worse, from this PoV.

So, those processors had to carry their own baggage, which might have crippled the performance in the long term.

cdimauro Quote:

It depends on how the ISA is designed, but the problem with designing an architecture is that the architects tend to model it around the defined goal/target and using the opcode space as much as possible in this direction. So, if you defined a 16 bit ISA, then very likely its opcode structure will be optimized for 16 bits (and 8 bits for a CISC), leaving little or no room for a further extension. It also happened with the 68k: it was designed as a 32 bit ISA, and there was not much room left for a 64 bit extension. Of course, there are much worse examples, like IA32/x86, which have exacerbated the concept.

the Z8000 has a 1 bit size field for 8 and 16 bit datatype sizes with no room for a 32 bit or 64 bit size. The 68000 ISA has a 2 bit size field for 8, 16 and 32 bit sizes with an unused size that could be used for 64 bit. The 68020 ISA was not smart about reserving it for a 64 bit size but that could be fixed with a 64 bit mode that simplifies instruction decoding and avoids a prefix that bloats code. As forward thinking as the 68000 ISA developers were in creating a 32-bit ISA so early, the 68020 ISA developers couldn't foresee a 64-bit ISA. Then the ColdFire developers repeated the same mistake of creating a 32-bit only ISA at a later date.

cdimauro Quote:

In fact, it has "only" (!) 16 x 32-bit registers.

Yes, you are correct. I was confused by the way the registers are numbered counting by 2 (RR0, RR2...RR28, RR30). I knew only 16 regs were being accessed at a time due to 4 reg encoding bits.

cdimauro Quote:

Exactly. I expect a poor code density, hence requiring larger caches to address it. The Z8000 should have a good code density, but I don't think that it's a the same level of 68k.

I agree. The design problem can be found in the manual.

http://bitsavers.trailing-edge.com/components/zilog/z80000/Z80000_CPU_Preliminary_Technical_Manual_Sep84.pdf Quote:

In addition, the delay caused by bus contention amounts to 0.2 procassor cycle per instruction for all of the memory systems. In general, a 32-bit memory would exhibit less bus contention then a 16-bit memory, but the memory systems show negligible difference in bus contention for this workload, which makes little use of longword operands. (Fewer than 2% of memory operands are longwords.)

A prefix for 2% of instructions may not be a problem for existing software. Software changed though as it is more efficient to use 32-bit datatypes on a 32-bit CPU. Advanced 32-bit CISC CPUs like the Pentium and 68060 were soon using over 50% 32-bit datatypes and 32-bit RISC CPUs may have been even higher due to less support for smaller datatypes. That is an ISA killing assumption. The AC68080 ISA similarly assumes that 64-bit datatypes will remain uncommon enough that a prefix will not cause code bloat.

P.S.
Lou and Hammer should read the Z80000 manual linked above pages E-19 and E-20. The proper way to calculate millions of instructions per second (VAX MIPS) is shown which includes not just the average instruction latency but average pipeline delay, average addressing delay and average memory delay. The Z80000 average instruction execution cycles is 1.8 cycles but the average instruction cycles can increase to 2.5 to 4.0 cycles depending on the memory used. This is with 16 GP registers and a fully associative 256B unified cache with a 62% to 88% hit ratio. A 6502 with 3 registers and no cache is likely to have a hard time with the memory delay no matter how optimized the memory accesses are.

@matthey

Quote:

matthey wrote: cdimauro Quote: It depends on how the ISA is designed, but the problem with designing an architecture is that the architects tend to model it around the defined goal/target and using the opcode space as much as possible in this direction. So, if you defined a 16 bit ISA, then very likely its opcode structure will be optimized for 16 bits (and 8 bits for a CISC), leaving little or no room for a further extension. It also happened with the 68k: it was designed as a 32 bit ISA, and there was not much room left for a 64 bit extension. Of course, there are much worse examples, like IA32/x86, which have exacerbated the concept. the Z8000 has a 1 bit size field for 8 and 16 bit datatype sizes with no room for a 32 bit or 64 bit size.

Which could have been used in a much smarter way.
Quote:

The 68000 ISA has a 2 bit size field for 8, 16 and 32 bit sizes with an unused size that could be used for 64 bit. The 68020 ISA was not smart about reserving it for a 64 bit size but that could be fixed with a 64 bit mode that simplifies instruction decoding and avoids a prefix that bloats code. As forward thinking as the 68000 ISA developers were in creating a 32-bit ISA so early, the 68020 ISA developers couldn't foresee a 64-bit ISA.

Unfortunately this big mistake already started with the 68000, where the Size = 11 was used for mapping other instructions (with MOVE being the most notable).
Quote:

Then the ColdFire developers repeated the same mistake of creating a 32-bit only ISA at a later date.

That's not necessarily a bad thing, but it depends on how you structure your ISA.

In this (68k) case, it was a really bad thing, because it ruined one of the advantaged of this CISC family: using data types of different sizes in a compact way.
MVZ and MVS were nice (and needed!) additions but cannot overcome this failure.
cdimauro Quote:

In fact, it has "only" (!) 16 x 32-bit registers.

Yes, you are correct. I was confused by the way the registers are numbered counting by 2 (RR0, RR2...RR28, RR30). I knew only 16 regs were being accessed at a time due to 4 reg encoding bits.[/quote]
Well, here it depends also on how you use the bits. The 68k sports only 3 bits (in the EA filed) for a register encoding, but it has 16 registers.
Quote:

cdimauro Quote: Exactly. I expect a poor code density, hence requiring larger caches to address it. The Z8000 should have a good code density, but I don't think that it's a the same level of 68k. I agree. The design problem can be found in the manual. http://bitsavers.trailing-edge.com/components/zilog/z80000/Z80000_CPU_Preliminary_Technical_Manual_Sep84.pdf Quote: In addition, the delay caused by bus contention amounts to 0.2 procassor cycle per instruction for all of the memory systems. In general, a 32-bit memory would exhibit less bus contention then a 16-bit memory, but the memory systems show negligible difference in bus contention for this workload, which makes little use of longword operands. (Fewer than 2% of memory operands are longwords.) A prefix for 2% of instructions may not be a problem for existing software. Software changed though as it is more efficient to use 32-bit datatypes on a 32-bit CPU. Advanced 32-bit CISC CPUs like the Pentium and 68060 were soon using over 50% 32-bit datatypes and 32-bit RISC CPUs may have been even higher due to less support for smaller datatypes. That is an ISA killing assumption.

Exactly. On modern software 32 bits are heavily used, so the Z80000 had no other chance to bloat the code with the 16 prefix, decreasing a lot the code density.

That was another short-minded decision (prefix should be avoided as much as possible as a general rule, but especially on common instructions / data types).
Quote:

The AC68080 ISA similarly assumes that 64-bit datatypes will remain uncommon enough that a prefix will not cause code bloat.

In fact. But that's not really a big problem, because the Apollo 68080 isn't a 64 bit architecture: it's just 32 bit with 64-bit data-only support.

This is ISA has already no future and will remain on the 32-bit domain.
Quote:

P.S. Lou and Hammer should read the Z80000 manual linked above pages E-19 and E-20. The proper way to calculate millions of instructions per second (VAX MIPS) is shown which includes not just the average instruction latency but average pipeline delay, average addressing delay and average memory delay. The Z80000 average instruction execution cycles is 1.8 cycles but the average instruction cycles can increase to 2.5 to 4.0 cycles depending on the memory used. This is with 16 GP registers and a fully associative 256B unified cache with a 62% to 88% hit ratio.

That's why it had good performance.
Quote:

A 6502 with 3 registers and no cache is likely to have a hard time with the memory delay no matter how optimized the memory accesses are.

Even with caches, it remains a toy.

@Kronos

Quote:

Kronos wrote: @WolfToTheMoon Was the HW anywhere near ready for public release? Did C= have any potential costumers for such a machine? Was there any upgrade path beyond that Z8000 (within a reasonable schedule)? Sure the A1000 had similar issues (well the upgrade path existed) but thats not the issue. C= was doomed the day the applied "for the masses not the classes" business tactics to their "pro" products.

"Workstation graphics for masses" enables economies of scale which enabled NVIDIA to beat graphics workstation establishments like SGI and 3DLabs.

When Henri Rubin issued "monochrome hi-res Denise" directive in mid-1986 and canceled Amiga Ranger, this R&D directive is too late when IBM recycled the use cases from 1984's PGC into 1987's VGA (256 at low resolution and 16 colors at 640x480p) and 8514 (256 colors at 640x480p). The SVGA clones targeted VGA's and 8514's resolution with 256 color capabilities.

Apple released 640 x 480p 256 color Macintosh II and color Quickdraw (similar to RTG) in 1987 which is an important foundation for following lower cost colored Macs.

Commodore was a headless chicken after IBM's 1987 nuke drop. The second nuke was dropped by Microsoft Windows 3.0's and Wing Commander 1990's releases.

Prior to Windows 3.0's 1990 release, Windows 2.x Excel (1987, 1988) and WinWord (1989) created a situation that enabled Microsoft to displace high-resolution text-based establishments such as Lotus 123, Word Star and Word Perfect. Microsoft's perfect storm is not monochrome business resolution.

According to Dataquest November 1989, VGA crossed more than 50 percent market share in 1989 i.e. 56%.
http://bitsavers.trailing-edge.com/components/dataquest/0005190_PC_Graphics_Chip_Sets--Product_Analysis_1989.pdf

Low-End PC Graphics Market Share by Standard Type
Estimated Worldwide History and Forecast

Total low-end PC graphic chipset shipment history and forecast
1987 = 9.2. million, VGA 16.4% market share i.e. 1.5088 million VGA.
1988 = 11.1 million, VGA 34.2% i.e. 3.79 million VGA.
1989 = 13.7 million, VGA 54.6% i.e. 7.67 million VGA.
1990 = 14.3 million, VGA 66.4% i.e. 9.50 million VGA.
1991 = 15.8 million, VGA 76.6% i.e. 12.10 million VGA.
1992 = 16.4 million, VGA 84.2% i.e. 13.81 million VGA.
1993 = 18.3 million, VGA 92.4% i.e. 16.9 million VGA.

1990's Atari TT030's 256 color business resolution unit sales are tiny.

For low cost gaming market,
1990's SNES's 256 color capability nuked C64 and A500 from the East Asian market.
1991's SNES's 256 color capability nuked C64 and A500 from the North American market.
1992's SNES's 256 color capability nuked C64 and A600 from the European market. A1200's 44,000 units wouldn't be enough. For Xmas 1992, Commodore spent its remaining cash on ECS A600, hence it's game over at this point.

256 color from PC's top end and SNES's low end are like the jaws shutting down on Amiga OCS/ECS.

Henri Rubin didn't listen to Jeff Porter's 8 bitplane arguments in 1987!

Henri Rubin wasted R&D resources on workarounds such as Amber flicker ficker, Hedley Hi-Res" A2024 monitor, #metoo monochrome hi-res Denise, four color hi-res Denise and A2410 TMS34010 graphics card.

Quote:

The A500 gave them a few years of life extension but it wasn't profitable enough for proper longlife support and once PCs managed to intrude into the "can be had for cheap and will play good enough games I can get on the schoolyard" segment that market dried up. Hence any "realistic" alt history fix for C= would have been applied at or even before the C64 launch.

You didn't read Commodore - The Final Years.

Since 1989's 386 excess stock debacle, Commodore PC was one of the millstone around Amiga's neck.

For the North American market, C64's budget gaming segment was slowly killed by NES. SNES was the final nail on the coffin for both A500 and C64.

Commodore wasn't ready against SNES's 1991 release in North America.

Last edited by Hammer on 21-Aug-2024 at 08:00 AM.
Last edited by Hammer on 21-Aug-2024 at 06:05 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@matthey

Quote:

P.S.Lou and Hammer should read the Z80000 manual linked above pages E-19 and E-20. The proper way to calculate millions of instructions per second (VAX MIPS) is shown which includes not just the average instruction latency but average pipeline delay, average addressing delay and average memory delay.

Quake, enough said.

I will continue to throw Quake at you since this is a major factor that killed many desktop CPUs.

Quote:

The Z80000 average instruction execution cycles is 1.8 cycles but the average instruction cycles can increase to 2.5 to 4.0 cycles depending on the memory used. This is with 16 GP registers and a fully associative 256B unified cache with a 62% to 88% hit ratio. A 6502 with 3 registers and no cache is likely to have a hard time with the memory delay no matter how optimized the memory accesses are.

Quake is resistant against Pentium 83 Overdrive's larger 32 KB (16 kB + 16 kB) L1 cache. Pentium Overdrive's 32 KB L1 cache was reused for Pentium MMX.

32-bit Z80000 is too late for Apple, Amiga and Atari platform vendors.

Z8000's memory segmentation model was rejected by Apple, Amiga and Atari platform vendors.

For Atari ST, one of the key engineers for Commodore 900 selected 68000 ahead of Z8000.


65CE02 has 1 IPC with 8-bit instructions, NOT the 6502. CSG added extra registers for 65CE02, but it remains inferior to ARM2's 16 32-bit registers.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@WolfToTheMoon

Quote:

WolfToTheMoon wrote: So it would have had at least 50 applications available at launch, probably ported along with Coherent - better suited as a business machine than the A1000, while costing a similar amount of money. The high resolution monochrome version might have been attractive to the digital publishing market.

Named these so-called "50 applications".

In 1985, Aldus PageMaker was released on Apple's MacOS, hence DTP on the get-go. MS Excel and Word in GUI version was also released in 1985. Macintosh 512K was released on September 1984. LaserWriter (Postscript) also released in 1985. Negotiations between Apple and Adobe over the use of PostScript began in 1983 and an agreement was reached in December 1983.

In 1987, QuarkXPress was released on Apple's MacOS.

Bill Gates used Apple's Macintosh experience to call IBM's OS/2 focus on 16-bit 286 as "brain dead" and used GUI WIMP to break high-resolution text-based establishment.

Aldus PageMaker helped to popularize both the Macintosh platform and the Windows environment. A key component that led to PageMaker's success was its native support for Adobe Systems' PostScript page description language.


https://www.youtube.com/watch?v=-edukIuxlYg
Commodore 900's demo is inferior to Macintosh's GUI WIMP demo. The command prompt from C900 is LOL.

https://youtu.be/2B-XwPjn9YY?t=49
Steve Job's Macintosh's 1984 release demo.

Commodore didn't have Steve Job's showmanship.

Commodore 900 didn't have Macintosh's GUI.

Commodore 900 didn't have Macintosh's GUI business apps.

There's nothing about Commodore 900 being different from a PC running Xenix or Coherent.

After I viewed several Commodore 900's demos, they are not polish when compared to Apple's Macintosh.

Coherent is not Steve Job's NextSTEP.

Coherent is a dead duck in 1995 along with Commodore UK's 1995 liquidation!

MAME has Commodore 900 emulation.

Last edited by Hammer on 21-Aug-2024 at 08:17 AM.
Last edited by Hammer on 21-Aug-2024 at 07:39 AM.
Last edited by Hammer on 21-Aug-2024 at 07:33 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

Quote:

You didn't read Commodore - The Final Years. Since 1989's 386 excess stock debacle, Commodore PC was the millstone around Amiga's neck.

Yep I for sure don't read any fan fiction level history books.

By 89 it was all too late, OCS/ECS Amigas could only be sold at lower and lower prices, AGA was nowhere near ready and would have been too little too late even if.

On top of that they were a 3rd tier OEM in a PC market where even 1st tier ones struggled.

So no there wasn't a single issue that killed C= just many small ones all routed in decisions made in the early 80s.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

@Kronos Yep I for sure don't read any fan fiction level history books.

It's not fan fiction when information is from former Commodore employees.


Quote:

@Kronos By 89 it was all too late, OCS/ECS Amigas could only be sold at lower and lower prices, AGA was nowhere near ready and would have been too little too late even if.

A500 game packs driven 1990 and 1991 boom sales are hiding Commodore PC's inventory control debacle.

Quote:

@Kronos On top of that they were a 3rd tier OEM in a PC market where even 1st tier ones struggled.

The problem is inventory control and weak road map access to Intel's 486 plans.

In early 1989, Commodore stockpiled with 386 CPUs.

From Commodore - The Final Years,
Quote:

During 1989, Frank and his team worked on the two latest models in the PC line that contained the Intel 80386 chip, which debuted back in 1985. Frank himself was product manager on the PC-60 tower computer, while the PC-50, a desktop, was in the works. However, in 1989 things began to change. “That was a time when there was Compaq and then everyone else,� says Joe Augenbraun. “Compaq came out with a 386 machine first because they were working directly with Intel. No one else had a 386 machine, not even IBM. And everyone else was scrambling to come out with a 386 machine.� In 1989 Commodore was finally about to match what Compaq had released years earlier. “By the time they came out with a 386 machine, Compaq came out with a 486 machine,� says Augenbraun. “So everyone was sort of a generation behind, other than Compaq, including IBM. So Commodore was in with the unwashed masses of being a generation behind, and Commodore was even slightly worse.� Intel had announced the 80486 at the Spring COMDEX in April 1989, with samples of the new chip expected for the third quarter of 1989 and production quantities in the fourth quarter of 1989. And as usual, Compaq was the first to announce a system using the new chip. “Until it got to the 486, Commodore was trying to build the previous generation machine. They were really behind,� says Augenbraun.

Intel played favoritism. Commodore is not Compaq.

Commodore Germany's cooking the books from Commodore - The FInal Years,
Quote:

Several warehouses housed old parts from past devices that were no longer marketable, such as PET, Plus/4, and VIC-20 computers. For example, Commodore had only assembled 20,000 C64GS systems but had manufactured 60,000 cases. They had reworked the C64GS motherboards into regular C64 computers but were now stuck with all those cases. “There was a C64 game console project which basically you took a C64 and you put it in a different case, which came without the keyboard,� explains Proudfoot. “Somebody thought that was a good idea. They built all the cases and there was a warehouse full of parts.� To remain compliant with the rules for public companies, Proudfoot realized Commodore would have to write down the value of those warehoused parts. He prepared a report for Mehdi Ali. “The German management were aghast that I was going to tell him all this stuff,� says Proudfoot. “He had a reputation for firing people who gave him bad news. I said, ‘Well I’ve got my three month assignment. I’m guaranteed money so I don't care if he fires me. That's OK.’� Ali was not amused by the findings. “I told Mehdi the true value of the German inventory was a fraction of what they had on the books,� recalls Proudfoot. “For the number of years it had been going on, it's very poor management if they're not aware of it. We just went through the report and Mehdi exploded. I had answers to all his questions because I had done my homework. But he fired three or four of the German management after I had left the meeting because it was a mess. It was a big write-down.� Ali was impressed by Proudfoot’s speedy resolution of the inventory problem and his discovery of the overvalued inventory. As a result, Ali would later hire him to address an even more serious issue. “Ever since then Mehdi and I got on, because I wasn't hiding anything from him,� says Proudfoot. “I just gave him honest answers and I knew what I was doing.� (skip)

There's additional information on "cooking the books" from Commodore's European operations. Proudfoot will bring down another Commodore managing director.

For CDTV-CR with AGA, the hardware C2P story was interesting i.e. management resisted and C2P was placed in by stealth and it was too late when it was discovered.

Last edited by Hammer on 21-Aug-2024 at 09:15 AM.
Last edited by Hammer on 21-Aug-2024 at 09:04 AM.
Last edited by Hammer on 21-Aug-2024 at 08:54 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

This is a joke, right?

Macintosh(the original) was a complete failure, lacking memory and performance. It didn't sell well and it was one of the main reasons why Jobs left/was fired.

Let's compare the specs of the C900 and the original Macintosh/Macintosh 512K

Macintosh vs C900
CPU: 68K at 7 MHz(no FPU option) vs Z8001 at 10 MHz(FPU coprocessor optional)
RAM: 128K/512K, with no expansion vs 512K with up to 2MB expansion
HDD: No HDD vs 20 MB HDD standard, up to 67 MB
Screen/Graphics:)9" screen with 512X342(used the RAM memory) vs 15" screen 1024X800(dedicated 128 kB 8563 MOS video chip)
Floppy drive: 400K vs 1.2 MB
OS: single user, no multitasking piece-of-shit vs UNIX, multiuser, multitasking


It wasn't even close! On top of that, C900 was to be priced as same as the base Macintosh, which in 1985 was mostly useless because of the slow system perfomance. Macintosh wouldn't really come into it's own until the expandable Macintosh II range was launched in 1987, which was fast, but extremely expensive(at 5500$ base price) and still had the same shitty OS.

Last edited by WolfToTheMoon on 21-Aug-2024 at 09:12 AM.

_________________