agami Quote:

Your assessment of “too early” is based on events which had transpired. However, there is nothing I can see that makes it impossible for Ranger to be market ready by 1987/88. Other than C= management not putting full support behind the effort. Ergo, Ranger or ECS by some other name, could’ve been ready in 1987/88 for the A2000/A500 after 2-3 years of market testing and validation with A1000 OCS (BetaCS).

cdimauro Quote:

You're assuming too much. What we know is only that the chips were ready and tested by 1987/88, but NOT if they were production-ready. So, we don't know how long it could have take to go from "chip ready & tested" to "production-ready".

It is easy enough to believe that the Ranger/ECS chipset could have been ready in 1987 and should have been ready by 1988. There is a big difference between a financially healthy business prioritizing a chipset and a financially distressed C= burying a chipset they believe costs too much and moves them away from their goal of the cheapest possible C64 replacement.

@cdimauro

What I am saying is that 2-3 years is enough time for a the team that designed and delivered OCS, to design and deliver (make production ready) an updated chipset with features found in 1990’s ECS.

Which is to say, there is nothing that was pysically restricting C= and the Amiga team from delivering Ranger in time for 1987/88, or even some other improved chipset in that same time.

The restrictions that did stop it from happening are commercial decisions and poor management decisions, which resulted in a lack of support for such improvements in that time.

Commodore was too narrowly focused on hopes of cost-reducing OCS to less than $50, so they can have a repeat of their C64 success.
While what I am saying is that OCS was the wrong starting point for such a strategy, because it was essentially a productionized beta chipset.
What they should’ve done first is improve the chipset. Something the Amiga team was very capable of doing and were very eager to do. If only they were given the right support.

So for C=, who in 1994 didn’t have a solid plan for a second act, it was good to buy/acquire advanced tech.
But the way I see it, Amiga tech wasn’t the right advanced tech to acquire for their needs.
I guess you could say it was too advanced for Commodore.

_________________
All the way, with 68k

@matthey

Quote:

matthey wrote: cdimauro Quote: You're assuming too much. What we know is only that the chips were ready and tested by 1987/88, but NOT if they were production-ready. So, we don't know how long it could have take to go from "chip ready & tested" to "production-ready". It is easy enough to believe that the Ranger/ECS chipset could have been ready in 1987 and should have been ready by 1988.

The problem is about believing: we've no clear statements towards 1987 or 1988 as for when the chips were ready and tested.
Quote:

There is a big difference between a financially healthy business prioritizing a chipset and a financially distressed C= burying a chipset they believe costs too much and moves them away from their goal of the cheapest possible C64 replacement.

Considering Commodore's financial situation, it made sense. It was only thanks to the Amiga 500 which the company earned a lot of money and this machine was just released on 1987 (so, it required time for Commodore to fill its wallet).


@agami

Quote:

agami wrote: @cdimauro What I am saying is that 2-3 years is enough time for a the team that designed and delivered OCS, to design and deliver (make production ready) an updated chipset with features found in 1990’s ECS.

Do you really believe that those minimal changes introduced by the ECS required 2-3 years for their development?

It might apply to the new engineers, but definitely not for the very experienced that have developed the OCS.
Quote:

Which is to say, there is nothing that was pysically restricting C= and the Amiga team from delivering Ranger in time for 1987/88, or even some other improved chipset in that same time.

I think that 3 years could be realistic, because Ranger introduced some important changes to the chipset.
Quote:

The restrictions that did stop it from happening are commercial decisions and poor management decisions, which resulted in a lack of support for such improvements in that time. Commodore was too narrowly focused on hopes of cost-reducing OCS to less than $50, so they can have a repeat of their C64 success. While what I am saying is that OCS was the wrong starting point for such a strategy, because it was essentially a productionized beta chipset. What they should’ve done first is improve the chipset. Something the Amiga team was very capable of doing and were very eager to do. If only they were given the right support.

The big problem was also the money: Commodore's situation was difficult. So, they NEEDED to cost reduce the Amiga 1000 hardware AND earn money.

We can't ignore this and just think: "they could have done this and this". Without money you can draw circles, but just on you mind.
Quote:

So for C=, who in 1994 didn’t have a solid plan for a second act, it was good to buy/acquire advanced tech. But the way I see it, Amiga tech wasn’t the right advanced tech to acquire for their needs. I guess you could say it was too advanced for Commodore.

It was, but the Commodore 64 was also advanced for its time, bringing a nice chipset AND a lot of memory.

@cdimauro

Quote:

cdimauro wrote: @agami [quote]Do you really believe that those minimal changes introduced by the ECS required 2-3 years for their development?

No. I’m not saying those minimal changes required 2-3 years.
I’m saying that 2-3 years is plenty of time for the same OCS team to deliver those minimal changes, and Commodore should’ve done that before looking at radically cost reducing the chipset.

Quote:

The big problem was also the money: Commodore's situation was difficult. So, they NEEDED to cost reduce the Amiga 1000 hardware AND earn money.

Which is why I question if buying Amiga tech was the right decision.
C=, as it turns out, desperately needed some UVP tech to follow-up the C64. Something that was ready to go without additional costs.
The problem was, they spent millions on R&D tech that needed at least one more iteration (ideally 2 more) before it was ready for prime time.
Which means, you better have the money to buy the tech and then fund another cycle of development before strategic implementation.

Quote:

We can't ignore this and just think: "they could have done this and this". Without money you can draw circles, but just on you mind.

I’m not ignoring those things. Commodore in 1985 had more options for borrowing money than in 1990. I’m saying that C= should have spent some more money (and time) to get the tech better ready for its cost reduction strategy.

_________________
All the way, with 68k

@agami

Quote:

agami wrote: @cdimauro Quote: cdimauro wrote: @agami [quote]Do you really believe that those minimal changes introduced by the ECS required 2-3 years for their development? No. I’m not saying those minimal changes required 2-3 years. I’m saying that 2-3 years is plenty of time for the same OCS team to deliver those minimal changes,

I agree on this.
Quote:

and Commodore should’ve done that before looking at radically cost reducing the chipset.

Not on this, because Commodore need to earn money. It was already on a difficult situation.
Quote:

Quote: The big problem was also the money: Commodore's situation was difficult. So, they NEEDED to cost reduce the Amiga 1000 hardware AND earn money. Which is why I question if buying Amiga tech was the right decision. C=, as it turns out, desperately needed some UVP tech to follow-up the C64. Something that was ready to go without additional costs. The problem was, they spent millions on R&D tech that needed at least one more iteration (ideally 2 more) before it was ready for prime time. Which means, you better have the money to buy the tech and then fund another cycle of development before strategic implementation.

OK, but they focused on the C128 (which I had) for those reasons. It didn't perform well compared to the C64 and that was the main problem.

Well, the real problem was that the C128 was a Frankenstein with those two CPUs and two video processors: another "great" example of Commodore's engineers vision and ability...
Quote:

Quote: We can't ignore this and just think: "they could have done this and this". Without money you can draw circles, but just on you mind. I’m not ignoring those things. Commodore in 1985 had more options for borrowing money than in 1990. I’m saying that C= should have spent some more money (and time) to get the tech better ready for its cost reduction strategy.

Spent money... without having enough of them?

@cdimauro

Quote:

cdimauro wrote: @agami Spent money... without having enough of them?

Aha, hence the reason for “borrowing”.

They spent $27M in ‘84 to buy Amiga. In ‘85 they show off the Amiga 1000.
Just like the Apple Macintosh in ‘84, the A1000 is also very different from the majority of computers in circulation since the late ‘70s and early ’80s.

Apple fell back on the excellent sales and profit margins of the Apple IIe, but Commodore didn’t have the luxury of falling back on C64 sales in 1985, because they gutted that market in 1984.
https://dfarq.homeip.net/commodore-financial-history-1978-1994/

They had the example of Apple Macintosh from ‘84 so I don’t know why they thought they could do better in ‘85.
The only thing the A1000 was good for, is to get some new investors interested or to put the IP in escrow to loan another $10M and complete the integration of Amiga into C=.
So then when they reached their second boom phase in 1991, they’d see higher than 13% margins, instead of the 4.6%

_________________
All the way, with 68k

@agami

Quote:

Apple fell back on the excellent sales and profit margins of the Apple IIe, but Commodore didn’t have the luxury of falling back on C64 sales in 1985, because they gutted that market in 1984.

I read somewhere how the C128 saved C= from going bankrupt before the Amiga sales kicked in.

Last edited by OneTimer1 on 04-Nov-2023 at 06:41 PM.

@OneTimer1

Quote:

OneTimer1 wrote: @agami I read somewhere how the C128 saved C= from going bankrupt before the Amiga sales kicked in.

If you call posting losses of $113M and $127M in ‘85 and ‘86 respectively “saving” Commodore, then yeah.

It just means that in a declining C64 market they at least had C128s to sell. But it was “saving” them directly into a bust phase of the previous cycle.
Their first act was over. Without the A500, that company would’ve been gone by 1988.

_________________
All the way, with 68k

@agami

Quote:

Without the A500, that company would’ve been gone by 1988.

The A500 was a huge economic success but it was a Home Computer like the C64, it didn't help establishing the Amiga as a professional computer system.

A desktop version with higher performance, a proper flicker free hires GFX and a HD, a good software support and marketing would have helped selling it as a professional PC. But that's not what most Amiga fans, who liked playing games on their TV, would have appreciated.

Most Amiga where sold via supermarkets and not by real dealers that would sell a rigged up A2000 instead of a PC. The A3000 had a built in flicker fixer and a fast SCSI interface, but came rather late.

If you want to compare Amiga to other companies, you should compare them to Apple, and you should judge them by public perception, their marketing and where this systems where used. When C= won the Home Computer market with PET, VIC20 and C64, Apple got the professional users and this continued when it came to their 68k Systems.

@agami

Quote:

agami wrote: Commodore was too narrowly focused on hopes of cost-reducing OCS to less than $50, so they can have a repeat of their C64 success. While what I am saying is that OCS was the wrong starting point for such a strategy, because it was essentially a productionized beta chipset.

The OCS chipset already cost around 20 $ from the start. It is explained in the Brian Bagnall books. And latter less than 20 $.

@babsimov & @agami

Well, the chipset is one part, the other part is RAM, in a time when 'professional' PCs could only use 640kB, 512kB RAM seemed to be luxurious.

And like I tried to explain before, RAM access got faster mainly due burst cycles. This means a CPU/GFX chips was accessing the RAM using continuous addresses. This didn't work on a system using the same RAM for CPU and GFX and especially with planar graphics, an the Amiga you need multiple read access cycles on different RAM addresses before you jump to the next pixel. You would have needed a small read cache for every DMA slot, so for every bitplane, every audio channel, the copper and the in the CPU.

And this meant higher resolution, refresh rates and colors needs a at least new type of GFX and this would have needed a new GFX chip using technologies that where out of reach for C= and a lot of resources for development.

Last edited by OneTimer1 on 05-Nov-2023 at 03:40 PM.

@Kronos

Quote:

Even if that would have made technical sense, it wouldn't been feasible given that AMIX was just a license

Just want to point out that Apple/UX too was an AT&T Sys V (albeit rev 2, not 4) license deal. An Amiga environment on top of AMIX, with perhaps “special attention “ to chipset access, could be done within license agreements. I mean, that’s what just about all Sys V licensees did to add their own “touch”, right?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro
Quote:

Well, the real problem was that the C128 was a Frankenstein with those two CPUs and two video processors: another "great" example of Commodore's engineers vision and ability...

Was it purely an engineering decision, though?

Last edited by kolla on 05-Nov-2023 at 08:00 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: @cdimauro Quote: Well, the real problem was that the C128 was a Frankenstein with those two CPUs and two video processors: another "great" example of Commodore's engineers vision and ability... Was it purely an engineering decision, though?

Apple2 where often sold and used with CP/M (Z80) cards and a 80 characters GFX card (Apple2 was originally introduced with 40 characters GFX) so awhat he describes as a 'Frankenstein computer' was standard at this time.

The C128 was a good CP/M platform, but CP/M was dying, the C64 inside couldn't use the 2MHz 6502* and the fast floppy transfers, so the build in C64 had no real benefits of the new hardware.

* Some found out the C64 could use the 2MHtz CPU with some tricks, a fact that Bill Herd described as a design error.

@OneTimer1

Quote:

OneTimer1 wrote: @babsimov & @agami Well, the chipset is one part, the other part is RAM, in a time when 'professional' PCs could only use 640kB, 512kB RAM seemed to be luxurious. And like I tried to explain before, RAM access got faster mainly due burst cycles. This means a CPU/GFX chips was accessing the RAM using continuous addresses. This didn't work on a system using the same RAM for CPU and GFX and especially with planar graphics, an the Amiga you need multiple read access cycles on different RAM addresses before you jump to the next pixel. You would have needed a small read cache for every DMA slot, so for every bitplane, every audio channel, the copper and the in the CPU. And this meant higher resolution, refresh rates and colors needs a at least new type of GFX and this would have needed a new GFX chip using technologies that where out of reach for C= and a lot of resources for development.

It's not clear to which historical period you are talking about.

Anyway, I've written an article (about Akiko) that has shown how to implement packed/chunky at 8 bit maintaining the same 8 bitplanes architecture, with minimal cost. With the same concept 16 and 32 bit packed/chunky can be easily introduced as well.


@kolla

Quote:

kolla wrote: @cdimauro Quote: Well, the real problem was that the C128 was a Frankenstein with those two CPUs and two video processors: another "great" example of Commodore's engineers vision and ability... Was it purely an engineering decision, though?

I think (MY personal idea) that adopting the CP/M was a management decision.

However and again IMO the rest was engineers decision.


@OneTimer1

Quote:

OneTimer1 wrote: @kolla Quote: kolla wrote: Was it purely an engineering decision, though? Apple2 where often sold and used with CP/M (Z80) cards and a 80 characters GFX card (Apple2 was originally introduced with 40 characters GFX) so awhat he describes as a 'Frankenstein computer' was standard at this time.

The time was 1984 and such configuration wasn't certainly standard.

SOME systems, like the Acorn BBC, allowed to add expansion cards with different CPUs, but those were rare cases.
Quote:

The C128 was a good CP/M platform, but CP/M was dying,

Exactly!
Quote:

the C64 inside couldn't use the 2MHz 6502* and the fast floppy transfers, so the build in C64 had no real benefits of the new hardware. * Some found out the C64 could use the 2MHtz CPU with some tricks, a fact that Bill Herd described as a design error.

Well, poking registers at the time was the standard...

@cdimauro

Quote:

cdimauro wrote: kolla wrote: @cdimauro Quote: Well, the real problem was that the C128 was a Frankenstein with those two CPUs and two video processors: another "great" example of Commodore's engineers vision and ability... Was it purely an engineering decision, though?

I think (MY personal idea) that adopting the CP/M was a management decision.

However and again IMO the rest was engineers decision.

[/quote]

Dunno, the story goes that the C128 was developed without any order/consent from management and was later deemed good enough to be a product. Similar how the C= Germany brainfart that was the broken A2000A birthed the somewhat sensible A2000B.

No idea what the original plan for the Z80 in the C128 was but CP/M might have just been the least stupid use case.

As for what C= could've should've done, one thigk they hated was buying in chips which they already had to do with the 68000 and worked very hard to avoid with the chips Jay had designed. Agnus was pushing beyond what MOS could do (within spec) but they somehow made it work.

Might be the little and late that ECS delivered was based on that problem and might even be that the A3000-AGA was canceled/delayed because they just couldn't do and management only caved in into outsourcing Lisa when time was running out (already had run out given the C= was dead 2 years later).

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

@cdimauro

Quote:

It's not clear to which historical period you are talking about.

About the time when reading RAM in burst cycles became common.

Last edited by OneTimer1 on 05-Nov-2023 at 11:32 PM.

@Kronos

Quote:

Similar how the C= Germany brainfart that was the broken A2000A birthed the somewhat sensible A2000B...

Well someone in the management thought a PC compatible Amiga might be a good idea, first came the A1060 Sidecar for the A1000, some rumors say the Sidecar was just an PC10 main board. The German division had some experience designing IBM compatible PCs, that sold quite well.

But building PC slots into an A2000 without a possibility to access them from the 68k was totally stupid, they should have build it without them, the money could have been better invested in a slightly faster 68k or into more RAM.

@cdimauro

Quote:

kolla, you're supposed to be a sysadmin and those concepts (at least the last two) should be your ABC, right?

I’ve been a sysadm long enough to see VirtualPC, a PC emulator for *PowerPC* macs, be bought by microsoft and end up as HyperV, now powering Azure. I also had a personal Vmware license from 1998. Qemu first without, then with KVM, and later again with KVM and hardware virtualization support.

Like I wrote, it’s a scale with its extremes (everything emulated to nothing emulated) and lots in between. Conceptually there’s not much difference. Like with Qemu, whether you use code that emulates a 68k in software or use code that use kvm and skips emulation, what you get is a virtual system.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

I agree the scale of virtualization is very grey.

Things are further blurred in the broader realm of intermediation, and one wonders where exactly to draw the lines between interpolation | interpretation | virtualisation | emulation | simulation.

_________________
All the way, with 68k