It's certainly true that 8000 000B exception is caused a fault with FPU-related opcodes, but it's often the result of the program counter ending up somewhere it shouldn't, and the machine trying to executing data as if it were code. So it can indicate a math / cpu library problem but it can also indicate memory corruption or a cache issue.
Lets actually try Hybrid Emulation
-
- Posts: 129
- Joined: Fri Jun 19, 2020 8:54 pm
- Has thanked: 13 times
- Been thanked: 57 times
Re: Lets actually try Hybrid Emulation
Re: Lets actually try Hybrid Emulation
So seems I can trace memory accesses using:
memory_region_ops_read, memory_region_ops_write
There is also a handy patch that
https://patchew.org/QEMU/20210307074833 ... amsat.org/
So we can trace the entire instruction sequence executed, the memory accesses and the registers. It must be possible to figure this out with all this, though it feels like finding a needle in a haystack.
Actually I couldn't reproduce with the register dump on...
BTW if you switch on this tracing be aware that its glacial if it doesn't go to /tmp/. Also they can be switched on at runtime in the monitor, so we can enable them after the boot up before running a test.
memory_region_ops_read, memory_region_ops_write
There is also a handy patch that
https://patchew.org/QEMU/20210307074833 ... amsat.org/
So we can trace the entire instruction sequence executed, the memory accesses and the registers. It must be possible to figure this out with all this, though it feels like finding a needle in a haystack.
Actually I couldn't reproduce with the register dump on...
BTW if you switch on this tracing be aware that its glacial if it doesn't go to /tmp/. Also they can be switched on at runtime in the monitor, so we can enable them after the boot up before running a test.
Re: Lets actually try Hybrid Emulation
i.e. enable like this...
& in the go script use -D /tmp/qemu.log
/media/fat# ./qemu_system_test/go
Init interrupt polling thread (requires kernel module):0xb4c1e000
QEMU 5.2.93 monitor - type 'help' for more information
(qemu) log in_asm,out_asm,exec,nochain
(qemu) trace-event memory_region_ops_read on
(qemu) trace-event memory_region_ops_write on
(qemu) trace-event memory_region_ram_device_read on
(qemu) trace-event memory_region_ram_device_write on
Can also log 'cpu' to get all the registers and 'int' to get all interrupts. I didn't manage to reproduce with 'cpu' on!
edit: memory_region_ram_device* doesn't seem to work,. though memory_* is good...
& in the go script use -D /tmp/qemu.log
/media/fat# ./qemu_system_test/go
Init interrupt polling thread (requires kernel module):0xb4c1e000
QEMU 5.2.93 monitor - type 'help' for more information
(qemu) log in_asm,out_asm,exec,nochain
(qemu) trace-event memory_region_ops_read on
(qemu) trace-event memory_region_ops_write on
(qemu) trace-event memory_region_ram_device_read on
(qemu) trace-event memory_region_ram_device_write on
Can also log 'cpu' to get all the registers and 'int' to get all interrupts. I didn't manage to reproduce with 'cpu' on!
edit: memory_region_ram_device* doesn't seem to work,. though memory_* is good...
Re: Lets actually try Hybrid Emulation
I see it double clicking on the drive icons (ram:, system: etc) on the workbench desktop mostly and sometimes in windows too. Miscellaneous guru.kolla wrote: ↑Mon May 10, 2021 6:54 am @foft
What kind of crashes do you see? Freeze? System failure with red alert? If so, what error code? All kinds of icons?
I ask since I don't really see such crashes myself.
EdIt: ah, ok, I see... so it happens when double clicking, regardless of where the pointer is?
Only thing I see here is that the mouse pointer is somewhat jerky and lagging.
I don't see a jerky mouse pointer though, except when I run at high trace levels.
Re: Lets actually try Hybrid Emulation
I have set up 3.1.4(.1) and using 68040.library from OS 3.1 (for some reason, 68040.library (44.2) from OS 3.9 doesn’t load) and I don’t have any issues with clicking or double clicking.
-
- Top Contributor
- Posts: 522
- Joined: Tue May 26, 2020 5:06 am
- Has thanked: 86 times
- Been thanked: 204 times
Re: Lets actually try Hybrid Emulation
I'm also using WB 3.1.4 and custom 3.1.4 ROM with https://aminet.net/package/driver/media/AtapiMagic
The library I tried was 68040old.library from https://aminet.net/package/driver/other/040_060Libs
Not having any issue with clicking or double clicking either with qemu and the kernel module, in fact it seemed fairly stable...
Re: Lets actually try Hybrid Emulation
I make something and it works for everyone but me!
I tried the same drive image with 68040 on FS-UAE. It runs fine, no crashes. So does seem core related, or my DE10 related.
I tried the same drive image with 68040 on FS-UAE. It runs fine, no crashes. So does seem core related, or my DE10 related.
-
- Top Contributor
- Posts: 522
- Joined: Tue May 26, 2020 5:06 am
- Has thanked: 86 times
- Been thanked: 204 times
Re: Lets actually try Hybrid Emulation
Here is a new 68000.zip for anyone interested.
The script is the same but I've updated MiSTer to include the latest changes which includes a reorganization to the Minimig OSD.
The script is the same but I've updated MiSTer to include the latest changes which includes a reorganization to the Minimig OSD.
Does whdload work for you?
Re: Lets actually try Hybrid Emulation
Its a bit big to share, so I'll cut it down first.
Its really just a vanilla 3.1.4 rom and 3.1.4.1 workbench install. The only changes were that I copied 68040old.library into libs:68040.library and now I installed this Peter K icon_68020.library into libs:icon.library.
- Caldor
- Top Contributor
- Posts: 930
- Joined: Sat Jul 25, 2020 11:20 am
- Has thanked: 112 times
- Been thanked: 111 times
Re: Lets actually try Hybrid Emulation
Maybe someone should share one of their Workbench HDF files to have a comparison here? Probably not on this forum directly, but testing whether this is a hardware issue, will require that we have the exact same settings and software setups.
Re: Lets actually try Hybrid Emulation
This is the image I'm using. It is basically vanilla except:
i) mister shared filesystem (mount share:)
ii) Peter K's icon library from Aminet
iii) 68040.library from the phase V Aminet link posted (68040old.library as 68040.library)
http://www.64kib.com/HDDSmallTestOnly.hdf.gz
Its just a 10MB image but compressed down to a couple of MB. I'm running minimig in AGA mode with 2MB chip and 384MB fast. I'm using the 3.1.4 A1200 rom.
Definitely crashes with qemu when I double click icons. I double clicked WB2: then closed that and double clicked RAM: -> boom. Though it varies how many double clicks I can do, sometimes first time, sometimes 10-20.
i) mister shared filesystem (mount share:)
ii) Peter K's icon library from Aminet
iii) 68040.library from the phase V Aminet link posted (68040old.library as 68040.library)
http://www.64kib.com/HDDSmallTestOnly.hdf.gz
Its just a 10MB image but compressed down to a couple of MB. I'm running minimig in AGA mode with 2MB chip and 384MB fast. I'm using the 3.1.4 A1200 rom.
Definitely crashes with qemu when I double click icons. I double clicked WB2: then closed that and double clicked RAM: -> boom. Though it varies how many double clicks I can do, sometimes first time, sometimes 10-20.
Re: Lets actually try Hybrid Emulation
Finally some progress on the icon double click crash issue.
Seems to be due to something like this:
i) IRQ processing starts
ii) cpu writes to disable irqs, immediately after I poll the irq line
iii) cpu writes to enable irqs, immediately after I poll the irq line
iv) RTE
Usually at step (ii) I read IPL2:0 of 15 -> i.e.no IRQ
Sometimes at step (iii) I read IPL2:0 of 12 -> this is when it blows up
I wonder if this is related to immediately polling the irq status and perhaps the minimig logic has not yet cancelled it due to some timing details.
I made a change:
i) ioctl irq -> always handle
ii) hardware write it irq regs -> only handle disable
Which leads to no crashes...
Seems to be due to something like this:
i) IRQ processing starts
ii) cpu writes to disable irqs, immediately after I poll the irq line
iii) cpu writes to enable irqs, immediately after I poll the irq line
iv) RTE
Usually at step (ii) I read IPL2:0 of 15 -> i.e.no IRQ
Sometimes at step (iii) I read IPL2:0 of 12 -> this is when it blows up
I wonder if this is related to immediately polling the irq status and perhaps the minimig logic has not yet cancelled it due to some timing details.
I made a change:
i) ioctl irq -> always handle
ii) hardware write it irq regs -> only handle disable
Which leads to no crashes...
Re: Lets actually try Hybrid Emulation
Onto the next question... performance.
In musashi this program takes 1 minute 50 seconds.
In qemu 'mister' this program takes > 6 minutes (I gave up timing but I tested it finished before probably about 10 mins)
From linux m68k qemu it takes <2 seconds.
/media/fat# ./run_m68k ./dhrystone_m68k -l 1
duration: 0 seconds
number of threads: 1
number of loops: 1000000
delay between starting threads: 0 seconds
Dhrystone(1.1) time for 1000000 passes = 1.8
This machine benchmarks at 550149 dhrystones/second
313 DMIPS
Total dhrystone run time: 1.854414 seconds.
...
So why?
I though perhaps its spending a lot of time accessing chip memory instead of fast memory. I instrument musashi to show the % fast/chip. >99% fast ram in the loop of running this.
In musashi this program takes 1 minute 50 seconds.
In qemu 'mister' this program takes > 6 minutes (I gave up timing but I tested it finished before probably about 10 mins)
From linux m68k qemu it takes <2 seconds.
/media/fat# ./run_m68k ./dhrystone_m68k -l 1
duration: 0 seconds
number of threads: 1
number of loops: 1000000
delay between starting threads: 0 seconds
Dhrystone(1.1) time for 1000000 passes = 1.8
This machine benchmarks at 550149 dhrystones/second
313 DMIPS
Total dhrystone run time: 1.854414 seconds.
...
So why?
I though perhaps its spending a lot of time accessing chip memory instead of fast memory. I instrument musashi to show the % fast/chip. >99% fast ram in the loop of running this.
-
- Posts: 129
- Joined: Fri Jun 19, 2020 8:54 pm
- Has thanked: 13 times
- Been thanked: 57 times
Re: Lets actually try Hybrid Emulation
I think I might have asked this before, but what about ROM functions? Would your calcs show accesses in the E0/F8 ranges as Fast or Chip?
Re: Lets actually try Hybrid Emulation
I copied rom into fast ram, so that doesn't go over the bridge.
But 0xe0 isn't rom is it? ... checks memory map, hmmm perhaps I should put that first 512k here too.
int rom_bytes = 1*1024*1024;
void * rom_addr_orig = mmap(NULL,rom_bytes,(PROT_READ|PROT_WRITE),MAP_SHARED,fdcached,hpsbridgeaddr+0xf00000);
void * rom_addr_fast = malloc(rom_bytes);
for (int i=0;i!=rom_bytes;i+=4)
{
*((unsigned int *)(rom_addr_fast+i)) = *((unsigned int *)(rom_addr_orig+i));
}
...
memory_region_init_ram_ptr(rom, NULL, "mister_minimig.rom", rom_bytes, rom_addr_fast);
rom->readonly = true;
memory_region_add_subregion(address_space_mem, 0xf00000, rom);
But 0xe0 isn't rom is it? ... checks memory map, hmmm perhaps I should put that first 512k here too.
int rom_bytes = 1*1024*1024;
void * rom_addr_orig = mmap(NULL,rom_bytes,(PROT_READ|PROT_WRITE),MAP_SHARED,fdcached,hpsbridgeaddr+0xf00000);
void * rom_addr_fast = malloc(rom_bytes);
for (int i=0;i!=rom_bytes;i+=4)
{
*((unsigned int *)(rom_addr_fast+i)) = *((unsigned int *)(rom_addr_orig+i));
}
...
memory_region_init_ram_ptr(rom, NULL, "mister_minimig.rom", rom_bytes, rom_addr_fast);
rom->readonly = true;
memory_region_add_subregion(address_space_mem, 0xf00000, rom);
-
- Posts: 129
- Joined: Fri Jun 19, 2020 8:54 pm
- Has thanked: 13 times
- Been thanked: 57 times
Re: Lets actually try Hybrid Emulation
Not usually, but on systems with 1 Meg ROMs it can be. (The CD32's extended ROM lives there, for instance.)
Anyhow, if you're copying the ROM to Fast then it's not that.
Is the dhrystone_m68k prebuilt, or are you compling it? If the latter, which compiler?
Re: Lets actually try Hybrid Emulation
The compiler is different.
Latest m68k gcc for Debian and this one for Amiga:
https://github.com/AmigaPorts/m68k-amigaos-gcc
I’ll have a look at the code they produce.
Latest m68k gcc for Debian and this one for Amiga:
https://github.com/AmigaPorts/m68k-amigaos-gcc
I’ll have a look at the code they produce.
-
- Top Contributor
- Posts: 522
- Joined: Tue May 26, 2020 5:06 am
- Has thanked: 86 times
- Been thanked: 204 times
Re: Lets actually try Hybrid Emulation
Would it be worthwhile trying to compile with SAS/c?foft wrote: ↑Sat May 15, 2021 9:37 am The compiler is different.
Latest m68k gcc for Debian and this one for Amiga:
https://github.com/AmigaPorts/m68k-amigaos-gcc
I’ll have a look at the code they produce.
Re: Lets actually try Hybrid Emulation
Here is the updated qemu that changes the irq handling, making it more stable:
http://www.64kib.com/qemu_system_testv9.tar.xz
As a reminder here is the kernel module that you need to setup on boot:
http://www.64kib.com/minimig_irq_core.tar.gz
Hopefully v10 will be stable and faster...
http://www.64kib.com/qemu_system_testv9.tar.xz
As a reminder here is the kernel module that you need to setup on boot:
http://www.64kib.com/minimig_irq_core.tar.gz
Hopefully v10 will be stable and faster...