@michalsc

szulc stop trolling start working on mui on aros

@Karlos

emulator is emulator nothing more
stop trolling and start working on mui on aros

@Karlos

so we again are going to endless aw loop

1. switch from that bad ppc

2. leave ppc as it is

provide sometning fast native up to date on x86/arm

3. some dumb scumbags here instead of starting working on x86/arm made goto 1

pixie Quote:

That's on point. As long the system feel snappy, you cannot get much more snappy than snappiness itself. We need more users so that software actually starts to take advantage of all that cpu power. For me as long as the system connect to hardware level in the gfx system and all that it needs to feel snappy, a transparent way to access all 68k library feels much more important to me.

Snappy enough for emulation is a minimal advantage. A virtual Amiga is snappy/quick but low performance and does not have memory protection? Not having full memory protection may be ok if snappy, fast for the hardware, uses a tiny footprint, has instant startup/bootup and is cheap enough but this does not describe a virtual 68k Amiga or even a PPC AmigaNOne.

@matthey

I would assume you could have the core system running natively and a transparent way to run all 68k software. What is stopping a raspberry like system to have a fast startup/boot up*? I am far from talking about a PC or a PPC for that matter, but I don't see all that need for speed as you do with the current pool of Amiga software. I don't know if raspberry has a slow boot up but I know that EMU68 doesn't run through Linux, that it runs straight on metal. I guess it would be feasible to have such a tight system built with drivers it already has for Amiga ported over for an Amiga like OS on the same hardware, perhaps most could even be kept on 68k side... It would be interesting to have either that or a Draco like system on a Raspberry 5 standalone... What sense does it make to buy a PPC nowadays when even Raspberry Pi has much better Linux support.

* https://youtu.be/M8JPFpz80mY
It seems it can boot in 6seconds

Last edited by pixie on 19-Dec-2024 at 08:14 PM.
Last edited by pixie on 19-Dec-2024 at 08:03 PM.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@ppcamiga1

Quote:

szulc stop trolling start working on mui on aros

It seems Scalos run just fine on AROS. You don't understand the relevance? It's just a desktop replacement which happens to use MUI as its Core.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

pixie Quote:

I would assume you could have the core system running natively and a transparent way to run all 68k software. What is stopping a raspberry like system to have a fast startup/boot up*? I am far from talking about a PC or a PPC for that matter, but I don't see all that need for speed as you do with the current pool of Amiga software. I don't know if raspberry has a slow boot up but I know that EMU68 doesn't run through Linux, that it runs straight on metal. I guess it would be feasible to have such a tight system built with drivers it already has for Amiga ported over for an Amiga like OS on the same hardware, perhaps most could even be kept on 68k side... It would be interesting to have either that or a Draco like system on a Raspberry 5 standalone... What sense does it make to buy a PPC nowadays when even Raspberry Pi has much better Linux support. * https://youtu.be/M8JPFpz80mY It seems it can boot in 6seconds

Why is such a fast SBC so slow to boot? I guess you haven't seen an Amiga 1200 boot from a PCMCIA drive?

https://kgsvr.net/andrew/amiga/amiga.diffnt.html#efficient Quote:

AmigaOS is Efficient From: Shireman, Steve I have run control software on the Amiga booting off of a battery-backed SRAM PCMCIA card without a hard drive or floppy using only 4K of the PCMCIA card to boot. Think of the PCMCIA card as replacing the hard drive in a desktop system. The only RAM overhead was about 54K, and with this I have the full color model and mouse control, and fully preemptive multitasking and of the 2 Meg of RAM that comes with the A1200, The Amiga OS has only needed less than 1 / 10,000 of the RAM available. And I know it is using a few of the OO Objects in the Kickstart, but not very many.

An Amiga 1200 and PCMCIA hardware are far from high performance. Actually, today you just put a little more code in your ROM/flash including LoadWB and then a 68k Amiga can boot practically instantly as far as human perception. Only the settings need to be loaded from the drive or memory that is retained on warm boot to determine the window size to open. Booting text could be placed over the drive that is booting while faster drives like ram drives could already be available and usable (requires some bootup and LoadWB logic recoding). A cold start may take a few seconds as hardware units are usually not activated all at once to reduce startup power but warm restarts could potentially be a second or less. Small applications like a clock, calender and calculator could be added to a recoverable memory drive (like RAD) or into the ROM/flash for usability while booting the primary boot drive. It would be a useful feature for embedded hardware as well as a time saver for humans.

@ppcamiga1

My darling, I don’t care what you want, remember? :)

@ppcamiga1

You can be sure that whatever you demand I do, is of no interest to me. Nobody wants to take your PPC away, least of all me.

I just want to move away from specific hardware dependency in general. Look, according to you, a PPC with a generic PCI bus and graphics card is "an Amiga". So you already accept the premise that the hardware is irrelevant since that combination has literally none of the original DNA.

So there's no reason - literally no reason at all - to get upset over a different hardware substrate.

The fact that you do, is because you are visibly unwell mentally. We can't help you with that, you need to speak to an appropriate clinician.

_________________
Doing stupid things for fun...

@matthey

Quote:

The newer ARM Cortex-A510 is higher performance than the Cortex-A55 but power efficiency is more important for a small E-core where the Cortex-A55 is a better design. https://www.reddit.com/r/Android/comments/ro7boy/golden_reviewer_a510_in_s8g1_has_33_worse/

Quote:

The Smartphone CPU Review You NEED to Watch! https://www.youtube.com/watch?v=s0ukXDnWlTY A 3 year older smartphone is outperforming the newer smartphone with newer ARM core designs and better fab processes which should not happen.

To get the cores to work properly they must have good caches, memory subsystems, interconnect etc. If any of these are weak then then the performance of the CPU will be degraded.

To draw conclusions about the CPU cores alone, you must test the CPU cores alone.

Spec and Geekbench are not CPU tests, they are system tests. Any claims about the CPU cores alone are therefore invalid.

They also ignore how CPUs actually operate in phones. The higher performance cores are less efficient yes, but they're only used in short bursts. It's mostly the little cores that are active.

_________________
Whyzzat?

@Karlos

Quote:

Abstract the CPU and enjoy the post physical Amiga universe.

Why stop at the CPU?

I like the AROS AxRuntime idea, it essentially abstracts the kernel away as well, you get an Amiga-like API but in return you get Memory protection, SMP, and potentially 64 bit as well ...and you don't need to write drivers.

You could make anything an Amiga.

_________________
Whyzzat?

@matthey

Quote:

Why is such a fast SBC so slow to boot? I guess you haven't seen an Amiga 1200 boot from a PCMCIA drive?

My guess is that it hasn't to do with processor, rather with the board. But I am under the impression also that an Amiga like OS should be able to boot in far less than 6s

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@matthey

Quote:

I guess you haven't seen an Amiga 1200 boot from a PCMCIA drive?

I have, an A1200 needs more time to figure out what to boot from than what RPi5 needs to boot to full online desktop.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Karlos

Quote:

The hubris is in thinking that you have to be native when most applications are IO bound most of the time and then fretting about the fact that your preferred CPU metal has gone / is going obsolete.

I don't see any hubris in preferring native compiled code. I never liked the "Java" approach.

Hans

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@terminills

Quote:

terminills wrote: @ppcamiga1 ... if it was up to me I would make sure stuff like the updated Final Writer never runs on PowerPC just out of spite because you act like a tool. Oh wait, it is up to me. 🤣

_________________
All the way, with 68k

@Hans

Quote:

Hans wrote: @Karlos I don't see any hubris in preferring native compiled code. I never liked the "Java" approach.

I too, and no doubt most people, would prefer native; But in the absence of native ARM apps/games I will take the Java VM approach any day.

The AmiBench system does also provide some native ARM libraries/datatypes. Any developer can add ARM native systems and subsystems which should in most cases be transparent to the rest of the hypervised 68k binaries.

_________________
All the way, with 68k

@OneTimer1

I know it would not mean that Hyperion/Aeon moves away from PPC, they are two different things. But right now it looks like that OS4 development is stalled, if not worse. So moving the classic line to ARM is not at all a bad move.
There is a rather long way to go, but this is a good start..

_________________

@agami

Quote:

But in the absence of native ARM apps/games I will take the Java VM approach any day.

Absolutely. Ironically, a usable Java VM never was completed for AmigaOS, despite multiple (independent) attempts).

Hans

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@Karlos

UAE is a kind of 68k VM today, very highly optimized. And it is possible to speed up and optimize further. For example there is a dll on winuae you can integrate that makes 3D faster. Very good for using existing 68k software including old and new games.

But there are limits on 68k hardware and OS level that are difficult to overcome without new native versions like 32bit or no memory protection what affects stability and security. I like the simplicity and extensibility of the OS, it is in sharp contrast to modern operating systems and makes it fun to use, but no option to use it for daily work like online banking. So to me there are two seperate branches, the retro market and the real world. Most current options including what is called NG by some are more or less retro because missing critical features.

AROS might overcome this in future with AxRuntime and a port of a amiga desktop (propably Scalos).

But most of this is OS related, we should come away from what hardware platform currently is ahead, it is risky to bind a platform on one specific hardware. Better to have something portable, of course you still need specific drivers. A real Java like VM would be a option too but as long API everywhere is the same and sofware is written in a portable language like C it should not be necessary.

Most users today do not even know what hardware they use, most of them do not care anyway. They buy a device for a certain use case for a certain price. They expect it to do what is promised. If it uses ARM or X86/X64 hardware or something else they do not know and do not care. Often administration is done with hardware independent web pages. The hardware discussions here are very retro in my view, even if talk is about modern processors.

More important would be what are the use cases for amiga tomorrow, except retro of course

Last edited by OlafS25 on 20-Dec-2024 at 10:56 AM.
Last edited by OlafS25 on 20-Dec-2024 at 10:47 AM.

@Hans

I didn't say there was hubris in preferring it. I said the hubris is in thinking you *need* native code, thereby marrying yourself to a given hardware platform. Tying ourselves to particular CPU hardware has worked out so well, wouldn't you say? Why didn't we just lock down everything else as well? Only one choice of graphics accelerator, one sound, one NIC.

Firstly, we don't have the resources of Apple when it comes to migrating the platform. We do not have a codebase that is portable enough - by which I mean free of pointer size and endian concerns

Secondly, Java is not the example here. Emu68, Petunia, Trance and UAE are.

Java is bad because the language is bad, the runtime is bad, and the software is overly abstract and heavyweight. However the VM is not bad. Today, that VM is very mature and able to perform runtime optimisations that can't be evaluated at compile time. I have examples of simple imperative Java code outperforming statically compiled C for the same tasks on the same hardware, simply because it can be tuned at runtime. But as I said, Java is neither the example nor the proposition. Our "bytecode" should run directly on any suitable 68K hardware. It's 68K object code.


Finally, on a JIT platform everything is native anyway. Unless you use a hybrid/hotspot, you aren't interpreting (and they do have their advantages too).

Don't think of it as emulation. Think of it as final mile compilation.

Last edited by Karlos on 20-Dec-2024 at 11:21 AM.
Last edited by Karlos on 20-Dec-2024 at 10:53 AM.

_________________
Doing stupid things for fun...