Why not use the second core for chipset emulation?

It feels to me that sometimes Amiga community thinking is limited by assumptions that were true in 1995 but may not be true now.

Case in point - in 1995 it was assumed that no next gen Amiga could be backwards compatible because of the dependency on custom chips, their designs, their availability (or lack of), their cost.

And it was assumed that a next gen OS would require features being seen in other operating systems, such as SMP, where any thread can run on any core without race conditions and so on causing problems.

But here in 2024 these assumptions are no longer correct. Even in 2010 they were no longer correct. Arguably even in 1999 they were no longer correct.

For the former, we now have both software (UAE) and hardware (FPGA) emulation options for the custom chips.

For the latter, well, just look at the PS3. That made use of the different cores a deliberate choice - one for the host OS, one for audio handling, others for gameplay and graphics to be used by the game developers as they saw fit. It wasn't like on Windows with 'any thread on any core'.

By the way what is an extra core? It's an additional CPU that has direct memory access same as the first CPU does, effectively. Is that really much different from the original Amiga architecture which had several different chips all accessing memory directly to do processing, it's just that they weren't all general purpose CPUs, they had specific jobs.

Which brings me to the idea I posed in the title. On the PowerPC machines that have an extra core that isn't used, could it be feasible to use that core to run a chipset emulator? If it's never preempted, it should be easier to keep timing, albeit it has to emulate several different chips, but none of them run at clock speeds close to the core's real clock speed.

How would it work? It would need some dedicated memory virtualized to match the chipset memory addresses. This memory would then be mapped to say, a surface on the graphics card that could be attached to a screen or window. Likewise the audio could be mixed with the wider system audio. It would still need applications to be earmarked as 'run this in a sandbox that uses the chip emulator'.

Anyway the point of my post is, rather than work on SMB support for OS4, when there are few chips with multiple cores, and the architecture itself is a dead end, why not use the second core just as a co-processor, same as the original WarpOS which just sent critical sections of code to the PowerPC as if it was some kind of super fast FPU.

We all have gazilion ideas, but to not be them cheap amigaworld.net's talk, you should develop them yorself or find developer on payment basis for. Everything possible, lots of good things can be done, ideas of all sort arise all the time in past: problem is actual coding and developers. Without them its all void which take your time for nothing. But if point to have simple talks without hope for real outcome, then yeah. Just its all crystal clear: ideas is no problem. No developers with time and motivation and/or payment are.

@NinjaCyborg

Quote:

nope, etch core has its own independent L1-cahce, this independent L1-cahce must be synchronize with the other cores L1-cahce. This is why this is not as simple as adding Mutex, and some spinlocks.

Quote:

yes, it is… old 680x0 does not have L1-cahce, and different chips do not have cache, this make old architecture a lot easier to work with.

The cache is only necessary if you are doing SMP. If you use other cores as dedicated co processors it's not relevant. You should know that, since you know everything else.

@NinjaCyborg

As far as I know High-End PCs work with extra CPUs and RAM on seperate cards, f.e. graphic cards that have several gigabyte RAM and its own CPU. That is of course possible but also costly. I read modern games use such aqdditional CPUs for calculations.

And as already mentioned somebody has to it, that means develop it or pay someone for it and then produce the cards.

Additionally you propably also need drivers for OS. Again you have to do it yourself or pay someone for it- And then you sell 10 cards... so if you do not have lots of money you can throw out of the window it is difficult to do

I'd be happy just to use the 2nd core period.

It's simpler using the XMOS integrated in the x1000 and x5000 models. And if your AmigaOne is not having the XMOS, you can use a USB model too.

The modern GPUs have a Blitter and Sprite controllers, it's more advanced than the old Amigas

@NinjaCyborg

The custom did also share bus cycles with CPU in Amiga chipset.

Before getting into the emulation itself, there's the first obstacle to move out the way, managing the other core. Ideally this would be managed by the OS itself. So for this case OS4 needs to technically support multi-core. However, itself and apps would still run on single core, but it would still need to manage two cores running and possibly isolate memory for other core.

To be practical only OS friendly apps can be supported. Because otherwise a 68k game or program could just take down the host system. That's another obstacle. Even without any chipset emulation most software that hits the hardware or even use it to open a screen will want to freeze the system until it's finished

UAE could be used on other core. Since audio can be simulated but graphics is harder and combining with CPU in one dedicated program like UAE can be better. But then UAE would need to run in parallel somehow while not interfering with the other core single running OS4.

Just my thoughts.

All this talk of using “the other core”. I’d like to be able to use my other three 😂

@NinjaCyborg

Quote:

AmigaOS4.x does have fixed address for CHIP memory, it’s not address space you expect infect the same address space as FAST.

Its also not as much of problem as you might think.
the chipset hardware registers typical has lower and upper register.

Reading the comments I can see people are still assuming an SMP approach to use the second core. My point is that, you don't.

@NinjaCyborg
Why do you want to use 2000-3000€ PPC Hardware (X1000, X5000, A1222) for emulating 30-35 Years old, system unfriendly (aka utterly broken) Amiga games, instead of using a 50-100€ Raspberry Pi, A500Mini or A600GS, or a 20-60€ software emulator (Amiga Forever, or 0€ for WinUAE/FS-UAE with stolen AmigaOS Kickstart/Workbench images) for that?

@joerg
Now using FPGAs and no longer using ‘emulation’ - ‘Raspberry Pi for 50-100 €, A500Mini or A600GS’.

e.g.: https://retroremake.co/products/mister ... ming-fpga-board-mega-pack

@smarkusg has anyone done the work do you know, to let the pi emulate the 68k and the mister to emulate the custom hardware? I do appreciate, despite the many comments pointing out the obvious, and despite my question obviously being a 'what if', that there is dearth of money and willing and able developers to make such a thing a reality.

@NinjaCyborg

most obvious is Pimiga

https://retrogamecoders.com/pimiga/

@smarkusg

If UAE was able to run on different CPU CORE, using RAM as frame buffer,
the keyboard IO, will need to somehow get to the other CORE, the network will need to get to other CORE (grated it’s not work now.) and you need to be able to copy memory from the CORE into a window. there must be some interaction between CORE1 and CORE2.

Some kind of framework will need to exist between the cores to interact, somehow I have the feeling, that’s not easy without the OS knowing about it.

@LiveForIt

This is probably the answer to @NinjaCyborg


@NinjaCyborg
FPGA if looking for something cool is probably the best solution. As for ‘MiSTer’
You have it all very well documented:

https://github.com/MiSTer-devel/Minimig-AGA_MiSTer/tree/MiSTer

as for me all solutions what @joerg (A600GS, A500mini, PI) gave are weaker than FPGA and you have to remember that you can always "insert a new cpu" and play on another machine

At this point in time, why would anyone in their right mind care about using an additional core on an OS4 system to emulate the custom chipset of a classic Amiga when OS4 itself doesn't even support SMP? If you want that, then use UAE or one of it's variants on an operating system that actually supports SMP and memory protection. OS4 will never support SMP. There isn't a large enough user base to even justify the investment to rewrite the kernel to make it SMP capable. And even if there were, rewriting OS4 to take advantage of SMP would break backward compatibility and cost a fortune. I'd wager there are less than 1000 users worldwide who actually use OS4 as their daily driver. For most, it's just a curiosity or a pastime for nostalgia seekers because it's so ancient in terms of what modern users want and expect from a PC. Use a PC, an Orange Pi 5, an A500 Mini, or an R Pi to emulate the classics. It's a hell of a lot cheaper and you'll have a much better user experience all the way around. OS4 at this point is nothing but layer after layer of Frankenstein hacks just to get it to even run on ever more rare and expensive CPUs that were EOL'd over 15 years ago. Same goes for the GPU.

@ferrels

Quote:
That's rather harsh, and also wrong. The OS4 code base is far higher quality than "layer after layer of Frankenstein hacks." A quick search shows that the P50x0 CPUs were EOL'd in 2020, and Radeon RX Polaris series GPUs are not yet considered EOL (link).

I do agree that there's no point in emulating the custom chipset using one of the as-yet unused cores.

Hans

@hotrod

Not sure what you're getting at. AFAICT, NinjaCyborg is genuinely interested in the question he has posed.

I'd personally rather have SMP than classic chipset emulation on a separate core (don't use anything that needs it), but it's a perfectly reasonable question.

Hans