@V8

What Hans does is quite niche. He's had to invest a lot of his time and energy into providing functional drivers for OS4 and kudos to him for that. I would contend that nothing he's had to do to make this happen is intrinsically dependent on PPC except by circumstance because the operating system he's working on only runs on PPC. I would be surprised if more than one percent was implemented in PPC assembler.

_________________
Doing stupid things for fun...

Hans Quote:

???? So, after insulting me multiple times you're now comparing me to Dr Evil and a black mailer holding you to ransom.

I was just saying you are out of touch with how much a million U.S. dollars has depreciated like Dr. Evil after being cryogenically frozen for 3 decades (the movie is another 25 years old now too).

Hans Quote:

I'm stating a simple fact: this kind of development is very expensive, and you're probably underestimating the cost, time & effort required significantly. Ignore at your own peril. Calling people Dr Evil won't lower the cost or make the economic viability any better.

Hiring top developers is expensive because they are worth it. I expect it would cost millions of dollars to develop and produce a professional quality 68k Amiga SoC ASIC that is in RPi hardware territory. I expect $7 million would go a along way and leave some reserve. The SoC chips could be sold for 3rd party boards and accelerators with high margin, due to lack of competition, soon after production and testing. Developers like Jens Schoenfeld could be approached and interest found for quantity discounts. Low cost 68k CPUs have dried up while higher performance 68060s are often unavailable or too expensive to provide for customers. There are at least 3 fairly new 68060 accelerator board designs despite 68060s going for insane prices if they can even be found. Improving the performance/price of accelerators by huge amounts would likely result in tens of thousands of SoC chips sold for retro hardware. Producing RPi like Amiga SBCs would also be very cheap due to the reduced components from using a SoC. It is not necessary to beat RPi pricing with unique features like native 68k support and retro features. Choice is good as some people prefer cherry pie over Raspberry pie and the 68k AmigaOS over ARM RISC OS. The key is to make the hardware competitive enough that the price isn't the biggest factor for choosing the hardware. RPi hardware is difficult to compete with on price but smart phone SoC features aren't the best for small SBCs. This is why they are also moving to custom SoC ASICs like the RP2040 but they are currently focused on very low end and power embedded, hobby and educational markets. A 68k Amiga SoC ASIC would be more expensive to develop than the RP2040 but it has potential to attract support from nostalgic developers that could reduce development costs if done professionally. Also, part of payment to developers could be stock in the business which encourages high quality work. Some original 68k and Amiga developers, even if some are just consultation roles, would generate excitement, momentum and grass roots support. A combined Amiga business could become a retro gaming power house and/or develop into a competitive fabless semiconductor business. The current Amiga businesses need to pool their resources and raise millions of dollars of capital to work with though. Maintaining the current niche PPC hardware path is wasting time and all these lawsuits are wasting cash. Switching to a software only Amiga business is low risk and low reward. Good luck competing with free emulators and OSs. There is a little profit to be made from selling retro Amiga apparel, ROMs and the AmigaOS but developers would need to work for free on any enhancements to keep it cheap. The 68k AmigaOS development is a good example of nostalgic developers sacrificing to try to further the Amiga platform but there is a problem.

Hans Quote:

AmigaOS is effectively "competing" with all other OSes regardless of the hardware it's running on. Or, should i say, "not competing," or "competing very badly." I don't buy the "you need different hardware or you'll be competing with Windows and MacOS" argument any more. Linux runs on all AmigaOS hardware, an nobody who needs/wants Windows is going to use AmigaOS because they accidentally bought a PowerPC/68K machine.

The AmigaOS doesn't compete with other OSs that can't run on as low of footprint hardware. The AmigaOS competes better on lower end hardware where fat OSs and cut down distros are sluggish and non-standard. The 68k Amiga offers a standard system that scales to a very small footprint (512kiB ROM, 2MiB of memory with little effort). It has a GUI, multimedia capabilities and preemptive multitasking while maintaining responsiveness down to single digit DMIPs CPU performance at this small footprint. It has a large software library for this standard system. Try running embedded Linux at this low of spec and see what you get. The Amiga is still fun with this low of spec where most Amiga games run. Scaling up provides a more comfortable Amiga system but other OSs start to become more competitive.

Hans Quote:

The advantage of avoiding custom hardware, is leveraging the work of thousands of engineers rather than having to finance it all yourself. Of course, this assumes that you actually do use available source-code (e.g., Linux driver source code) rather than trying to do it all yourself. This isn't about just the initial work to get the system running, but also ongoing maintenance and future work. You get to cooperate with talented companies that have much larger markets supporting their R&D. Apart from reducing the cost, it opens up opportunities that simply wouldn't be economically feasible. And, if you're still worried about competing because you're on the same platform, you can always take an open-source ARM motherboard design, create your own custom variant, slap an Amiga logo on it, and target just that.

Just open source the AmigaOS and get rid of all the Amiga businesses then. AROS and AxRuntime are the new AmigaOS replacements. What applies to leveraging easy and open hardware also applies to leveraging easy and open software.

Hans Quote:

The question is, what do people want? A retro machine for nostalgia? FPGA implementations are more than good enough for that. A "noveau retro" machine with modern functionality? Both x64/ARM and your ASIC could provide, although the ASIC route is more expensive. Or, are people's heart set on creating "the modern Amiga they think would exist if Commodore hadn't gone bust?" In that case, an ASIC would be the only option. Well, maybe. IIRC, Dave Haynie is on record as saying that they would have switched to PCI (because they like standards), and he would have gone x86 instead of PowerPC when 68K started lagging behind.

CBM was researching many options to replace the Amiga because they had not invested in upgrading the technology. Many times they went back to more conservative incremental upgrades of the Amiga rather than more radical upgrades that broke compatibility with the 68k Amiga standard. The Amiga certainly could have switched to PCI and/or used a Hombre 3D gfx card for the Amiga but they were planning the next incremental chipset AA+ upgrade which integrated the chipset from 3 to 2 chips and were looking into licensing the 68k for a single chip 68k Amiga SoC. Compatibility has only been shown to be more important over the years. Just look at x86(-64) CPUs and hardware. I believe the more compatible and conservative approach of incremental improvements and integration was the right approach. The 68k Amiga standard and Amiga community were too valuable to abandon and CBM should have prioritized upgrading and integrating it. Looking at it today, the 68k Amiga had fewer limitations and better standardization than the x86 hardware path had back then. Not maintaining good enough Amiga compatibility with PPC Amiga like hardware and x86-64 AROS has resulted in disappointing adoption. Today, maintaining 68k compatibility has only become easier and cheaper while its importance remains.

ASiegel Quote:

Perhaps more importantly, Intel did not see a future in (32-bit) x86 and developed Itanium as its 64-bit replacement.

With x86, it is easy to think that an ISA that ugly, with such poor orthogonality and with so much baggage from its ancestry and partial compatibility that goes all the way back to the 1972 8 bit Intel 8008 would have poor performance. The problem is that RISC CPUs, despite all the propaganda and hype, have low performance traits. They are simple, easy to develop and use fewer resources until trying to make them high performance. Intel had RISC architectures yet decided to replace x86 with the Itanium which is VLIW. VLIW looks good on paper with good performance traits and exceptional peak performance but there are too many branches in general purpose code to maintain peak performance. Humble little CISC CPUs ended up outperforming VLIW CPUs for general purpose code which really isn't that surprising despite the huge Intel investment in the Itanium. It's not that x86(-64) is even a good example of CISC but it survived due to compatibility and performance, lacking a better CISC competitor when the 68k was retired for PPC which was then killed by x86(-64).

ASiegel Quote:

Also, ARM had zero market share at the time. Nobody could have foreseen what it would eventually become.

ARM had Zero market share? What year are we talking about? Amiga Technologies announced they would port the AmigaOS to PPC in 1995, ESCOM went bankrupt in 1996 and Phase5 released PPC boards in 1997. Let's look at the market in 1995.

1995 32 and 64 bit units shipped
1) x86 ~70 million
2) 68k ~50 million
3) SuperH ~14 million
4) i960 ~6 million
5) MIPS ~5 million
6) PPC ~4 million

http://www.ee.unlv.edu/~meiyang/ecg700/readings/micro-today.pdf

ARM is definitely not at zero market share although it is difficult to see which line is for ARM on the bottom of the chart (figure 1) but PPC is pretty low too. The article mentions Digital's StrongARM and there is a diagram of a ARM7 CPU. ARM licensed SuperH from Hitachi around 1992 and released Thumb in the ARM7TDMI in 1994 which allowed them to have code density to compete with the 68k and SuperH. ARM was already aggressively licensing its ARM processors as the above article states.

Quote:

In this world of core-based ASICs, some microprocessor cores are becoming near commodities. Advanced RISC Machines (ARM) in the UK has licensed its core designs widely, and many companies offer ARM cores as part of their ASIC libraries. Mips has also licensed its cores widely, though not as widely as ARM, and Sparc cores have a few licensees.

Why didn't ARM give up when they had less than 3% of the market. Of course, why didn't PPC give up when they had less than 3% of the market? At least ARM made the move to license Thumb to have the code density for embedded use to compete with the 68k with about 33% of the market and SuperH with about 9% of the market. The article makes it clear who was the embedded champion.

Quote:

Motorola is the champion of embedded processor proliferations, with uncounted 68000 variations. Now it has even modified the base instruction set architecture to produce the RISC-like ColdFire subset.

The 68k was far from dead when Amiga Technologies decided to switch to PPC. The 68k was selling ~50 million units vs PPC selling ~4 million units. Why would you switch from the 2nd most popular ISA to the 6th most popular? Motorola signed the AIM alliance in 1991 which made the PPC their high performance architecture. That is where most of their development dollars went and they were pushing it on customers. Motorola moved from the best code density 68k architecture to the fat PPC architecture while ARM moved from its fat original ARM architecture to an improved code density Thumb architecture, derived from the 68k but inferior in code density. Let's see how that worked out.

1999 32-bit Microcontroller Sales in units
1) ARM 151 million
2) Motorola 68k 94 million
3) MIPS 57 million
4) Hitachi SuperH 33 million
5) x86 29 million
6) PowerPC 10 million

https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.29.1298&rep=rep1&type=pdf

The 68k is still in 2nd place despite all the investment in fat PPC but has lost market share to ARM which is now the embedded market champion. The 68k has better code density and performance than Thumb but Motorola was developing and pushing fat PPC even for embedded use. ARM was working on higher performance and improved ARM cores while the 68k receiving minimal development and was limited in performance so as not to compete with the "high performance" PPC. The 68k was still the 2nd most popular architecture and PPC the 6th but by the late '90s the high performance 8 stage pipeline perpetually 50MHz 68060, even with a die shrink, was only losing competitiveness. I remember going to the Gateway Amiga Show where the Motorola promoters came in and were telling us that PPC was the future and that the dual CPU accelerators were just a bridge to full PPC use. What do you do when Motorola anti-markets their much more popular 68k CPUs and pushes their less popular fat PPCs?

ASiegel Quote:

68K-derived ColdFire CPUs scaled well beyond the performance of the 68060.

ColdFire is a different architecture than the 68k architecture despite the similarities. Despite the higher clock speeds of later ColdFire CPUs, there was no mass produced commodity ColdFire CPU which surpassed the 68060 in performance/MHz.

V4 ColdFire 1.54 DMIPS/MHz
68060 1.56 DMIPS/MHz
V5 ColdFire 1.83 DMIPS/MHz

Only a few large customers were able to license the V5 ColdFire before it was withdrawn from the market. The V5 ColdFire is essentially the same superscalar design as the 68060 but it has some more modern features like a 32kiB I+D L1, a 4 entry return/link stack and a tweak to branch prediction. I believe ColdFire sacrificed performance/MHz for a smaller core by castrating the 68060 considering the process advantage. It really wasn't necessary to castrate the 68k as far as ColdFire did and drop 68k compatibility. The CPU32 68300 family was much more 68k compatible and popular in the embedded market but Motorola wanted to see how far they could scale down the 68k with the ColdFire. The bonus was that the ColdFire was further from competing with PPC which could never scale anywhere near that low.

ASiegel Quote:

As long as they run perfectly well via emulation, why would anybody possibly care what CPU retro games would run on?

Emulation increases latency and jitter. A high enough performance CPU running the emulator with no OS or a real time OS may be able to come close with 100 times the resources, clock speed and power usage of real hardware. There is a reason why FPGA hardware offers a better retro gaming experience but it is better at simulating chipsets than CPUs.

ASiegel Quote:

As for modern games, outstanding performance is a crucial reason why AMD64 is to the go-to-choice for high-end game consoles. (Apple Silicon is quite competitive but obviously not available to third-parties.)

CISC is the high performance choice. AArch64 has closed the gap with "AMD64" by using some CISC like features. AMD64 still has some CISC advantages that AArch64 doesn't but it has also lost some of them with all the baggage, especially code density. It's bad CISC vs bad RISC. Which has more good CISC features to win the performance battle?

@matthey

Quote:

matthey wrote: Emulation increases latency and jitter. A high enough performance CPU running the emulator with no OS or a real time OS may be able to come close with 100 times the resources, clock speed and power usage of real hardware. There is a reason why FPGA hardware offers a better retro gaming experience but it is better at simulating chipsets than CPUs.

Sure emulation may use 100x the resources of the actual HW, but given that you'd be running on HW with 30 years worth of node shrinks you end up with a 5W/5$ chip already being overkill.

FPGAs are always a few nodes behind and they also need to use x times the resources to emulate a specific HW.


Quote:

CISC is the high performance choice

CISC/RISC was terminology that made sense in the 90s, not so much today. AMD is used in consoles because the are:
- available
- available in high numbers
- offer good enough CPU and GPU in 1 package
- are the same architecture as PCs (making developing multiplatform games easier)

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

@SHADES

Quote:

SHADES wrote: @matthey Quote: matthey wrote: [quote]RISC-V RV64C is variable length but it doesn't use variable length data in the code to improves code density and reduces the number of instructions with minimal additional encoding overhead. There is more to an ISA than just code densities, it depends on what you aim to do and general based CISC ISA always make compromises. [...] Exactly. There are already decent ISA RISC SoC platforms available that could take over in a cheap, cost-effective way, without trying to re-develop/modernise from an old CISC 68K standard, without trying to get Mitch and a team together to decide on yet another ISA extension, just for code densities a little better than what is already available, maybe slightly easier, yet to be even tooled, chip.

You underestimate the importance of code density when talking about computer architectures.

There should be a reason why almost all architectures present solutions, ISA extensions, or even proper ISA only devoted to have very good code density. Or do you think that such companies like to waste millions just for a tantrum? Why there are so many studies in the architectures literature explicitly targeting the code density? Why so many talks in conferences?

The reason is simple: we're talking of BILLION dollars markets.

So, yes, there's more to an ISA than code density, but this is a KEY feature for an architecture which nobody in this field would ignore.
Quote:

ARM big-endian support is already there, with a hell of a lot of stuff already. It works, is proven, has decent density already and it's cheap!

And you're wrong here. ARM has a decent code density but only compared to architectures which have NO variable-length instructions. I'm referring to AArch64 AKA ARM64 which Michal is using on PiStorm for its Emu68.

And there's NO chance for ARM to introduce something like Thumb/-2, because it used the entire opcode space for AArch64. So, it will stay with fixed, 32-bit opcodes.

The only thing which ARM could do in future is to create a brand NEW 64-bit ISA, only devoted to address code density.
This architecture will NOT have the same advantage of Thumb/-2, which was able to use exactly the same ARM (ARMv4..v7) instructions but just without using the predication; which was a great advantage of Thumb-2 (since ARM developers were used to the canonical instructions of that t ISA). It means that it'll a completely new ISA, as said.
So, ARM could end-up to have 4 ISA (ARM, Thumb-2, AArch64, Thumb64 = just a fantasy name about it) which requires quadruple the effort to support all of them both for compilers and developers.

You should be able to see yourself the advantage of having a single base ISA (or a few ISAs anyway) which provides all the above benefits.

@agami

Quote:

agami wrote: As I have mentioned before, the intricate business plan and architecture I have put together for the development and production of a 3rd commercial consumer computing platform does not even specify a CPU architecture.

Seriously? I think that you better have to make a deep clarification about your project, because it looks really too fuzzy in its current state.
Quote:

A phase of the project would evaluate and determine which hardware design would be best suited, and given the current state of the industry would most likely select x86-64 or ARM for the initial iterations. Which means that RISC-V would be evaluated, and were the plan to find adequate funding, I'd have the team look into 68k resurrection. I'm convinced and a lot of the data supports the notion that the 68k was abandoned too hastily. That alone merits a second look at 68k and the viability of renewed market positioning. Plus, it would make for an amazing story.

So, in short, you don't evaluate new architectures, but you're only looking at existing ISAs (which might be improved over the time. IF the project succeeds).

Correct?

@thread

I think people vastly overestimate the desire for a commercial "third platform". Firstly there are more than two already. I know people happily using Chromebooks for all their computing needs. I know people who profess to hate windows but wouldn't countenance using anything else on pain of death because it's a pain they are used to. I know people that use macs that pretend they aren't acolytes to the cult, yet if Tim Cooke announced bottled iWater tomorrow they'd bathe in the stuff.

You could try to make the Amiga relevant again and if you plan to, that's fine. I'm 99.9% sure it would just be a money burning party.

_________________
Doing stupid things for fun...

@Hans

Quote:

Hans wrote: @matthey Quote: Did WinUAE PPC emulation support really help the NG AmigaOS 4 market though? Does emulating PPC provide a better NG experience than real NG hardware or is it more of a marketing tool to encourage people to try AmigaOS 4 first while selling a few more copies of the OS in the process? AmigaOS 4 on WinUAE is horribly slow and vastly inferior to real hardware. I think it's partially due to the emulated graphics cards being old and not supporting compositing, but the PPC emulation is probably also slower than real hardware. Anything Warp3D Nova related won't work either. The same goes for QEMU based NG emulation. It can't match real hardware at all. Not even close.

The only problem stays on those emulators, which aren't good enough for that purpose.

PowerPC emulation could be made very fast.

Apple already shown it with the first version of Rosetta, where the new Intel MacBooks were running at around 50% (and sometimes much more) the performance of the previous G5-based ones.

A recent example is with RPCS3, the PS3 emulator, which runs at 78FPS on a PC with AlderLake 12900K way better than the original: https://twitter.com/rpcs3/status/1461369839491026948
On the PS3 the 3 in-order PowerPC cores are running at 3.2Ghz. One of such core has performance roughly equivalent to a 1.6Ghz G5 (which is a massive out-of-order PowerPC monster).

Anyway, writing a brand new PowerPC emulator for OS4 is a challenge, which I don't think is worth the effort due to the limited audience.

There's one thing that MIGHT be done to improve the situation on WinUAE: writing a "native" driver like uaegfx &wazp3d but for OS4/AmigaOne. This could enable composition and, in general, getting way better graphic performances. Nova might work as well.

Another thing is improving QEMU's JIT. But that's much more difficult.

Last but not really least, a "virtualizer" based on an equivalent of Emu68 would be the best solution, since you don't have to emulate the entire machine (included the graphic card) but you provide a very high-level emulation (so, just fake OS4 enough to make it boot) which maximizes the performance on both CPU and graphic side.
But, as I've said, it's a big challenge.

@Karlos

Quote:

think people vastly overestimate the desire for a commercial "third platform

Well it really depends on how big you want the platform to be, i agree that its unlikly without billions of pound and even then no guarantee that we could ever compete with apple, windows, and google.

But the pi again proves that you can be a hobbist system and have success. I think even now the amiga is doing alright i would just like the market size to say double or tripple to what it currently is and i really think thats possible with better directions

_________________
AmigaNG, YouTube, LeaveReality Studio

OS4 on WinUAE is indeed poor compared to real hardware, even the lowest end. Floating point performance in particular is extremely poor (I think the 603/604 uses some software FPU emulation due to compatibility issues but I may be mistaken). Certainly my i7 can't match (or even come close to) my 603e in real tests. I don't think that's the reason for the slowness however. I'm also not convinced it's the lack of compositing support either because I don't have that enabled on my BlizzPPC/BVision either and it's still much more responsive in general use.

This is not a criticism of UAE. The technical accomplishment of integrating PPC support into it at all, particularly something as opaque as the classic PPC boards is something to appreciate. It is possible that it may improve in the future but for now it's more of an interesting curiosity. I also don't think it matters much because most sources for PPC Amiga systems should both still exist and be in more portable languages in the first place.

I can understand there will be people heavily invested (their money, time, effort, patience, emotion) in PPC that won't want to leave it behind, but you can't move forwards - in any way whatsoever, even as a hobbyist interest - on a platform that is that niche, expensive and behind. You need to adopt commodity hardware and you x64 and/or ARM for that.

The dots are all there already, they just need joining up. A 68K legacy, extremely mature 68K emulation, an active and enthusiastic 68K scene and a corpus of software for PPC that should be relatively straightforward to backport.

_________________
Doing stupid things for fun...

@cdimauro

What really need is PowerPC virtualized for AmigaOS4.1.

PowerPC to PowerPC JIT compiler, that allow people run Linux PPC on top of AmigaOS4.1 and MacOS 8,9 and MacOS X (PPC) in Basilisk and QEMU.

The task of hack, should be to allow virtualizing Memory on top of AmigaOS, the majority of instruction can skipped only some instructions that uses reserved registers, or something that might interfere with hos OS, need to be emulated.

Maybe a mask can be used to identify potential candidates, that needs to be replaced. In the final JIT cache.

Now bring a lot interesting software and games, and useful for cross compiling.

Last edited by NutsAboutAmiga on 25-Sep-2022 at 01:22 PM.
Last edited by NutsAboutAmiga on 25-Sep-2022 at 01:20 PM.
Last edited by NutsAboutAmiga on 25-Sep-2022 at 01:18 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro What really need is PowerPC virtualized for AmigaOS4.1. PowerPC to PowerPC JIT compiler,

So what is it?


Not that it would make any sense or solve any issues....

Other way round (run OS4/MorphOS hosted under LinuxPPC or MacOS) would make some sense, but still not enough to waste any resources on it.

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

@Kronos

Not really, you can already do that, with QEMU, Kernel VM. (KVM) (not the Keyboard VIdeo Mouse switch)

I know some emulators allow you assign PCIe slot to the emulator, now that might help a lot. If any emulator that support AmigaOS offered that.

Most emulation options sucks compared to the real thing, VM’s are cool video is often slow.

Last edited by NutsAboutAmiga on 25-Sep-2022 at 02:15 PM.
Last edited by NutsAboutAmiga on 25-Sep-2022 at 02:13 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Just no. PPC today has zero, repeat absolutely and emphatically zero benefits to any of us today. Whether it's OS4 or MorphOS, PowerPC is a pair of concrete boots (that cost their equivalent mass in pure gold) you're wearing to a beach party everyone else left hours ago. The tide is already up to your neck and still you cling to the monstrously absurd notion that these boots are somehow useful or even necessary.

There's likely a sum total of *slaps calculator* ... zero maintained software for NG PPC that couldn't be ported to another platform. Difficulty would vary depending on how dependent that code is on PPC particulars but as long as it's not completely assembler, it can be ported.

It doesn't matter how good or bad the decisions to move to PPC were in the past, it has no bearing on how utterly futile it is to stick with it today.

_________________
Doing stupid things for fun...

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Kronos Not really, you can already do that, with QEMU, Kernel VM. (

Well QEMU is not a virtualization it is a full emulation ( at least when used in the way it is used to run OS4 and MorphOS on non PPC HW).

Real virtualization would be much closer to stuff like ShapeShifter or MacOnLinux, not that they would count as virtualization but as in running code for "hosted" that was compiled for the same ISA as the host system without emulating a CPU.

Passing through a GFX-card is another issue where current QEMU based solution emulate a full a card on the host CPU (slow) where it really should be a OS4/MorphOS driver connecting function for function to the APIs in the host system.

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

@matthey

Quote:

matthey wrote: Emulation increases latency and jitter.

Not really true, but I don't want to repeat myself here.
Quote:

A high enough performance CPU running the emulator with no OS or a real time OS may be able to come close with 100 times the resources, clock speed and power usage of real hardware.

100 times is too much. 10x is more realistic. I'm talking generically here: it might require more resource or less resources.

And, BTW, it also depends on the emulated system, the accuracy that you want to get.

A bare-metal emulator with no o.s. could control the raster / display exactly like the emulated system, so with zero jitter / latency, and using limited resources.

So, a rasterline-based emulator is possible, but the problem here is that it requires to reinvent the wheel, since it has no o.s. APIs usable to access and control the hardware. This requires an effort much bigger than writing the emulator itself, which makes it non-practical. But it's just to underline that it's definitely possible, at a low cost (from a used resources / power perspective. And money, of course).

Maybe a collection of libraries or, much better, a "bare-metal o.s." could be written that can be used for emulators as well as for realizing embedded or real-time projects which need total control of the hardware (in a predictable manner, at least). But I don't know if something like that already exists.

As an alternative, AROS could be used and/or adapted for this scope, since at least it has some drivers, libraries, filesystems, etc. that are immediately usable. AFAIR it lacks APIs for "following/controlling the raster" on a per-line basis, but I think that it could be added. Since AROS already supports SMP (somehow) you can also think of "taking ownership" of some processor's cores where the emulator (or the embedded / real-time projects) could run, leaving the other cores to serve the system.

This is just an idea that it came me when I've seen that MiSTer was running a Linux instance for controlling the emulated system (through super-imposed GUI controls) which requires around 600MB of RAM. AROS could be a perfect fit for this while using a fraction of the resources.


@Kronos

Quote:

Kronos wrote: @matthey Quote: matthey wrote: CISC is the high performance choice CISC/RISC was terminology that made sense in the 90s, not so much today.

It IS still relevant today.

@Karlos

Quote:

Karlos wrote: OS4 on WinUAE is indeed poor compared to real hardware, even the lowest end. Floating point performance in particular is extremely poor (I think the 603/604 uses some software FPU emulation due to compatibility issues but I may be mistaken). Certainly my i7 can't match (or even come close to) my 603e in real tests. I don't think that's the reason for the slowness however. I'm also not convinced it's the lack of compositing support either because I don't have that enabled on my BlizzPPC/BVision either and it's still much more responsive in general use. This is not a criticism of UAE. The technical accomplishment of integrating PPC support into it at all, particularly something as opaque as the classic PPC boards is something to appreciate.

Indeed. (Win)UAE serves well its purpose and it's more than good enough for that.

PowerPC / OS4 support was "just" a big bonus added to a wonderful product (UAE).
Quote:

A 68K legacy, extremely mature 68K emulation,

And more could be still made...

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro What really need is PowerPC virtualized for AmigaOS4.1. PowerPC to PowerPC JIT compiler, that allow people run Linux PPC on top of AmigaOS4.1 and MacOS 8,9 and MacOS X (PPC) in Basilisk and QEMU. The task of hack, should be to allow virtualizing Memory on top of AmigaOS, the majority of instruction can skipped only some instructions that uses reserved registers, or something that might interfere with hos OS, need to be emulated. Maybe a mask can be used to identify potential candidates, that needs to be replaced. In the final JIT cache. Now bring a lot interesting software and games, and useful for cross compiling.

Again PowerPC? It's DEAD!

You need a better PowerPC to Any-OTHER-alive-and-kicking-architecture JIT (and virtualizer, which is better)!


@Kronos

Quote:

Kronos wrote: @NutsAboutAmiga Quote: NutsAboutAmiga wrote: @Kronos Not really, you can already do that, with QEMU, Kernel VM. ( Well QEMU is not a virtualization it is a full emulation ( at least when used in the way it is used to run OS4 and MorphOS on non PPC HW). Real virtualization would be much closer to stuff like ShapeShifter or MacOnLinux, not that they would count as virtualization but as in running code for "hosted" that was compiled for the same ISA as the host system without emulating a CPU. Passing through a GFX-card is another issue where current QEMU based solution emulate a full a card on the host CPU (slow) where it really should be a OS4/MorphOS driver connecting function for function to the APIs in the host system.

This!

@Karlos

Quote:

Karlos wrote: @thread I think people vastly overestimate the desire for a commercial "third platform". Firstly there are more than two already. I know people happily using Chromebooks for all their computing needs. I know people who profess to hate windows but wouldn't countenance using anything else on pain of death because it's a pain they are used to. I know people that use macs that pretend they aren't acolytes to the cult, yet if Tim Cooke announced bottled iWater tomorrow they'd bathe in the stuff.

Are you accusing me of only performing cursory analytics of the commercial consumer computing market?

I have no doubt that there are many people who's estimates on the subject of potential demand for a 3rd consumer computing platform are based on intuition, anecdotes, and perhaps a sprinkling of an availability heuristic from skimming certain tech news forums, and have therefore constructed in their mind the idea that it is a veritable "gold mine" of an opportunity.

I can assure you that I am not one of those. The business plan cites many sources of data supporting the marketability of such a platform, and "desire" for such is only one metric.

Furthermore, Google's Chromebook does not qualify as a commercial computing platform, much as iPhone+iOS and iPad+iPadOS are not. Whilst Google and its OEM partners sell hardware running Chrome OS, they are not marketing it as a general computing platform for the consumer (personal and business), but more narrowly focused on internet/web based applications and workflows. A hardware extension of their overall cloud-based strategy.

Across personal, home business, small and small-to-medium business applications, there are essentially two commercial consumer computing platforms, namely Microsoft's Windows ecosystem and Apple's macOS ecosystem. While there are entities in the Linux world that sell Linux-focused hardware System76, Pine64, Tuxedo, etc. it does not make Linux as an ecosystem, a commercial consumer computing platform.


Quote:

You could try to make the Amiga relevant again and if you plan to, that's fine. I'm 99.9% sure it would just be a money burning party.

The aim is not make "the Amiga" relevant again. The aim is to offer an alternative to the users of Windows and macOS who are not adequately served by those platforms.

The Amiga is relevant in this endeavor as far as it occupied this space in the early '90s with a 5% global market share, and insights therein can be leveraged to influence the next potential 3rd commercial computing platform.

There's also more than a handful of workflow paradigms which were fostered/emerged on the Amiga platform that have not found their modern implementation counterparts, which from a contemporary UX aspect could form part of the set of differentiators of the 3rd platform.

Are their those who bemoan their computing lot, but are unwilling to part with the devil they know? Absolutely. Are their those that even dipped their toes in the proverbial waters of the alternative platform, only to quickly retreat to the messy comfort of their computing hovel? You bet.
These are not representative of the target audience.

But there are about 0.1% of the global addressable market for commercial consumer computing platforms, across personal, home business, small and small-to-medium business applications, who are dissatisfied with their current platform, and have tried to improve their situation with the other platform and have not made the switch due to a net increase in challenges. While estimates vary, we can be conservative and round-down to 2 billion. This number excludes people who only use a smartphone/tablet/Chromebook, and it excludes servers.

0.1% of 2 billion is 2 million. 50% of these (1 million) represent the low-hanging fruit. The platform would need to grow to above 20 million users through serving niches, and creating additional platform switching opportunities. At 1% market share, accompanied by moderate but reasonable yearly growth numbers, the platform would be considered sustainable and viable.

Last edited by agami on 26-Sep-2022 at 05:48 AM.

_________________
All the way, with 68k

@agami

I'm not accusing you of anything. I'm commenting on what seems to be self evident.

Quote:

But there are about 0.1% of the global addressable market for commercial consumer computing platforms, across personal, home business, small and small-to-medium business applications, who are dissatisfied with their current platform, and have tried to improve their situation with the other platform and have not made the switch due to a net increase in challenges

So Joe Average on Mac or Windows can't swap over to the alternative due to it being more difficult. If he can't find what he needs using free alternatives like Linux or by switching to something like ChromeOS I'm all ears as to how switching to anything resembling AmigaOS will help with it's total lack of familiar application software and general immaturity as an operating system (lack of SMP, security etc.)

_________________
Doing stupid things for fun...