Best 68040 emulator

[jotd]

Hi,

I've got a long shot project planned. My requirements:

- I want to run some 68040 code on a windows machine
- I don't care for any custom stuff (blitter, copper...), it's not amiga code
- The emulation solution must be open-source
- I must be able to install some "hooks" on traps/illegal/PC=such or such address to call "native" windows functions

Any serious candidate?

thanks

[Locutus]

there is QEMU 68k support nowadays, it wont do calling to windows stuff out of the box but its opensource and the closest to your feature request box you are going to find.

Check:

https://github.com/vivier/qemu-m68k

and https://wiki.debian.org/M68k/sbuildQEMU

I cant tell you exactly how accurate it is yet, but ive not run into any problems with gcc compiled code (including recompiling gcc itself).

Also, its quite a bit faster then WinUAE/Aranym :-)

[Toni Wilen]

Does "68040" mean = "68020 + added 68040 instructions" or full 68040 including MMU and FPU and all?

UAE (or QEMU) probably is far too complex if simple 68020 (+some extra instructions) is all you need.

[Locutus]

QEMU has a Usermode target for that though, which greatly cuts down on complexity. I'm not sure what other 68k emulator you would use otherwise.

[jotd]

Qemu is the one! I ll probably need fpu. Thanks guys!

Edit: QEMU usermode sounds interesting but it needs linux...

Well if address spaces are compatible, I'd like to try playing with WinUAE:

- boot without startup sequence with a lot of memory i.e. the widest addressing space possible
- load the chunk in memory with allocabs() if possible or a memcpy (with a resident program like whdload in case the memory zone destroys the OS)
- zero VBR, SR... and start the proggy

The part I'm puzzled about is how to plug some "native" events: ex: I reach a given PC or zone: winuae calls some of my code/scripts (like python, C??). That would allow me to connect my program to the outside world (windows)
I'm sure it is possible with WinUAE right?

[meynaf]

Originally Posted by jotd

Edit: QEMU usermode sounds interesting but it needs linux...

I'd like to play with some cpu emulation as well, like trying to add new instructions in the cpu, and call some kind of "native" features.
It seems QEMU won't do it with a windows compiler...

Originally Posted by jotd

Well if address spaces are compatible, I'd like to try playing with WinUAE:

- boot without startup sequence with a lot of memory i.e. the widest addressing space possible

Just configure the mem in winuae's settings and you're done.
You can get 1.5GB of Z3 fastmem

However you won't have a direct access to the host's address space.

Originally Posted by jotd

- load the chunk in memory with allocabs() if possible or a memcpy (with a resident program like whdload in case the memory zone destroys the OS)
- zero VBR, SR... and start the proggy

If you don't need any OS on the Amiga side, perhaps you can just replace the Amiga ROM by other code.

Originally Posted by jotd

The part I'm puzzled about is how to plug some "native" events: ex: I reach a given PC or zone: winuae calls some of my code/scripts (like python, C??). That would allow me to connect my program to the outside world (windows)
I'm sure it is possible with WinUAE right?

From what i've read WinUae has the ability to call native x86 code.
But i don't know how to do that.

Hacking winuae is possible as well, because sources are available... even though it's far from being easy.

[Photon]

Where relevant:

I optimize for the worst case (68000) and use 68020+ instructions only when needed for performance on 68020+, but I can see that fallback compatibility is more important to me and I'm a bit extreme in the way that I only really care about 68000 and 68060.

But it's good advice to avoid if you can instructions removed in the 68060 (which IMO is even better designed than the very nice 68040!), and also to not rely on Copyback Cache features. While both these helped with performance, they're also the reason for software requiring patches. If a CPU emulator or compiler has a 68060 mode (is there one??), do use it and it might warn you so you can avoid it.

[jotd]

reviving an old thread.

I've finally use Basilisk (using winuae core) but now we're stuck because it's GPL so we cannot use it in our commercial product (yes, I'm working on a 680x0 related thing at my job )

I've checked musashi which is completely non GPL but also completely 68020 max

Any other ideas?

[Hewitson]

Originally Posted by jotd

I've checked musashi which is completely non GPL but also completely 68020 max

Originally Posted by https://github.com/kstenerud/Musashi

Musashi is a Motorola 68000, 68010, 68EC020, 68020 and 68040 emulator written in C. This emulator was written with two goals in mind: portability and speed.

But I see what you mean, 68040 can not be selected.

[Cyprian]

what about ARAnyM https://aranym.github.io/
It offers emulation - CPU: 68040 with MMU and FPU 68882

[britelite]

Originally Posted by Cyprian

what about ARAnyM https://aranym.github.io/
It offers emulation - CPU: 68040 with MMU and FPU 68882

It's also GPL, so that's a no-go

[jotd]

I don't need MMU. 'Just' the 040 instructions and FPU. Adding 040 support to Musashi would be the best option.

And if there's a non-GPL 680x0-binary software which is able to emulate 040 instructions by software on a 68020 that could work too. Speed isn't too much of an issue, we can use fast machines to emulate that, we're a company

[Toni Wilen]

If not including MMU, 68040 in instruction level has very few new instructions: MOVE16 and cache instructions (CINVx, CPUSHx). CACR bits have changed. Cache instruction can be ignored unless you need to run some kind of OS or program that uses CACR bits to detect CPU model.

FPU is also almost same except D and S (FDADD, FSADD etc) instruction variants are new and not supported by 68881/68882. (But 6888x emulation may still support them)

Both should be relatively easy to implement in existing 68020/030 + 6888x emulation.

[jotd]

Thanks Toni. I don't need cache instructions either or CACR. Actually I'm emulating an application. It's running in supervisor mode (I know it sucks!) but not as an operating system (it handles some traps, peeks into the VBR to get some OS vector (dirty, I have stubbed that), so it seems that I can start from musashi 020. At least 95% of the instructions are correct. And the ones that aren't, I can compare in/out with UAE core.

Actually it's the fact that I have plugged one of our proprietary OS (simulated) that renders the whole GPL thing impossible since I'm not allowed to disclose the source for the simulated proprietary OS. Joys of open source.

Now I have to provide an estimate and I'll have to code that IN MY OFFICE TIME oh dear… At least we won't be needing to provide the source of the thing. I'm regaining hope, and the project managers will be pleased because they don't like GPL too much.

[hooverphonique]

Can't you package the emulator and the proprietary OS separately to get around the GPL thing? I mean, if you only need minor mods on the emulator (which hardly would be worth protecting as your IP if they're just a few 68040 add-ons), then implement those and contribute them back to the community...

[jotd]

> if you only need minor mods on the emulator

that's not minor mods. that's plugging the emulator on our custom OS API & removing everything but the CPU emulation We had a talk with legal dep and we can't. And I can't disagree with that.

Of course I didn't mind provide the source of the modified thing, but that's not enough.

[jotd]

problem solved: switched from UAE/Basilisk core to musashi.

After *ahem* a few changes, the code is running properly. I've "forked" musashi on my repo with my changes, hoping that they'll make into the official repo.

https://github.com/jotd666/musashi040

I found issues with CHK2/CMP2 instructions & TRAP16/32 stackframes manually/implemented some missing FPU instructions & modes.

Then, since it wasn't running properly, I recorded a complex computation done with Basilisk core and musashi core on the same program and compared the FPU regs & PC, fixed the remaining FPU instructions errors, until it matched 100%

Who has time for this? Well, me, at work, with my bosses telling me to do it

[dirkwhoffmann]

Hi Jotd. I'm excited to read that you've build a test program which runs Musashi against Basilisk. I am doing exactly the same thing with Moira (which is the CPU powering vAmiga). What I did is to implement a "tesrunner" that iterates over all opcodes and executes them with random register and memory values both with Moira and Musashi. In runs in an endless loop until a mismatch is found. Is your testing code (Basilisk vs. Musashi) available in some public repo? If so, I could probably add Basilisk as another "reference core" to the Moira test runner without having to dig too deep into the Basilisk / UAE sources. Running all three cores against each other might reveal some more bugs in Musashi (and my own CPU).

[bebbo]

I also added some fixes to the fpu: https://github.com/bebbo/Musashi
And there is no pull request, since previous pull requests did not work out^^

EDIT: there maybe even more fixes in the musashi of my amitools fork: https://github.com/bebbo/amitools. With these changes the gcc execute testsuite runs successfully with vamos.

[dirkwhoffmann]

Beppo, thanks for sharing the updated Musashi core. I'll merge those changes into my local version of Musashi. My own CPU is not able to do any FPU stuff at the moment, but I plan to add those capabilities in the future. Having a reliable reference implementation is invaluable for this task.