@kolla

Quote:

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.

Yes, I am aware of the end goal, and further ambitions. I was more commenting on the present day comparison.

More importantly, I am not advocating for one over the other. Both initiatives are based on and around higher performing 68k.
While they’re going with different approaches and in slightly different directions, it’s nothing that can’t eventually be converged, especially if AROS 68k continues to be the basis for the OS.

Both of them together can reignite an interest in developing apps and games for the 68k.
If we could reach Haiku levels of engagement, there’d be critical mass to explore moving toward a 64bit and multi-core/thread 68k soft-CPU.

Last edited by agami on 23-Feb-2023 at 11:15 PM.

_________________
All the way, with 68k

@agami

For pc I have windows.
Our community has uae with jit for almost 23 years.
It not help 68k.
Nobody sane will write software for emulator.

Last edited by ppcamiga1 on 24-Feb-2023 at 05:10 PM.

@ppcamiga1

Quote:

ppcamiga1 wrote: Nobody sane will write software for emulator.

Luckily, sanity isn’t widespread in the Amiga community.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Q.E.D.

_________________
Doing stupid things for fun...

@kolla

Quote:

kolla wrote: @ppcamiga1 Quote: ppcamiga1 wrote: Nobody sane will write software for emulator. Luckily, sanity isn’t widespread in the Amiga community.

Ah, you beat me to it.

_________________
All the way, with 68k

@ppcamiga1

Quote:

It not help 68k

Absolute garbage.
A lot of 68k software is developed using emulation.
It's been integral to 68k.

Quote:

Nobody sane will write software for emulator

You're not remotely qualified to say what sane people will do.
It's nowhere in the vicinity of your wheelhouse.

Last edited by fishy_fis on 25-Feb-2023 at 07:13 AM.
Last edited by fishy_fis on 25-Feb-2023 at 07:12 AM.

"Nobody sane will write software for an emulator."

I just saw the legion of .net, Java, JS, PHP, web assembly and countless other language programmers all cast a sideways glance.

And while there's a difference between an software emulator and a software virtual machine, it's a pretty nebulous one at an implementation level.

_________________
Doing stupid things for fun...

@Karlos

At this point it seems reasonable to assume he's a sadomasochist with nipple clamps at the helm, eagerly awaiting responses to whatever it is he types.
Such is his enthusiasm he even has a document open at all times so that humiliation is just a copy and paste away.
Amigaworld.net appears to be his pornhub.

@fishy_fis

You're giving him too much credit, he's just a troll and a thoroughly feeble one at that.

_________________
Doing stupid things for fun...

@Karlos

Yeah, but sometimes its fun to laugh at and mock clowns when you have a little free time.

@fishy_fis

That's true and I'm equally guilty.

_________________
Doing stupid things for fun...

@fishy_fis

Quote:

Karlos wrote: @fishy_fis You're giving him too much credit, he's just a troll and a thoroughly feeble one at that.

Yeah, and you’ve given my mind an image that is hilarious. There’s definitely some self-flagellation going on.
After all, the gimp took out a loan from the Polish mafia and he risked his knees getting ball-peened to get an A1X1k.

_________________
All the way, with 68k

@Karlos

Quote:

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.

Definitely very feasible --- so feasible, in fact, that that's exactly what Amithlon/Umilator were doing. The kernel graphics drivers back then had some low-level hardware acceleration which was exposing functions pretty much comparable to the P96 card interface (because both were simply providing a thin veneer over what the gfx chips of the era offered in hardware). My custom kernel exposed some more of that to user space than a standard one, and IIRC I taught some of the drivers a couple extra functions --- but yeah, P96 was definitely hitting the actual hardware. Which is one of the reasons for...
Quote:

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

with the major other one being the same approach on the input side (see above --- the PS/2 mouse causes actual hardware interrupts, which immediately get passed on and immediately change the state of the emulated CIA.

A third, minor reason might have to do with the JIT compiler's approach to invalidating[1] cache. The approach in UAE/JIT can, in extreme cases, introduce human-noticeable latencies; I.e. it may keep the host CPU busy tearing down data structures for tens of milliseconds. Not much of a problem on UAE, as (a) it's quite rare, and (b) such latencies are not uncommon, anyway, due to the layers of emulation in both input and output.
In Amithlon, where 68k drivers actually drive things like (some) network and (some) sound cards, such latencies were, of course, not viable, so I spent a lot of time designing data structures that replaced the one-time walk over the whole JIT cache with spread-out, on-demand operations triggered whenever a piece of "invalidated" code is actually used.[2]

So yes, as you put it:
Quote:

there was more to it than just "no custom chip overhead",

[1]: Due to some applications, and especially Mac emulators, being extremely trigger happy with invalidating ICache (having been written for processors where that cache is, relatively, tiny), actually discarding all the translated code is not an option. Instead, each translated block "just" gets marked so that prior to it running next time, a check is performed on whether any 68k code has changed since it was last compiled. If not, the block is marked as valid again; If yes, the block is actually invalidated, and will eventually be recompiled.
[2]: If I recall correctly, this was already done in UAE/JIT. However, in UAE/JIT, marking each block literally involved accessing each block; In Amithlon, it instead was an O(1) operation.

@umisef

Quote:

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.

Upon further reminiscing, I realise that the above actually described what I used in a (never released) 68k=>PPC JIT for UAE.

In Amithlon however, I tried that initially, but eventually came up with a much uglier (and, of course, faster :) hack --- rather than the JSR, the compiler will simply sprinkle writes to a special address. Those writes had both immediate address and data, so didn't touch any registers, didn't clobber any flags, and (unlike the JSR/RET combo) is fully pipelineable and reorderable. Being 9 (or 10?) bytes long was a bit of a bummer, but a lot of the time, that write still got scheduled in an otherwise unused execution slot, and didn't add any extra execution time.

When the need arose to exit the JITed code, Amithlon would use the MMU to write-protect the address in question, so the write would cause a segmentation fault. For speed reasons, segfaults to that special address were caught and handled inside the kernel; The handler would simply set the PC to the value written, and return. So the JIT compiler would put "MOV 0x12345678,(0x9abcdef0)" instructions in, which, in effect, turned into "Jump to 0x12345678 if there is a need to exit compiled code, otherwise do nothing" --- with 0x12345678 being the address of the code that would unwind the execution state at that point.

Last edited by umisef on 26-Feb-2023 at 01:22 PM.

@umisef

_________________
Doing stupid things for fun...

@Karlos

Literally LOL

_________________
All the way, with 68k

@umisef

Going back to RTG, let's say, purely hypothetically, assume you had some Linux native Vulkan driver (which I believe is pretty decoupled from the windowing system) and let's further assume (TBC) that it's able to render to the same VRAM surfaces you are sharing with the emulation as bitmaps.

How feasible to expose, say a thin layer resource for implementing say an OpenGL client on the Amiga side that is accelerated natively?

Note that I'm not saying it should be a Vulkan client, just implemented natively by Vulkan to avoid inflating dependencies.

_________________
Doing stupid things for fun...

@agami

That's literally me, reading Bernie's posts.

_________________
Doing stupid things for fun...

@Karlos

So just to clarify; have all the sources for Amithlon 2 ACTUALLY been destroyed? If so what are we left with here? Is this discussion for reimplementing the lessons learned by Bernie if applicable in 2023?

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@BigD

I do not know the answer to that but I assume from what @umisef is saying that the sources, or at least some of them, are intact.

Just reading Bernie's posts here makes me appreciate what we truly lost with Umilator and Amithlon and that it's not just my hazy nostalgia. People assume that Amithlon was just like UAE but a bit quicker due to being less compatible via not having custom chip emulation*. Those people have never tried it. 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.

It was a beast. Make no mistake. Like a fully roided up imagining of Draco.

*Ironically many of the same people cheered NG systems that also didn't have custom chip emulation.

Last edited by Karlos on 27-Feb-2023 at 11:34 AM.

_________________
Doing stupid things for fun...