@agami

Quote:

At $5 a pop, it wouldn't even make its money back. At $10, maybe it makes its money back. To be considered "back in business", it would at the very least need to sell 500k units annually for about 5 years. At $5 - $10 per unit, the only way to make the kind of profit that can be used for the v2 and v3 products, is through quantity.

I think you and @matthey are both forgetting that right now the A500 mini is selling at £100 or more with a board not much more capable than a Pi Zero 2, so it shows with the right package / eye candy / marketing around it you can do quite a bit of up-marketing on the system.

then add that if you had the internet on this device with a App store, that could maybe generate a small amount of income, suddenly the amount you got to sell and the size of the market to be self sustainable is a lot smaller.

_________________
AmigaNG, YouTube, LeaveReality Studio

@kolla

I use the term Amithlon model to differentiate from Amithlon proper. There's little chance that the real Umilator will be resurrected. The L Box I'm describing would have to be based on a more modern kernel, something capable of being updated from upstream fixes. FWIW, you can't blame Amithlon for being stuck to an old kernel when it was released 20+ years ago and hasn't been worked on since.

In my head, L Box would use Linux native drivers for graphics, audio, networking, USB, storage, etc. A simple abstraction layer for each one would then be exposed to the 68K box in much the same manner as UAE exposes RTG etc. You'd include stub RTG/AHI/SANA/SCSI drivers for the 68K box that talk directly to these abstractions. There would be no need for "sketchy quality" 68K drivers for key functionality. However, like Amithlon, the ability to map physical PCI devices into the memory map of the 68K box is nice to have for more obscure devices, or obsolete PCI hardware someone may already own that already have existing 68K drivers that they prefer to use.

If all you want is a fully emulated system then I agree, there's no need to step away from UAE. Having used both Amithlon and UAE, I can't overstate the difference in user experience. Your regular PC or Mac running UAE is great for quick a quick session, especially if you want some retrogaming nostalgia or have other stuff to do. But the moment you pause it, or it loses focus and you see the native mouse pointer, or you see some notification from your host OS, the whole illusion is lost. With a machine dedicated to the one job of providing your Amiga user experience, that it boots into, if you want to quickly do something else, you're either going to do it in session or have to pull out your mobile phone or use another machine. It has one job; it's not just another task to switch between for every other distraction that comes up. Having experienced both, for me the latter is much more satisfying and immersive. You also find yourself using more and more Amiga software for things because you can't just switch tasks to whatever other application you'd normally use on your host machine/OS for. And what you don't have Amiga software for, you're more inclined to consider developing for yourself, which for me has always been a big part of the whole experience. You become a producer and not just a consumer.

Ultimately I would like for the L Box to also provide native chipset emulation, especially if it can be implemented in a manner that allows the more intensive aspects of that to run on one of the other CPU cores, but for me at least that's not an immediate requirement because most of the software I want to run is system / RTG friendly.

Last edited by Karlos on 01-May-2022 at 11:17 PM.
Last edited by Karlos on 01-May-2022 at 11:09 AM.

_________________
Doing stupid things for fun...

agami Quote:

To be considered "back in business", it would at the very least need to sell 500k units annually for about 5 years. At $5 - $10 per unit, the only way to make the kind of profit that can be used for the v2 and v3 products, is through quantity.

My point about the RPi Pico and SoC price was to show just how important price is, at least to the Raspberry Pi Foundation. You appear to have marketing knowledge to understand how important price can be for the success of a product but others do not. I'm not saying a 68k SoC would need to be within $1 of their price or anything like that. The RPi SoC is competing with other cheap ARM SoCs where a 68k SoC could likely have a significant price premium. It still needs to be close enough in price and offer value in other ways which I believe it could. The RPi Zero actually offers better value than the RPi Pico for many potential customers. Still there were enough customers that needed lower power and a smaller sized embedded device. The embedded and hobbyist market is huge as shown by RPi products but a 68k SoC could appeal to a healthy retro 68k market as well. Starting small in area and relatively simple with a 68k SoC reduces capital requirements and increases chip yields. This is likely why the RPi Foundation started small and it will be interesting to see if they make larger customized SoCs to replace their off the shelf SoCs.

amigang Quote:

I think you and @matthey are both forgetting that right now the A500 mini is selling at £100 or more with a board not much more capable than a Pi Zero 2, so it shows with the right package / eye candy / marketing around it you can do quite a bit of up-marketing on the system. then add that if you had the internet on this device with a App store, that could maybe generate a small amount of income, suddenly the amount you got to sell and the size of the market to be self sustainable is a lot smaller.

As I stated above, a well designed 68k SoC should command a price premium, at least for 68k use. We have talked about an online Amiga store with games before. Prepared and pretested online games could extend the concept of THEA500 Mini hassle free game play and generate extra income. Accessories could be sold with units also. It has been common for the computer unit to be sold at near cost while accessories, games and services have much higher profit margins. Actually, this marketing goes all the way back to the first personal computer, where the CBM PET accessories were big money makers. Chuck Peddle talks about it in his Oral History interview.

Oral History of Chuck Peddle (4 hours long)
https://www.youtube.com/watch?v=enHF9lMseP8

He talks about the importance of price many times too. It was his recognition of the importance of the CPU price which revolutionized the personal computer market with the 6502. There were plenty of people who didn't listen including the management at Motorola.

@amigang

most people today buy just devices for a certain purpose. People do not care about OS or hardware, just that it does what they expect and price

@Karlos

you want Amithlon with chipset emulation? I guess then you end in UAE

Last edited by OlafS25 on 01-May-2022 at 01:39 PM.

@OlafS25

Quote:

@Karlos you want Amithlon with chipset emulation? I guess then you end in UAE

Not in its current incarnation, no. I would much rather have it as described, a box based solution, as close to the metal as is sensible, able to leverage multiple cores to to ensure the 68K box isn't spitting it's CPU time with chipset emulation. And in the final analysis if that's not possible, I'd sacrifice the chipset emulation in order to keep everything else since I can always port UAE to run in the 68K box for a RunInUAE type approach.

_________________
Doing stupid things for fun...

@Karlos

Quote:

There's that misconception again. Emulated. Once you're in JIT territory, it's a misnomer, really. Unless it's a hybrid model that only recompiles hot code paths and interprets the rest, there's no emulation per se. It's all native. It doesn't matter that much about endianness or register counts. FWIW I don't believe that Petunia does fixed register mapping (I could be wrong). This is something you might do in an interpreter model but JIT just look at your binary as another higher level code to be compiled and it will do it's own register allocation as it sees fit.

It takes memory to do. And code blocks must be interpreted. Also it can't be avoided as when you do memory operations it needs to emulate that operation by checking the address or program the MMU to do itin hardware. As well as convert endians. It's not as clean as simply runnng native code.

Quote:

I mentioned Amithlon rather than AROS because of how it works. The model promised by Umilator was brilliant. I've nothing against AROS at all, but as a continuation of the Amiga experience, Amithlon (aside from getting it working in the first place) was peerless. Unless you stopped to remind yourself it was running on an x86/64 there was just nothing to remind you. Want to put in a new disk? Put an actual disk in and set it up with HDToolBox. Same with expansion cards. Other than the otherworldly speed of execution, it just felt exactly like using the real thing. Completely different than UAE. No alien user interface popping up because you hit F12 by accident.

Where as Amithlon looked like AmigaOS x86 and people wanted it to be sold as OS4 instead ( ironic since the first OS4 Amiga announced was an x86 OS) AROS is exactly like AmigaOS x86. The closest we have. It doesn't have to emulate anything. Since it can't emulate 68K, and that's likely the biggest showstopper, the next best thing is Amithlon support. That is running Amithlon x86 binaries on a fully native OS. No need to for an AmigaOS emulator. Of course AROS lacks the 68K support Amithlon has.

I expected by now someone would have redone the Amithlon idea. I mean one guy did it years ago. Why can't a team do it again now? I hear that they would be sued but it seems ridiculous they would be sued over an idea. Are H&P even around? What Amiga software are they selling?

Quote:

From a UI perspective, face it. If there was a modern 68K emulation solution along the above lines, it could run a 68K backport of OS4 no problem.

That's pretty much OS3.2 which inherits code from OS4. But, I don't know if I would bother. Running a VM is okay but it annoys me to reboot into another OS. It's okay for testing but I like a dedicated machine running native code. Even if most 68K stuff I would run isn't on a native 68K.

I don't quite know why 68K is easier and faster to emulate then PPC now. 68K is complicated with extended codes that all need interpreting. By comparison PPC is simple for most instructions. You've got 16 bit code and 16 bit data. Just like 68K has 16 bit codes. The rest are 32 bit but can still be found from a 16 bit code. I expected AmigaOne emulation years ago because there are no custom chips like in the Amiga. But no practical solutions appeared. All we have are experiemental QEMU builds you need to compile yourself that are faulty in some way.

Last edited by Hypex on 01-May-2022 at 07:48 PM.

@agami

Quote:

To go back to your original gripe of Apple branding it as "Apple Silicon", you should have no qualms. ARM is an architecture and does not produce ARM-based silicon.

One that Apple did not invent.

Quote:

Now, if you're going to say that only fabs can use the moniker of "silicon" on their products, and the fabless should abstain, then there is a whole slew of labels all of us in contemporary society accept that would need to be re-evaluated because they don't fit your if-this-then-that literal interpretation of the world.

Logic such as: If girlfriend = false then gay = true? A lot of that logic is common.

Quote:

Also, you refer to things in such binary terms. There are many shades of grey between black and white, and most things in life fall under the Theseus' Ship paradox.

Yes the computers are digital.

These days it's become Theseus' car. Or just the car now.

Quote:

The fact of today is that neither Nvidia, nor AMD, nor Intel, nor Qualcomm, nor ARM, are designing CPUs. Just like the team at Apple, the teams at these other companies are evolving "customising" the designs of previous engineers, who for the most part did the same.

There hasn't beem much point designing CPUs since the IBM PC chose x86 or it's close ancestor. The ARM got lucky late in life. Since it did start out as a desktop CPU.

Quote:

Here's another of Theseus' Ships. How many intel engineers have to leave intel and join the likes of Apple or AMD before whatever the contingent remaining at intel can be beat? Johny Srouji is formerly of intel. If Apple's engineering team has greater than 50% former intel engineers, is their team effectively an intel engineering team? Are people born as intel engineers, or are they also plucked from competing firms?

Obviously they work under a directive they are employed for. But what's the Ship got to do with it? My point is CPUs have come and gone and no one has beat Intel. Even AMD produces the same ISA so there is no real competiton. So who is going to come along and beat Intel and their engineers with a new CPU design to take over the computer world?

Not even Intel could beat it when they brought out Itanium. Knowing that x86 was becoming archaic. AMD came out with AMD64 and totally stuffed them up.

Quote:

Incorrect. They were not a licensee of x86 and were therefore not designing their own "customised" versions. They had even less influence with intel than they did with Motorola and IBM as part of AIM.

They shouldn't need too. The hard work was done for them. They didn't even need to design computers anymore. Just contract the work out. And keep it fabulless.

Quote:

All large companies grow through acquisition. It's a key vector for gaining new IP and growing the talent pool. So when a company such as Apple acquires P.A. Semi, it is not considered "stealing" when they implement something that team of engineers developed.

I see it as no coincidence they targetted a PowerPC company. Apple even caused delays for the X1000. When they wouldn't let a shipment of CPUs out. And that must have been almost five years after they dropped the G5. The PA6T should have been 3 Ghz by then.

@Hypex

The inefficiency you speak of there affects only the most compute bound code and only the branchiest, least predictable compute bound code at that. And even then, it usually only impacts the first trace through a code block to be translated. Some pathological raytracing example would be perhaps the only example that springs to mind. It's the sort of code compilers avoid producing most of the time, because it turns out that it's terrible for native performance too.

As for the memory overhead for translation cache it's memory allocated from the emulation host, which is plentiful and not stolen from within the emulation memory space.

Quote:

Where as Amithlon looked like AmigaOS x86 and people wanted it to be sold as OS4 instead

I can only disagree in the strongest possible terms to this. Configuring Amithlon was a pain and only got worse after it was left to wither on the vine. However, once working it in no way whatsoever presents itself as an x86 platform to the user. I can't imagine who would come up with such demonstrably nonsense argument than an architecture fanboy unable to cope with the idea that the x86 was able to evolve into something decent. It ran every system friendly 68K application I owned at the time and at a performance UAE on the same machine couldn't match. The only omission was the lack of custom chipset emulation. But it was no different in that regard to OS4, MorphOS or AROS at the time running on non-original hardware.

Only OS4 on the blizzardppc with BlizzPPC felt closer to the "real" Amiga experience in my view as it was able to run code depending on native chipset and it was of course running on the original machine. This was nice but the whole experience was somewhat underpowered from an OS4 ecosystem perspective given that all the cool things for OS4 were happening on G3 and G4 processors by then. Sure I got Quake 3 working on my A1200/Bvision when developing the Permedia2 driver for it, but you'd be insane to actually want to play it. It was slightly better on the CSPPC. Same with all the web browsers that were coming out at the time.

Switching from a sub optimal OS4 experience back to a good OS3 experience on that machine was always a reminder that there was no hope of a direct continuation. I had an A1XE and it was clearly s far better experience on that hardware. But you could console yourself with the fact it was based on 3.1 sources and was pretty compatible with system friendly back catalogue.

Amithlon was the same in that regard except for one thing. It was just much faster at everything. PPC native application code on my G4, except where carefully tuned for altivec often ran slower than equivalent 68K versions on the Amithlon system I had at the time. And as for the BlizzPPC, there was no contest at all. I'm a software engineer. I benchmark things carefully. I write my own tests. The crappy Duron 1200 was faster. The Athlon XP I briefly had it working on was much faster.

Since those days, the NG era has seemed more and more a misstep. If the most significant step was to avoid falling into obsolescence, moving to PPC was the wrong choice. The writing was on the wall even then, but it was generally easier and more palatable to most users. It wasn't a dead platform at the time, either so I don't blame anyone for taking it that way.

So, this is why decades later I advocate for a 68K future, albeit one based on JIT.

Quote:

I don't quite know why 68K is easier and faster to emulate then PPC now. 68K is complicated with extended codes that all need interpreting. By comparison PPC is simple for most instructions. You've got 16 bit code and 16 bit data. Just like 68K has 16 bit codes. The rest are 32 bit but can still be found from a 16 bit code.

You're confusing the complexity of interpreting binary code with recompiling it. Your code to interpret/JIT looks like something with a few very hot globals (the registers). An interpreter for 68K may be more complicated to implement than PPC (possibly), and pays the price of that complexity per instruction interpreted.

This is not true, or as true for JIT. The fewer registers and such are required for everything, the more a JIT is able to register allocate things and produce streamlined code for the host. PPC has at 64 registers to care about between the FPU and IU and it's triple operand register to register workflow is awkward to allocate into a smaller number of host registers than a single 68K one with a complex address operation. It's also not particularly RISC from a simplicity perspective. Some instructions are pretty damn complicated. And in the end, you do the complicated interpretation of a code block once, but repeatedly execute the result.

Then there's the PPC FPU. In principle, bring IEEE754 by design ought to make it simpler but it's also made more complicated to by other factors around interpretation of condition codes etc. It's generally easier and more compatible to emulate the FPU instructions in software. This is a big performance hit, even on JIT.

Also, PPC instructions are generally 32 bit wide btw, you need 15 bits just to encode a register triplet.

Last edited by Karlos on 01-May-2022 at 07:34 PM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

I think you are missing the point of my suggestion maybe. The point is not to simply reduce a modern PC to a turbocharged museum piece. The point to decouple AmigaOS from any specific hardware requirements and to provide a means for universal software distribution as 68K binaries that will still run on real 68K, FPGA, Emu68K, OS4, MOS and finally also on commodity PC hardware as close to the metal as is practical while retaining full binary compatibility.

I understood your suggestion. And having used OS4 you can understand the point of it as well. But I've heard similar arguments to what I shared so many times. And it's really just to demean OS4 and AmigaOne hardware. It doesn't need anyone's help in looking bad against modern computers, we know how it is. But it tends to come from ex Amiga people that think the PC is great since they converted to it. And by all accounts worship it the way they go on about how AmigaOne hardware is so bad and the PC is so great. It's just eye roling for me at this point.

Quote:

Since PPC is dead and more obsolete today than 68K was when it was first introduced, having the Amithlon/Umilator model provides a path out of total obsolescence for the ongoing development of AmigaOS, new applications for it and the emerging hardware 68K ecosystem around it.

Which is funny as the last PowerPC's are still faster than the last 68K. Ridiculous really. I wouldnt say totally dead as the Power 9 looks cool, but like anything not x86 based, quite expensive. But yes the "PC" variant of the Power has taken its couse. And for better or worse, there are people who bought a Power 9 machine, and then hang crap on an X5000 about how expensive and slow it is.

Quote:

The whole thing comes full circle. Perhaps the Amithlon style solution could evolve to better support JIT PPC code too and in the process allow PPC binaries to be supported later down the line, preserving access to software that won't get backported to 68K for whatever reason.

That would be interesting. Good for classic OS4 like in UAE. But I don't know about a full on transparent OS4 experience.

I've had my ideas as well but instead using PPC as a kind of byte code. Like I said else where it's simpler. I've imagined both an x86 and ARM solution that loads PPC as virtual CPU code, converts it to native at load time with simple translator that does 1:1 coversion as much as possible. Then jumps in. It's not exactly a JIT or PJIT as the whole code would be converted at once. So just like AmigaDE or Java.

@Hypex

Quote:

And it's really just to demean OS4 and AmigaOne hardware. It doesn't need anyone's help in looking bad against modern computers, we know how it is. But it tends to come from ex Amiga people that think the PC is great since they converted to it

I don't think you can make that claim with me. I was an early PPC adopter and despite not wanting to become partisan, worked on some driver components (mostly graphical) of OS4 and tested it as abeta tester too. I'm ex-amigan by circumstance only; three young kids means no time for such hobbies at the moment.

I'm not anti PPC. It was a fun ride and an interesting architecture to write code for (which I still do from time to time). But as a continuation of the Amiga, for me at least, it's over. For legacy applications, the basic G4 is definitely "fast enough", being at least a full order of magnitude faster at running those applications than a decent 040 was. Faster PPC hardware is still out there but it's also crossed that event horizon of no further development. Which leaves PPC parts intended for increasingly niche use cases that are correspondingly more expensive. It's just not a sustainable model. The same is true for MorphOS. The hardware may be more available, bur for how long? G5 systems in particular were not known for their long term reliability, even among the most ardent fans at the time.

Quote:

I've had my ideas as well but instead using PPC as a kind of byte code. Like I said else where it's simpler.

Simpler on paper. Simpler maybe to interpret than 68K. Difficult to interpret efficiently and harder still to JIT translate into effective code. You only have to look at existing emulations to see why. I spent a few weeks hacking away at QEMU source used in the UAE PPC JIT to see if I could fix the FPU performance without it being a buggy crashfest. I gave up after a while because it just wasn't worth the time investment and wasn't clear if it even could be appropriately fixed.

68K JIT emulation is much more mature and more pervasive with good quality implementations for x64, PPC and ARM.

Last edited by Karlos on 01-May-2022 at 09:37 PM.
Last edited by Karlos on 01-May-2022 at 08:14 PM.
Last edited by Karlos on 01-May-2022 at 07:52 PM.

_________________
Doing stupid things for fun...

@Karlos
The 68k is so efficient to emulate yet you created the MC64K ISA with a different endianess, added 8 more FPU registers converting them all to 64 bit and 8 bit encodings instead of only 16 bit encodings. The MC64K ISA is clearly targeting emulation yet you made these changes? If JIT performance is so good then why create this ISA? If the primary goal of the ISA is to add 64 bit support and JIT performance will be as good as you imply, then why not create a more compatible 68k 64 bit ISA that could be used efficiently in hardware too? What is the point of optimizing for emulation that performs different on different hardware and has more than enough performance for 35 year old software anyway?

@matthey

You're confusing a just for fun hobby project to explore what a 64 bit extension of 68k assembly language programming might be like with actual 68K emulation? Not quite sure how to respond to this.

MC64K isn't a 68000 emulation. It's not even an emulation. It's a bytecode interpreter that exists solely to allow code expressed in the aforementioned hypothetical 64-bit assembly language to be executed. That's all. It's like comparing apples and oranges.

MC64K's bytecode is designed to be trivially easy to write an interpreter for. It should also be relatively easy to write a JIT for, if I ever get that itch.

Last edited by Karlos on 01-May-2022 at 09:59 PM.

_________________
Doing stupid things for fun...

Karlos Quote:

You're confusing a just for fun hobby project to explore what a 64 bit extension of 68k assembly language programming might be like with actual 68K emulation? Not quite sure how to respond to this. MC64K isn't a 68000 emulation. It's not even an emulation. It's a bytecode interpreter that exists solely to allow code expressed in the aforementioned hypothetical 64-bit assembly language to be executed. That's all. It's like comparing apples and oranges. MC64K's bytecode is designed to be trivially easy to write an interpreter for. It should also be relatively easy to write a JIT for, if I ever get that itch.

Maybe MC64K is a research project if you say so but it is still clearly intended to improve emulator efficiency of 68k like code on little endian targets which should not be necessary with JIT according to some of your arguments above. Are you just trying to get rid of the resource overhead of JIT and move to a simpler 68k interpreter? If all x86-64 targets have adequate performance for emulation then shouldn't they have adequate resources for JIT too?

Last edited by matthey on 01-May-2022 at 10:42 PM.

@matthey

None of the above. I designed MC64K for fun, during some spare time over lockdown following some nostalgic conversations with a few close friends while we reminisced about writing 68K assembler and wondering what it would be like to have a 64 bit version. It's not remotely intended to be a vehicle for 68K advancement. If that was my aim, I would have started with 68K instruction encoding and tried to find a way to add the same features to it.

It's little endian for the same reason it doesn't have a condition code register either and for the same reason it has 16 of each register and has a bytecode layout. Simplicity. There's no benefit to binary ISA compatibility, endian conversion or CCR for the interpreter model. Big endian would just be data conversion for its own sake. It's not running 68K binaries, there's no existing code or infrastructure to worry about.

For all that, it's pretty rapid. Probably faster than any existing hardware 68K, but a long way behind what a JIT could achieve.

Last edited by Karlos on 01-May-2022 at 10:48 PM.

_________________
Doing stupid things for fun...

@OlafS25

Quote:

most people today buy just devices for a certain purpose. People do not care about OS or hardware, just that it does what they expect and price

I 100% agree, I’m just more pointing out people under estimate how much more people are willing to pay if you dress things up. A500 mini is a perfect example, without the brand it would of been tough to sell a mini generic console for that price. There 100’s of them on eBay / Ali express.

The controller too, £6 for basically the same button layout but in a different case https://thepihut.com/collections/raspberry-pi-usb-game-controllers/products/raspberry-pi-compatible-usb-gamepad-controller-snes-style

I will alway remember a tv show demonstrate the importance of packaging and presentation. Two coffee stand selling the same coffee and same amounts, one was sold in a cheap plastic cup for 20p, the other had deluxe Starbucks like cup, with designs etc, £1, the one selling for £1 sold 10 to 1 plastic one. Dont underestimate branding / packaging / eye candy.

_________________
AmigaNG, YouTube, LeaveReality Studio

@Karlos

Quote:

The inefficiency you speak of there affects only the most compute bound code and only the branchiest, least predictable compute bound code at that. And even then, it usually only impacts the first trace through a code block to be translated. Some pathological raytracing example would be perhaps the only example that springs to mind. It's the sort of code compilers avoid producing most of the time, because it turns out that it's terrible for native performance too.

Unless it's really optimised most PPC asm I examine stores data and variables in memory on the stack so likely doesn't matter in the long run. But if it was coded in a way to make use of the host data cache that would be a good way to speed it up. However, unless all the memory is coupled close together, it would have diminishing returns on speed.

Quote:

As for the memory overhead for translation cache it's memory allocated from the emulation host, which is plentiful and not stolen from within the emulation memory space.

It is but the more code blocks needing JIT the more management it needs. As opposed to a run time loader doing all code in one block.

Quote:

I can only disagree in the strongest possible terms to this. Configuring Amithlon was a pain and only got worse after it was left to wither on the vine. However, once working it in no way whatsoever presents itself as an x86 platform to the user. I can't imagine who would come up with such demonstrably nonsense argument than an architecture fanboy unable to cope with the idea that the x86 was able to evolve into something decent. It ran every system friendly 68K application I owned at the time and at a performance UAE on the same machine couldn't match. The only omission was the lack of custom chipset emulation. But it was no different in that regard to OS4, MorphOS or AROS at the time running on non-original hardware.

Let me explain. I was a member of both the AUG and MAUG Amiga clubs where Bernie, the author of Amithlon attended and demonstrated his product. Before it was released and before OS4 was released. There was mixed feelings as you can imagine promoting an Intel PC to take over the Amiga. But, on the whole, when people could see what it could do, they wanted the Amiga OS port to PPC to be scrapped and wanted to see Amithlon released as the official Amiga OS4 instead. It created so much excitement. So, to use your words, it actually came from Amiga users who agree x86 was able to evolve into something decent.

I could understand their excitement. But I thought it was pointless to suggest scrapping the OS4 port for an AmigaOS emulator. As useful as it was it didn't update or improve the OS itself, it just ran the current one and OS friendly applications a lot faster. I didn't see it as future proofing since there was no new OS being worked on.

Quote:

Only OS4 on the blizzardppc with BlizzPPC felt closer to the "real" Amiga experience in my view as it was able to run code depending on native chipset and it was of course running on the original machine. This was nice but the whole experience was somewhat underpowered from an OS4 ecosystem perspective given that all the cool things for OS4 were happening on G3 and G4 processors by then. Sure I got Quake 3 working on my A1200/Bvision when developing the Permedia2 driver for it, but you'd be insane to actually want to play it. It was slightly better on the CSPPC. Same with all the web browsers that were coming out at the time.

That's fair enough since it has the real chipset. It was a bit quirky with the setup and some things didn't want to work. I forget what as I only tested it on a friends Amiga who had the hardware. And for some reason things that work on Classic don't work on an AmigaOne. Case in point, the audio.device. I found recently the "non Amiga" version for AHI is broken. It doesn't do locks. Instead of locking or returning an error it just replies back. Which is annoying as I spent a few nights writing a routine that cleanly allocated a lock but couldn't get it to work and I studied the instructions and thought I had it. But there was not one example code I could find to compare with. I test on UAE and it works. Broken on my OS4. After asking about it I find the AHI version is broken and won't lock. Well they could have amended the documentation! I hate wasting time on things that just don't work because some OS4 component is broken and needs fixing by third party software to work as it should.

Quote:

Switching from a sub optimal OS4 experience back to a good OS3 experience on that machine was always a reminder that there was no hope of a direct continuation. I had an A1XE and it was clearly s far better experience on that hardware. But you could console yourself with the fact it was based on 3.1 sources and was pretty compatible with system friendly back catalogue.

I tend to agree that 68K is best on an Amiga. And OS4 best on hardware like AmigaOne. With 68K being a lucky guess if it works on OS4.

Quote:

Amithlon was the same in that regard except for one thing. It was just much faster at everything. PPC native application code on my G4, except where carefully tuned for altivec often ran slower than equivalent 68K versions on the Amithlon system I had at the time. And as for the BlizzPPC, there was no contest at all. I'm a software engineer. I benchmark things carefully. I write my own tests. The crappy Duron 1200 was faster. The Athlon XP I briefly had it working on was much faster.

At the time I recall the Athlon, from where the Amithlon name was also derived, was running at 1Ghz on average. You've got a mid 90s's PPC CPU running at most 240 MHz with an Amiga. On the One a G4 running at 800 or even clocked to 933 with some overclocking to 1Ghz. Which is close to Ghz speeds. It says a lot, if not even PPC JIT, but native PPC code was slower than JIT code on an x86 CPU. And Apple was using the same CPU! But on a better motherboard.

Quote:

Since those days, the NG era has seemed more and more a misstep. If the most significant step was to avoid falling into obsolescence, moving to PPC was the wrong choice. The writing was on the wall even then, but it was generally easier and more palatable to most users. It wasn't a dead platform at the time, either so I don't blame anyone for taking it that way.

That choice was made by Phase 5. But, looking back, there wasn't much WarpOS or WarpUP software around, which is the only compatibility PPC would give. And OS4 didn't even include any direct support for it IIRC. But PPC was entrenched with ASM tutorials and all that. Largely accepted because of Motorola I think. And the big one was that only a PPC plugged into an Amiga. There was no other expansion boards with any other CPU. No ARM, not even a ColdFire. x86 bridgeboards would have been unacceptable to port to. To port to another CPU another CPU card would have needed to be engineered. And to ease porting needed to be big endian. There was more choice back then to fill those requirements but no other choice was made.

Quote:

So, this is why decades later I advocate for a 68K future, albeit one based on JIT.

These days I'm thinking it's more practical to simply give up. It seems like we are at the point of kicking a dead horse around. You can lead a horse to water but you can't revive a dead horse by making it drink.

Amithlon was a sign. A big sign. That said to the Amiga; I can be you and I can be you faster you ever were, I am so much better, so just die already.

And then the Amiga said "Die heretic!" and pushed him off the bridge!

LOL. Well not really. I can see Amithlon was a useful tool. But as an Amiga fan I also took it as a kick in the guts. We already knew the Amiga's time had come and gone. But this and everything after just doesn't let the Amiga have a respectable death and die in peace. It just seems like kicking a corpse when it's down. Such is Amiga life.


Quote:

You're confusing the complexity of interpreting binary code with recompiling it. Your code to interpret/JIT looks like something with a few very hot globals (the registers). An interpreter for 68K may be more complicated to implement than PPC (possibly), and pays the price of that complexity per instruction interpreted.

I know it's more complex. It practically needs to be an assembler that is working with a raw code source. Made up of macros that need expanding to target CPU.

Quote:

This is not true, or as true for JIT. The fewer registers and such are required for everything, the more a JIT is able to register allocate things and produce streamlined code for the host. PPC has at 64 registers to care about between the FPU and IU and it's triple operand register to register workflow is awkward to allocate into a smaller number of host registers than a single 68K one with a complex address operation. It's also not particularly RISC from a simplicity perspective. Some instructions are pretty damn complicated. And in the end, you do the complicated interpretation of a code block once, but repeatedly execute the result.

It's possible an optimised block could use host registers but it needs loading in and saving later. So more load/store in CISC code than the original RISC. But, using a JIT compiler for all blocks could produce better code. Most Elfs have PPC code in one block. As opposed to 68k hunks where organisation was more dynamic with no rigid rules.

Quote:

Then there's the PPC FPU. In principle, bring IEEE754 by design ought to make it simpler but it's also made more complicated to by other factors around interpretation of condition codes etc. It's generally easier and more compatible to emulate the FPU instructions in software. This is a big performance hit, even on JIT.

Being it's down from 80 to 64 bits should make it easier. Plus x64 has much wider vectors than PPC. Last checked PPC was still using an old 128 bits which looks laughable these days. Power may have better but last I checked P9 was still using classic 128. Vectors could also be used on x64 for some operations but best to simulate PPC vectors.

The odd thing is, is that even PPC64 which over is ten years old in the PA6T, and a PPC32 G4 at least 15 years, should be so old and obsolete that a modern x64 should emulate it easily. Perhaps PPC is just a tad too modern in design and features to be so. OTOH, the 68k was halted in the 90s', has a smaller register file, doesn't have vectors, does have a large FPU size, but is also CISC so a lot easier to translate to on a newer CISC CPU.

Last edited by Hypex on 02-May-2022 at 08:09 AM.

@Hypex

Quote:

It is but the more code blocks needing JIT the more management it needs. As opposed to a run time loader doing all code in one block.

So far in Emu68 I have managed to fill the JIT cache up to maybe 10-20% (corresponding to about 12MB at most) when working with AmigaOS. Unfortunately it is flushing **entire** CPU cache, both instruction and data, every time it is loading an executable. By its nature, instruction cache flush is also JIT cache flush.

The only piece of software which manages to fill up the JIT cache entirely is PCTask running in dynamic mode, so to say JIT engine on JIT engine.

Not to mention the ahead of time recompilation of binaries from m68k to e.g. arm may be hard since the HUNK format gives only very scarce information about structure of executable.

@Karlos

Quote:

I don't think you can make that claim with me. I was an early PPC adopter and despite not wanting to become partisan, worked on some driver components (mostly graphical) of OS4 and tested it as abeta tester too. I'm ex-amigan by circumstance only; three young kids means no time for such hobbies at the moment.

Because I'm not making that claim with you. I know you was an early PPC adopter. I also said you would understand. I've heard it from other people which I somehow failed to convey. But their comments are always made in a fashion to put OS4 down.

Sometimes I don't understand. Before OS4 and AmigaOne came out there was a bit of excitement about it and was from the 68K crowd. Some like me even bought into it. It was a good time really. Most Amiga people knew what was going on even if they gave up for the PC scene or relegated their Amiga to UAE. But there are other Amiga people who didn't even know about it, some didn't even know it ran 68k software and others thought was running on a Linux kernel! You'd think that Commodore was marketing OS4 on the AmigaOne!

Then I meet people who I thought were Johnny come lately's. Because they didn't seem to be aware of any Amiga developments after Commodore. And they wonder what the point of OS4 is when Windows works and is cheap so don't know why a new expensive machine would be created that can't boot Amiga floppies and has no Amiga chipset.

Quote:

I'm not anti PPC. It was a fun ride and an interesting architecture to write code for (which I still do from time to time). But as a continuation of the Amiga, for me at least, it's over. For legacy applications, the basic G4 is definitely "fast enough", being at least a full order of magnitude faster at running those applications than a decent 040 was. Faster PPC hardware is still out there but it's also crossed that event horizon of no further development. Which leaves PPC parts intended for increasingly niche use cases that are correspondingly more expensive. It's just not a sustainable model. The same is true for MorphOS. The hardware may be more available, bur for how long? G5 systems in particular were not known for their long term reliability, even among the most ardent fans at the time.

MorphOS had a problem when the Pegasos workstations stopped being produced and I don't even know if the last ODW was produced which looked like the future models. But after they managed to port it to Mac hardware. It was good as Mac hardware was better PPC hardware than most. But it was bad as they then needed old second hand computers. Which isn't good for new development. OTOH OS4 got dragged out with average embedded PPC design boards with more than average prices.

I read more PPC than I write. I still prefer it to x86 of any kind which I consider to be in the realm of an assembler and not a human. I did do some PPC ASM a few years back and a little more recently. But I prefer to keep it minimal and let the compiler do the rest. Also, GCC is terrible at assembler in lines. It should be simple, know what I want to do, but on GCC to have to work with this extra language getting in your way. So the ECX compiler is great. Inline my PPC ASM. Works out of the box!

I wonder if this is why AROS didn't take off as expected. The Amiga has 68K as well as ASM embedded into it's soul. No Amiga person wants to learn x86 ASM to program AROS at the bare metal!

Quote:

Simpler on paper. Simpler maybe to interpret than 68K. Difficult to interpret efficiently and harder still to JIT translate into effective code. You only have to look at existing emulations to see why. I spent a few weeks hacking away at QEMU source used in the UAE PPC JIT to see if I could fix the FPU performance without it being a buggy crashfest. I gave up after a while because it just wasn't worth the time investment and wasn't clear if it even could be appropriately fixed.

It's gotta be better than those terrible looking PPC versions of register byte swapping. Which it has no instructions to do when I looked. It's logically a memory only operation. A roll, swap, roll and your feeling queasy before the 68K is done. On PPC it's... oh... never mind.

Quote:

68K JIT emulation is much more mature and more pervasive with good quality implementations for x64, PPC and ARM.

I favour ARM as a target. Work should have been put in place years ago. 2015 was the average ten year point OS4 had been on PPC. The move to ARM was then.

Thus why I had an idea to model a word code on PPC. Wait I said PPC, half word. Stupid weird PPC conventions. Though calling a 64 bit long on PPC makes more sense than making up a long long for 64 bit every where else. I don't know if they kept it going that way.

Compiler people:
We need another word to extend it. Hey I know, instead of another word being longer lets juts make it longer and call it long long!

Predicted evolution of CPU word sizes against PPC
Standard:
32: Long. 64:Long long. 128:Long long long long. 256: Long long long long long long long long.

PPC:
32: Word. 64: Long. 128: Longer. 256:Longest.

@Hypex

I dont really buy the narrative of an Amithlon solution being the inevitable death of AmigaOS development because it would have been limited to 3.x. Very little of OS4 is written in assembler, for good reason. What assembler there is resides in low level routines that manage hardware or accelerate specific functions like copying memory around.

If Amithlon had been a success and loads of people had gone that route, porting OS4 back to 68K would've been less effort than porting the guts of 3.1 to PPC was originally. I very much doubt anyone on a core i5 or better "modern" evolution of Umilator today running a 68K OS4, with a couple of native accelerations would have particularly missed the PPC. And with cheap commodity hardware for said modern Umilator there's be a much bigger market for OS4/68K than there ever has been for PPC.

Even without any new high end 68K to run on, OS 3.1.4 and 3.2 have still done pretty well.

_________________
Doing stupid things for fun...

@hypex


Quote:

But as an Amiga fan I also took it as a kick in the guts. We already knew the Amiga's time had come and gone

Why though? As an Amiga fan I saw it as a neat solution to a difficult problem. That problem being the discontinuation of 68K hardware. One that didn't require porting to an alien architecture that was always at risk given that the only real consumer was Apple. One that allowed the 68K to continue, even if nothing more than a CLR, but with the advantage of genuine backwards compatibility.

_________________
Doing stupid things for fun...