![]() |
![]() |
#1 |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
Integrated 68K in AROS
So when I was more active in the AROS project I was very vocal about trying to integrate a 68K emulator into the system so older application could be run.
My first idea was to simply let a 68k emulator run in the native environment and see what happens. But endian and ABI issues immediately rule this out. My second attempt was a project called "Emulatron" (a version of which can still be found on my GitHub) . This ran the 68K emulator in a private address space, with a custom set of exec type libraries, where each function entry had a 0x4E70 instruction, which halted my 68k emulation, allowed me to trap the function call perform the desired operation naively and then return control and any results back to the calling program. Essentially Wine for AmigaOS. This worked quite well, but was a huge amount of work, and I simply ran out of time and interest, problems with missing hardware features made this project a real headache. The project is still there if anyone wants to carry the torch. Now, I'm wondering if such an approach could be made the other way around. Since I now have a working Amiga Emulator which can boot Amiga OS and run programs. Perhaps this idea can be revitalised, but starting with a working Amiga emulation and then patching the OS running in the emulation (or preferably running a special build of 68k AROS) to call the native AROS functions via a similar mechanism I used in Emulatron. Anyway, I wanted to open this up for discussion! Let's discuss. |
![]() |
![]() |
#2 |
Registered User
Join Date: Apr 2012
Location: Cardiff
Posts: 414
|
On a related note, have you seen Michal Schulz's current work on Patreon? Port of AROS to ARM/RPI and transparent JIT 68k emulation.
https://www.patreon.com/michal_schulz |
![]() |
![]() |
#3 | |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
Quote:
![]() |
|
![]() |
![]() |
#4 |
Registered User
Join Date: Nov 2018
Location: Germany
Posts: 120
|
Indeed, and during the discussion it turned out we have few different ideas. The question is, which would you all prefer
![]() Matt's idea is to use M68K JIT running on bare metal ARM and emulating parts of the Amiga chipset. One could run AmigaOS on top of it and eventually replace parts of it (or maybe whole AmigaOS later on) with AROS. On the other hand, I have nearly complete m68k JIT designed explicitly for ARM, where every m68k instruction is translated to (statistically) 2 ARM instructions, only, giving a hope for really good performance. First tests with synthetic as well as real world benchmarks oscillate around 630 MIPS on RasPi 3b+. Now, my approach would be, to run the m68k JIT directly on RasPi (bare metal, no other operating system above us!). Then, instead of emulating chipset and running AmigaOS on top of it, we could run m68k AROS with all the drivers needed for RasPi. That would be something like Amithlon, but for ARM, without Linux and with all drivers provided directly by AROS. Of course I will also integrate my JIT in ARM-BE version of AROS, no doubt. The m68k AROS on RasPi is just a nice idea to toy with. What do you think? |
![]() |
![]() |
#5 |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
For the record, I find Michal's approach more exciting long term. My idea is to try and get things moving quickly.
|
![]() |
![]() |
#6 | |
BoingBagged
Join Date: Aug 2007
Location: The South of nowhere
Age: 46
Posts: 2,358
|
Quote:
BTW, if you really get over 500 mips on it, it will certainly make the Raspberry Pi a very atractive choice to anyone. I am looking forward to any progress on this. |
|
![]() |
![]() |
#7 |
Registered User
Join Date: Jun 2012
Location: Worksop/UK
Age: 60
Posts: 1,328
|
Sounds great! Anything Amithlon alike should also be well received.
An Amithlon alike system on ARM is what a lot of people have dreamed of for a while! |
![]() |
![]() |
#8 | |
Registered User
Join Date: Nov 2018
Location: Germany
Posts: 120
|
Quote:
![]() There are 3840000 iterations with 100 instructions each, so to say 384 millions of m68k opcodes to execute. On RasPi3b+ it takes about 0.6 seconds. I will try to run dhrystone test asap, since this one should give slightly more reliable results ![]() |
|
![]() |
![]() |
#9 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,659
|
So this m68 JIT is not just a cpu emulator, but must also forward any AmigaOS calls from a running m68k app to AROS (below the emulator), and then return the result back to the app through the emulator, is that correctly understood?
|
![]() |
![]() |
#10 | |
Registered User
Join Date: Nov 2018
Location: Germany
Posts: 120
|
Quote:
On the other hand, when run directly on RasPi, one could use this JIT to execute the m68k on bare metal ARM machine (with some slowdown of course) and e.g. compile entire AROS as m68k code with drivers for Raspberry. That way you would in principle turn RasPi to a m68k virtual machine running AROS m68k and all classic software on it. No, AmigaOS would not work since the JIT translates only the CPU code, no Amiga hardware support there. Think of Chipset-less Amiga clones such as DraCo ![]() |
|
![]() |
![]() |
#11 | |
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,502
|
Quote:
![]() No, seriously: I think a combination of your efforts would be best. I see the charm of letting the 68k-JIT run on bare-metal, "below" the OS. But how about allowing native ARM-code to bypass the JIT? (and execute it maybe on the second core?) This way the result should be almost the same as running the JIT under ARM-AROS ... with just kind of a reversed default. Would this be possible? And additionally a 68k-binary should be able to run in "high compatibility mode", that provides (some) chipset emulation. This should be selectable like via tool types or cli. Too ambitious? |
|
![]() |
![]() |
#12 | ||
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,659
|
Quote:
Quote:
How would AROS talk to its RasPi drivers in this case? |
||
![]() |
![]() |
#13 | |||
Registered User
Join Date: May 2017
Location: Munich/Bavaria
Posts: 2,502
|
Quote:
At least with system friendly ones it should. Just like on MOS or OS4. For software/games that need direkt access to the hardware, some other emulation layer is needed of course. This could be some UAE-version or Matt's bare metal emulation System calls from the 68k-side could be handled by its counterparts on the ARM-side and/or by a set of (duplicate/fake) 68k libraries. Quote:
You can test "AROS Vision" on UAE. Quote:
but a good question. |
|||
![]() |
![]() |
#14 | |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,659
|
Quote:
I'm only talking system friendly here ![]() Yes - this is what I was talking about above for it to work. |
|
![]() |
![]() |
#15 | |
Registered User
Join Date: Jan 2017
Location: London, UK
Posts: 433
|
Quote:
![]() |
|
![]() |
![]() |
#16 | ||
Registered User
Join Date: Nov 2018
Location: Germany
Posts: 120
|
Quote:
But since you ask exactly this, here is how the emulator will work, at least more or less. On ARM side the pages with m68k code will be marked as XN (eXecute Never) so that an attempt to jump there will trigger a page fault. The exception handler will recognize that a call to m68k code was requested, will jump back to user mode, return address (of ARM code) will be pushed on the m68k stack, Program Counter will be set and main JIT execution loop will start. The loop will work as following: - Check if current PC corresponds to ARM or m68k code. If ARM, then leave JIT loop - Request translation unit (something like instruction cache) for given m68k PC. The JIT engine will either return the unit immediately in case it was already translated and is still in the cache, or will perform translation. - The ARM code in translation unit will be called. As a result of the above code call the PC might have changed - Go back to step 1. The details are not absolutely polished yet and I am aware that this is just a rough plan, but this is more or less how it will work. Such construction will allow me to jump from ARM code to m68k code (either directly by calling JIT engine or through MMU page fault handler) and to call ARM code from m68k code. Quote:
That depends on which project idea we are talking about. In case of regular ARM-based AROS the whole AROS can be ARM code and as such does not need anything particular to talk to the ARM hardware. If we are talking about bare metal m68k cpu emulator, then one could talk to the ARM hardware from m68k side with ease. The ARM cpu does not have any IO ports with special instructions, everything is accessible through MMIO (memory mapped IO). Therefore, it would be theoretically possible to compile all hardware drivers as well as nearly entire AROS as m68k code and let it all run through m68k JIT. Please note our hardware drivers are written in C and, therefore, it does not really what CPU they are compiled for. PS. Please forgive me if something is unclear. As said - very early stage ![]() |
||
![]() |
![]() |
#17 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,659
|
|
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
AROS 68k Emulation | AMIGASYSTEM | support.WinUAE | 6 | 30 January 2023 22:02 |
WinUAE And AROS 68k | AMIGASYSTEM | support.WinUAE | 0 | 29 July 2017 11:56 |
Aros Vision 68k on FS-UAE 2.6.2? | Samurai_Crow | support.FS-UAE | 0 | 09 June 2016 07:06 |
New Video of my Aros 68k distribution "Aros Vision" | OlafSch | Amiga scene | 26 | 16 February 2016 11:16 |
News about AROS 68k development? | Leandro Jardim | Coders. C/C++ | 80 | 29 November 2014 18:30 |
|
|