Lets actually try Hybrid Emulation

[foft]

Late now, but have to try turning off the OS and disabling interrupts next. Then I guess changing background colour to see how long things take.

[foft]

I can't think I'm doing much to slow it down, but one thing springs to mind is how I handle interrupts. Updated with a ptimer in qemu that fires 50000 times/second and also on irq register writes. This may not be a root cause of this issue (still TBD) but I think I should update this to do it correctly in any case.

The plan:
i) Use f2h_irq bridge
ii) Write a kernel module that provides an ioctl to wait for an irq
iii) High priority user space thread that waits on this irq and calls set_irq in qemu when woken.

+ some notes:
// qemu_mutex_lock_iothread();
// mpc8xxx_gpio_set_irq(arg,mg->pin,mg->state);
// qemu_mutex_unlock_iothread();
// see:
// ../svn/Linux-Kernel_MiSTer/drivers/video/fbdev/MiSTer_fb.c
// also:
//../svn/Minimig-AGA_MiSTer/sys/sys_top.v
// wire [63:0] f2h_irq = {video_sync,HDMI_TX_VS};
// cyclonev_hps_interface_interrupts interrupts
// (
// .irq(f2h_irq)
// );
// if (ioctl(fb, FBIO_WAITFORVSYNC, &zero) == -1)

In the meantime going to also try to build my own rom from C which gives more flexiblity. + try diagrom without that interrupt polling, I think it works without.

[foft]

Turned off the 'device' that does the interrupts and stuff - raster test is near perfect now. So I think this is a good track.

[ByteMavericks]

That sounds promising: are you saying you were actively polling thousands of times for interrupts? I can see that being an issue!

[foft]

Well yeah, but what is 50000 times/second when you have 800000000 cycles? 16000 cycles/poll. That is like half a frame vs say 2-3 instructions in the 8-bit world that I'm used to.

Anyway I tried changing it to a thread that polls 5000 times/second and ... while the raster stuff looks better and it feels better it didn't fix the core perf issues. Still I'm going to implement this.

[foft]

OK, this has been an adventure.
Built uboot and kernel (only actually needed the kernel).
Updated kernel device tree to add the irqs.
Wrote a kernel module that has an ioctl to wait for irqs.
So far so good, lets try waiting for them now!

[allyourbasekris]

Just saw this project, It's a 68k emulator written for ARM that targets the amiga processors. I don't know how useful it would be. https://github.com/captain-amygdala/pistorm

[kolla]

Just saw this project, It's a 68k emulator written for ARM that targets the amiga processors. I don't know how useful it would be. https://github.com/captain-amygdala/pistorm

See earlier discussions here, any time you see “musashi” mentioned, it’s the pistorm emulator

[allyourbasekris]

Just saw this project, It's a 68k emulator written for ARM that targets the amiga processors. I don't know how useful it would be. https://github.com/captain-amygdala/pistorm

See earlier discussions here, any time you see “musashi” mentioned, it’s the pistorm emulator

Got ya, I wasn't sure if they were doing anything different in the project.

[ByteMavericks]

Interestingly the pistorm developer is reworking irqs as they’re causing some compatibility problems: is there a chance to team up on this as it sounds like a common challenge?

[foft]

IRQs are running better with the new kernel module.

Still performance is lower than I'd expect, but its getting there.

[ByteMavericks]

That’s good progress, and pretty incredible to get a kernel module up and working so quickly! Kudos

[Caldor]

That is impressive performance. Especially since it now has FPU enabled... and MMU?

[robinsonb5]

That's more like it! Congrats!

[foft]

I've been doing some more performance testing.

Some of the qemu api seems expensive.

Time for 1000000 dhrystones in (unoptimised code):
i) user mode: 11 seconds
ii) system mode: 30 seconds

So that (optimised) 400000 dhrystones/sec becomes 130000 dhrystones/sec due to overhead of using system mode.

[kolla]

I wanted to ask earlier, what is the reason for using system mode? Normallly, system mode is used for emulating a particular hardware configuration in addition to CPU, but is that really the case here?

Thinking a little more, I suppose it is - interfaces to the real hardware only exists in system-mode I guess

Btw - I am ready to try out the new stuff, I always build my own kernels for MiSTer anyways (to add IPv6 and various) so I can easily drop in another kernel module in the build

[foft]

System mode is a much better fit in general:
Define machine memory app
Add virtual peripherals to memory map (I use it for irq règ writes to react faster).
Simple irq support

I didn’t expect this magnitude of overhead though. I’m going to try tomorrow running the same test code in the maintainers simple virtual machine to see if it’s the same. If it is then I’ll have to dig deeper.

I do wonder though, could user mode work...

[foft]

I’ll post code/binaries tomorrow!

Probably this is enough performance for v1 now, I should focus on the main problems:
i) Crashes often on clicking icons!
ii) Crashes when I put in 68040.library

Any 68k gurus here?

[Fularu]

I’ll post code/binaries tomorrow!

Probably this is enough performance for v1 now, I should focus on the main problems:
i) Crashes often on clicking icons!
ii) Crashes when I put in 68040.library

Any 68k gurus here?

Never click on icons, problem solved!

Did you try with the 68060 library? afaik the 060 is just a refined, lower voltage version of the 040 (just like the 030 was to the 020)

[Caldor]

I experimented some more and managed to get it to run. I used the test7 files and the newest files BBond007 shared. I am able to consistently boot and I can run an old version of SysInfo which does show a 68040 CPU and it does seem to have FPU and MMU but "not in use". It is SysInfo 3.24. But when I try SysInfo 4.3 or 4.4 it seems to freeze and I cannot boot Workbench either, or maybe its just that its really really slow.

Its speed tests as about the 030 25Mhz in SysInfo 3.24, but with 4.3 and 4.4 not working it seems unstable. I have also not been able to boot Workbench, at least not any of the setups I have been running before. It seems to have some hard crashes now and then where I need powercycle the MiSTer. Not sure if its because I maybe have not used the correct memory configuration or something like that. I tried switching between 8MB and 384MB to see if it would make a difference. Both seemed to have the same issues though.

But I am happy I got it to be able to run at all and that its possible to use the uncompiled CPU cores. I suspect many of my problems might be solved by using the new 3.14 ROM.

[kolla]

Oh, use 68040.library from OS 3.1, it works

[foft]

For anyone who wants to try the current state 'as-is'...

OK, here is a new core and kernel module.
http://www.64kib.com/minimig_irq_core.tar.gz

After booting up you can install it using:
./minimig_module/setup
Then you can check /proc/interrupts and dmesg to check it is happy.

Next you need a new qemu:
http://www.64kib.com/qemu_system_testv8.tar.xz

Clicking on icons is crashy but you can run stuff from the cli!

[foft]

Thanks Kolla, with the old 68040 library it seems happier.

Grab it from here:
https://aminet.net/package/driver/other/040_060Libs
copy 68040old.library libs:68040.library

No crashes yet from clicking on icons! edit: spoke too soon... just rebooted and clicked on an icon -> boom

[hitm4n]

Amazing work going on here, enjoying dipping in each day to see progress... Keep the chat going, its cool to follow along, even if i don't understand most of it Keep it up guys.

[Jeruro]

It's awesome. I refresh this thread every day to see the progress. I'm going to try last version you posted. Thanks fort!

[NovaCoder]

Best 040 library to use will probably be the one from the OS 3.9 CD-ROM.

Alternatively you could try MMU.library

http://aminet.net/package/util/libs/MMULib.lha

060 CPU was very different to the 68040 so best not to use that library unless you are emulating an 68060.

Also be mindful that most 68060 libraries are designed for a specific accelerator card. Even some 68040 libraries were bundled with accelerators so may possibly contain some proprietary code.

MMU libs are generic but can be tricky to setup in workbench.

You can obviously use winaue to test that you have a working workbench set-up before switching over to the MiSTer.

[foft]

So, the user mode vs system mode qemu thing is the case with other qemu machines. So nothing to do with my homebrew one!

time ./run_m68k ./main_68k_elf
real 1m38.438s
user 1m38.294s
sys 0m0.064s

vs

@debian:~/test_hybrid_freestanding# time ./main_68k_elf
real 4m43.590s
user 4m30.640s
sys 0m0.230s

This matches what I see when I write my own amiga 'rom' that just runs the same program in fast ram.

[kolla]

Regarding the 68040 libraries, I think the problem with the mmulib ones are either the mmu, or perhaps that it tries to “fix” known issues with the real 68040s that aren’t necessarily there with a software emulated 68040…

[bbond007]

For anyone who wants to try the current state 'as-is'...

OK, here is a new core and kernel module.
http://www.64kib.com/minimig_irq_core.tar.gz

After booting up you can install it using:
./minimig_module/setup
Then you can check /proc/interrupts and dmesg to check it is happy.

Next you need a new qemu:
http://www.64kib.com/qemu_system_testv8.tar.xz

Clicking on icons is crashy but you can run stuff from the cli!

Thanks!

I was able to run a demo targeted for AGA/060+

Very cool that it ran at all but underwhelming framerate wise. SysInfo lies

OceanMachine.png (2.17 MiB) Viewed 8738 times

http://www.pouet.net/prod.php?which=16337

Updated my script to load the kernel module:

68000.zip

(583.07 KiB) Downloaded 210 times

[kolla]

Can’t expect too much when emulating full 040 with MMU and (hence) no JIT