@vox

Quote:

vox wrote: Hopefully legal hell has to be resolved at some point

Even if you'd remove all the egos, still far to convoluted with far too little value to ever get resolved.

It might be at some point be ignored by everybody, but will for sure pop up again once any money is being made.

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

vox Quote:

I agree much bigger problem is Hyperion - on user side not honoring their promises, laging updates, not fixing bugs, outsourcing work (most recent example is CFE not being updated because sources are lost). I can say OS4 is quite advanced to OS 3.1 but not taken much more forward software wise.

There is nothing wrong with outsourcing (contract development work). In-house development work would likely add too much expense and work as home tools have improved a lot. The contracts need to be managed correctly, which Ben as a lawyer was supposed to be good at, and people payed, which Ben as a con artist was bad at. A-Eon and AmigaKit are developing software with satisfied developers who are likely working from home most of the time, whether contract workers or regular employees. Ben has enough business sense to realize there is no money to be made in the tiny PPC AmigaOS 4 market so he got creative. Cheated employees and developers resulted in lawsuits and a legal mess for AmigaOS 4 which will need to be addressed after Ben is out of the picture. Scamming Amiga Inc. and Trevor for more development funds was more lucrative until Ben was caught embezzling funds and forging bank records by Trevor who then had the negotiating advantage. This only left moving in on Cloanto's larger retro 68k Amiga business as a revenue stream and even better for Ben was that the developers agreed not to be paid at all in return for him "allowing" the 68k AmigaOS to come to market. They should have talked to Cloanto/Amiga Corporation first but AmigaOS 3 and AmigaOS 4 developers and development are intertwined so they went to Hyperion. Hyperion has a monopoly on the AmigaOS 4 source code they failed to deliver as contractually obligated, even after additional shakedown AmigaOS 4 development payments.

By Hyperion "user side not honoring their promises" do you mean announcements that were not delivered, broken business contract "promises" that affect users or both? Isn't it clear that Ben is an opportunistic con-man looking for big payouts, beyond even the classic unethical litigation lawyer? Wouldn't a business man make deals to create bridges to prosperity rather than con anyone and everyone thus burning his bridges? How do people not see Ben for what he is and still expect good from this lost soul?

vox Quote:

Since OS4 ecosystem was constantly locked in perpetum of short avail and expensive hardware (with Moana port as lost opportunity) and not fully developed OS-drivers for existing board, OS 3.2 and backporting to m68k is Hyperions lifeline. Like now backporting their game catalogue to OS3 :D

The AmigaOS 4 problem of expensive hardware is not by accident. Part of the problem may have been Hyperion's business model of requiring businesses to pay them for an AmigaOS 4 port to their hardware. Amiga IP licensing likely costs extra like "AmigaOne and boing ball logo use which Hyperion "obtained" in the 2009 settlement agreement. Hyperion likely considered non-payed ports to cheaper PPC hardware but may have changed their mind due to the 2009 settlement agreement or the 2010 secret agreement which sublicensed Amiga IP to A-Eon.

2006 PS3 released which later had partially working PPC AmigaOS 4 port
2006 Wii released which has AmigaForever support (https://www.amigaforever.com/wii/)
2006 Efika PPC released
2009 settlement agreement between Amiga Inc. and Hyperion
2009 A-Eon Technology of Belgium created
2010 Secret Agreement due to Ben Hermans embezzlement of A-Eon Belgium (https://docs.google.com/file/d/1CubXmx5uhTn_i4h2sVP5N1gjbqwTPK2u/edit)
2012 AmigaOne X1000 released
2012 A-Eon Technology Ltd. of Wales created
2012 AmigaOne netbook was due to launch but later cancelled
2016 AmigaOne X5000 released (X3500/A1222 low end motherboard designed concurrently)

There were several opportunities to use cheap PPC hardware. There are likely legitimate reasons why some of the hardware was not used but there could be political reasons why AmigaOS 4 did not make it to low cost PPC hardware. Would a $299 USD PS3 with Cell@3.2GHz affect the sales of a $2000+ USD AmigaOne X1000 with PA6T@1.8GHz? Why did MorphOS get cheap used Macs and cheap PPC Efika but the cheapest AmigaOS 4 hardware was several times more expensive? Who was in control? Did someone plan on bringing out their own low end PPC hardware later? Did someone try to monopolize the AmigaOne brand?

Cool_amigaN Quote:

Heh, 10 to 1? Make it 100 to 1 to be more accurate. But still, this just further highlights and strengths my original point: despite it's huge financial and commercial success, it returned zero impact to the active Amiga market/eco-system sadly. Or to state it otherwise: the AmigaOne which sold 99% less times, produced software 99% more. I still believe that RGL didn't / don't want to really dip into the Amiga, as I can't understand how they couldn't strike a deal for AOS 3.2 which was available a whole year before the A500 mini release. Especially given the fact that they did license the original kickstart roms. Therefore, the only logical assuption is that they licensed only the bare minimum in order to have a plug and play console built for clearly nostalgic audience. Which again, is totally fair from a business pov but is also a reminder that managing a (successfull) product in the Amiga/retro market from strictly bussiness perspective doesn't really mean that the product will actually help advance the platform.

Yes, THEA500 Mini to Amiga1 hardware sales ratio is likely closer to 100 to 1 but without sales numbers, I gave a very conservative estimate. I have made similar statements as you about THEA500 Mini. I feel like THEA500 Mini is a missed opportunity because it doesn't add new Amiga users or developers. It is too handicapped to do much more than raise Amiga awareness. Awareness is important for future products but the window of opportunity to benefit from the momentum with hardware that would make a difference won't last forever. We need affordable retro 68k Amiga hardware that is as functional and compatible as the original but with more modern features and performance. We also need the Amiga IP squatters and road blocks to become road bumps. It would be interesting to see what RGL could and would do without situation limitations. I'm afraid THEA500 Maxi will have too many situation limitations to build on THEA500 Mini momentum resulting in another missed opportunity for the Amiga.

@matthey

The fact they call it the full sized 'Amiga' console indicates that IP restrictions may have eased.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

BigD Quote:

The fact they call it the full sized 'Amiga' console indicates that IP restrictions may have eased.

It appears to be official.

Retro Games Timeline – Updated
https://youtu.be/ADODEjGNAYg?t=50 Quote:

Q1 2025 NEW FULL SIZE AMIGA CONSOLE LAUNCHED

Maybe they are just referring to an Amiga in general but with Amiga Corporation owning the "Amiga" brand, they don't have to worry as much where they already are licensing Amiga IP. "AmigaOS" is the real sticking point and more of a problem for a Maxi device with the expectation of original functionality. I would rather not see an emulation based product soil the Amiga brand. They do say console so it could be a close to full size CD32 that doesn't need a keyboard but maybe has a CD-ROM drive and internal storage? They already have CD32 controllers and it would be easier to produce than an Amiga 1200 which also makes sense due to being more popular, more recognizable and relatively small. There are a few options for real 68020 CPUs and a FPGA could be used for the chipset but I would be surprised if it is not emulation based again.

Last edited by matthey on 17-Sep-2024 at 04:10 PM.
Last edited by matthey on 17-Sep-2024 at 01:15 AM.

@matthey: Indeed. There cannot be surprises: it'll be based again on emulation.

It's a console, at end: it's all about games, and UAE is the best option here until all schematics of the original chips are found.

@matthey

Quote:

They do say console so it could be a close to full size CD32 that doesn't need a keyboard but maybe has a CD-ROM drive and internal storage?

It'll likely be an Amiga 600 Maxi hence some of the annoyance from other parties. The joys of this market!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

cdimauro Quote:

It's a console, at end: it's all about games, and UAE is the best option here until all schematics of the original chips are found.

Michele has a large archive of information from CBM which he has talked about in show videos. I'm not sure he even has it all sorted as he has to perform searches. Jeri Ellsworth has schematics.

The Amiga on a Chip Project - Too bad it was canceled
https://www.youtube.com/watch?v=5uaDzF99a80 Quote:

In fact, is was much easier to reverse engineer the Amiga even having the schematics. I mean that helped a lot but the Amiga was a far more straight forward design than the original C64 because they didn't have to do as many naughty tricks to make things work.

One person was preparing an ASIC Amiga chipset. I expect FPGA Amiga chipset cores are close as well because the logic is "straight forward". I wonder if any HDL code ever existed for the original OCS or even ECS. Surely it did by the time of AGA which would be very helpful. They likely had to submit the Lisa chip to HP in some format although it may have been a netlist.

https://vhdlwhiz.com/terminology/netlist/

Netlists would be valuable too. There likely is enough data around to accurately recreate the custom chips but they need integrating together into a single chip, even without enhancements, which Jeri was also doing. AGA and 68020 compatibility would be more important today to make more than an extremely low cost toy. A more enhanced chipset, a highly compatible 68000 core and enhanced 68060 cores with enough performance to embarrass the ARM 68k emulation competition could still have a very low production cost as an ASIC SoC. Development and one time ASIC costs would be millions of USD but it is an investment in ridiculously low production costs for mass production.

BigD Quote:

It'll likely be an Amiga 600 Maxi hence some of the annoyance from other parties. The joys of this market!

An Amiga 600 Maxi would be the cheapest wedge Amiga to recreate but it was not popular and seen as a mistake even though it regained some popularity more recently. I would recreate an Amiga 1200 before an Amiga 600 even if the production cost was higher. A CD32 would be an interesting curve ball and I wouldn't put it past them especially if they could use "Amiga CD32" which works better than "CD32". I think it would sell well and could potentially be cheaper than a wedge computer even with a CD-ROM but I don't want to see "Amiga" branded hardware using emulation. It's disrespectful when the Amiga was designed for elegance and efficiency to use emulation which is the opposite.

Last edited by matthey on 17-Sep-2024 at 11:49 PM.

@matthey

Quote:

matthey wrote: cdimauro Quote: It's a console, at end: it's all about games, and UAE is the best option here until all schematics of the original chips are found. Michele has a large archive of information from CBM which he has talked about in show videos. I'm not sure he even has it all sorted as he has to perform searches. Jeri Ellsworth has schematics. The Amiga on a Chip Project - Too bad it was canceled https://www.youtube.com/watch?v=5uaDzF99a80 Quote: In fact, is was much easier to reverse engineer the Amiga even having the schematics. I mean that helped a lot but the Amiga was a far more straight forward design than the original C64 because they didn't have to do as many naughty tricks to make things work. One person was preparing an ASIC Amiga chipset. I expect FPGA Amiga chipset cores are close as well because the logic is "straight forward". I wonder if any HDL code ever existed for the original OCS or even ECS. Surely it did by the time of AGA which would be very helpful. They likely had to submit the Lisa chip to HP in some format although it may have been a netlist. https://vhdlwhiz.com/terminology/netlist/ Netlists would be valuable too. There likely is enough data around to accurately recreate the custom chips but they need integrating together into a single chip, even without enhancements, which Jeri was also doing.

OK, then recreating the chipset in a high-level form is definitely possible. What's strange is that they weren't used.
Quote:

AGA and 68020 compatibility would be more important today to make more than an extremely low cost toy. A more enhanced chipset, a highly compatible 68000 core

As I've said in the past, the two primary configurations are needed for such projects: 7Mhz 68000 + ECS and 14Mhz 68EC020 + AGA. Since the platform is running games, those should be supported hardware platforms.
Quote:

and enhanced 68060 cores with enough performance to embarrass the ARM 68k emulation competition could still have a very low production cost as an ASIC SoC. Development and one time ASIC costs would be millions of USD but it is an investment in ridiculously low production costs for mass production.

Unfortunately, this goes well beyond the goal of the Amiga Mini and Max: it's completely out of scope.

However, another big problem with an ASIC is that it cannot give you the control and easy of development of a platform based on emulation.
You've, again, to think about the goal of the project. This product requires a frontend for presenting, launching, and controlling games.
Doing it "inside" a running system (e.g. a 68k ASIC with the Amiga chipset) is impossible, for obvious reasons. You can add another processor (ARM?) to act as the master of the system and controlling everything, but it complicates the design and requires time to develop from scratch all the needful to achieve the goal.

That's very likely the reason why they decided to go to the easy way: a cheap ARM Linux box with an emulator for the Amiga games.

The only difference between an A600 and an A1200 in this context, is the numpad for certain games, and one can get USB numpads cheaply. A full size CD32 makes no sense at all, just a big empty box and no keyboard?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Quote:

What's strange is that they weren't used.

Why? Minimig already goes beyond what original chipset was capable of, and is open source, ridden from claims of copyrights etc. And software emulation is a heck lot easier to deal with, than sourcing cheap yet capable FPGAs.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: @cdimauro Quote: What's strange is that they weren't used. Why? Minimig already goes beyond what original chipset was capable of,

But it's lacking full compatibility...
Quote:

and is open source, ridden from claims of copyrights etc.

Which wasn't the problem with RGL, thanks to the partnership with the Amiga Corporation, which has all IPs.
Quote:

And software emulation is a heck lot easier to deal with, than sourcing cheap yet capable FPGAs.

Exactly. Because you don't just need to run the system, but you need much more for the final product, as I've already stated.

@cdimauro

Quote:

But it's lacking full compatibility

With what? It’s a heck lot more compatible than any given CBM Amiga - it does AGA better than any ECS Amiga and it does ECS and OCS a heck lot better than any AGA system. Lacking a few of the more exotic screen modes that AGA has is compensated greatly by other means (including RTG), and for audio tocatta is built in.

So exactly what compatibility is missing?

Quote:

which has all IPs

No, they don’t, they don’t even have the OS sources. They have _rights_ to the IP, but a lot of it is forever lost, and would need to be reverse engineered and reimplemented somehow anyways, also to fit in a "modern" design (lower voltage etc).

Last edited by kolla on 18-Sep-2024 at 10:31 PM.
Last edited by kolla on 18-Sep-2024 at 10:23 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

cdimauro Quote:

OK, then recreating the chipset in a high-level form is definitely possible. What's strange is that they weren't used.

The chipset was straight forward to reverse engineer even without the schematics. The schematics were helpful for bugs and verification. It may be that the toy business wanted to avoid any extra cost of licensing the Amiga chipset and may have never tried to license the chipset. It's too bad when licensing is not attempted as sometimes they can be good deals and business partners found. I wonder if anyone has even tried to license Amiga chipsets or 68k CPUs recently. I suspect not many if any have.

Even the reverse engineered FPGA cores are in high level logic form. The developers usually work with Verilog of VHDL code. They may use higher level tools though.

cdimauro Quote:

As I've said in the past, the two primary configurations are needed for such projects: 7Mhz 68000 + ECS and 14Mhz 68EC020 + AGA. Since the platform is running games, those should be supported hardware platforms.

A cycle exact 68000 with programmable clock speeds would be needed for best compatibility with 68000 computers and consoles. There is a 68000 open hardware core available that aims to be cycle exact although it may need more verification work so licensing the original 68000 may save time and reduce potential bugs. I'm not sure a 68EC020 is needed as cycle exact timing was not as important and most 68020+ hardware were more flexible computers and not bang the hardware consoles (Amiga, Atari, Mac, X68000). A 68020+ CPU is complex enough that it would be difficult to reverse engineer a cycle exact core and time consuming. The Amiga, Atari, X68000 and Amiga CD32 console (more upgradeable than most other consoles) all support a 68060 already and Mac emulators could use a 68060 with some patching. Many of the games that have 68060 issues already have 68060 patches and compatibility upgrades to the 68060 could and should be made like adding the 64-bit MUL and DIV instructions back. With the 68060.library in flash ROM, I believe it is possible to have upgradeable performance with good compatibility. Games could be slowed down by lowering the CPU clock speed with fine grain clock selection, changing cache selections and adding wait states to memory. Fine grain clock selection is already possible with the CD TF360 accelerator as demonstrated in the following video.

Best Amiga gaming combo: CD32 + TF360?
https://youtu.be/MyH7sWahGRU?t=1698

A 68LC060 without FPU is used as it is cheap. It was chosen over a 68030 accelerator because the value is better and compatibility is adequate as explained in the video. If new CD32s with TF360 rev6 68060@100MHz were available and affordable, they would sell like hot cakes. Now imagine what a 68060@1GHz SoC ASIC that is more affordable and with more modern features like HDMI and USB would do for the Amiga. It could have features for other 68k consoles too to further increase demand like a small FPGA for chipsets.

cdimauro Quote:

Unfortunately, this goes well beyond the goal of the Amiga Mini and Max: it's completely out of scope.

An ASIC is a cost reduction for mass production. This is why Jeri developed SoCs for the C64 and Amiga. Once developing an ASIC, it is very cheap to enhance it (transistors are cheap).

68000+OCS $.20
68020+AGA $.50
2x68060+68000+AA+ $1

The additional development time is more important than the small difference in ASIC production cost. Until adding an OoO CPU core or a semi-modern GPU, there is only a small difference in ASIC production cost but a lot of value can be added. This is a similar situation as CBM chipset enhancements that were not made by CBM even though they were the cheapest way to add value. The CPU is even added to the SoC which CBM planned according to the CBM post bankruptcy docs.

cdimauro Quote:

However, another big problem with an ASIC is that it cannot give you the control and easy of development of a platform based on emulation.

$10 USD FPGA? It may be a large cost for very low priced hardware but it gives a lot of flexibility for chipsets and more. There are FPGAs with flash memory built in and since flash memory doesn't scale below about 50nm, flash memory is usually not included in newer SoCs adding at least one extra chip. If the FPGA flash memory could be accessed for other than FPGA needs, then a FPGA+flash may not be more chips than just flash.

cdimauro Quote:

You've, again, to think about the goal of the project. This product requires a frontend for presenting, launching, and controlling games.

All that is needed is to boot just like original Amigas. There can be a program in flash ROM or the Startup-Sequence that detects when a key is held to get to a special menu. Some Amiga owners have set up their original Amigas this way. There can also be hot keys/commodities after the computer is booted to quickly access settings. There are already game launchers available some of which are likely open source. Some new software would be required but it is hardly rocket science.

cdimauro Quote:

Doing it "inside" a running system (e.g. a 68k ASIC with the Amiga chipset) is impossible, for obvious reasons. You can add another processor (ARM?) to act as the master of the system and controlling everything, but it complicates the design and requires time to develop from scratch all the needful to achieve the goal. That's very likely the reason why they decided to go to the easy way: a cheap ARM Linux box with an emulator for the Amiga games.

Poor ARM outside please.

Last edited by matthey on 19-Sep-2024 at 12:56 AM.

@kolla

Quote:

kolla wrote: @cdimauro Quote: But it's lacking full compatibility With what? It’s a heck lot more compatible than any given CBM Amiga - it does AGA better than any ECS Amiga and it does ECS and OCS a heck lot better than any AGA system.

This isn't about compatibility, rather ENHANCING ("better") both chipsets. Which could hurt the compatibility, if not properly made.
Quote:

Lacking a few of the more exotic screen modes that AGA has

Do you mean the 800 x 300 screen?
Quote:

is compensated greatly by other means (including RTG), and for audio tocatta is built in.

Again, see above.
Quote:

So exactly what compatibility is missing?

Implementation of the chipset, of course, in all its details.

I think that you don't follow the WinUAE development since some decade, because almost on every release that are new things of the chipset which are discovered and implemented, and that enhance the compatibility, of course.

Which means that games with some defects now properly work.

THAT IS COMPATIBILITY!
Quote:

Quote: which has all IPs No, they don’t, they don’t even have the OS sources.

Are you sure? And if then haven't them, you should know that such sources are "around", so they can download and use them (since they are the right to do it).
Quote:

They have _rights_ to the IP, but a lot of it is forever lost, and would need to be reverse engineered and reimplemented somehow anyways, also to fit in a "modern" design (lower voltage etc).

Of course, work is required. But it looks that the schematics are available.

@matthey

Quote:

matthey wrote: cdimauro Quote: OK, then recreating the chipset in a high-level form is definitely possible. What's strange is that they weren't used. The chipset was straight forward to reverse engineer even without the schematics. The schematics were helpful for bugs and verification. It may be that the toy business wanted to avoid any extra cost of licensing the Amiga chipset and may have never tried to license the chipset.

I don't think so. The interest of the Amiga Corporation was to make money out of this new console, and adding more costs only for the chipset could have hurt the production.

At the end, I think that, overall cost/business wise, the solution found was more convenient.
Quote:

It's too bad when licensing is not attempted as sometimes they can be good deals and business partners found. I wonder if anyone has even tried to license Amiga chipsets or 68k CPUs recently. I suspect not many if any have.

The primary problem is... having the product. Who has the chipset schematics? I think only Jeri. Is Jeri inclined to give out them to Amiga Corporation?

After that, we can think about asking how much costs licensing them. But I don't think that Michele can raise the bar so much for this obsolete stuff.
Quote:

Even the reverse engineered FPGA cores are in high level logic form. The developers usually work with Verilog of VHDL code. They may use higher level tools though.

But you've to convert the schematics in such form. From what I've seen from Alice's schematics, there's nothing like that.
Quote:

cdimauro Quote: As I've said in the past, the two primary configurations are needed for such projects: 7Mhz 68000 + ECS and 14Mhz 68EC020 + AGA. Since the platform is running games, those should be supported hardware platforms. A cycle exact 68000 with programmable clock speeds would be needed for best compatibility with 68000 computers and consoles.

Exactly. This is absolutely mandatory if compatibility is important, since a lot of OCS/ECS games were developed by dogs which have used all sort of dirty tricks.
Quote:

There is a 68000 open hardware core available that aims to be cycle exact although it may need more verification work so licensing the original 68000 may save time and reduce potential bugs.

Hum. Licensing the original might require a lot of money. I don't know if it's the right way to proceed here.

Actually WinUAE has a cycle-exact 68000 implementation, so it's definitely possible to do the same in some HDL, taking its sources as a reference. But requires time/effort/money, of course.
Quote:

I'm not sure a 68EC020 is needed as cycle exact timing was not as important and most 68020+ hardware were more flexible computers and not bang the hardware consoles (Amiga, Atari, Mac, X68000). A 68020+ CPU is complex enough that it would be difficult to reverse engineer a cycle exact core and time consuming.

Indeed, and it's not required.
Quote:

The Amiga, Atari, X68000 and Amiga CD32 console (more upgradeable than most other consoles) all support a 68060 already and Mac emulators could use a 68060 with some patching. Many of the games that have 68060 issues already have 68060 patches and compatibility upgrades to the 68060 could and should be made like adding the 64-bit MUL and DIV instructions back. With the 68060.library in flash ROM, I believe it is possible to have upgradeable performance with good compatibility. Games could be slowed down by lowering the CPU clock speed with fine grain clock selection, changing cache selections and adding wait states to memory. Fine grain clock selection is already possible with the CD TF360 accelerator as demonstrated in the following video. Best Amiga gaming combo: CD32 + TF360? https://youtu.be/MyH7sWahGRU?t=1698 A 68LC060 without FPU is used as it is cheap. It was chosen over a 68030 accelerator because the value is better and compatibility is adequate as explained in the video. If new CD32s with TF360 rev6 68060@100MHz were available and affordable, they would sell like hot cakes. Now imagine what a 68060@1GHz SoC ASIC that is more affordable and with more modern features like HDMI and USB would do for the Amiga. It could have features for other 68k consoles too to further increase demand like a small FPGA for chipsets. cdimauro Quote: Unfortunately, this goes well beyond the goal of the Amiga Mini and Max: it's completely out of scope. An ASIC is a cost reduction for mass production. This is why Jeri developed SoCs for the C64 and Amiga. Once developing an ASIC, it is very cheap to enhance it (transistors are cheap). 68000+OCS $.20 68020+AGA $.50 2x68060+68000+AA+ $1 The additional development time is more important than the small difference in ASIC production cost. Until adding an OoO CPU core or a semi-modern GPU, there is only a small difference in ASIC production cost but a lot of value can be added. This is a similar situation as CBM chipset enhancements that were not made by CBM even though they were the cheapest way to add value. The CPU is even added to the SoC which CBM planned according to the CBM post bankruptcy docs. cdimauro Quote: However, another big problem with an ASIC is that it cannot give you the control and easy of development of a platform based on emulation. $10 USD FPGA? It may be a large cost for very low priced hardware but it gives a lot of flexibility for chipsets and more. There are FPGAs with flash memory built in and since flash memory doesn't scale below about 50nm, flash memory is usually not included in newer SoCs adding at least one extra chip. If the FPGA flash memory could be accessed for other than FPGA needs, then a FPGA+flash may not be more chips than just flash.

As I've said before, that goes well beyond the scope of the product. I know that you're passionate about such stuff, but you should put aside it for a moment, and think more as a company which has to sell a console.

So, if you would be someone that wants to create a console to run Amiga games, and only them, what solution you should have implemented? Answering this questions shows what's really need to reach the goal AND make it... profitable... as much as possible (remember: it's a business).
Quote:

cdimauro Quote: You've, again, to think about the goal of the project. This product requires a frontend for presenting, launching, and controlling games. All that is needed is to boot just like original Amigas. There can be a program in flash ROM or the Startup-Sequence that detects when a key is held to get to a special menu. Some Amiga owners have set up their original Amigas this way. There can also be hot keys/commodities after the computer is booted to quickly access settings. There are already game launchers available some of which are likely open source. Some new software would be required but it is hardly rocket science.

Feasible, but limited (since the hardware is the same / "original") and requires more development.
Quote:

cdimauro Quote: Doing it "inside" a running system (e.g. a 68k ASIC with the Amiga chipset) is impossible, for obvious reasons. You can add another processor (ARM?) to act as the master of the system and controlling everything, but it complicates the design and requires time to develop from scratch all the needful to achieve the goal. That's very likely the reason why they decided to go to the easy way: a cheap ARM Linux box with an emulator for the Amiga games. Poor ARM outside please.

You can use another 68k only for that, I don't see the problem.

My problem on products like that is having an hypervisor which controls everything and can take actions also in the case that the system crashed for some reason, for example (which isn't rare on the Amiga land, as you know).

So, to me the most important thing is giving the best possible user experience: turn on the system and play, leaving all above burden to the implementation.