@matthey

Quote:

matthey wrote: cdimauro Quote: When you count the number of transistors, are you removing / reusing the 13M ones used by the RP2040 for the 264kB SRAM for implementing the two 68060 cores + AGA? The RP2040 SoC chip at 40nm uses over 13 million transistors and costs $1 USD (production cost is significantly lower as development costs, licensing costs, overhead costs and profit should be included). Most mass produced chips at 40nm which are similar could have a similar cost. I just pointed out that a dual core 68060 with AA+ chipset uses less than half the transistors of the RP2040 chip.

OK, understood. So, you reused the full transistor budget as you wished.
Quote:

https://en.wikipedia.org/wiki/AA+_Chipset

Is it really needed to implement the AA+ chipset? No software was written for it.
Quote:

The fact that the 264kiB of SRAM uses most of the transistor budget of the RP2040 is not important. The SRAM is simple and offers increased performance for a microcontroller like caches increase performance for a microprocessor. At least the L1 I+D caches of the 68060s should be increased as well which would use 2,359,296 transistors for each core or 4,718,592 for increasing both cores to 32kiB I+D L1 caches.

Which is better choice. You also have to consider that you need to add more BTC caches and TLBs to make the cores more modern and getting more performances.
Quote:

dual 68060 Amiga SoC AA+ chipset uses 200,000 transistors 2x68060 with 32kiB I+D L1 cache uses 9,778,592 transistors --- 9,978,592 transistors total L2 cache options 128kiB shared L2 cache uses 6,291,456 transistors 256kiB shared L2 cache uses 12,582,912 transistors 512kiB shared L2 cache uses 25,165,824 transistors 1MiB shared L2 cache uses 50,331,648 transistors 2MiB shared L2 cache uses 100,663,296 transistors The SRAM for a L2 cache could also be configurable as memory for an embedded microcontroller or Amiga where no external memory is used.

Unfortunately there's not enough transistor budget for adding some useful L2 cache. It's better to used what's left for improving the platform (the chipset, which is very old).
Quote:

It would be cool to be able to run the 1MiB or 2MiB Amiga standard out of ultra fast SRAM and it could be useful for a retro Amiga built into a controller or a portable Amiga gaming device.

1 or 2MB SRAM requires too many transistors, as you reported. So, it's not possible looking at the budget which is left.
Quote:

A $1 SoC chip includes the chip package and other per chip costs so the transistors/$ are significantly cheaper when scaling up to a larger transistor budget. It's just amazing how cheap transistors have become.

And even better with much newer productive processes (but which are more expensive).
Quote:

cdimauro Quote: It depends on the specific market: the Amiga o.s. is very lightweight and responsive, but it can easily crash with a breath. Even for a game machine, something which crashes so easily can be not acceptable for the wider audience of modern game players. It wasn't a problem for the Amiga back when it was popular and it is not a problem for budget and retro gaming today.

That's ok, but then the market is restricted.
Quote:

It would be a different story if trying to make the Amiga competitive on the desktop.

The desktop market is over and not reachable anymore.
Quote:

cdimauro Quote: Last but not least, we (Amiga coders) were used to directly hit the hardware, to better use it. Taking the AGA chipset as it is on the above "new Amiga SoC" may require the same, which isn't good nowadays. More performance means developers don't need to bang the hardware and I would encourage them not to for new projects.

Even the AA+ chipset is stone age from performance perspective. You need to improve it A LOT in order to make it developers happy to code without banging the hardware registers.
Quote:

At the same time, it is important to accept that some developers enjoy banging the hardware and that is easier to enhance games that already do.

Well, Amiga coders were much used to it. So, improving old games requires it.
Quote:

Compatibility is important while AmigaOS 3 can be enhanced with more modern functionality including MMU use for improved stability.

MMU can't help that much here: it gives very little benefits. At least with how the Amiga o.s. is working.
Quote:

WHDLoad and patching works well enough for misbehaving software.

That's fine.
Quote:

cdimauro Quote: LOL: 64kB or even 80kB. The stack had to be at least 16-bit aligned with the 68k, so even doubling the default 4kB size of the generic Amiga o.s. application does NOT justify bringing it to 64kB or even 80kB: you can expect 8kB as the corresponding size for PowerPCs. Here the problem I think is more related to the ridiculous ABI which PPCs have regarding function calls. There's nothing else that can justify the so much increased default stack space required. It's not even the whole PPC ABI as it is good about passing function args in registers which decreases memory traffic from push/pop of args on the stack. It's the PPC mandated stack frame handling and function prologues/epilogues without mandated multiple register load/store that is both annoying and inefficient for shallow functions. The 68k AmigaOS makes use of extensive code sharing that results in such a small footprint but this is inefficient on load/store cores with load-to-use penalties. The PPC ABI is optimized for deep functions with extensive function inlining and loop unrolling to minimize load-to-use penalties.

AmigaOS4 is an Amiga o.s. 3 port and it doesn't need to follow the PowerPC ABI.
Quote:

These are different and practically opposite philosophies and we can see the result as modern compilers are designed for this too. Old C compilers generated WYSIWYG code that was similar to the translation of what was written and worked fine on the 68k while the code from a modern compiler is often bloated and unrecognizable, especially so in PPC assembler which is difficult to read. The 68k takes more penalties from unaligned memory accesses, extra function calls and a little decoder overhead but even the mostly modern 68060 handles it with grace while avoiding load-to-use penalties and sharing already dense code which more than offsets the penalties. The 68k processors should be called a code sharing processors while load/store processors should be called code bloating processors.

*
Quote:

Most of the world chose code bloating as it is better for security but the Amiga was different.

Security? How/why? Could you please clarify it?
Quote:

It is not unusual for an Amiga to have many tasks/processes executing on startup even though most are waiting asleep. The following video shows someone testing SysMon on AmigaOS 4 which states, "There are 102 tasks/process in the system". SysMon for Amiga OS4, by Guillaume Boesel https://youtu.be/pbAKRtirckc?t=22 With an AmigaOS 4 stack default of 64kiB of stack for each task/process that would be ~6.4 MiB of memory and with 80kiB of stack that would be ~8.0MiB of memory. AmigaOS 3.1 with a 4000 byte stack per task/process would take less than 400kiB of memory and potentially still work on a 2MiB system where the stack alone in AmigaOS 4 would take 8MiB of memory as recommended by an official Hyperion AmigaOS 4 developer. That is a huge increase to the 68k Amiga footprint before even mentioning 50% larger PPC code.

Absolutely! The only "good" thing is that the machines where AmigaOS4 runs have much more memory compared to the Amigas.

Last edited by cdimauro on 30-Oct-2023 at 05:25 AM.

cdimauro Quote:

Is it really needed to implement the AA+ chipset? No software was written for it.

I chose AA+ because it is the most advanced Amiga chipset with a suggested transistor count. Integrating chips should save transistors and AA+ is down to 2 major chips from 3 giving a closer approximation of transistor cost. It's nice that AA+ includes many features that didn't make it into AGA and it shows that adding chunky modes is possible and not too expensive even though it was only planned to include 16 bit chunky. Several of the SAGA enhancements are similar to the AA+ spec. The Apollo core team discussed AAA but many of the enhancements were rejected as not useful enough today while AA+ was found to be more practical. A new retro Amiga that borrows from what Amiga Corporation or C= was planning is more likely to have retro appeal today. For example, the following video shows SAGA sound enhancements (reverse engineered Paula upgraded to 16 bits with 16 voices).

Vampire 4 STANDALONE 16 Bit 16 Track Pamela Audio running Milky Tracker Vamped Edition
https://youtu.be/41vHR4dhN8M?t=48

cdimauro Quote:

Which is better choice. You also have to consider that you need to add more BTC caches and TLBs to make the cores more modern and getting more performances.

Sure. At least the 68060 ATC with 64 entries 4 way is larger than the Cortex-A53 L1 TLB of 10 entries (L2 TLB is 512 entries 4 way). MMU hardware upgrades are not a high priority for the AmigaOS. The 68060 Branch Cache and prediction is relatively simple and doesn't use much logic (256 entry 4 way currently). A return/link stack is high priority for a shallow function code sharing Amiga but relatively cheap (8 entry?).

cdimauro Quote:

Unfortunately there's not enough transistor budget for adding some useful L2 cache. It's better to used what's left for improving the platform (the chipset, which is very old).

I didn't say we were limited to a $1 USD SoC. Raising the cost decreases general purpose embedded use and economies of scale while specialized options need to be very appealing for our own use and/or specialized embedded use.

cdimauro Quote:

And even better with much newer productive processes (but which are more expensive).

No. The cheapest transistor/$ is using a somewhat older fab process. The RP2040 SoC likely was near cheapest transistor/$ when developed but prices have dropped quickly on newer processes.

cdimauro Quote:

The desktop market is over and not reachable anymore.

A frontal assault of a seemingly impenetrable fortress is not recommended. ARM CPU cores and the RPi are showing that chipping away with a stealth approach is possible with economies of scale.

cdimauro Quote:

MMU can't help that much here: it gives very little benefits. At least with how the Amiga o.s. is working.

Protecting the zero page is quite helpful and more can be done. The MMU has been helpful for fixing bugs and improving compatibility on the Amiga too.

cdimauro Quote:

Security? How/why? Could you please clarify it?

Many exploits are through code and memory sharing mechanisms. More process isolation gives better security and stability. The 68k AmigaOS is small and it is possible to use isolated processes instead of shared processes. If WHDLoad games could be executed in an isolated environment it would improve Amiga stability for example.

Last edited by matthey on 30-Oct-2023 at 01:11 AM.

@matthey

Quote:

matthey wrote: cdimauro Quote: Is it really needed to implement the AA+ chipset? No software was written for it. I chose AA+ because it is the most advanced Amiga chipset with a suggested transistor count. Integrating chips should save transistors and AA+ is down to 2 major chips from 3 giving a closer approximation of transistor cost. It's nice that AA+ includes many features that didn't make it into AGA and it shows that adding chunky modes is possible and not too expensive even though it was only planned to include 16 bit chunky. Several of the SAGA enhancements are similar to the AA+ spec. The Apollo core team discussed AAA but many of the enhancements were rejected as not useful enough today while AA+ was found to be more practical. A new retro Amiga that borrows from what Amiga Corporation or C= was planning is more likely to have retro appeal today. For example, the following video shows SAGA sound enhancements (reverse engineered Paula upgraded to 16 bits with 16 voices). Vampire 4 STANDALONE 16 Bit 16 Track Pamela Audio running Milky Tracker Vamped Edition https://youtu.be/41vHR4dhN8M?t=48

I know it, but why to repeat the same mistakes which Commodore and Vampire engineer have made? Since there's no software written, the AGA chipset could be expanded in a different way.

For example, virtualizing the old register set and providing a brand new set of 32-bit registers which have a clean design and that are already open for future enhancements WITHOUT requiring horrible patches every time.

If you recall it, I've already defined all details more than 10 years ago on Olaf's Amiga forum. Unfortunately he closed it and everything is lost now (I had not even the time to make a copy of such threads).

An example, taking the 16 voices of SAGA that you've talked about. This was made by simply copying 4 times the Audio registers from Paula and with another horrible patch for extending the length of the samples.

My design, instead, defined 64 voices (but you don't have to implement all of them: only a subset can be added on first versions, and more to be added in subsequent ones) where the 4 original audio channels are mapped on 4 new channels of the new audio subsystem, all of them using 32-bit registers for holding the settings WITHOUT using bits randomly where they are free. Interrupts generated by the audio subsystem are grouped in 4 "macro channels", with additional registers used to signal which audio channels of the specific group have played all samples (and need to be set again).
Abandoning completely the support for 16-bit systems then 128 voices could be added (e.g.: 32 voices for each "macro channel group").

I'v made something similar for each Amiga subsystem (display with multiple playfields, sprites, big colour palettes, packed/chunky, Load-registers-DMA, and I think more).
Quote:

cdimauro Quote: Which is better choice. You also have to consider that you need to add more BTC caches and TLBs to make the cores more modern and getting more performances. Sure. At least the 68060 ATC with 64 entries 4 way is larger than the Cortex-A53 L1 TLB of 10 entries (L2 TLB is 512 entries 4 way). MMU hardware upgrades are not a high priority for the AmigaOS. The 68060 Branch Cache and prediction is relatively simple and doesn't use much logic (256 entry 4 way currently).

That's why it needs to be enhanced.
Quote:

A return/link stack is high priority for a shallow function code sharing Amiga but relatively cheap (8 entry?).

With so many transistors available, you can have a larger return stack.
Quote:

cdimauro Quote: Unfortunately there's not enough transistor budget for adding some useful L2 cache. It's better to used what's left for improving the platform (the chipset, which is very old). I didn't say we were limited to a $1 USD SoC. Raising the cost decreases general purpose embedded use and economies of scale while specialized options need to be very appealing for our own use and/or specialized embedded use.

Maybe it's better to focus on a simple and cheap SoC first.
Quote:

cdimauro Quote: The desktop market is over and not reachable anymore. A frontal assault of a seemingly impenetrable fortress is not recommended. ARM CPU cores and the RPi are showing that chipping away with a stealth approach is possible with economies of scale.

But they're running Linux: a monolithic mammoth.
Quote:

cdimauro Quote: MMU can't help that much here: it gives very little benefits. At least with how the Amiga o.s. is working. Protecting the zero page is quite helpful and more can be done.

Yes, but only this.
Quote:

The MMU has been helpful for fixing bugs and improving compatibility on the Amiga too.

You can use it for protecting code and data, but then the memory granularity increases a lot and becomes aligned to the MMU pages size, wasting a lot of memory (which isn't good on a system which can address only 2GB of memory).

Plus, it can lead to incompatibilities (since everything is shared on the Amiga o.s. address space).
Quote:

cdimauro Quote: Security? How/why? Could you please clarify it? Many exploits are through code and memory sharing mechanisms. More process isolation gives better security and stability. The 68k AmigaOS is small and it is possible to use isolated processes instead of shared processes.

That's totally against the Amiga o.s. foundation and cannot be achieved.

Unless you want to drop the compatibility. But then you've other, much bigger, problems.
Quote:

If WHDLoad games could be executed in an isolated environment it would improve Amiga stability for example.

This is possibly only for games which had / require no o.s. interaction, where WHDLoad has full control of what they are doing (basically the games only take care of hitting the hardware registers for the business logic. All I/O stuff is delegated to WHDLoad).

A good part of them should work like that, but others will be problematic (e.g.: some jump to the Kickstart, for example).

Anyway, isolating such processes when running isn't an easy task.

@cdimauro

Quote:

cdimauro wrote: For example, virtualizing the old register set and providing a brand new set of 32-bit registers which have a clean design and that are already open for future enhancements WITHOUT requiring horrible patches every time.

Anybody (commercially) developing custom HW past 1990 while not having a plausible plan to sell in 8-9 figures was and still is a fool.

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

@Kronos

Quote:

Kronos wrote: @cdimauro Anybody (commercially) developing custom HW past 1990 while not having a plausible plan to sell in 8-9 figures was and still is a fool.

I agree. Except I would say 7 figures and up.

_________________
All the way, with 68k

@Kronos: that's obvious.

cdimauro Quote:

I know it, but why to repeat the same mistakes which Commodore and Vampire engineer have made? Since there's no software written, the AGA chipset could be expanded in a different way. For example, virtualizing the old register set and providing a brand new set of 32-bit registers which have a clean design and that are already open for future enhancements WITHOUT requiring horrible patches every time. If you recall it, I've already defined all details more than 10 years ago on Olaf's Amiga forum. Unfortunately he closed it and everything is lost now (I had not even the time to make a copy of such threads). An example, taking the 16 voices of SAGA that you've talked about. This was made by simply copying 4 times the Audio registers from Paula and with another horrible patch for extending the length of the samples. My design, instead, defined 64 voices (but you don't have to implement all of them: only a subset can be added on first versions, and more to be added in subsequent ones) where the 4 original audio channels are mapped on 4 new channels of the new audio subsystem, all of them using 32-bit registers for holding the settings WITHOUT using bits randomly where they are free. Interrupts generated by the audio subsystem are grouped in 4 "macro channels", with additional registers used to signal which audio channels of the specific group have played all samples (and need to be set again). Abandoning completely the support for 16-bit systems then 128 voices could be added (e.g.: 32 voices for each "macro channel group"). I'v made something similar for each Amiga subsystem (display with multiple playfields, sprites, big colour palettes, packed/chunky, Load-registers-DMA, and I think more).

There are different options which are not always right or wrong. I'm not a hardware expert and I don't know what would be the best for hardware register compatibility. It would be best to talk to experts and try to form a consensus but a conservative route is likely better for retro appeal marketing.

cdimauro Quote:

With so many transistors available, you can have a larger return stack.

CPU core development is all about tradeoffs and limited resource usage. The Cortex-A53 has an 8 entry hardware return stack and the ColdFire V5 only a 4 entry return stack. Hardware which reduces code sharing overhead is certainly good for the 68k Amiga but I would need to see statistics on how deep function calls go before suggesting more than 8 entries. The chief architect and/or core development team may have a valuable opinion and should have some say if not final say. The business management sets overall goals but this is more of a core design choice.

cdimauro Quote:

But they're running Linux: a monolithic mammoth.

Yet it is more competitive for the desktop than the AmigaOS. There are other kernel options as well. The macOS uses a hybrid kernel and provides standardization that Linux lacks. Yes, it has more BSD influence than Linux but they both have Unix roots.

cdimauro Quote:

Yes, but only this.

More MMU support can be provided for new Amiga software just not old Amiga software. For better security, old software could be selectively restricted from executing. It sounds crazy to talk about a significant amount of new 68k Amiga software but I'm talking about mass produced affordable hardware which should spur development.

cdimauro Quote:

You can use it for protecting code and data, but then the memory granularity increases a lot and becomes aligned to the MMU pages size, wasting a lot of memory (which isn't good on a system which can address only 2GB of memory). Plus, it can lead to incompatibilities (since everything is shared on the Amiga o.s. address space).

Yes, MMU use significantly increases memory requirements. Adding full AmigaOS MMU use is difficult and bad for compatibility as AmigaOS 4 found. Perhaps optional and modular partial MMU use is an acceptable compromise for small footprint systems?

cdimauro Quote:

That's totally against the Amiga o.s. foundation and cannot be achieved. Unless you want to drop the compatibility. But then you've other, much bigger, problems.

I believe ARIX launches each program in an isolated process, albeit Linux process underneath AROS code. The lack of code and memory sharing is not only good for security but also allows other CPU cores to be used since the sharing is a problem for SMP as well. It uses more memory than sharing and inter process communication is not possible but the small size of the AmigaOS reduces the overhead. Sometimes it would be nice to sand box programs which are known to mis-behave. Perhaps a poor man's hardware virtualization without the overhead of twin pointers on every memory access is possible?

cdimauro Quote:

This is possibly only for games which had / require no o.s. interaction, where WHDLoad has full control of what they are doing (basically the games only take care of hitting the hardware registers for the business logic. All I/O stuff is delegated to WHDLoad). A good part of them should work like that, but others will be problematic (e.g.: some jump to the Kickstart, for example). Anyway, isolating such processes when running isn't an easy task.

WHDLoad is already providing some process isolation. An MMU may be able to improve the isolation.

Kronos Quote:

Anybody (commercially) developing custom HW past 1990 while not having a plausible plan to sell in 8-9 figures was and still is a fool.

There is high priced niche market embedded hardware using custom developed ASICs for lower production volumes. You are likely talking about mass produced commodity "custom HW" though. What I have been talking about may or may not be commodity hardware depending on if the SoC chip is available for others to purchase. The Raspberry Pi Foundation RP2040 has been my reference and is sold as commodity hardware as well as used in the RPi Pico. I estimate their goal is indeed 8 figures although their break even point may be 7 figures depending on the markup per chip.

Raspberry Pi Produced 10 Million RP2040s in 2021, More Pi Stores Likely
https://www.tomshardware.com/news/raspberry-pi-10-million-rp2040s

The article below states, "We have sufficient wafer stock on hand to produce 20 million chips, with more on the way." They also have volume discounts down to $0.70 per chip.

https://www.raspberrypi.com/news/raspberry-pi-direct-buy-rp2040-in-bulk-from-just-0-70/

The low cost of the chip and the small die size keeps the capital expenditure reasonable. For the RPiF first custom commodity ASIC, it looks like it is successful. There is a list of 19 devices the RP2040 is used in at the following link.

https://en.wikipedia.org/wiki/RP2040

They are trying to sell it as a microcontroller for embedded use too.

https://www.eenewseurope.com/en/raspberry-pi-starts-direct-sales-of-microcontroller/

Is it a home run? No. The Raspberry Pi direct site above comments give some hints.

MrZANE Quote:

Any chance you will be selling the required external flash also, or maybe make a version with built in flash?

A single chip SoC is a big advantage especially in the era of de-globalization and common supply disruptions. On chip flash would be nice but there are some disadvantages. The cheapest flash memory only works down to a certain chip process node. There are alternatives but they are more expensive and have disadvantages as well.

Joseph Quote:

If you want to talk about hard to get it is the $5 pi Zero. They did say this was a newer process so maybe they can’t get the other stuff themselves?

The RP2040 uses a very low power design but only has dual Arm Cortex-M0+ CPU cores at 133MHz. The Raspberry Pi Zero uses a single core ARM1176JZF-S at 1 GHz and the new RPi Zero 2 W uses a 4 core Cortex-A53 at 1 GHz. The RPi Zero isn't completely replaced by the Zero 2 W because the former is $5-$10 and the latter is $15. They both have only 512MiB of memory limiting them in some cases to the Thumb2 ISA instead of AArch64 ISA to save memory. Right here is your sweet spot in demand and where I believe a 68k Amiga SoC would be best placed. The 4x64 bit cores of the Cortex-A53 are unnecessary and inefficient use of transistors while in-order RISC CPU cores offer underwhelming performance. If transistors didn't matter, the successors to the Cortex-A53 would be used instead but it is the smallest AArch64 core and remains popular.

Last edited by matthey on 31-Oct-2023 at 07:04 PM.

@matthey

Well I'm pretty sure all rPI are just preexisting SoC that were designed for other markets, so "all" they do is design PCBs around that to make ready for tinkering.

But sure it is a question of complexity needed vs. $ that can be earned with. Which for general computing is all the same, small support chips can be had for little money of the shelf and anything that can be called CPU or GPU will need billions of transistors on a current node to make sense (or your back to buying of the shelf parts for little money).

The point is that all talks about better Amiga chips past and present was futile and 100% the effort should have gone into a proper RTG solution even before C= went down.

Most people that still !used! Amiga in the late 90s had already gone that road and where running the worst kind of "NG", the one where you still used a real Amiga for some basic IO and as a backplane to put all the -special_overpriced_sauce_based_on_PC_parts- cards into that provided all the functionality .

That kind of fake-Retro/fankenNG is still around today and even activly pushed by some to MAGA.


I'm pretty sure that 1st A is for Amiga, what else could it be

Last edited by Kronos on 31-Oct-2023 at 08:26 PM.

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

Kronos Quote:

Well I'm pretty sure all rPI are just preexisting SoC that were designed for other markets, so "all" they do is design PCBs around that to make ready for tinkering.

RPis originally used commodity mobile phone SoCs but the RPi Pico uses their custom SoC with MCU and they sell the SoC separately as commodity hardware.

https://en.wikipedia.org/wiki/RP2040

The RPiF may move to more complex SoCs replacing the mobile phone SoCs with custom SoCs containing exactly the features they want for their market. The ARM cores are a la carte making development easier but at a cost.

Kronos Quote:

But sure it is a question of complexity needed vs. $ that can be earned with. Which for general computing is all the same, small support chips can be had for little money of the shelf and anything that can be called CPU or GPU will need billions of transistors on a current node to make sense (or your back to buying of the shelf parts for little money).

A 68060 Amiga is less than 3 million transistors and the CPU core could operate at over 1GHz using less than a state of the art node. A 68060 Amiga SoC could likely cost less than $0.50 USD but transistors are very cheap so it is worthwhile to increase the value for a minimal cost. Between the RPi Zero and RPi 3, there is a huge market for embedded, hobby, educational and entertainment use. These CPU+GPU SoCs use tens of millions perhaps up to low hundreds of millions of transistors but not billions and they use less than state of the art chip process nodes (40nm-28nm) that offer more transistors/$. The hardware has the performance of ancient desktop hardware but using much lower power.

Kronos Quote:

The point is that all talks about better Amiga chips past and present was futile and 100% the effort should have gone into a proper RTG solution even before C= went down. Most people that still !used! Amiga in the late 90s had already gone that road and where running the worst kind of "NG", the one where you still used a real Amiga for some basic IO and as a backplane to put all the -special_overpriced_sauce_based_on_PC_parts- cards into that provided all the functionality .

There is nothing wrong with an integrated CPU+I/O+GPU which is where low end computing has moved today with SoC ASICs. The advantages are improved performance, reduced power, standard hardware requires fewer drivers, standard hardware often results in more optimized code and significantly lower cost. It looks like C= had a single chip 68k Amiga SoC in their product roadmap which would have put them ahead of the competition and created a RPi like Amiga. See the slide labeled "Hardware Technology History/Plan" for the "Single Chip" 68k SoC plan claimed to be from C= internal documentation.

https://archive.org/details/commodore-post-bankruptcy

The problem is that C= failed to integrate and upgrade the Amiga chipset. While SoCs are used extensively for low end computers today, Apple is leveraging the advantages of standard SoCs with integrated GPUs for high performance computers as well. A plug in GPU is more hardware cost and a data transfer bottleneck between the CPU and GPU. SoCs with CPU and GPU are cheaper than just a gfx card. The problem is actually the opposite of what you imply. The logic that a high performance computer, including an Amiga, needs a plug in GPU is flawed and outdated. A 68k Amiga SoC has the potential to solve the problem of drivers and expensive hardware.

@matthey

Goalposts, goalpost a forest of goalposts

-rPI

So after selling millions of tinker level HW each year they are now at a point where they can license some IP and have a custom IC made.
Far cry from someone (like C= in the 90s) trying to build maintain their own IP from the bottom up (based an flawed legacy tech and with SW relying on that flawed legacy tech).

- 1GHz 68060
Now this needs to be sperated:
- alternate history Moto/FreeScale/... trying to do that for a 2000 release to compete with Pentium3 and Athlon.
This at they time would have been a (multi) billion $ development
-- With 68k-Mac,Amiga and AtariST gone
Not even remotely viable.
--alternative universe with no PPC and all 3 still alive and kicking
Might have been viable in a best case scenario

- Creating something like that today
Sure might be "just" a few millions to spend but outside of a few 1000 fake retro fans, whos gonna buy?
Thats why all attempts in that direction are (were) done emulating it on existing HW, UAE/Amithlon, PiStorm and everything FPGA.

- Apple using standard SoCs
Obviously not true, Apple is at the scale where apart from some basic IP they licenced decades ago they can do and do everything in house.


- a 68k Amiga SoC has the potential....
...to sell a few 1000 units today and wasn't a viable option when it could have been sold in millions.

And here lies the issue, either we are talking about how to create a 1997 computer in 2023 for the faithfull few or we are talking about how C= (ESCOM) could have made the Amiga survive in a completive and somewhat realistic way.

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

vampire failed bacause
- it has not mmu even simple zero page protection
- it has not 3D
- it has not compatible FPU
all this shoud be in vampire v2 instead of useless AGA and AMMX.
people should not be forced to buy v4 for it

New amiga retro hardware should be ECS and somethign better for 2D/3D in parallel to ECS.
Amiga retro fans should use ECS for old things.
Play games on it, use DP PT etc on it.
Use ECS for everything that was made on Amiga up to spring 1993.
For never games and apps use something better for graphics in parallel to ECS.
2D is 3D without one D. So if You have 3D You may use it as well in 2D.
New amiga retro hardware should have some easy to use basic 3D.
zbuffer, perspective correction 640x480 25 fps. no more.
New amiga retro hardware should be made in way that
it may be used as graphics card in Amiga NG.
so everybody will use it.

I just want “turbo AGA”, compatible with existing AGA software, only faster.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Isn't that what the Vampire is for?

_________________
Doing stupid things for fun...

@ppcamiga1

And here we have the SoundByte X9000 chiming in with random words.

Vampire failed?
By whatever measure the Apollo Team is considered a failure with their Apollo range of FPGA-based accelerators and Standalone 080 + SAGA devices, then by the same measure A-EON is also failure with their range of non-upgradable PPC-based line of computers and system boards.

The Apollo team has sold more V2 + V4 devices than A-EON and Eyetech (combined) have sold PPC systems for AmigaOS 4.

Nobody was forced to buy anything. Though I’m sure the fascist in you would like to force everyone to buy a PPC-based AmigaOS 4 + Enhancer 2 compatible computer.

Commodore failed because they released ECS in 1990 instead of 1988.

Last edited by agami on 01-Nov-2023 at 01:13 PM.

_________________
All the way, with 68k

@ppcamiga1

And here we have the SoundByte X9000 chiming in with random words.

Vampire failed?
By whatever measure the Apollo Team is considered a failure with their Apollo range of FPGA-based accelerators and Standalone 080 + SAGA devices, then by the same measure A-EON is also failure with their range of non-upgradable PPC-based line of computers and system boards.

The Apollo team has sold more V2 + V4 devices than A-EON and Eyetech (combined) have sold PPC systems for AmigaOS 4.

Nobody was forced to buy anything. Though I’m sure the fascist in you would like to force everyone to buy a PPC-based AmigaOS 4 + Enhancer 2 compatible computer.

Commodore failed because they released ECS in 1990 instead of 1988.

_________________
All the way, with 68k

@Karlos

Quote:

Karlos wrote: @kolla Isn't that what the Vampire is for?

According to some, a computer is only as good as can be used to feel superior and lord over others.

The V2 and V4 series of 080 + SAGA retroputers do very little to confir status. Worthy only of the disapproval which parents have for wayward children.

Last edited by agami on 01-Nov-2023 at 01:26 PM.

_________________
All the way, with 68k

@agami

Quote:

agami wrote: Vampire failed? By whatever measure the Apollo Team is considered a failure

I'd say we use their own words/plans as "measure" .... oh boy.

Pointing out that the failed a bit less than a total s##tshow is pretty much admitting that they failed even in your eyes.

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

@Kronos

Missing a target in some original plan, does not a failure make.

Sony may “fail” to release a game by some pre-announced date. That does not make SONY, nor the game in question, a “failure”.

_________________
All the way, with 68k

@agami

No idea what you are talking bout, but at least one Apollo team member (leader) had made statements over a long period of time that were and still are outright delusional.

You know like the "on schedule and rocking","2 more weeks" kinda obvious BS swallowed wholesale by the gullible parts parts of the community a decade before.

By those claims they have failed and anything but a failure was never even a possibility.

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