@NutsAboutAmiga

Yeah. It wasn't great. Lots of defects for what was supposed to be the next generation at the time. Nevertheless, it was still fun and I won't claim otherwise. I was gutted the day it joined its brethren and decided, completely out of the blue, to never boot again.

The most important defect it had is one that has never been addressed and only gotten worse in every subsequent machine: being tied to a gold plated boat anchor on a one way trip to a very expensive obsolescence.

_________________
Doing stupid things for fun...

@Bosanac

Quote:

You didn’t destroy all the source? Or making it all GPL back then wouldn’t have hurt them financially?

Both, actually. Assuming any meaningful interpretation of "them".

Oh, and before anybody asks --- no, I do not currently have access to any of the sources. I have lived in a 1975 VW Kombi for the last year, and some 20+ year old sources did not make the cut for what to fill what little space it offers with.

@Karlos

The reason why Amithlon (and by descent, Umilator) were so fast is that, despite many claims to the contrary, it isn't just UAE with the customs chip emulation thrown out.

In UAE's JIT, which has to play nice with any underlying OS, memory accesses in high compatibility mode are done through a table lookup and function call. In so-called "direct memory access" mode, they are still done that way during the initial, pre-compile phase, and the JIT just logs whether they hit RAM or anything special. Then at compile time, the instructions that hit RAM are assumed to always hit RAM. And the RAM is allocated from the host OS at addresses which have a constant offset from the Amiga's addresses for it, so the memory access "just" has to add that offset.

In Amithlon, the host OS instead plays nice with the emulator. The addresses the emulated Amiga sees are the same as the x86 side sees --- no need for any offset. Which is problematic, because some of the addresses the Amiga is quite firm about are where a 2001 era PC maps the PCI bus by default. So one of the first things Amithlon does on boot up is to remap all the PCI space somewhere else.
And it's all memory accesses that simply hit the exact same address in x86 address space. Anything that isn't access to actual RAM or ROM is caught by the MMU, and the appropriate handler is called that way.

Also, in UAE (at least back then), the custom chip emulation's state is updated in the main thread -- which means that the JIT must keep track of roughly how much work it has done, and occasionally, exit to advance that emulation. The same applies for 68k interrupts --- if any of them happen, the JIT'ed code must be exited; And finding out whether any happened (e.g. because of keyboard input) also requires periodic checking with the OS. And while I cut the keeping-track effort down as much as possible, it, and especially the checking, really slowed things down (the checking, by necessity, clobbers the flags, so whatever 68k flags are held in the x86 flags at the time must be saved, and later restored --- which aren't fast operations).
In contrast, in Amithlon, what custom chips remain (mainly the CIAs) have their state calculated on-demand, from the x86's cycle counter. And any 68k interrupts are actually interrupts on the x86 side, which then get passed to the emulator as signals (i.e. actually interrupt the program execution). They still require a well-defined exit from the JIT'ed code, but that is realised by sprinkling JSR instructions throughout that code, to an address that usually simply holds a RET. That kind of thing is blindingly fast, because everything is cached. Also, it doesn't clobber anything. So if an exit is required, the RET is replaced with a JMP to somewhere that knows how to look up where the matching code to unwind the emulation state for any given JSR can be found, replaces the return address on the stack with it, and then does a RET. That's painfully slow, of course, as it's self-modifying code, and replacing the return address causes a mis prediction from the corresponding cache --- but when the CPU is blindingly fast, interrupts are so (relatively) rare that it doesn't matter.

There is lots more hackery like that. Some is really clever. Some is truly awful, involving nasty hacks in the kernel itself, FFS, and I'd be ashamed because of it --- except for the simple fact that it does its job, it makes things faster.

Building that sort of no-holds-barred, anything-goes collection of weird and wonderful hacks was great fun; Still, the result gave Amithlon performance a CPU generation or two ahead of UAE. Or maybe even three, on a good day. It's now 2023, and we are, what, a dozen CPU generations further along, and there hasn't really been any 68k software development in the meantime. So whatever Amithlon could do in 2002, UAE can easily do faster today, without any of the nasty hacks, and with at least the option of dialing up compatibility.

@twomilator

Quote:

bosanac wrote: Bernie destroyed all copies of the source.

What has been invented, can't be uninvented.

Quote:

Hypex wrote: I don't understand why there are so many hang ups over Amithlon or Umilator when an equally skilled developer could have implemented the same idea.

Even when starting from scratch, as the amount of intervening years now dictate, it is always helpful to look at previous solutions as a helpful "roadmap" or "recipe".

Quote:

umisef wrote: Oh, and before anybody asks --- no, I do not currently have access to any of the sources. I have lived in a 1975 VW Kombi for the last year, and some 20+ year old sources did not make the cut for what to fill what little space it offers with.

When you do happen to get a chance to be in proximity of the stagnant sources, the community would appreciate it if you could chuck 'em over the fence and let us play with it.

#vanlife

Last edited by agami on 23-Feb-2023 at 12:49 AM.

_________________
All the way, with 68k

@DiscreetFX

Quote:

Karlos wrote: @DiscreetFX Excuse me, but no. The vampire is a cool product and I'm not knocking it, but you can't possibly claim that it's fast enough.

@DiscreetFX

I agree with @Karlos on this one.

What the Apollo Team have achived is remarkable and I am certainly a big fan. I have 2x V2 units, and 2x V4 units. And I will be giving them my money for the Kraken as soon as they open pre-orders.

I think the work Gunnar and co are doing is important, both tactically and strategically, but the speed required for a daily driver machine is just not there. For a hypothetical 68080 web browser, even with Javascript acceleration logic directly in the FPGA, the speed of these systems will not support an acceptable UX.

A non-janky 68k soft-hardware solution via an Amithlon/Umilator style implementation is the kind of solution around which to build a new standard.

_________________
All the way, with 68k

@agami

Quote:

When you do happen to get a chance to be in proximity of the stagnant sources, the community would appreciate it if you could chuck 'em over the fence and let us play with it.

Don't hold your breath --- I do not anticipate having physical access for quite some months yet. And even then, finding those old sources is likely to be really low priority.

@agami

There is Emu68 you know, open source and all, doesn’t even have a Linux kernel under it.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@DiscreetFX
Quote:

Vampire makes it redundant anyway. Why have a super fast emulated ECS Amiga with almost no compatibility with classic Amiga games when you have a AAA chipset equivalent 68080 based machine that runs most 68k software and has new exciting releases.

Back in 2002 when i was beta testing Amithlon, I had UAE running OCS games at fullspeed on an Athlon Thunderbird 900mhz. A can't imagine anything have changed in that regard, so you could have a fast Amithlon setup, and run the old games in UAE.

Vampire is a nice product line, but i fully believe that the future for classic Amiga hardware is in PiStorm and Emu68. You buy one adaptor, and can then upgrade your Amiga very cheap when a new Rasberry pi comes out with a better CPU. In the not so distant future i suspect i Pi Zero (next gen) to be faster than any Vampire setup.

Maybe PiStorm can even be made compatible with other SBC's, to give even more performance.

As for myself. If the computer is not a laptop, i'm not interested , I don't use Desktop PC's anymore (except for work), and i don't see any Amiga setup that could replace my laptop as a daily driver. For me Amiga is pure nostalgia, and a fun trip down memory lane.

Last edited by LaBodilsen on 23-Feb-2023 at 06:33 PM.

_________________

@umisef

Quote:

Don't hold your breath --- I do not anticipate having physical access for quite some months yet. And even then, finding those old sources is likely to be really low priority.

No rush. But when you’re back in town, I’d be happy to sweeten the deal. A nice dinner perhaps? A donation to your favourite not-for-profit? Wash your kombi?

Last edited by agami on 23-Feb-2023 at 08:49 AM.

_________________
All the way, with 68k

@umisef

Quote:

So whatever Amithlon could do in 2002, UAE can easily do faster today, without any of the nasty hacks, and with at least the option of dialing up compatibility

The question on my mind is, what could an updated Amithlon machine do on today's hardware?

UAE is great and while my current Amigas are decommissioned awaiting maintenance and rebuild (seemingly forever now that I have much more important responsibilities) I use it regularly. But what I will tell you is, it's not a substitute and I have to run it on a non dedicated machine. So, while blindingly quick most of the time, I get occasional janky mouse movements, frame drops, audio issues and other continuous reminders that it's an entirely emulated experience. I'm sure some of that is down to running WinUAE on Linux which is my x64 OS of choice.

I can honestly say, that even on my then much older PC, Amithlon was a much smoother experience than, at least for me, UAE is today.

Last edited by Karlos on 23-Feb-2023 at 08:22 AM.

_________________
Doing stupid things for fun...

@kolla

Quote:

kolla wrote: @agami There is Emu68 you know, open source and all, doesn’t even have a Linux kernel under it.

I do know, and Michal and I have had discussions around this a while back.

_________________
All the way, with 68k

@umisef

The technical details are very enlightening. I always suspected there was more to it than just "no custom chip overhead", because even running in pure RTG at the time the difference with UAE was conspicuous.

One of the things I found really tantalising at the time was the whole idea of being able to use Amiga 68K device drivers for actual hardware installed in the system. I love the convenience of emulated framebuffers and other virtual devices that generally forms part of the emulation canon, but the idea that you could plug some PCI card in the machine and bang it directly from the Amiga side. It may not be as relevant today, but it's still an intriguing idea.

_________________
Doing stupid things for fun...

@LaBodilsen

Quote:

LaBodilsen wrote: @DiscreetFX Vampire is a nice product line, but i fully believe that the future for classic Amiga hardware is in PiStorm and Emu68. You buy one adaptor, and can then upgrade your Amiga very cheap when a new Rasberry pi comes out with a better CPU. In the not so distant future i suspect i Pi Zero (next gen) to be faster than any Vampire setup.

I agree. The ARM emu68 68k will outperform the V4 FPGA 68080. But there are other things in that FPGA that go beyond just 68k,

The one big difference is that Apollo has a Stand-alone system, and the optional miniITX board: Not requiring a very rare OG Amiga.

Quote:

As for myself. If the computer is not a laptop, i'm not interested , I don't use Desktop PC's anymore (except for work), and i don't see any Amiga setup that could replace my laptop as a daily driver. For me Amiga is pure nostalgia, and a fun trip down memory lane.

So an “Amithlon” Ryzen 6000/7000 laptop then? After about a year of development to get a web browser and a few other subsystems in place.

_________________
All the way, with 68k

@kolla

Quote:

kolla wrote: @agami There is Emu68 you know, open source and all, doesn’t even have a Linux kernel under it.

It would be interesting to understand if Emu68 could be ported to run in a similar way on x64.

I never made too much of the Linux kernel running under Amithlon at the time. You never really got the feeling as a user that it was anything more than glue for hardware initialisation and abstraction.

That's probably a big piece of the attraction of both Umilator and PiStorm to me: the idea that you can have a blazing fast CPU emulation that's able to interact directly with real hardware.

_________________
Doing stupid things for fun...

@unisef

Something I always wondered about that maybe you could give your opinion on.

I wondered how feasible it would be to provide an RTG implementation that allowed AmigaOS accessible VRAM allocation for BitMaps while still providing the ability to virtualise drawing operations on them via a native path that could make use of hardware acceleration on the kernel/Linux side. The idea being to allow for a UAE style single RTG driver that works with most of the Linux supported display hardware but without reducing it to a completely dumb framebuffer from the Amiga side. Having a virtualized, accelerated graphics display that you can still plot a pixel on a BitMap with a single 68K move instruction is something I'd love to have.

_________________
Doing stupid things for fun...

@agami

Quote:

I agree. The ARM emu68 68k will outperform the V4 FPGA 68080. But there are other things in that FPGA that go beyond just 68k, The one big difference is that Apollo has a Stand-alone system, and the optional miniITX board: Not requiring a very rare OG Amiga.

Sure there is more in the Vampire, for now. I don't se any reason why Emu68 could not provide the same functionality in the future.

Quote:

So an “Amithlon” Ryzen 6000/7000 laptop then? After about a year of development to get a web browser and a few other subsystems in place.

It don't even need to be that new of a system. The fastest Amithlon system i have seen online was running on a Core 2 Duo E8600, which is mighty impressive all things considered. But even my previous laptop, a 10 year old Asus with Core i7 3610qm and GeForce 650M would have it beat in performance.
But, some apps would surely be missing. My biggest problem would be running Blender with Optix enabled.

_________________

@agami

Quote:

The one big difference is that Apollo has a Stand-alone system, and the optional miniITX board: Not requiring a very rare OG Amiga.

Then you're will likely be glad to hear that Pistorm is not that much far from that goal

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

@agami

Vampires are glad they are no longer human and humans fear Vampires until they become one.

_________________
Sent from my Quantum Computer.

LOL

Found the screenshot from 2002 with UAE running under AMithlon:

_________________

@agami

You can run Emu68 on JUST a Raspberry pi, a Rapsberry Pi IS standalone.

The original gangsta motherfu…boards is just a temporary stop that is very useful to find and fix bugs in emu68 using existing Amiga software - all along the goal in the end is to have AROS/68k (and whatever else, like Linux/68k) running directly on Emu68 on the Raspeberry Pi, essentially a 68k Raspberry Pi.

AmigaOS? Sure, it can run too, provided that drivers are written, and possibly minimal chipset emulation layer. Like with Amithlon.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC