@Karlos

Quote:

I always doubted that claim because my own tests at the time showed Amithlon to be much faster than UAE on the same machine and also much lower latency with respect to input etc.

That lower latency makes the whole thing "feel" so much better in my opinion. Probably largely due to the responsiveness that low latency offers.

I still have an Amithlon system set up and I still enjoy it more than WinUAE despite the monumental gulf in specs between the systems I run them on (core2duo e8500 overclocked to 4.4ghz/1GB ddr2@1200-ish mhz (1066, but the RAM is overclocked as the fsb is overclocked) + gf pcfx (gf 5200 on a pci express interface)) for Amithlon vs an i9-13900k/ddr5@6400mhz/rtx 3080ti for WinUAE).

Both are impressive pieces of software and I use them both for different usage scenarios, but Amithlon is definitely my go to for "proper" 68k/OS3.x use.
Strangely the Amithlon system gives higher scores for fpu performance for synthetic tests despite the WinUAE host having probably 10x+ single threaded speed and using multiple threads vs Amithlon's one.
I suspect its just synthetic tests where this is the case, but Ive always found it curious.
Never had a need to see if there's anything to it for real world usage, and the gfx hardware is a bottleneck, so it doesnt show up for software I use that utilizes an fpu.

@fishy_fis

Have you considered running Amithlon in a modern virtual machine on the faster hardware? Even with the virtualisation, I expect the performance to hold up since virtualisation has already come a long way in removing the overhead of dealing with things like host hardware integration.

_________________
Doing stupid things for fun...

@Karlos

I was planning on giving it a try this weekend actually, just out of curiosity.
The main thing that has stopped me thus far though is the inability to create custom screenmodes when using vesa gfx, and the fact vesa modes appear to cause random pauses in the system. Faster hardware may help there though.
On top of that though I have the Amithlon box connected to a 22 inch crt, which is very flexible with the resolutions/refresh rates I can create with it, whereas the i9-13900k is connected to a 70 inch 4k display, which is a bit too big to use at a desk at 1080p, which I think is the highest res that can be used.
Depending on how the experimenting goes though I might just buy a dp to vga adapter and run an Amithlon VM as a secondary display.

Glad this thread happened. I had fun trying to create the ultimate Amithlon box some years back and Im now motivated/curious enough to do some more experimenting.

@Karlos

Quote:

Karlos wrote: @fishy_fis Have you considered running Amithlon in a modern virtual machine on the faster hardware? Even with the virtualisation, I expect the performance to hold up since virtualisation has already come a long way in removing the overhead of dealing with things like host hardware integration.

But the the latency gains would probably be lost

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

@pixie

I don't know that this is the case today. Virtualisation is used for servers which need to have rapid response to network packets so I'm confident that a lot of effort has gone into latency. Also the other benefits would largely still apply, such as display buffer access etc.

Last edited by Karlos on 27-Feb-2023 at 02:27 PM.

_________________
Doing stupid things for fun...

@Karlos

Amithlon can never return, it’s been too long. Also it’s very obsolete, dead and the corpse kind of smells.

_________________
Sent from my Quantum Computer.

@DiscreetFX

The future of the Amiga is 68K, emulated. OS3.2. Vampire, PiStorm. Hell, even PPC/NG makes a good platform to run system friendly 68K applications on. A modernised Umilator Redux could be the high end Amiga workstation of your dreams.

If you think it's just a less compatible UAE, you haven't used it.

_________________
Doing stupid things for fun...

@Karlos

amiga community has uae jit 22 years.
22 years without anything worth use.
nobody sane will write software for emulator.
accept that.

Did anyone else hear a fart just now?

_________________
Doing stupid things for fun...

@Karlos

Don’t get me wrong, I was/am a big fan of the product but it’s developer wants it to stay dead for some reason.

_________________
Sent from my Quantum Computer.

@Karlos

Quote:

purely hypothetically, assume you had some Linux native Vulkan driver

I am afraid I haven't got the slightest clue how 3D works, on either side. So I really couldn't tell.

But to flesh out the Amithlon graphics system description --- the VRAM "simply" exists in PCI space, as does the memory-mapped IO. Back then, graphics cards were relatively simple; There was RAM, and there were registers. Some registers could be used to fill command pipelines, but (best as I ever knew), RAM was simply there for things to be displayed.

So Amithlon mapped all the PCI space into the 68k address space, and P96 was handed the actual gfx card memory when it asked for gfx card memory.

In theory, it would have been quite possible to handle the register stuff from 68k, too --- I certainly did that at times, by fooling some libraries into believing I had a Mediator. S3 Virge, Permedia2, and Voodoo were all things I had going at some point. Never allowed that out of the lab, of course, due to those 68k drivers being, uhm, "problematic"...

Also, those weren't cards typically found in PCs; nVidia, ATI and Matrox were "it", and I sure as hell wasn't going to start writing P96 drivers for them. So anything requiring register access was passed to x86, and straight into the kernel, where the kernel FB drivers had a lot of accelerated drawing functions, as well as mode setting functions available (albeit not usually fully exposed to userland). How to go from "I want to blit a block from (x1/y1/x2/y2) to (x3/y3)" to writing magic values into registers was the kernel drivers' problem, not mine.

Of course, ideally one should be able to do make that request, and then go do something else while it's being handled. Memories of how that was handled are fuzzy --- I believe P96 has a "check whether all operations have completed" API call which took some wrangling to satisfy in that setup. But it was all doable.



Now, as I keep saying, it's 2023. Even cheap gfx cards have more memory than AmigaOS can handle, never mind P96. And my (very, very vague) impression is that all that lovely 2D acceleration stuff has disappeared from gfx cards, and if at all implemented, is implemented on the GPU. But mostly things get composited, not moved.
On the plus side, compositing is trivial, and gfx card bandwidth is insane. So if one were to do it again in 2023, a viable approach might be to (a) reserve 128M or so of gfx memory for P96, (b) map those 128M into 68k space, (c) implement P96 blits/line draws/circles/text etc in x86 native code, then (d) have a 3D system running on the x86 side which supports OpenGL (or Vulcan, or whatever --- can you tell I am not a 3D person? :), and has the ability to composite the P96 frame buffer into the actual display surface. And (e) make that the default, which can be manipulated through a 68k->x86 OpenGL tunnel, but can also be restored through some key combo.

Oh, and maybe don't use P96, but whatever RTG system AROS comes with these days. P96 licensing hasn't been without issues over the years...

@BigD

Quote:

So just to clarify; have all the sources for Amithlon 2 ACTUALLY been destroyed?

To the best of my knowledge[1], no. I don't know where that rumor originated --- it's not something that I'd ever intentionally do. What would be the point?

Quote:

Is this discussion for reimplementing the lessons learned by Bernie if applicable in 2023?

Honestly --- this came up because Lasse found his old demo CD, and got nostalgic. Then I got nostalgic. Then Karlos caught nerd-nostalgia... And as far as I am concerned, that's "what we are left with" --- an opportunity to catch up on some nerding-out which should have happened 20 years ago, but didn't.

The sources themselves have basically no value, monetary or otherwise, in 2023. Most of the clever hacks solving 2002 problems are completely irrelevant in 2023, and if anyone were silly enough to try something similar today, there are lots of brand new cool hacks they could do.[2]

[1]: I haven't checked, or even looked for, any of the storage media in many, many years. I don't think they were affected by the Great Garage Floodings of the mid-naughties. They should be in a storage unit in Melbourne, along with about 95% of everything I own. I am still being charged for the unit, so I bloody well hope it hasn't burned down.

[2]: And if you asked me, the best platform to target would be ARMv8 (64 bit ARM).

@umisef

Interesting. I mention Vulkan not because it's the "in thing", but specifically because it's designed to be implemented cleanly of the host windowing system and secondly because it permits the developer to do the low level resource management. It's also multithreaded, so one could even envisage offloading the actual graphical operation setup to another core in the CPU.

What I really wanted to emphasise here is that the management of the hardware remains native but there's a small API exposed to the Amiga side that allows an opengl client for the Amiga to be implemented.

This works in part because opengl is very much the opposite of Vulkan, where all the resource management is hidden from the client. This is due to the fact that it was originally designed as a genuine client server architecture in which the renderer may be on a different machine.

So for an opengl client on the Amiga side, you could make use of more texture memory than the Amiga can address easily because the Amiga doesn't need to address it, it just gets returned a resource ID.

_________________
Doing stupid things for fun...

@fishy_fis

Quote:

Strangely the Amithlon system gives higher scores for fpu performance for synthetic tests despite the WinUAE host having probably 10x+ single threaded speed and using multiple threads vs Amithlon's one.

Any idea what UAE uses for FPU emulation these days? They might have moved everything to 64 bit, at which point the support for x87 FPU disappears, and good riddance! You get lovely XMM (I think?) vector FPU support instead, with actual registers and, I believe, even three operand instructions.

But there are two drawbacks: (a) XMM and descendants all "only" support 64 bit FP values at most, so are not really good enough to emulate the 80-bit-supporting 68k FPUs, and (b) the original UAE/JIT FPU support is for the insane x87 stack based nonsense. So while moving the original UAE/JIT's integer support to x86/64 could largely be done by generating 32 bit prefixes all over the place, moving FPU support to 64 bits would require a complete rewrite, pretty much from scratch. And then, the result would still be somewhat incompatible, due to lack of 80 bit support --- the UAE folk are very keen on high compatibility.

So I wouldn't rule out that they simply decided it wasn't worth the hassle, and switched FPU back to being fully emulated (which, I believe, can be done quite speedily while completely ignoring the native FPU).


Note, though, that this is purely speculation --- I have zero idea what's going on inside UAE these days!

@umisef

Quote:

The sources themselves have basically no value, monetary or otherwise, in 2023

With respect, I disagree. I don't think they necessarily have monetary value (I'm sure some vulture might think otherwise), but the code has the same intrinsics value all "old" code has. Furthermore, it's a snapshot of something that was genuinely state of the art when it was written. For the technically curious, the chance to study them is a goldmine learning opportunity. If there were to be a modern equivalent, most of the same challenges have to be met even if the required solutions in 2023 are different.

_________________
Doing stupid things for fun...

@umisef

I suspect you're not far off the mark there.

Don't quote me on it, but I think it's based on uae-jit, but changed little by little over time to a point it shares no more than what can still be used.
I didnt use it for a handful of years, but reading the changelogs when revisiting it I seem to recall fpu was being fully emulated but evolved since to a point a form of jit was reintroduced.
It can now use jit, or not, specifically for fpu instructions, with options for "host 64 bit", "host 80-bit" and "softfloat 80bit", so I think they initially didnt think it was the hassle, but the desire for being very compatible was enough to bite the bullet.

This is all pieced together based on what I remember in the change logs coupled with your above speculation, but if I was a gambling man I'd put my money on it being not too far removed from how things are.

Last edited by fishy_fis on 28-Feb-2023 at 09:52 AM.

@Karlos

Quote:

Karlos wrote: @umisef Quote: The sources themselves have basically no value, monetary or otherwise, in 2023 With respect, I disagree. I don't think they necessarily have monetary value (I'm sure some vulture might think otherwise), but the code has the same intrinsics value all "old" code has. Furthermore, it's a snapshot of something that was genuinely state of the art when it was written. For the technically curious, the chance to study them is a goldmine learning opportunity. If there were to be a modern equivalent, most of the same challenges have to be met even if the required solutions in 2023 are different.

Couldn’t have put it better myself.

I hope I’m not seen as the vulture alluded to above.

_________________
All the way, with 68k

@fishy_fis

Current UAE options allow the selection of 68881/882/internal, the latter being for 68040/060. The options for the emulation hint strongly at more than one implementation:

* Host 64-bit (could be vector perhaps)
* Host 80-bit (Legacy x87 ?)
* Softfloat 80-bit

I'll be honest I tend to leave it on Host 64-bit.

_________________
Doing stupid things for fun...

@agami

I dunno, it wasn't aimed at you, there are many people that seem to cling to IP and trademarks keen to stifle anything that looks like progress. Why, do you think it applies?

_________________
Doing stupid things for fun...

@Karlos

68881/882/internal options have been around for a few decades (or thereabouts).
The bit precision selector is new(ish) as is the ability to use jit, or not, specifically for fpu.

I suspect it's the reverse for vectors/legacy x87 vs. what you've written. Softfloat is nigh on certainly all emulated. Im not sure 80bit was supported at all previously.

You could be correct though in regards to implementations. May be a few as opposed to one all encompassing method. Would very likely be the easier way to go about things.


edits: aaargg,.... Im the typo king with strong enough OCD that I need to correct them all.

Last edited by fishy_fis on 28-Feb-2023 at 10:41 AM.
Last edited by fishy_fis on 28-Feb-2023 at 10:40 AM.
Last edited by fishy_fis on 28-Feb-2023 at 10:36 AM.
Last edited by fishy_fis on 28-Feb-2023 at 10:35 AM.