Lets actually try Hybrid Emulation

[SpacemanX]

Absolutely amazing progress! It's hard to fathom that you have got this working in such a short time.

To me Buffee looks similar to this approach on ground level. They are claiming close to 100x performance target to what is achieved here currently. I do understand that it's still very very early days, but it got me wondering what is the theoretical performance level achievable with de10-nano cpu/fpga combo?

[foft]

Question for people who know Amiga JIT options... Which is best to try:
Aranym uat_cpu: https://github.com/aranym/aranym/tree/m ... rc/uae_cpu
Emu68: https://github.com/michalsc/Emu68
TomB's Pandora uae4arm: https://github.com/PandTomB/uae4arm

None of them are as well documented as musashi, but I'll have a go at figuring out how to use them.

I'm thinking the last one is the best option, since the gp32/gp2x/openpandora devs were super at doing arm optimisation.
I remember this one was used a lot, though its interpreted iirc and only 68000.
https://github.com/notaz/cyclone68000

One complication in all this is that the hps-fpga bridge is little endian, at least in how it automatically handles misaligned accesses. If all the accesses are aligned then I could put big endian format through it to avoid the conversion arm side (fpga side is basically 'free').

[lordoftime79]

nice work. unfortunately even following your insturctions it wouldnt work for me, just got a blue and purple garbled screen.

[foft]

nice work. unfortunately even following your insturctions it wouldnt work for me, just got a blue and purple garbled screen.

Yeah you need to start it in the right order.
e.g. set to 8MB fast ram, reset on the core. THEN start the cpu process.

[foft]

Absolutely amazing progress! It's hard to fathom that you have got this working in such a short time.

To me Buffee looks similar to this approach on ground level. They are claiming close to 100x performance target to what is achieved here currently. I do understand that it's still very very early days, but it got me wondering what is the theoretical performance level achievable with de10-nano cpu/fpga combo?

Their work is open so we'll be able to use their pjit when its working. Actually I think they expect their approach to be slower than standard jit, just with fewer 'jitters'.

Not sure how the Buffee CPU compares to the ARM Cortex A9 @800MHz here.
Edit: Looked it up: Octavo OSD335x-SM with ARM Cortex A8 AM335x @ 1GHz.

Should be pretty comparable I'd have thought, the A9 has a shorter pipeline.

[SpacemanX]

...
Not sure how the Buffee CPU compares to the ARM9 @800MHz here.

800MHz Arm A8 vs A9, so DE10-Nano should be faster in that regard.

https://octavosystems.com/octavo_products/osd335x-sm/

[petarku]

@foft This is amazing work! Do you take any donations ? if you do how I can donate ?

[lordoftime79]

Finally got it working but I cant seem to get it to load hardrive images - I get a bus error?

[foft]

Finally got it working but I cant seem to get it to load hardrive images - I get a bus error?

Thanks, good to know. I'll try one out just need to work out how to make one.

[allyourbasekris]

Finally got it working but I cant seem to get it to load hardrive images - I get a bus error?

Thanks, good to know. I'll try one out just need to work out how to make one.

I've had HD images load with no issues. It was a 3.14 installation, stock.

[lordoftime79]

I tried a Coffin image and hst install thats from my CD32 both usually work on the minimig core.
I was able to boot from floppy to workbench but I dont have all the adfs so cant really test much more than that as all my stuff is on HDFS

[foft]

The bus error is 16-bit aligned 32-bit writes (at least the one I see)
Cortex a9 is supposed to support these.
https://developer.arm.com/documentation ... rt?lang=en
Perhaps this flag is set wrong.

[Bas]

Such progress so quickly, very interesting!! Thanks for your efforts.

[allyourbasekris]

If you try to enable RTG then you also get a bus error. I'm not really surprised it didn't work with it being very early days. Exciting times. thanks Foft for the effort you're putting in, it's much appreciated.

[foft]

I spent the evening trying to figure out how to use one of these JITs.

I tried the uae4arm one. It was non-obvious how to rip it out. Since it seemed to be based on aranym anyway I decided to go direct to that.

Onto aranym: I managed to cross compile the whole thing fine. Then I tried to find the CPU interface - and couldn't! So I decided to rip out everything bit by bit until I got to just the CPU. I got pretty much there but am not confident I managed to remove everything + its still not obvious how to plumb in the memory. It has funky custom SIGSEGV handling and memory offsets. So now I have something that might be pretty close to ... the raw 68k jit ... but not sure. It seems that aranym has really nice clean code, but then bits and pieces of custom stuff leaked into the cpu jit part. I've just signed up to their mailing list to see if one of their developers can give me a hand a ripping it out.

Which leaves Emu68. I checked it out from git and didn't really see how to use it standalone.

So... little bit stuck here. Hoping the aranym devs can help me out.

Help!

[foft]

Regarding bus errors: try this cpu.

It only fixed up 16-bit misaligned 32-bit writes, but that sorted a bunch of stuff.

[foft]

Another option for the cpu is qemu.

It has had 68k support for a few years now and ... has documentation and a load store and memory api.

Might give that a try.

Edit: another advantage of qemu: It also has powerpc support.

Edit2: https://stackoverflow.com/questions/370 ... emory-maps

edit3: + I can try a native 68k dhrystones on the existing machines first to see how fast it is

[robinsonb5]

edit3: + I can try a native 68k dhrystones on the existing machines first to see how fast it is

That would be a good idea. Also yet another option is Cyclone 68000 - https://notaz.gp2x.de/cyclone.php - apparently not JIT-based, but the Buffee blog described it as one of the fastest interpretive 68000 emulators. I think only covers the base 68000 instruction set though.

PPC is an interesting Pandora's Box to open, though. It's also occurred to me a number of times that with so many different ARM-based solutions appearing, some kind of PowerUP / WarpOS solution for running native ARM code from within AmigaOS would be very interesting, much like how Amiga PPC applications were handled back in the day.

[xolod79]

PPC will allow you to see the Amiga PPC demoscene, we already have RTG.

[foft]

m68k:
/media/fat# LD_LIBRARY_PATH=./libs/lib/arm-linux-gnueabihf/ ./libs/lib/ld-linux-armhf.so.3 ./qemu-m68k ./dhrystone_m68k -l 10
duration: 0 seconds
number of threads: 1
number of loops: 10000000
delay between starting threads: 0 seconds

Dhrystone(1.1) time for 10000000 passes = 19.0
This machine benchmarks at 526624 dhrystones/second
300 DMIPS

Total dhrystone run time: 19.020809 seconds.
---
ppc:
Run failed. Did not crash but results printed out are garbage.
Took 16 seconds.

---
arm (native):
/media/fat# ./dhrystone_arm -l 10
duration: 0 seconds
number of threads: 1
number of loops: 10000000
delay between starting threads: 0 seconds

Dhrystone(1.1) time for 10000000 passes = 2.3
This machine benchmarks at 4442697 dhrystones/second
2529 DMIPS

Total dhrystone run time: 2.252560 seconds.

[Bas]

Just ran a few quick tests and it works like a charm mostly. Feels like a reset leaves the CPU or some other components in a wonky state sometimes. Makes me curious as to what the reset menu item in the core actually does and to what extent it really resets the whole system and brings them back in line together.

[foft]

I have a new qemu m68k 'machine' that points to the chip ram (hps fpga bridge) and some fast ram. It has a single device that polls the irqs.

Will it work, won't it work. Lets try!

[foft]

Just ran a few quick tests and it works like a charm mostly. Feels like a reset leaves the CPU or some other components in a wonky state sometimes. Makes me curious as to what the reset menu item in the core actually does and to what extent it really resets the whole system and brings them back in line together.

Yeah I didn't tie reset of the 'software cpu' to the hardware reset yet. So currently need to stop the process, reset on the core, then start the process.

[robinsonb5]

Will it work, won't it work. Lets try!

Of course it will - have a little faith!

[foft]

Diagrom starts to boot with qemu, I don't believe it!

[foft]

Some problem with interrupts, I think I'm raising the right interrupt, but its not executed.

[foft]

OK, interrupts work.

Here is a binary if anyone wants to play. Its like the other one though (fixed 8MB fast, no reset plumbing etc) - except worse since only Diagrom runs

http://www.64kib.com/qemu_system_test.tar.xz

Extract in /media/fat then run ./qemu_system_test/go

Perhaps someone smart can run it in trace mode and see why it gets stuck on workbench?

[bbond007]

Regarding bus errors: try this cpu.

I was successful at running the following programs:

• Deluxe Paint 5

• Photon Paint 2.0

• Cloanto Personal Paint

• NewTek DigiPaint 3.0

• Brilliance

• Monkey Island 2

• GODs

And ShapeShifter Mac emulator worked too! I know that one is difficult for compatibility.

While testing, manually starting/restarting the CPU with SSH was slowing me down so I did this hack to main:

https://github.com/bbond007/Main_MiSTer ... 42a5d8cc8b

This will kill and start the 68000 CPU when reset is selected. You still must first (set RAM) and reset initially on cold boot.

68000.sh should go in your Minimig home dir - Typically /media/fat/Amiga unless using USB

68000.sh will look for musashi_68020_mister in /media/fat/Amiga, but this can be changed by editing the script.

MiSTer.zip

(582.5 KiB) Downloaded 154 times

This MiSTer (most likely) won't adversely effect other cores (including standard Minimig) if you cold boot after using it.

Remember to turn off FSynth or MUNT if enabled in the UART menu. Even sitting idle they will slow down your software CPU somewhat.

*** The core .rbf filename must contain "_Hybrid" for this hack to work. ***

Thanks for working on this project foft! This is very cool and unique.

[Neocaron]

Well I guess this is going way beyond the proof of concept now. Truly amazing work foft!

[foft]

Awesome, thanks for testing though and the MiSTer patch.

Its still a PoC, but it'll be a usable PoC once I get qemu working. I also got some help from TomB of uae4arm, so will try that one too.