Lets actually try Hybrid Emulation

[foft]

Did you put stackattack and the patched allocp in the startup sequence? For disk games not sure how we can do that. Perhaps a patched rom will be needed.

I always faster in sysinfo, perhaps a version.

Yes workbench and boot is slow. Not sure if it is the memory use patterns or something else…

ADoom has 2x fps of 020.

[foft]

I’ll post docs on the kernel interface and memory map. So that any other software dev can try porting emu68 and anarym. The _interfaces_ for those are not well designed (in my opinion!) so they need a dev with experience of those code bases - or at least more patience than me:)

[foft]

I mean look how simple this is to use:
https://github.com/kstenerud/Musashi
Qemu is much more complex but at least has docs:
https://qemu.readthedocs.io/en/latest/devel/index.html

[foft]

Tidying up a bit...

Put these onto my github:
https://github.com/scrameta/MiSTer_Hybrid_Support (release scripts and binaries)
https://github.com/scrameta/Minimig-AGA_MiSTer_Hybrid (core)
https://github.com/scrameta/Main_MiSTer_Hybrid (modifications to start hybrid emulation)
https://github.com/scrameta/qemu_MiSTer_Hybrid
https://github.com/scrameta/Musashi_MiSTer_Hybrid
https://github.com/scrameta/MiSTer_Hybrid_Kernel_Module

[ron]

Thanks very much for you effort and investigations.

I'm not able to launch the emulation... I got segmentation faults with both emus, any clue will be appreciated.
However, with last year's tests they did work for me, both the hybrid core and the emulators.
The kernel message totally throws me off.

This is my uname output: Linux MiSTer 5.15.1-MiSTer #1 SMP Fri Nov 12 21:05:10 CST 2021 armv7l GNU/Linux


With qemu:

Code: Select all

/media/fat/Minimig_Hybrid# ./start
pid 822's current affinity mask: 3
pid 822's new affinity mask: 1
Kernel module already installed
qemu ram size:10485760 KB
Segmentation fault

And with Musashi:

Code: Select all

/media/fat/Minimig_Hybrid# ./start_musashi
pid 842's current affinity mask: 3
pid 842's new affinity mask: 1
Kernel module already installed
0xb5ef4000:0xff0fffff:0xb6f0f000:0xffffffff:0xb56f4000
Segmentation fault

Thanks a lot. Regards

[foft]

The core needs to be started before starting the emulation. Normally it runs 'start' for you. Are you running it directly from the menu like normal?

[Caldor]

Did you put stackattack and the patched allocp in the startup sequence? For disk games not sure how we can do that. Perhaps a patched rom will be needed.

I always faster in sysinfo, perhaps a version.

Yes workbench and boot is slow. Not sure if it is the memory use patterns or something else…

ADoom has 2x fps of 020.

Strange... I added it all to the user-startup, and I also added the the MiSTer share drive setup to it and that part worked. Maybe I need to add it earlier? I just added them as if they were executables, I did not add any parameters or anything. As I wrote, I use KS 3.1 and WB 3.1. I even installed it all using the 68ARM CPU.

Maybe a patched rom would be a good solution. I already have a 1MB version of the 3.2 ROM. Which also works with this core btw. I guess stackattack is supposed to be early in the startup sequence? Come to think of it, it helps loads stuff into fast ram or something like that? I am pretty sure the problem is me not using it correctly.

[ron]

The core needs to be started before starting the emulation. Normally it runs 'start' for you. Are you running it like that?

Yes, from ssh I try to launch the emulators first, but emus don't work, I get a Segmentation Fault. The core loads but without emulation nothing to do.

[foft]

The core needs to be started before starting the emulation. Normally it runs 'start' for you. Are you running it like that?

Yes, from ssh I try to launch the emulators first, but emus don't work, I get a Segmentation Fault. The core loads but without emulation nothing to do.

Are you using the 20220114 version of the tar?

[ron]

OK recreated all again. Reboot and !

Code: Select all

/media/fat/Minimig_Hybrid# ./start
pid 764's current affinity mask: 3
pid 764's new affinity mask: 1
/media/fat/Minimig_Hybrid/kernel_patch/minimig.dts:9.11-37: Warning (interrupts_property): /fragment@0/__overlay__/minimig_irq:interrupt-parent: Bad phandle
qemu ram size:10485760 KB

it seems to begin working... let me test some more... i'll keep you informed.

[ron]

Okay fellows, seems to work
Qemu now works but I lost HDMI video. I 'll keep testing a bit more.
Thx

Edit : qemu now working with video OK !

[Caldor]

ADoom has 2x fps of 020.

What is the 2x fps btw? By the 020 you mean the MiSTers 020 CPU right? It ought to get an fps of about 7-10 I think. So with the QEMU 020 it should get 10-20?

I have tried editting my startup sequence. I moved stackattack_020 and allocP into startup-sequence and removed them from user-startup. Same with "mount share:".

It is using quite a bit of chip-ram. Its been a while since I edited Amiga startup sequences, but I Am pretty sure I should be able to make it all only use fast-ram instead of chip-ram. I am down to about 700-800k of RAM after the boot, but now at least Workbench is a bit faster. The SysInfo tests are the same though. SysInfo 4.4 shows a higher score than 4.3, and I think the version 3 I have of SysInfo shows a lower score than both the v4 ones.

My startup-sequence now starts with:
C:SetPatch QUIET
C:StackAttack_020
C:AllocP
C:Version >NIL:
C:AddBuffers >NIL: DF0: 15
FailAt 21

and then a bunch more stuff. I will try to add -2000 to StackAttack_020. Not sure it does anything.

I have begun using my 1MB AmigaOS 3.2 ROM. It helps the icons be nicer and I think it might help support the FPU better.

I got Quake 1 to run. Its a slideshow, but I think it proves that FPU is working:

image_2022-01-15_144413.png (577.79 KiB) Viewed 8698 times

[foft]

Yes about 20fps on doom vs 10fps on tg68k. Not as much as I'd expect, probably some bottlenecks remain.

With stackattack and the memory patch you should see ~150-200k dhrystones if you run the app I included. Its the real thing, unlike sysinfo.

I wonder if the quake memory layout suffers from the sharing code and data stuff somehow else. Or if it has another bottleneck. The FPU in sysinfo benchmarks much slower than the 060 one, not sure why it is so slow.

I used stackattack with 'auto'. With allocP the memory usage is higher since I round up to get 4k aligned pages, if asking for 256 bytes you get 8k! Pretty stupid initial implementation. I'll make better versions of both of these at some point...

[Caldor]

Yes about 20fps on doom vs 10fps on tg68k. Not as much as I'd expect, probably some bottlenecks remain.

With stackattack and the memory patch you should see ~150-200k dhrystones if you run the app I included. Its the real thing, unlike sysinfo.

I wonder if the quake memory layout suffers from the sharing code and data stuff somehow else. Or if it has another bottleneck. The FPU in sysinfo benchmarks much slower than the 060 one, not sure why it is so slow.

I used stackattack with 'auto'. With allocP the memory usage is higher since I round up to get 4k aligned pages, if asking for 256 bytes you get 8k! Pretty stupid initial implementation. I'll make better versions of both of these at some point...

Could you share your lines where you load stackattack and AllocP? I keep getting the same score in SysInfo and with the dhrystone_amiga app:

image_2022-01-15_151931.png (95.61 KiB) Viewed 8682 times

Well, it varies a little, but it is usually 45-47mips,43k dhrystones and around 12 mflops in SysInfo 4.4. SysInfo might not be measuring it correctly, but it does seem pretty consistent as long as you use the same version every time. So far it has not made any difference for me whether I have included stackattack and allocp in the boot sequence or not.

If you add stackattack_020 without any arguments, will it be the same as auto? Does AllocP need any arguments? I moved AllocP up to before SetPatch, but it does not seem to have made any difference. I do have 1.8mb chip ram free now though.

By the way, I suspect the CHIP RAM is slower because of the emulation. This is one of the issues PiStorm still has, that the connection to the chip-ram is slow because of how the Pi emulates the CPU and other stuff, and the CHIP RAM needs pretty fast and low latency access to the CPU... or some other chips, not sure. But its a problem there as well. I do think Workbench seems faster with AllocP and StackAttack added early in the boot though. Not as fast as with the MiSTer CPU, but much better at least.

As for the FPU, the FPU being emulated is supposed to be much slower than the 060 FPU I think. That is one of the advantages of the 060 FPU.

[Caldor]

I have been trying different startup sequences, kickroms, Amiga chipsets and combinations of these, and the result does not seem to change much.

So I am thinking, this does use the ARM CPU on the MiSTer and whatever configuration we are running on the MiSTer might affect the cores performance? I am running a setup that uses the analog IO board and its VGA out. I think my MiSTer is set to run a resolution of 1280x1024 and I am guessing it also might matter what other settings are set.

If its not that, I am out of ideas as to why there are 3 setups with 3 different benchmark results. I am getting 47k, someone earlier in the thread got 50k+ and foft must be getting more than 60k I am guessing if he did the SysInfo 4.4 benchmark.

I think I will try experimenting with the settings a bit and see if it might affect performance.

[foft]

I added some developer docs here.
https://github.com/scrameta/Minimig-AGA ... doc/hybrid. ***** Emu 68 and ARAnyM devs read this please and help us ***

While 125000 is low, its better than the 4000 I was getting without these patches! Perhaps its related to a different memory layout of a different amiga os?

Why do you think chip ram is slow? I don't see that on the benchmarks. Enabling the cache seems to turn on the fast path for aga too. I see 5x speed on sysinfo the chipram and good results on bustest and ssspeed. I do see the gui as slower but am not sure why. I think its more likely interrupt latency but, as always, I might be completely wrong.

I'll post my startup-sequence later, but I just popped them at the top, with no options. Then for some reason I have a second stackattack AUTO before LoadWB? Probably a mistake.

[foft]

I guess memory access from the scalar could impact fast ram latency. Early in the thread I had 70k+ "dhrystones" in sysinfo, not sure how! Now I get 53K consistently I think.

[Caldor]

I thought you said the chip ram was slow? I am not sure if it really is.

125000 is good, but when running Doom f.ex. I do not see any performance difference even though the benchmark scores show this CPU as much faster. If you score 53k now consistently I guess I am not that far from your performance anyway. But I am getting 47k whether I am using Stackattack and allocP or not. I have been trying out different MiSTer setups and I have so far not found any settings that impact the score I am getting.

I do guess it might be about what type of SD RAM we have and also I am using a special USB hub that might make a difference. I think I have USB Polling set to high which could also do something I guess.

[foft]

Oh I might have said that last week. I had the cache turned off by accident and it took me a while to realise.

For Doom I used ADoom with -fps. I’m using rtg otherwise it’s probably chip ram bound anyway.

[foft]

I think sdram timings are fixed for all boards. Fast ram is ddr3, ie on the de10 nano itself.

USB polling: could be I guess. It’s also possible I posted the wrong version of the stack and alloc patches. I’ll check.

[foft]

OK, dhrystones drop with rtg on. From 160->130k on mine (pal highres vs 1280x720x8). Depends on the mode of course, if you have higher bpp might be more.

As for app versions, they match what I included:
01e9f684ff929a186af52bf888023087 allocp < from c:
bd16359c630b07356c669e5ac1e83b95 stackattack < from c:
bd16359c630b07356c669e5ac1e83b95 ../StackAttack_020 < in tar
01e9f684ff929a186af52bf888023087 ../Alloc32P/AllocP < in tar

Attached my startup sequence, but I don't really do anything special with them.

[Caldor]

So I should be using the same versions of AllocP and StackAttack.

Best score I have gotten so far with Dhrystone_Amiga -l 1 is now 142857. I used kickrom 3.1 that time.

But it is not consistent and I have tried booting with no startup sequence, and manually running allocp and stackattack, but dhrystone_Amiga seems to crash or fail. It starts running and then does nothing. I figured there must be something in the start sequence it was missing, so I also manually ran setpatch and version but still the same problem. Seems it just wont run from the shell.

I guess I will try USB polling.

Other strange issues, is that when running Directory Opus 5, I can run it fine from the share: MiSTer drive, but copying it to a hard disk, it fails to run and crashes the system. I formattet a 200MB HDF with the WB 3.1 install disks. Default file system and such.

I noticed you have stackattack twice in your startup sequence, the first time with no argument and the second time with the AUTO argument. Might that do anything?

[Caldor]

It worked... something worked. I changed several settings and now I am getting this benchmark with more than 50k dhrystones. For some reason the Chip speed at the bottom now only says 1.06, but MFlops is also a bit higher. Also its now 52.48 Mips instead of 47.

But it does mean that the MiSTer settings impact the performance of this. Some of the things I changed was to disable VGA... something. I disabled high speed USB polling, the resolution for the MiSTer in general is lowered to 640x480.

[foft]

Great:-) Turn on data cache and you'll be the same pretty much but with 5x chip speed.

I'm going to have another bash at stripping down aranym to just the jit. 3rd time lucky:-) Wish me luck!

[NinjaWarrior]

It worked... something worked. I changed several settings and now I am getting this benchmark with more than 50k dhrystones. For some reason the Chip speed at the bottom now only says 1.06, but MFlops is also a bit higher. Also its now 52.48 Mips instead of 47.

You can check my captures in the previous page, I get 54 mips and 52k dhrystones without touching any Mister setting (I have a IO Board, VGA enable, 1080p resolution, polling as standard, 128 Mb SDRAM 4 chips). Seems there is something that makes the numbers fluctuate, but I get around 54 Mips quite steady.

[NinjaWarrior]

I'm going to have another bash at stripping down aranym to just the jit. 3rd time lucky:-) Wish me luck!

Good luck! I hope Emu68 dev joins in!

[Caldor]

It worked... something worked. I changed several settings and now I am getting this benchmark with more than 50k dhrystones. For some reason the Chip speed at the bottom now only says 1.06, but MFlops is also a bit higher. Also its now 52.48 Mips instead of 47.

You can check my captures in the previous page, I get 54 mips and 52k dhrystones without touching any Mister setting (I have a IO Board, VGA enable, 1080p resolution, polling as standard, 128 Mb SDRAM 4 chips). Seems there is something that makes the numbers fluctuate, but I get around 54 Mips quite steady.

Well, I am thinking that is because your standard setting was standard polling instead of high polling. I usually enable high polling. The numbers do fluctuate, but before I changed the settings I think the highest dhrystones I got was 48k and mips was 48.

Hard to know which of the settings take the most ressources, but it seems like the high frequency USB polling is a bit CPU heavy.

[Caldor]

Great:-) Turn on data cache and you'll be the same pretty much but with 5x chip speed.

I'm going to have another bash at stripping down aranym to just the jit. 3rd time lucky:-) Wish me luck!

That would be very nice But yeah, if we could get Emu68 running on the MiSTer, then that is probably the best bet. Its designed to run on the Pi and its ARM, which I am not sure if its the same type of ARM as the MiSTer. I know they are not exactly the same, but there are different types where the architecture might be very different instead of just variations of the same.

I had d-cache disabled and I am pretty sure that will increase the speed. Doom was running a bit better. I will try to see what happens.

[Solskogen]

Emu68 runs on the Pi bare-metal, so not much help there I'm afraid.

[foft]

So I forked aranym and stripped out almost all the Falcon hardware. I need to figure out their memory access system now and strip out the Falcon memory layout, so I can provide my own. Then figure out the interrupts.

Seems there is some helpful description here, so I'd better dig through that...
https://raw.githubusercontent.com/scram ... hguide.txt