@Karlos

Quote:

Karlos wrote: This is all a massive load of bollocks. Commodore didn't design the Amiga, Hi-Toro did. Consequently Commodore had no say whatsoever in the CPU selection; it happened before they bought it. It would have been suicide to release the A1000 then release a successor based on a different CPU that the machine wasn't designed around. There was no "missed opportunity" here, thankfully. But it was OK, commodore had plenty of further opportunities to screw up and they didn't miss a single one.

The original Los Gatos Amiga team didn't cost reduce the successful Amiga 500.

For cost reduction, Amiga 500's Gary chip was outsourced to VLSI Technology Inc (VTI).

From Commodore - The Final Year,
Quote:

CSG was able to produce Agnus, Denise, and Paula for $5.49, $5.19, and $7.91 respectively. Curiously, Gerard Bucas did not trust CSG to produce the Gary chip on time. “MOS Technology, I would say, eventually became a millstone around Commodore’s neck,� he says. “Jeff Porter and I, but especially me, decided, ‘Listen, I'm not going to do the gate array with them. I don't believe they can meet the timeline and I don't believe they can make it in volume at the right price.’� This was not politically popular at Commodore, but Bucas felt it was the correct move. “We designed it, but the manufacturing of that, we actually outsourced to someone else,� he says. “We outsourced the chip to VLSI Technology, which was a third-party chip company.� It was up to Bucas to negotiate with suppliers and make sure Commodore received the best prices. A few years ago, the 68000 sold for $15 in quantity. Now Bucas negotiated it down to $5 per unit.

Around August 1987, CSG started to fabricate Amiga's Gary chip.

Amiga's success is based on two halves i.e. the original Los Gatos Amiga team's cutting-edge R&D specialty and the systems engineering group's cost reduction specialty.

Commodore management killed the balance between the two halves.

Commodore's LSI team wasn't quick enough for the original ECS Denise's high resolution 8 colors with a shared 4096 palette which the LSI team labeled as too complex. LOL

Henri Rubin is the major factor for the lost years between 1986 and 1988. Henri Rubin has no experience with computer design except for being a friend of Irving Gould's.

Henri Rubin ordered #metoo monochrome high-res Denise and canceled the Amiga Ranger R&D.

Commodore's LSI team is blamed for the 4 color with 64 color palette high-res Denise. #too complex. Commodore's LSI team backed the C65 project instead of the Amiga.

Henri Rubin's pet project is turning Amiga into an X86 PC i.e. bridgeboard R&D.

Henri Rubin is blamed for A2410 (TIGA) workaround.

Henri Rubin is blamed for Amber flicker fixer workaround.

Henri Rubin is blamed for the A2024 high-res monitor workaround.

Henri Rubin focuses on Amiga add-ons.

Mehdi Ali ordered the A1200's design in Feb 1992 which is followed by Jeff Porter's CD32.

Jeff Porter has to justify every major component in CD32 to Commodore management which reduced CD32 with 40 Mhz MIPS-X based SoC + 8 MB RAM + AGA/EC020 + Akiko C2P into a barebone CD32.

For Xmas 1992 sales period, Commodore management ordered too many A600 and didn't order enough Lisa chips from HP.

Last edited by Hammer on 26-Aug-2024 at 05:38 AM.
Last edited by Hammer on 26-Aug-2024 at 05:30 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

@WolfToTheMoon

Quote:

WolfToTheMoon wrote: @cdimauro Quote: However, workstations and servers have different needs. Commodore wasn't in a business selling workstations and servers. Their bread and butter were cheap home computers. And in that market, in 1985, 6502>68000. Strategically, it made a lot more sense to design a backwards compatible cheap 6502 16/32 bit home computer system than the Amiga, but not like the C128 was.

Well, they decided to build the C128 primarily for running CP/M, which was a business OS and for a much more costly market segment (however, PETs were sold for business as well and they were costly; so, not a news here).

A totally crazy move, since DOS already took a large part of the business market, and CP/M was fading, but we know how Commodore management was, right?

Despite this, which 16/32 bit 6502 system could Commodore have produced in 1985? None.
For 32-bit not for sure because there was no such processor available.
For 16-bit there was only the 65816, which was released just this year. So, not an option again, since it takes time to develop a new system and of course you need some processors for it (e.g.: no time machine available for the engineers).

The maximum that Commodore was able to produce is the 65CE02, but on 1988, and it was still an 8 bit processor...
Quote:

Quote: Then please tell me more about my Plus/4 and its compatibility with the previous Commodore's machines, from Pets to the Vic20 and C64... that was not CPU's fault.

It's also a problem, because the processors were incompatible (with the exception of PETs and the VIC 20, which shared the 6502).

Once you integrate a sort of MMU on the processor, and it's different from a processor to another one, then it's not easy to write software which is compatible with all such processors.

Especially when you also have to take into account different memory maps for distributing the code and the assets.

Backward-compatibility wasn't really on Commodore scope, and the C128 is almost compatibile with the C64 just by case.

@agami

Quote:

agami wrote: @Karlos Quote: Karlos wrote: This is all a massive load of bollocks. Commodore didn't design the Amiga, Hi-Toro did. Consequently Commodore had no say whatsoever in the CPU selection; it happened before they bought it. It would have been suicide to release the A1000 then release a successor based on a different CPU that the machine wasn't designed around. There was no "missed opportunity" here, thankfully. But it was OK, commodore had plenty of further opportunities to screw up and they didn't miss a single one. The argument could be made (but not won) that Commodore could've asked the Hi-Toro team to re-engineer the Amiga computer around a different CPU.

You're asking for the impossible, since the Amiga OS was largely written in 68000 assembly.

The developers were already very late compared to the hardware, as we know from history. In fact, they had to rush like devils to be ready for the first presentation (January 1984).

And they were using a 68000, which was/is a piece of cake to code in assembly!

Now imagine that on August 1984 the new owner, Commodore, asked to use another processor (whatever it was): do you think that they were able to rewrite all such software?

On top of that, we know very well that the part of the Amiga OS software was loaded from disk because it wasn't mature enough.

So, when the machine with the new processor should have been released? Another couple of years after? Not even a chance...

@cdimauro

C128's Z80 CP/M + high-resolution text VDC was a weak #metoo move by the Commodore LSI team.

_________________
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

@cdimauro

Quote:

cdimauro wrote: Well, they decided to build the C128 primarily for running CP/M, which was a business OS and for a much more costly market segment (however, PETs were sold for business as well and they were costly; so, not a news here). A totally crazy move, since DOS already took a large part of the business market, and CP/M was fading, but we know how Commodore management was, right?

And yet at the same time Amstrad put CP/M in the CPC series, then used it in their very successful 'word processors' (which were actually full computers that could play games too!). Crazy huh?

Now some historical context. Before the IBM PC came out in August 12, 1981 (starting at US$1,565 for a configuration with 16 kB RAM, Color Graphics Adapter, no monitor, and BASIC in ROM with a cassette port and no disk drives) CP/M was the primary OS used in business microcomputers. This wouldn't change overnight. The C64 was released almost exactly one year later, in August 1982. On the box it promised CP/M compatibility via a Z80 CPU cartridge.

At this time the PC was still in its infancy (the PC XT wouldn't arrive until March 1983) and only one legal fully compatible clone was available (the MPC 1600). Meanwhile other mainframe and minicomputer manufacturers such as Hewlett-Packard, Xerox, and Control Data Corporation were producing microcomputers using CP/M as the OS.

Without the benefit of hindsight it was perfectly reasonable to assume that CP/M would continue to be a popular OS for quite a few more years. Furthermore a large library of software was available for it, including compilers, assemblers and BASIC interpreters - all of which would run on any CP/M machine (preferably but not necessarily with 80 column text and 64k RAM). This meant that the C64 could have business and development software ready to go on launch without any effort.

There was just one problem - the Z80 CPU cartridge wasn't ready when the C64 was launched. The FCC forced Commodore to remove the advert from the box until they actually had the product ready for sale. Then a while later they changed the clock chip in the C64, and the CP/M cartridge wouldn't work with it. "Big deal.", you say, "Nobody was using it so..." and there you would be wrong. Some people were using it, and they complained.

Now fast forward to 1984 when Commodore decided to produce the C128 as a stopgap until Amiga sales ramped up. It was based on another machine being developed that used a 6809 CPU and 6845 display controller with 80 column text, called the D128. The engineers had also hacked a VIC-II chip into it to get color graphics, but it was not compatible with the C64. When Bil Herd took over the project he decided to redesign it with C64 compatibility in mind, unlike the Plus/4 which wasn't. That was a smart decision IMO - why have all that C64 hardware in it and not be C64 compatible?

However again there was a problem. Marketing quite rightly insisted that it be 100% C64 compatible, as they didn't want any flack from customers or the FCC. That meant it had to be compatible with the CP/M cartridge! With the C128 having 80 column text this was even more desirable. However the cartridge had a lot of bus interface chips that drew more power than the C128's internal supply could handle. A more expensive power supply would be needed, or would it? Bil Herd came up with the brilliant idea of putting the Z80 on the motherboard, which turned out to be cheaper than upgrading the power supply. The Z80 was effectively free!

So the C128 got CP/M because Commodore didn't want to fined again for false advertising. Building it in effectively cost nothing, and the new 1571 disk drive would be more compatible with other CP/M disk formats. CP/M may have been dying at this point (Amstrad not withstanding) but it didn't cost much to add it to the C128 so it wasn't a big deal.

Quote:

Despite this, which 16/32 bit 6502 system could Commodore have produced in 1985? None.

Exactly. The 65C816 was originally developed for Apple, but the first batch didn't work at all and the next lot maxed out at ~3 MHz. Apple was forced to use this non-catalog 3MHz part in the Apple IIGS, which was released in September 1986. Commodore would not be able to get their hands on a large quantity of 65C816 CPUs in 1985 - if any. It was a total non-starter. Furthermore they wouldn't want to when they were making their own cheaper 6502 variants in-house.

Quote:

Backward-compatibility wasn't really on Commodore scope, and the C128 is almost compatibile with the C64 just by case.

The Plus/4's lack of compatibility was quickly realized to be a mistake - a mistake that Jack Tramiel made in his quest to drive out the competition. Instead it became a mill-stone around post-Tramiel Commodore's neck. That was not a mistake they wanted to repeat! C64 compatibility saved the C128.

Last edited by bhabbott on 26-Aug-2024 at 10:18 AM.

@Hammer

Quote:

Hammer wrote: C128's Z80 CP/M + high-resolution text VDC was a weak #metoo move by the Commodore LSI team.

I disagree. From Bil Herd's book "Back Into The Storm" which I recently bought from Amazon Australia:-
Quote:

In my mind, it was to get users and CBM used to to the 80-column concept... I pushed for a continuance of the 80-column chip that was common in the business machines... I had designed computers with the 6845 CRT controller... it was an old friend, and I was certain I could make it do color

Some other home computers had an 80-column mode, but few did it in color. The BBC micro did it in two colors via a 640x200 bitmap screen, as did the Amstrad CPC. The Apple II did it with the optional 80 column card, which was monochrome. 80 column text was standard on CP/M machines, but again generally only monochrome with no bitmap graphics. MSX 2 got it in 1985 same as the C128, so Commodore wasn't copying them either. Atari's 8-bit machines only did 40 column text.

So who exactly was Commodore '#metoo'ing with their high-resolution color text?

As for CP/M, perish the thought that a computer manufacturer might want to follow a standard. I guess we should excoriate Dell, Acer, HP and Toshiba for producing machines that all run the same OS, right?

@bhabbott

Quote:

Exactly. The 65C816 was originally developed for Apple, but the first batch didn't work at all and the next lot maxed out at ~3 MHz. Apple was forced to use this non-catalog 3MHz part in the Apple IIGS, which was released in September 1986. Commodore would not be able to get their hands on a large quantity of 65C816 CPUs in 1985 - if any. It was a total non-starter. Furthermore they wouldn't want to when they were making their own cheaper 6502 variants in-house.

Nobody's arguing for the use of 65816. MOS was perfectly capable of developing a 16/32 bit extension to the 6502 in the late 70s/early80s.... but it didn't, because Tramiel cut costs.

In the late 70s, early 80s... Commodore was in a really unique position. They had the market and they had the complete vertical integration that possibly no other manufacturer at the time had. They were very nicely positioned to exploit these competitive advantages when going 16/32 bit, but because of the lack of vision on behalf of Tramiel and constant cost-cutting, they had to buy in on outside projects(Zilog's chips in the case of the aborted C900, Lorraine in the case of the Amiga).
This weakened Commodore's market position considerably as they had to start from scratch in the 16/32 bit era, not being able to exploit a large base of 6502 software that already existed.

There really was no good reason not to do a inhouse 16/32 bit 6502 earlier than WDC 65816. Only poor management.

_________________

Anyone arguing for anything other than the 68000 is loving in cloud cuckoo land.

Commodore recognised the Hi-Toro machine was groundbreaking when they saw it. Getting into production while the advantage could be capitalised on was the priority. Not telling the hardware designers that the system they'd built, carefully designed around around DMA enabled custom chips and memory sharing with the CPU needed to have that CPU swapped out for some cheap, untested 8-bit outgrowth. Pronto pronto!!

_________________
Doing stupid things for fun...

@Karlos

Quote:

Commodore recognised the Hi-Toro machine was groundbreaking when they saw it.

nobody's arguing that.

I'm arguing C= could have had an inhouse 16/32 bit design, cheaper than Amiga, that could have been backwards compatible with the C64 - if they played their cards right!

Did the market appreciate the Amiga's custom chipset at launch? It didn't. Apart from some fun demos, nobody cared. It was too expensive(especially coming from Commodore, who were known for cheap home computers) and it had no software. It took another 3-4 years and the A500 for amiga to get going.
I'm not arguing if the Amiga was great, it was. Nobody denies that.
PC showed what a great asset backwards compatibility was. On the Amiga side, you couldn't even guarantee full backwards compatibility within Motorola's own 68K family because of Motorola's shenanigans. And then they pull the rug from 68K users in the 90s.

_________________

@WolfToTheMoon

The Amiga was a moonshot. Whether or not the market appreciated it or not, it set key standards which all future personal computer hardware would eventually need to match:

Hardware accelerated graphical operations
Hardware accelerated audio playback
Self-configuring expansions

Also, operating system/software features:

Full graphical user interface/desktop
Preemptive multitasking

The word "multimedia" hadn't been invented yet, but by every meaningful measure, the Amiga defined it.

The Amiga was also a move into the 32-bit era. Sure, we called it a 16-bit machine because back then we looked at ALU width but the 68000 was a forwards facing CPU without all the unnecessary crap that comes with maintaining 8-bit backwards compatibility.

The machine you are describing would have been firmly anchored in the past in 1985.

Last edited by Karlos on 26-Aug-2024 at 04:14 PM.
Last edited by Karlos on 26-Aug-2024 at 04:13 PM.

_________________
Doing stupid things for fun...

@WolfToTheMoon

Quote:

WolfToTheMoon wrote: @Karlos Quote: Commodore recognised the Hi-Toro machine was groundbreaking when they saw it. nobody's arguing that. I'm arguing C= could have had an inhouse 16/32 bit design, cheaper than Amiga, that could have been backwards compatible with the C64 - if they played their cards right! Did the market appreciate the Amiga's custom chipset at launch? It didn't. Apart from some fun demos, nobody cared. It was too expensive(especially coming from Commodore, who were known for cheap home computers) and it had no software. It took another 3-4 years and the A500 for amiga to get going. I'm not arguing if the Amiga was great, it was. Nobody denies that. PC showed what a great asset backwards compatibility was. On the Amiga side, you couldn't even guarantee full backwards compatibility within Motorola's own 68K family because of Motorola's shenanigans. And then they pull the rug from 68K users in the 90s.

PC's backwards compatibility is the entire platform not just the x86 CPU.

There are other non-PC x86 that are not compatible with the standard x86 PC clones.

Commodore 65xx-based computers prove backwards compatibility can be a mess. C64 has a 3rd party PET emulator.

Last edited by Hammer on 26-Aug-2024 at 05:00 PM.

_________________
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

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: Well, they decided to build the C128 primarily for running CP/M, which was a business OS and for a much more costly market segment (however, PETs were sold for business as well and they were costly; so, not a news here). A totally crazy move, since DOS already took a large part of the business market, and CP/M was fading, but we know how Commodore management was, right? And yet at the same time Amstrad put CP/M in the CPC series, then used it in their very successful 'word processors' (which were actually full computers that could play games too!). Crazy huh?

Without any doubt.
Quote:

Now some historical context. Before the IBM PC came out in August 12, 1981 (starting at US$1,565 for a configuration with 16 kB RAM, Color Graphics Adapter, no monitor, and BASIC in ROM with a cassette port and no disk drives) CP/M was the primary OS used in business microcomputers. This wouldn't change overnight. The C64 was released almost exactly one year later, in August 1982. On the box it promised CP/M compatibility via a Z80 CPU cartridge. At this time the PC was still in its infancy (the PC XT wouldn't arrive until March 1983) and only one legal fully compatible clone was available (the MPC 1600). Meanwhile other mainframe and minicomputer manufacturers such as Hewlett-Packard, Xerox, and Control Data Corporation were producing microcomputers using CP/M as the OS. Without the benefit of hindsight it was perfectly reasonable to assume that CP/M would continue to be a popular OS for quite a few more years.

Sure, nothing to say here: it started years before, so more software was available for it.

However, IBM was THE business company of the time, and it attracted a lot of software houses and applications for its new machine.
Quote:

Furthermore a large library of software was available for it, including compilers, assemblers and BASIC interpreters - all of which would run on any CP/M machine

IF they were ported. Not all systems were compatible: there were hardware differences.
Quote:

(preferably but not necessarily with 80 column text and 64k RAM). This meant that the C64 could have business and development software ready to go on launch without any effort. There was just one problem - the Z80 CPU cartridge wasn't ready when the C64 was launched. The FCC forced Commodore to remove the advert from the box until they actually had the product ready for sale. Then a while later they changed the clock chip in the C64, and the CP/M cartridge wouldn't work with it. "Big deal.", you say, "Nobody was using it so..." and there you would be wrong. Some people were using it, and they complained. Now fast forward to 1984 when Commodore decided to produce the C128 as a stopgap until Amiga sales ramped up. It was based on another machine being developed that used a 6809 CPU and 6845 display controller with 80 column text, called the D128.

Unbelievable: they were using a CPU and video processor from OTHER suppliers. No comment...
Quote:

The engineers had also hacked a VIC-II chip into it to get color graphics, but it was not compatible with the C64. When Bil Herd took over the project he decided to redesign it with C64 compatibility in mind, unlike the Plus/4 which wasn't. That was a smart decision IMO - why have all that C64 hardware in it and not be C64 compatible? However again there was a problem. Marketing quite rightly insisted that it be 100% C64 compatible, as they didn't want any flack from customers or the FCC. That meant it had to be compatible with the CP/M cartridge! With the C128 having 80 column text this was even more desirable.

Even more desirable was an updated VIC-II to display 80 columns, instead of having TWO completely different video processors in the same machine...
Quote:

However the cartridge had a lot of bus interface chips that drew more power than the C128's internal supply could handle. A more expensive power supply would be needed, or would it? Bil Herd came up with the brilliant idea of putting the Z80 on the motherboard, which turned out to be cheaper than upgrading the power supply. The Z80 was effectively free! So the C128 got CP/M because Commodore didn't want to fined again for false advertising. Building it in effectively cost nothing, and the new 1571 disk drive would be more compatible with other CP/M disk formats. CP/M may have been dying at this point (Amstrad not withstanding) but it didn't cost much to add it to the C128 so it wasn't a big deal.

Even Windows was released that year, as GUI on top of the DOS. CP/M was really the last OS to think about at that time.
Quote:

Quote: Despite this, which 16/32 bit 6502 system could Commodore have produced in 1985? None. Exactly. The 65C816 was originally developed for Apple, but the first batch didn't work at all and the next lot maxed out at ~3 MHz. Apple was forced to use this non-catalog 3MHz part in the Apple IIGS, which was released in September 1986. Commodore would not be able to get their hands on a large quantity of 65C816 CPUs in 1985 - if any. It was a total non-starter.

Absolutely. That processor was too much immature.
Quote:

Furthermore they wouldn't want to when they were making their own cheaper 6502 variants in-house.

Well, they only extended it a bit, but it remained 8 bits.
Quote:

Quote: Backward-compatibility wasn't really on Commodore scope, and the C128 is almost compatibile with the C64 just by case. The Plus/4's lack of compatibility was quickly realized to be a mistake - a mistake that Jack Tramiel made in his quest to drive out the competition. Instead it became a mill-stone around post-Tramiel Commodore's neck. That was not a mistake they wanted to repeat! C64 compatibility saved the C128.

Yes, but it was the first time for Commodore: all other systems weren't backward-compatibile.

@WolfToTheMoon

Quote:

WolfToTheMoon wrote: @Karlos Quote: Commodore recognised the Hi-Toro machine was groundbreaking when they saw it. nobody's arguing that. I'm arguing C= could have had an inhouse 16/32 bit design, cheaper than Amiga, that could have been backwards compatible with the C64 - if they played their cards right!

I only quote this, because first I've a question: cheaper than Amiga = to avoid buying Hi-Toro and create a machine completely internal?

Now let's focus on the 16/32 bit design.

I think that here you're only referring to the CPU, because Commodore has already shown that creating cool chipsets wasn't the best thing that its engineers were able to do.
VIC-II and SID were very good once the C64 was sold, but they remain unique / not-repeated-anymore chips.
In fact, the SID's creator left the company and the created... Ensoniq!
And the VIC-II stayed as it is, since they weren't able to add an 80 columns mode (see above the other comment).
So, the engineers weren't great at making good chips, unfortunately.

Last but not really least, the same happened with the 65xx processors: we've seen only very very minimal changes since Commodore bought MOS and this processor project. Yes, Tramiel cut many engineers from MOS, but many others remained, and basically nothing changed.

However, and let's assume that the company had good engineers for evolving the 6502: how to you think that they new 16 and 32 bits design could have been architected? I bet that they would be much different from the 65816 and 65832, because the 65xx processors are all structured in a certain way, and the opcode space was already used for a good part.
To be more clear, there was no chance to add 16 and even 32 bit instructions of the equivalent 8 bit ones.
The only solution to support all datatype sizes at the same time could have been... using prefixes (ala 80386 and x64), which would have complicated the instruction decoder AND made code density even worse than it was with the 6502.

The good thing is that a 32-bit version could have had a 32-bit PC (instead of the bank + 16-bit PC = 24 bit address space for code of both 65816 and 65832), which is much more general purpose.

But the poor code density and execution speed would have remained.

In short: the 65xx family had no future, whatever solution you could have found to extend it to 16 or 32 bit (or even 64 bit).

However, if someone has a different, better idea on how to evolve it... I'm greatly interested on knowing the details about his/her design.

cdimauro Quote:

However, and let's assume that the company had good engineers for evolving the 6502: how to you think that they new 16 and 32 bits design could have been architected? I bet that they would be much different from the 65816 and 65832, because the 65xx processors are all structured in a certain way, and the opcode space was already used for a good part. To be more clear, there was no chance to add 16 and even 32 bit instructions of the equivalent 8 bit ones. The only solution to support all datatype sizes at the same time could have been... using prefixes (ala 80386 and x64), which would have complicated the instruction decoder AND made code density even worse than it was with the 6502. The good thing is that a 32-bit version could have had a 32-bit PC (instead of the bank + 16-bit PC = 24 bit address space for code of both 65816 and 65832), which is much more general purpose. But the poor code density and execution speed would have remained. In short: the 65xx family had no future, whatever solution you could have found to extend it to 16 or 32 bit (or even 64 bit). However, if someone has a different, better idea on how to evolve it... I'm greatly interested on knowing the details about his/her design.

You are on the right track to upgrade the 6502.

1. A new encoding is practically required. I would go with a 16-bit VLE as it is easier to decode, allows more orthogonality and has better code density than an 8-bit VLE.

2. Add more GP registers. With multiple GP registers that are similar, orthogonality is improved if they have similar names like A0-A7 rather than different names like X, Y, Z. The index/address registers could easily be upgraded to 8 and the accumulator/data registers could easily be upgraded to 8 also. The registers could be named R0-R15 but encoding space could be saved if the index/address registers and accumulator/data registers had different features. To better specify the functionality, it is better to name the registers according to their features so A0-A7, I0-I7, D0-D7, etc. The index registers could be enhanced to be not only index registers but more general purpose address registers which we will designate as A0-A7. Since the A0-A7 name is taken for address registers, we will call the 8 accumulator/data registers D0-D7.

3. Upgrading to a large flat 32-bit address space would be a major advantage so the registers and PC should be upgraded to 32-bit.

4. Compatibility and versatility would be improved with smaller 8-bit and 16-bit datatype sizes while a 32-bit size is needed for pointers and the large flat address space. Three datatype sizes requires 2 encoding bits with one left over that should be reserved for a later 64-bit datatype size to maximize decoding efficiency and code density with 64-bit support.

5. The 6502 addressing modes should be included but with more orthogonality and versatility.

6. The 6502 can perform mem-reg operations and keeping them could allow nearly one to one instruction equivalents. A RISC ISA does not have mem-reg instructions while a CISC ISA does, as well as reg-mem further reducing the number of instructions and memory traffic.

7. Simplify the mnemonics based on the improved orthogonality.

6502 instruction | 68k instruction | category
lda move load/store y
ldx move load/store y
ldy move load/store y
sta move load/store y
stx move load/store y
sty move load/store y

tax move reg-transfer
tay move reg-transfer
txa move reg-transfer
tya move reg-transfer

tsx move stack
txs move stack
pha move stack
php move stack
pla move stack
plp move stack

and and logic
eor eor logic
ora or logic
bit btst logic

adc add(x) alu
sbc sub(x) alu
cmp cmp alu
cpx cmp alu
cpy cmp alu

inc add(q) alu
inx add(q) alu
iny add(q) alu
dec sub(q) alu
dex sub(q) alu
dey sub(q) alu

asl asl shift
lsr lsr shift
rol rol shift
ror ror shift

jmp jmp branch
jsr jsr branch
rts rts branch

bcc bcc branch
bcs bcs branch
beq beq branch
bmi bmi branch
bne bne branch
bpl bpl branch
bvc bvc branch
bvs bvs branch

clc move cc
cld move cc
cli move cc
clv move cc
sec move cc
sed move cc
sei move cc

brk bkpt/trap/illegal system
nop nop system
rti rtr system

The 68k only needs 20-28 instructions/mnemonics to simplify the 6502 45-56 instruction/mnemonics. Most of these instructions are one for one replacements but much more powerful with much improved orthogonality and using many GP registers. The large flat address space, multiple datatype size and very good code density complete the upgrade. Many of the instructions even use the same mnemonics like the 68k ISA designers had programmed the 6502 in assembly and decided to create the ultimate 6502 upgrade. The 6502 would have required major upgrades early to compete with the 68k but compatibility was a limitation for a bad ISA design. The 6502 is a legendary CPU with a bad ISA but a primitive ISA was required to enable the cheapest possible CPU due to extremely limited silicon space and poor chip yields at the time it was introduced.

Practically every CPU that came after the 6502 had a better ISA. Even the upgraded 6502 CPUs had some of the worst ISAs available but compatibility was important. Even then, it was usually not worth the boat anchor around the neck. It was not usual for the 6502 to be effectively upgraded in later devices like the SuperPET 6809, the C128 Z80 and the SNES cartridge CPU/DSP upgrades. It was bad enough to be 2nd best when 16-bit CPUs were being introduced like the Z8000.

https://thechipletter.substack.com/p/captain-zilog-crushed-the-story-of Quote:

Why Was Captain Zilog Defeated? So why did Zilog fail when, in many respects, it had a competitive and arguably better product than Intel? Zilog was owned by Exxon, who was both ambitious and also happy to shower large amounts of cash on its promising subsidiary. These might seem to be advantages, but they came with significant drawbacks. Zilog was encouraged by its parent to do more than might be reasonable for a startup of its size. So whilst the cash was available to support development, the resources within Zilog were spread thin. Then there was the Z8000 itself. It fell between two stools. It wasn’t the cheapest, nor did it have the most advanced architecture. It was destined to be second choice in any contest. Furthermore, it’s also arguable that the Z8000 was focused on the wrong goals. Code size was a key target, but the additional memory that was available with 16-bit systems made this less important. Zilog kept the cost of the Z8000 itself down using fewer pins, memory segmentation and avoiding microcode, but the CPU itself would be a small part of the cost of a complete system. The additional MMU chip increased costs. And memory segmentation meant that the Z8000 would lose out against the Motorola 68000 when it came to choosing a CPU for more powerful Graphical Systems such as Apple’s Lisa and Macintosh. And then there was Crush and IBM. Intel’s marketing campaign was hugely successful because it focused on the issues that mattered to potential customers and sold a complete solution. Zilog had, for a long time, had a weaker and incomplete offering. Did Zilog have it too easy with the Z80? Bernard Peuto would say that the Z80 had sold itself. Intel had struggled with the 8080’s successor and knew that they had to focus on making the 8086 a success. So it was probably game over for the Z8000, even before IBM selected Intel’s 8088. Zilog had made extraordinary progress in the few short years after its founding. Quoting Federico Faggin: "… I think actually that for five years Zilog set the pace for the industry. Zilog was for its first five years of life, maybe four you can argue, the pacesetter in the industry, what Intel later became." But in the end, even Captain Zilog couldn’t defeat Big Blue.

The 68000 was the best MPU and the 808x was the cheapest. The Z8000 had a much better ISA than any 6502 family ISA and a better ISA than the 808x but even 2nd best was not a good choice. The Belmac-32 and NS32k were competitive 32-bit ISAs but 68k MPUs were often cheaper, less buggy and likely had better performance metrics including code density. Jay Miner took a stand on the 68000 for good reason which thankfully CBM could not replace with their political choice of CPU. Political architecture choices instead of tech driven choices soon became rampant with the RISC hype. The 68k was abandoned for PPC due to the AIM Alliance (Apple, IBM, Motorola) and competing Advanced RISC Computing (ARC)/Advanced Computing Environment (ACE) consortium (MIPS, Microsoft, DEC, SGI, Sony, Compaq, Acer, Siemens, Olivetti, Wang, etc.) adopted MIPS for the workstation market and x86 for the desktop market. The ARC/ACE consortium only lasted about a year as x86 CPUs caught up with RISC CPU performance. The Motorola political choice of throwing out their 68k baby with the bathwater was never reversed even as CISC performance soon surpassed RISC performance even with political RISC architecture choices by alliances and other big players (Sun with SPARC and HP with PA-RISC). The "best" ISA didn't matter anymore as political alliances, economies of scale and quick to market CPU designs with Moore's Law tail winds were enough. Well, eventually code density seemed to matter as Alpha, PA-RISC, MIPS, SPARC, PPC and the original ARM architectures with the worst code density all failed even before Moore's Law came to an end.

@bhabbott

Quote:

@bhabbott I disagree. From Bil Herd's book "Back Into The Storm" which I recently bought from Amazon Australia:-

1. C128's monochrome high-resolution text mode is a weak #metoo.

The original Macintosh can move large graphics areas at high business resolution. https://youtu.be/2B-XwPjn9YY?t=102

On top of the MacOS GUI toolbox experience, the "killer app" example for the MacOS 68K is Aldus (Adobe) PageMaker+Adobe's Postscript+LaserWriter.

By 1994, MacOS reached 14 million install base. By 1997, MacOS had reached more than 20 million (cite: Steve Jobs returns to Apple presentation, Jan 1997).

C128 is less polished when compared to Apple's Macintosh.

Compaq and MS Excel kept Windows 2.x development alive, backed by IBM's VGA and other VGA/SVGA clones.

PageMaker+WinWord+Excel+printer drivers help Windows 2.x and created a perfect storm for Windows 3.0 which helps Microsoft displace high-resolution text-based Lotus 123 and Word Perfect establishment.

From 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.


2. Z80 is a dead end when Zilog ditched Z80 backward compatibility with Z8000.

3. Digital Research's "next-gen" environment focus is GEM. Digital Research's major design win is Atari TOS (GEM 68K).

Quote:

@bhabbott, Some other home computers had an 80-column mode, but few did it in color. The BBC micro did it in two colors via a 640x200 bitmap screen,

BBC Micro is a UK government state-sponsored.

Like many other 65xx platform vendors, Acorn faced the same slow 65xx evolution roadmap issue which led to ARM's existence.

The 16-bit PC has a 32-bit road map future with Intel's 386 timely 1985 release.

Both Western Design Center (WDC) and CSG/MOS's 32bit 65K road map is POS.

Apple's 68K switch is about the slow road map issue with 65xx/65K CPU.

Quote:

@bhabbott as did the Amstrad CPC. The Apple II did it with the optional 80 column card, which was monochrome.

From https://www.youtube.com/watch?v=UDUQEKxfGEw

1. Apple exclusive had a shouting match against Bill Mensch about the 65C816 supply issue at the promised clock speed.

2. Commodore's Dave Haynie publicly complains about the 65C816 supply issue.

Quote:

@bhabbott 80 column text was standard on CP/M machines, but again generally only monochrome with no bitmap graphics. MSX 2 got it in 1985 same as the C128, so Commodore wasn't copying them either. Atari's 8-bit machines only did 40 column text.

That's meaningless without factoring in the entire platform.

Quote:

@bhabbott So who exactly was Commodore '#metoo'ing with their high-resolution color text?

Again, C128's monochrome high-resolution text mode is a weak and late #metoo.

Fact: BBC Micro's December 1st, 1981 release was after IBM's original PC model 5150's MDA which is released on August 12, 1981.

Acorn faced the same slow 65xx evolution road map issue which led to ARM's existence.

Fact 2: Apple Macintosh and MS Windows displaced older business OS platforms. High-resolution text-based UI is not enough, hence #metoo is not enough.


Quote:

As for CP/M, perish the thought that a computer manufacturer might want to follow a standard. I guess we should excoriate Dell, Acer, HP and Toshiba for producing machines that all run the same OS, right?

1. Digital Research's "next-gen" environment is GEM.

2. Digital Research's GEM caused an insult against Compaq.

Initially, Digital Research locked GEM for IBM PC which locked out PC clones like Compaq.

For GEM, Digital Research wanted availability fees from PC clone vendors. This caused Compaq to fully cooperate with Microsoft's Windows 2.x R&D and Intel's 386 R&D.

The rest of the PC clones followed Compaq's leadership. After a few months, Digital Research removed the IBM PC lock, but the PR damage was incurred.

For PC clones from 1985 to 1988, Dell, Acer, original HP, and Toshiba have less influence when compared to Compaq.

Compaq has unequaled Intel R&D map access i.e. Compaq's 386 PC project started in March 1985 with Intel. Compaq was the major glue for "Wintel" i.e. Microsoft and Intel.

Bill Gates was a bit paranoid about the OS/2 project with IBM, hence Windows insurance was kept alive.

Microsoft hired David Cutler in 1988 for 32-bit focus OS/2 3.0 which is later known Windows NT. Bill Gates disagreed with IBM's 16bit 286 OS/2 focus. Due to 68K MacOS influence, Bill Gates called 16bit 80286 as brain dead.

Microsoft's Windows roadmap is the Macintosh and NextSTEP (for Windows 95/NT4.0 GUI design).

Compaq being the 1st 386 PC exists for a valid reason.

https://en.wikipedia.org/wiki/Extended_Industry_Standard_Architecture
Quote:

A group of companies led by Compaq (the Gang of Nine) created a new bus instead. This new bus was named the Extended (or Enhanced) Industry Standard Architecture, or "EISA", while the older AT bus had already been renamed Industry Standard Architecture, or "ISA"

Last edited by Hammer on 27-Aug-2024 at 05:00 AM.
Last edited by Hammer on 27-Aug-2024 at 04:51 AM.
Last edited by Hammer on 27-Aug-2024 at 03:40 AM.
Last edited by Hammer on 27-Aug-2024 at 03:33 AM.
Last edited by Hammer on 27-Aug-2024 at 03:20 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

@cdimauro

Quote:

I think that here you're only referring to the CPU, because Commodore has already shown that creating cool chipsets wasn't the best thing that its engineers were able to do. VIC-II and SID were very good once the C64 was sold, but they remain unique / not-repeated-anymore chips.

As mentioned in Commodore - The Final Years book, Commodore lost SID's main engineer, Bob Yannes. Bob Yannes comes from MOS.

For the C65 project, Commodore LSI engineers would take several months to reverse engineer the SID chip and improve upon it, hence it was decided to "glue" two SIDs for stereo sound.

Commodore suffered a "brain drain" and lost specific technical knowledge.

Commodore LSI group was influenced by A500's design i.e. bitplanes and memory bandwidth design which is modified for 65xx's 16-bit memory segmented model. C65's 256-color with 4096 color palette chipset exploited Commdoore's newer 2-micron fabs.

Bob Yannes co-founded Ensoniq.

Quote:

https://en.wikipedia.org/wiki/Ensoniq In spring 1983, former MOS Technology engineers Robert "Bob" Yannes, Bruce Crockett, Charles Winterble, David Ziembicki, and Al Charpentier formed Peripheral Visions. The team had designed the Commodore 64. (skip) In January 1998, Ensoniq Corp. was acquired by Creative Technology Ltd. for $77 million.

The original wow factor from C64 couldn't be repeated due to the "brain drain" caused by Jack Tramiel's management style.

The original wow factor that made MOS great in the 1st place has disappeared during Jack Tramiel's Commodore.

By 1986, Commodore LSI team had a few engineers who could design 1 IPC 65CE02 which is an improvement from 0.5 IPC 6502.

C65 wasn't 256 color tiled graphics architecture since key VIC-II engineers have exited CSG/MOS (Commodore LSI group).

A tech company is nothing without engineers who design the original wow factor.

The main point with Intel re-hiring Patrick Gelsinger as its CEO is an attempt to restore its core direction.

https://www.anandtech.com/show/16807/intel-continues-to-rehire-veterans-at-some-point-theyll-run-out
Under Patrick Gelsinger's administration, Intel is rehiring Intel veterans who made Intel great. It's about Making (insert an item) Great Again. Apple is not the only company attempting to pull the "Steve Jobs" return.

Last edited by Hammer on 27-Aug-2024 at 04:45 AM.
Last edited by Hammer on 27-Aug-2024 at 04:29 AM.
Last edited by Hammer on 27-Aug-2024 at 04:22 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:

matthey wrote: cdimauro Quote: However, and let's assume that the company had good engineers for evolving the 6502: how to you think that they new 16 and 32 bits design could have been architected? I bet that they would be much different from the 65816 and 65832, because the 65xx processors are all structured in a certain way, and the opcode space was already used for a good part. To be more clear, there was no chance to add 16 and even 32 bit instructions of the equivalent 8 bit ones. The only solution to support all datatype sizes at the same time could have been... using prefixes (ala 80386 and x64), which would have complicated the instruction decoder AND made code density even worse than it was with the 6502. The good thing is that a 32-bit version could have had a 32-bit PC (instead of the bank + 16-bit PC = 24 bit address space for code of both 65816 and 65832), which is much more general purpose. But the poor code density and execution speed would have remained. In short: the 65xx family had no future, whatever solution you could have found to extend it to 16 or 32 bit (or even 64 bit). However, if someone has a different, better idea on how to evolve it... I'm greatly interested on knowing the details about his/her design. You are on the right track to upgrade the 6502. 1. A new encoding is practically required. I would go with a 16-bit VLE as it is easier to decode, allows more orthogonality and has better code density than an 8-bit VLE. 2. Add more GP registers. With multiple GP registers that are similar, orthogonality is improved if they have similar names like A0-A7 rather than different names like X, Y, Z. The index/address registers could easily be upgraded to 8 and the accumulator/data registers could easily be upgraded to 8 also. The registers could be named R0-R15 but encoding space could be saved if the index/address registers and accumulator/data registers had different features. To better specify the functionality, it is better to name the registers according to their features so A0-A7, I0-I7, D0-D7, etc. The index registers could be enhanced to be not only index registers but more general purpose address registers which we will designate as A0-A7. Since the A0-A7 name is taken for address registers, we will call the 8 accumulator/data registers D0-D7. 3. Upgrading to a large flat 32-bit address space would be a major advantage so the registers and PC should be upgraded to 32-bit. 4. Compatibility and versatility would be improved with smaller 8-bit and 16-bit datatype sizes while a 32-bit size is needed for pointers and the large flat address space. Three datatype sizes requires 2 encoding bits with one left over that should be reserved for a later 64-bit datatype size to maximize decoding efficiency and code density with 64-bit support. 5. The 6502 addressing modes should be included but with more orthogonality and versatility. 6. The 6502 can perform mem-reg operations and keeping them could allow nearly one to one instruction equivalents. A RISC ISA does not have mem-reg instructions while a CISC ISA does, as well as reg-mem further reducing the number of instructions and memory traffic. 7. Simplify the mnemonics based on the improved orthogonality. [...] The 68k only needs 20-28 instructions/mnemonics to simplify the 6502 45-56 instruction/mnemonics. Most of these instructions are one for one replacements but much more powerful with much improved orthogonality and using many GP registers. The large flat address space, multiple datatype size and very good code density complete the upgrade. Many of the instructions even use the same mnemonics like the 68k ISA designers had programmed the 6502 in assembly and decided to create the ultimate 6502 upgrade. The 6502 would have required major upgrades early to compete with the 68k but compatibility was a limitation for a bad ISA design.

Basically you transformed the 6502 in a 68000.

But this would be a completely new ISA, requiring an additional and totally different decoder & a good part of the backend.

I don't think that it could a good solution, albeit ARM proved that something similar is possible (e.g.: Thumb/-2 after the ARM ISA, and AArch64 after ARM & Thumb/-2 ISAs).
Quote:

The 6502 is a legendary CPU with a bad ISA but a primitive ISA was required to enable the cheapest possible CPU due to extremely limited silicon space and poor chip yields at the time it was introduced.

That's the reason why I've proposed to use prefixes to evolve it: to keep almost everything existing and maintaining its core very small. So, basically retaining its identity / philosophy.

It's certainly possible to add more registers and datatype sizes in different ways, like you suggested, but it ultimately depends on what's the goal of the new project.

I've some ideas on how to better use the prefixes to evolve the 6502 in a certain direction which is compatible with what people liked of this processor, but it would be still too limited for GP computing. So, it's just time wasted.
Quote:

Practically every CPU that came after the 6502 had a better ISA. Even the upgraded 6502 CPUs had some of the worst ISAs available but compatibility was important. Even then, it was usually not worth the boat anchor around the neck. It was not usual for the 6502 to be effectively upgraded in later devices like the SuperPET 6809, the C128 Z80 and the SNES cartridge CPU/DSP upgrades. It was bad enough to be 2nd best when 16-bit CPUs were being introduced like the Z8000.

Exactly. That's the reason why evolving it doesn't make much sense: the 65xx ISA cannot be recovered by upgrading it. It's too bad and needs a completely new design -> not worth it.
Quote:

https://thechipletter.substack.com/p/captain-zilog-crushed-the-story-of Quote: Why Was Captain Zilog Defeated? So why did Zilog fail when, in many respects, it had a competitive and arguably better product than Intel? Zilog was owned by Exxon, who was both ambitious and also happy to shower large amounts of cash on its promising subsidiary. These might seem to be advantages, but they came with significant drawbacks. Zilog was encouraged by its parent to do more than might be reasonable for a startup of its size. So whilst the cash was available to support development, the resources within Zilog were spread thin. Then there was the Z8000 itself. It fell between two stools. It wasn’t the cheapest, nor did it have the most advanced architecture. It was destined to be second choice in any contest. Furthermore, it’s also arguable that the Z8000 was focused on the wrong goals. Code size was a key target, but the additional memory that was available with 16-bit systems made this less important. Zilog kept the cost of the Z8000 itself down using fewer pins, memory segmentation and avoiding microcode, but the CPU itself would be a small part of the cost of a complete system. The additional MMU chip increased costs. And memory segmentation meant that the Z8000 would lose out against the Motorola 68000 when it came to choosing a CPU for more powerful Graphical Systems such as Apple’s Lisa and Macintosh. And then there was Crush and IBM. Intel’s marketing campaign was hugely successful because it focused on the issues that mattered to potential customers and sold a complete solution. Zilog had, for a long time, had a weaker and incomplete offering. Did Zilog have it too easy with the Z80? Bernard Peuto would say that the Z80 had sold itself. Intel had struggled with the 8080’s successor and knew that they had to focus on making the 8086 a success. So it was probably game over for the Z8000, even before IBM selected Intel’s 8088. Zilog had made extraordinary progress in the few short years after its founding. Quoting Federico Faggin: "… I think actually that for five years Zilog set the pace for the industry. Zilog was for its first five years of life, maybe four you can argue, the pacesetter in the industry, what Intel later became." But in the end, even Captain Zilog couldn’t defeat Big Blue.

Nice reading. Which further shows that ISAs are only one factor when products arrive to the market.
Quote:

The 68000 was the best MPU and the 808x was the cheapest. The Z8000 had a much better ISA than any 6502 family ISA and a better ISA than the 808x but even 2nd best was not a good choice. The Belmac-32 and NS32k were competitive 32-bit ISAs but 68k MPUs were often cheaper, less buggy and likely had better performance metrics including code density. Jay Miner took a stand on the 68000 for good reason which thankfully CBM could not replace with their political choice of CPU. Political architecture choices instead of tech driven choices soon became rampant with the RISC hype. The 68k was abandoned for PPC due to the AIM Alliance (Apple, IBM, Motorola) and competing Advanced RISC Computing (ARC)/Advanced Computing Environment (ACE) consortium (MIPS, Microsoft, DEC, SGI, Sony, Compaq, Acer, Siemens, Olivetti, Wang, etc.) adopted MIPS for the workstation market and x86 for the desktop market. The ARC/ACE consortium only lasted about a year as x86 CPUs caught up with RISC CPU performance. The Motorola political choice of throwing out their 68k baby with the bathwater was never reversed even as CISC performance soon surpassed RISC performance even with political RISC architecture choices by alliances and other big players (Sun with SPARC and HP with PA-RISC). The "best" ISA didn't matter anymore as political alliances, economies of scale and quick to market CPU designs with Moore's Law tail winds were enough. Well, eventually code density seemed to matter as Alpha, PA-RISC, MIPS, SPARC, PPC and the original ARM architectures with the worst code density all failed even before Moore's Law came to an end.

Sad story.

But code density wasn't the only factor which matter to such "RISC" vendors: number of instructions in the ISA and CPI (Cycles Per Instruction) were also very important to follow on.

Despite all stupid claims that academics were spreading about how beautiful are RISCs which should NOT have it.

However, reality is a completely different thing and it has proven that RISC as a concept was a complete failure, and processors had to follow the same CISC designs. But they spread the lie that modern processors are "RISCs". Bah...

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: I think that here you're only referring to the CPU, because Commodore has already shown that creating cool chipsets wasn't the best thing that its engineers were able to do. VIC-II and SID were very good once the C64 was sold, but they remain unique / not-repeated-anymore chips. As mentioned in Commodore - The Final Years book, Commodore lost SID's main engineer, Bob Yannes. Bob Yannes comes from MOS. For the C65 project, Commodore LSI engineers would take several months to reverse engineer the SID chip and improve upon it, hence it was decided to "glue" two SIDs for stereo sound. Commodore suffered a "brain drain" and lost specific technical knowledge. Commodore LSI group was influenced by A500's design i.e. bitplanes and memory bandwidth design which is modified for 65xx's 16-bit memory segmented model. C65's 256-color with 4096 color palette chipset exploited Commdoore's newer 2-micron fabs. Bob Yannes co-founded Ensoniq.

That's what I've already stated:

the SID's creator left the company and the created... Ensoniq!
Quote:

The original wow factor from C64 couldn't be repeated due to the "brain drain" caused by Jack Tramiel's management style. The original wow factor that made MOS great in the 1st place has disappeared during Jack Tramiel's Commodore.

He never understood the value of R&D and having/keeping good engineers in this team.
Quote:

By 1986, Commodore LSI team had a few engineers who could design 1 IPC 65CE02 which is an improvement from 0.5 IPC 6502.

This IPC "measure" is only for single-byte instructions.

All 65xx performance is dominated by the number of memory accesses.
Which means that if you've an ADD instruction using the absolute addressing mode, it requires 3 bytes for its encoding -> 3 cycles for accessing those bytes. Plus one cycle for accessing the memory content. Total: 4 cycles (at least. Since crossing the page on the 6502/8502 added another cycle).

In short: no, the IPC is absolutely not the one that you've reported.
Quote:

C65 wasn't 256 color tiled graphics architecture since key VIC-II engineers have exited CSG/MOS (Commodore LSI group). A tech company is nothing without engineers who design the original wow factor. The main point with Intel re-hiring Patrick Gelsinger as its CEO is an attempt to restore its core direction. https://www.anandtech.com/show/16807/intel-continues-to-rehire-veterans-at-some-point-theyll-run-out Under Patrick Gelsinger's administration, Intel is rehiring Intel veterans who made Intel great. It's about Making (insert an item) Great Again. Apple is not the only company attempting to pull the "Steve Jobs" return.

Exactly. And the article should pay more attention on it, since and if you want to nurture the younger engineers to build its future team of (super) professionals then you need the good, old, experts for doing it.

@matthey

Quote:

The 68000 was the best MPU and the 808x was the cheapest. The Z8000 had a much better ISA than any 6502 family ISA and a better ISA than the 808x but even 2nd best was not a good choice. The Belmac-32 and NS32k were competitive 32-bit ISAs but 68k MPUs were often cheaper, less buggy and likely had better performance metrics including code density. Jay Miner took a stand on the 68000 for good reason which thankfully CBM could not replace with their political choice of CPU.

Commodorer-Amiga Inc. is a subsidiary of Commodore Business Machines.

C900 was canceled due to Commodore's financial problems.

Plus 4 and C900 almost bankrupted Commodore while C64 was holding the line until the A500 took over this role.

Like Plus 4, the A600 and PC excess inventory debacle bankrupted Commodore into $116 million debt.

Quote:

Political architecture choices instead of tech driven choices soon became rampant with the RISC hype. The 68k was abandoned for PPC due to the AIM Alliance (Apple, IBM, Motorola) and competing Advanced RISC Computing (ARC)/Advanced Computing Environment (ACE) consortium (MIPS, Microsoft, DEC, SGI, Sony, Compaq, Acer, Siemens, Olivetti, Wang, etc.) adopted MIPS for the workstation market and x86 for the desktop market. .

Advanced Computing Environment (ACE) was the common standard desktop computer industry's insurance if Intel wasn't able to compete against the RISC competition. Like 386's timely 1985 release, Intel's Pentium Pro (P6) 1995 release was timely.

NexGen was founded in 1986 by Thampy Thomas, and is funded by Compaq, ASCII, and venture capital firm Kleiner Perkins.

Compaq had backed NexGen financially.

AMD purchased NexGen when AMD's K5 chip failed to meet performance (e.g. hit a clock speed wall) and sales expectations. Development of AMD's internal K5 successor was halted in favor of continuing from NexGen's Nx686 designs, eventually becoming K6 which was released in 1997.


Quote:

The ARC/ACE consortium only lasted about a year as x86 CPUs caught up with RISC CPU performance. The Motorola political choice of throwing out their 68k baby with the bathwater was never reversed even as CISC performance soon surpassed RISC performance even with political RISC architecture choices by alliances and other big players (Sun with SPARC and HP with PA-RISC).

Reminder, PowerPC has an FMA advantage, and PowerPC 601 rapidly reached clock speeds higher than 68060 rev1.

0.5 μm CMOS PowerPC 601v reached 120 Mhz. 601 and 601+ were designed with IBM EDA tools on IBM systems i.e. PowerPC 601 wasn't Motorola's design.

Apple's PowerPC selection includes "second source" requirements.

Power Macintosh 7200/90's PowerPC 601 in August 1995 reached 90Mhz. 68060 rev1/rev2 wouldn't be able to match PowerPC 601's road map pace.

Power Macintosh 7200/120's PowerPC 601 in April 1996 reached 120 Mhz.

If you track PowerPC 60x's Mhz releases against 68060's release, PowerPC pounded 68K into dust.

Motorola couldn't beat IBM's high-clock-speed road map.

Apple selected PowerPC due to road map superiority.

Many desktop/workstation class RISC CPUs reached clock speeds faster than 68060 rev6 (450 microns)'s 100Mhz.

For the 3DO M2 project, IBM was able to offer a game console price for PowerPC 602 @ 60 Mhz.

IBM was able to offer a game console price for PowerPC 604 @ 110 Mhz for 3DO MX (M3).

IBM was able to offer game console prices for the PowerPC 750CXe core variant @ 486 Mhz for Nintendo's Game Cube. IBM designed a 64-bit 3D SIMD (pack math two 32-bit FMAC) for the PowerPC 750CXe core. ArtX and IBM designed Nintendo's Game Cube's main processing units.

AMD worked with Microsoft's original Xbox with K7 Duron CPU (+700 Mhz range) until Bill Gates overridden it for Intel Coppermine-128 @ 733 Mhz. Both K7 and Coppermine have split 64-bit SIMD FADD and FMUL hardware implementation.

The 3DO MX was effectively 'M3' and Microsoft ultimately acquired the 3DO Systems hardware team (CagEnt under Samsung) and chipset in 1998, but not before Nintendo took a serious pass at CagEnt's 3DO MX in 1997 before selecting ArtX in 1998.

The original XBox project started in 1998. Ditching MX's PowerPC 604 @ 110Mhz would require access to AMD's and Intel's internal road maps. NVIDIA was selected for NV2A with programmable vertex shaders reversed the fixed function T&L hardware direction.

For 3D, Freescale ColdFire v5 will be beaten by IBM PowerPC 750CXe with 3D focus 64-bit SIMD.

------------------

DEC has Alpha and StrongARM.

DEC's intervention with ARM CPU designs made ARM competitive with triple-digit Mhz clock speed which pushed out 68000-based DragonBall from the smart handheld market.

Both MIPS and ARM strongly competed in the booming smart handheld market until the ARM-based champion was created i.e. Qualcomm.

Quote:

The "best" ISA didn't matter anymore as political alliances, economies of scale and quick to market CPU designs with Moore's Law tail winds were enough. Well, eventually code density seemed to matter as Alpha, PA-RISC, MIPS, SPARC, PPC and the original ARM architectures with the worst code density all failed even before Moore's Law came to an end.

You can't use the X86 example for 68K since funding model and collective engineering skill sets are different.

When both AMD and Intel gained ex-Alpha engineers, the X86 CPU vendor's clock speed race accelerated.

_________________
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

@cdimauro

Quote:

That's what I've already stated: the SID's creator left the company and the created... Ensoniq!

I've backed your argument with additional Commodore The Final Years' context.

Quote:

This IPC "measure" is only for single-byte instructions. All 65xx performance is dominated by the number of memory accesses. Which means that if you've an ADD instruction using the absolute addressing mode, it requires 3 bytes for its encoding -> 3 cycles for accessing those bytes. Plus one cycle for accessing the memory content. Total: 4 cycles (at least. Since crossing the page on the 6502/8502 added another cycle). In short: no, the IPC is absolutely not the one that you've reported.

65CE02 has 8-bit ALU, hence one shouldn't expect more than this.

65CE02 would be multi-cycling anything beyond 8 bits via the programmer's effort which is no different from multi-cycle 68000 implementation. The difference is that 68000's microcode is less verbose with memory bus when processing 16-bit and 32-bit datatypes which gives opportunities for Amiga's custom chipset value add. 16-bit memory segmentation is wasteful beyond 65K memory.

My point is Commodore LSI group CPU team has been degraded.

Between 65CE02 vs 68000, I prefer 68K for easier ASM due to the lease amount code for the job.

68K was frozen in time which lacks 3D-related optimizations and focus, hence it's an administration issue with 68K's problems i.e. management problems.

Removing the microcode layer, a 68000 microarchitecture CPU core is a simpler design in its given era.

Last edited by Hammer on 27-Aug-2024 at 07:37 AM.
Last edited by Hammer on 27-Aug-2024 at 07:28 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