@agami

Quote:

agami wrote: @purists My A4000 has a ZZ9000 for RTG + Ethernet. The hardware solution uses 2 x ARM Cortex A9 cores. Does that make my A4000 unclean? Who is left out there that can bless and make kosher the non-PPC hardware for the Amiga platforms. Does Sensei Dave Haynie wield such power?

I believe you are addressing a crowd of strawmen, not even ppcamiga falls under your "purist" here, what he opposes is really just "emulation" as a "platfom target". Using ARM processors for I/O on Amiga systems isn't exactly a novelty.

Quote:

Also while I got you: If I’ve written things in PHP, Python, Node.js, or Wasm on Linux (x86-64), how much time would it take me to learn the PPC versions of PHP, Python, NodeJS, or Wasm?

No time at all. Good luck with 68k ports of all those, though.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

There's no point in targeting native unless you intend to go the AROS route and have all native applications too.

Tell me, what is it your Operating System userland does, that is so computer bound that you need native binaries for every damn thing? Last time I looked, snapshotting icons and changing your wallpaper just wasn't that big a deal. Native passthrough for datatpes and codecs may make sense especially if they can leverage the native vector extensions but the rest of the time everything is sitting there waiting for something to happen.

Hell, I ran 68K cnet.device on OS4 for my A1200 and OS4 was fine with it. The bottleneck was entirely hardware.

A native HAL. Some support for native code in compute/data intensive operations. That's all that needs to be native. I get that some people may have some insufferable OCD and want everything native, but that fails to appreciate that under JIT, the application *is* native at the point of execution, so what's the problem?

_________________
Doing stupid things for fun...

@Karlos

Quote:

Absolute nonsense and your lack of imagination with this statement is a great indicator of the problem.

"Lack of imagination" or just "not living in la la land".

I can imagine a lot of things. Like there already been an AROS fork designed for "virtual 68k".
I can also imagine pretty much no interesting SW to be released for it and what little does get released been lacking compared to MorphOS or even OS4.

-> you are beating a horse that had been shot years ago.


As for not using the full extend of HW, you are suggesting on top of throwing away extra cores, memory and features to also throttle that last core to 50% (at best) performance......

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

@Kronos

Where do you get 50% at best from? A quality mature JIT should generally be running at around 80% of native speed for equivalently complied code (e.g. not depending on features like vectorisation in the native build that the JIT isn't able to use due to the guest ISA), single thread/core. Unless you're telling me trance is lousy and that's where your benchmark comes from.

You are absolutely living in la la land if you think that sticking to hand-me-down PPC hardware that's almost old enough to vote, is a sensible choice for *anything whatsoever* in 2023. An even worse choice is going for ludicrously expensive boutique PPC hardware, it's the same insanity for those with just as little sense but more money.

You all need to get it through the bone and into the grey stuff. PPC is dead has been dead since around 2006 and is not ever going to make any sort of miraculous comeback. It is used in niche applications and the only real userbase it had all ran to x64 overnight without looking back once. It's that ... beige.

It's not cool enough to enjoy retro status, it's a pain in the arse to emulate properly on commodity hardware and doesn't have any software that couldn't be ported to almost anything else - including 68K - anyway.

Last edited by Karlos on 22-Oct-2023 at 05:15 PM.

_________________
Doing stupid things for fun...

@Karlos

With everything JIT there is a massive difference between what you might get in a benchmark and what is real life.

I never really benchmarked Trance (why should I) but I do remember what my AthlonXP Amithlon box could do, and there 50% was an extremely best case cherry picked result.

But as for who is living in la la land
Quote:

Karlos wrote: is a sensible choice for *anything whatsoever* in 2023.

-> Win,Linux, macOS, choose your poison

Everything else is impractical with 0% chance of ever being sensible and you a bad mouthing existing dumb choices in order to promote a slightly different bad (worse) choice.

UAE surpassed any real 68k some 25 years ago and a few later it always had an performance edge over what ever PPC was available for NG, but yet there is little to no 68k SW that requires >060@50Hz or >100MB RAM.

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

Things would have been so much simpler if Motorola had delivered the 68000 for sale at the beginning of 1980 instead of at the end of the year.

@Karlos

Quote:

Karlos wrote: @kolla There's no point in targeting native unless you intend to go the AROS route and have all native applications too.

Yes? Wasn’t that what you guys suggest for 68k as well? Port all the lovely OS4 goodness, including somewhat “modern” (heh) web browsers to 68k? Because Emu68 for sure can handle all the OS4 nonsense superwell?

Quote:

Tell me, what is it your Operating System userland does, that is so computer bound that you need native binaries for every damn thing?

I don’t need native binaries, but also don’t need all the nonsense that comes with OS4.

Quote:

Hell, I ran 68K cnet.device on OS4 for my A1200 and OS4 was fine with it. The bottleneck was entirely hardware.

And I have 68k USB stack (Poseidon) under OS4 because Os4 USB stack is shite and barely capable of handling anything correctly. And I have USB ethernet device, which drops offline once a wee bit of traffic happens because of ancient bugs in Roadshow that were fixed soon a decade ago on Roadshow/68k _still_ are there on latest OS4 because Hyperion are masters of organizing, so Olsen keeps missing their once in a cyan moon “get ready for release” windows. And hardware that works with DMA on OS3 needing PIO on OS4… and I haven’t even touched all the nonsense that isn’t bugs, but plain silly “design decisions”. I’m no huge fan of MorphOS, but what it offers is miles ahead of OS4.

Quote:

A native HAL.

That’s part of Emu68.

Quote:

Some support for native code in compute/data intensive operations.

And Emu68 is not going there, so why bother bringing it up again and again?

Quote:

That's all that needs to be native. I get that some people may have some insufferable OCD and want everything native, but that fails to appreciate that under JIT, the application *is* native at the point of execution, so what's the problem?

The problem, if it wasn’t obvious is OS4 itself, I cannot grasp why anyone would want OS4 on 68k, even something as fast as Emu68, when even natively on much faster PowerPC systems, it’s a big bloated mess.

Luckily, the chances of OS4 being ported to anything, be it ARM or 68k, is close to none. FFS they struggle to even “port” OS4 to other PPC hardware produced by their own partners! The chance of OS3.2+ stuff being ported and incorporated into OS4 is probably much higher, as that’s where actual coding and so called improvements take place.

Last edited by kolla on 22-Oct-2023 at 06:30 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Kronos

Quote:

but yet there is little to no 68k SW that requires >060@50Hz or >100MB RAM.

That would change when you throw the OS4 monster and its “portfolio” on it.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

You hate OS4, we totally get it, why keep bringing it up? Nobody is asking you to run it on anything at all, let alone on 68K of any form, physical or virtual. There's no need to be a heckler.

Strange as it may seem, not everyone feels the same way. Agami has already stated some objective benefits of OS4, whether you agree is immaterial really since you are not the target audience.

If anything they are an even tougher crowd

_________________
Doing stupid things for fun...

@kolla

I think there something to what you’re saying.

there some stick too them attitude, in AmigaOS4.x for sure. The development team don’t agree if they want support classic stuff, or if should forget about it.

they removed BCPL, low level stuff, it probably broke few programs, and games.
but over all it does make much difference. you can’t get free chip memory from Execbase, you need to call AvailMem(), so they dropped support for software written for Kickstart 1.2. AvailMem function does not exist in Kickstart 1.2, if want support it all you need to do some version checking.

timer.device runs on different EEClock frequency, then what you might expect.

OpenScreen prefers RTG instead of planar, when no Mode ID is set,
that one breaks a lot of 68K software. They also do not include support dbpal and dbntsc, productivity modes. Some stuff there refuse to open, or crash when there is only one RTG plan.

Oh yes peeking in 0 page, will give random values you did not expect. There is stuff like Interrupt vectors stuff in 0 page, sure its not supported, but perhaps it can have been done a little differently.

This are main issues I know of.
Most of issues with 68K programs, is bad init code, bad exit code, making assumptions about screens, and often depending on none system friendly cooper screens, when it was not necessary. there is lot software simply crash if you did not install the fonts.

Last edited by NutsAboutAmiga on 22-Oct-2023 at 07:20 PM.
Last edited by NutsAboutAmiga on 22-Oct-2023 at 07:11 PM.

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

@Karlos

Great points on PPC hardware, etc.

I will say first that anyone is obvious to use whatever OS they want and get the enjoyment with it...

I tried to make OS4 work for me, but at the end of the day it is severely hampered by largely being ignored or dedicating small resources to more pie in the sky stuff that I would assign to just fixing it up. Kolla does have valid points on that. Again it doesn't take away any enjoyment and fun one has.

MorphOS is many many miles ahead to be fair. The OS is very mature and bullet proof and made to adopt modern conveniences taken for granted on other platforms (ie multimonitor or smb). We just saw the browser updated again with decent milestones over 6.2 that was release a month ago. The email is getting calendar integration with invites (a first in Amiga land) and already support vcards. PolyOrga is incredibly good at what it does. All these examples show an active OS community with 30 point releases. The OS and apps are very polished and you can deploy the OS in 5 minutes with a great experience and move on.

Would I like them to release a new platform for MorphOS sure, but on a fast Mac it runs extremely well.

Great (and very funny) remark about the unicorn turb :) and that is the other problem to me. The cost of entry is big especially when the OS is so very stale at this point. The stakeholders would be much better served using MorphOS that is readily available and would heal the wounds from the 90's and just invest in that. We all can disagree, but having something so well development with a real appset is something users can enjoy and get the benefits from.

I really don't see hardware being the issue for OS4, the issue is OS4. MorphOS is at/getting to a done level so if they make a switch they all ready have something.

OS4 can do things and be enjoyed yes, and that is good and fine but the reality is that OS4 is dead with many I know leaving the platform. I just don't see them turning that around at this point. I'm certainly not in the know, but just watching the videos at amiwest, no one attended and AOS4 showed very poorly with what they showed and discussed.

@Matt3k

MorphOS does not support NallePuh, the 680x0 support less integrated with rest of the OS, there different design decisions made, and different priorities. People will use what they like.

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

@Kronos

Quote:

Kronos wrote: @Karlos With everything JIT there is a massive difference between what you might get in a benchmark and what is real life.

Yes, I usually find real software performs better than benchmarks suggest rather than the contrary. For example, a number of synthetic benchmarks of petunia on my 603e did not suggest it would be able to run DoomAtrack at 4x the resolution at a better frame rate than my 040 (which was already playable enough). Yet it did. The only slow part was the screen wipe because reading back from VRam on the BVision is just as slow as ever and now I'm doing 4x more of it.

Quote:

UAE surpassed any real 68k some 25 years ago and a few later it always had an performance edge over what ever PPC was available for NG, but yet there is little to no 68k SW that requires >060@50Hz or >100MB RAM.

Yes, they've all been wasting time writing it for PPC instead :p

_________________
Doing stupid things for fun...

@NutsAboutAmiga

Sure, fully agree as I said above people should use what they like.

Sure they went different directions. MorphOS used MUI, Turboprint, cybergraphics, and Poseidon where AOS4 went with reaction and native printing, ANAIIS, and roadshow. One could argue what path was better back and forth.

But at the end of the day a fresh install of both operating systems and doing tasks most would want to do on a computer (email, browsing, networking, other general use) really illustrates the differences. Certainly free to choose, but the differences exist none the less.

@Matt3k

In case it's not abundantly clear, I think OS4 and MOS are both great hobbyist platforms, but I think sticking to PPC doesn't do anyone any favours. I appreciate that compatible Mac hardware is relatively inexpensive and generally well made, but it's not going to last forever.

Anything written that requires the full native scalar performance of a G4 and even G5 is eventually going to be usurped by the equivalent performance of 68K code in UAE or even some future Pi. This is absolutely inevitable at some point, since only one side or that equation is actually moving. And while you could emulate PPC on said hardware, it's not as mature and not as performant. Like it or not, 68K emulation is both simpler and has had a significant head start.

I mean years ago, I had that epiphany with an A1 G4 800MHz versus Amithlon on an Athlon. Code I'd written that was compute bound on the G4, recompiled for 68K ran significantly faster on Amithlon than the PPC version did on the G4. And while the A1XE was hardly a poster boy for PPC performance, this was many years ago. Those G4 and G5 haven't changed, but x64 and ARM sure have. And will continue to do so.

Last edited by Karlos on 22-Oct-2023 at 09:01 PM.
Last edited by Karlos on 22-Oct-2023 at 08:54 PM.
Last edited by Karlos on 22-Oct-2023 at 08:53 PM.

_________________
Doing stupid things for fun...

@Karlos

Assuming an ISO shift for both AOS4 and MorphOS say to either ARM or X86, both platforms would have to be transformed to do it. You gave a great example and we have the videos of MorphOS running on X86, both have potential. But if they both land, AOS doesn't have any of the tools as MorphOS and the already high level of OS and App offering and sophistication.

So in the end we would have the same thing on a new platform.

Free to use what you want, but the difference won't go away with a shift of both.

@Matt3k

Say you shift for Arm, you could do it just as you did up till now, fall back on 68k software when needed, on x86 I would be harder to do it like that.

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

@pixie

ARM is very much a tantalising target since Emu68 and PiStorm. I'm sure there's a minority within this minority that don't care about legacy/68K or Amiga hardware. It's an odd thought but I'm sure some do genuinely feel that PPC NG is actually something legitimately worth having for its own sake. It's a hobby platform so I don't disagree. Whatever floats your boat is fine.

Contrary to how it may sound, I don't even dislike PPC. I was an early adopter and it was a lot of fun for a while, but it was ultimately another dead end.

For power users, I still think 68K on x64 has the biggest gains but for me personally, the fastest 68K ARM can JIT shoved up the expansion slot of an A1200 is about as good as it gets. Real Amiga hardware, unreal 68K accelerator performance, with RTG.

_________________
Doing stupid things for fun...

pixie Quote:

Say you shift for Arm, you could do it just as you did up till now, fall back on 68k software when needed, on x86 I would be harder to do it like that.

I'm not so sure.

https://arstechnica.com/gadgets/2022/06/arm-announces-the-cortex-x3-cpu-headed-for-2023-android-phones/ Quote:

Arm's new chips completely drop 32-bit support, which might cause problems. ... Arm is promising the X3 CPU will 25 percent performance improvement over the X2, while the Cortex A715 is claiming a "20 percent energy efficiency gain and 5 percent performance uplift" compared to the current-gen Cortex A710. Arm claims the A715 is as fast as the Cortex X1 CPU from 2020. The A715 also drops 32-bit support, making it the last part of our theoretical flagship SoC to go 64-bit only. The smaller A510 CPU is returning, but Arm says it is "an updated version" with a 5 percent power reduction. ... There are already rumors that Qualcomm won't use Arm's suggested SoC design layout for its 2023 chip, the Snapdragon 8 Gen 2 SoC. The rumor claims Qualcomm's layout would be one Cortex X3, two Cortex A720s, two A710 CPUs from the current generation, and three A510 CPUs. The justification for this would be that Qualcomm doesn't want to drop 32-bit support entirely yet for the Chinese market, and dragging two A710 CPUs from 2022 into next year would keep the 32-bit train going.

The Cortex-A715 is already a generation old as the Cortex-A720 was launched in 2023. This is the popular Cortex-A line that the newer RPi models use. AArch64 is little endian only with a few endian conversion instructions to convert big endian data but ARM 32 bit endian support was much better allowing memory to become big endian and normal load/store instructions to be used which are more powerful and versatile. AArch64 has some support for 32 bit integer datatypes but how well it can support a 32 bit AmigaOS I can't say.

In theory, PPC code shouldn't be much more difficult to emulate than 68k code but emulating the PPC MMU is likely difficult. How much difference is there between MMU emulation turned on and off in WinUAE for 68040 or 68060 emulation?

@Karlos

Quote:

Karlos wrote (edited): Real Amiga hardware, unreal 68K performance

That should be the official marketing tag for the PiStorm32.

_________________
All the way, with 68k