MiSTer FPGA Forum

foft wrote: ↑Mon May 10, 2021 6:48 am I'm not just getting 8000 000B, so I think this is more than 68040.library. In fact I seem to get a random exception each time and the address it jumps to seems somewhat random.

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.

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.

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...

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 see it double clicking on the drive icons (ram:, system: etc) on the workbench desktop mostly and sometimes in windows too. Miscellaneous guru.

I don't see a jerky mouse pointer though, except when I run at high trace levels.

Turning on "trace-event memory_* on" or "log cpu" both make it work. Must be something timing related... Heisenbug!

@kolla: I wonder if it works for you, perhaps its a timing bug that is fixed in 3.9. I've used 3.1 and 3.1.4.

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.

kolla wrote: ↑Thu May 13, 2021 9:36 am 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.

With qemu and the kernel module?

Yes

kolla wrote: ↑Thu May 13, 2021 9:36 am 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.

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...

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 use PeterK’s icon.library 46.4… don’t know what else could make a difference.

Oh - Piru’s “WhichAmiga” makes the Minimig freeze here.

Good thought, put that icon.library on. Unfortunately nope!

Maybe you could share VHD (make certain there's an "H" in that).

foft wrote: ↑Thu May 13, 2021 4:01 pm 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.

Could it be your RAM module maybe?

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.

kolla wrote: ↑Thu May 13, 2021 7:06 pm Oh - Piru’s “WhichAmiga” makes the Minimig freeze here.

Does whdload work for you?

ZigZag wrote: ↑Thu May 13, 2021 11:06 pm Maybe you could share VHD (make certain there's an "H" in that).

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.

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.

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.

Definitely happens too if I boot the vanilla install 3.1.4 pdf (no hdd) then double click the icons.

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...

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.

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?

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);

Anyway I’m on to literally testing a for loop now running in fast ram - so that shouldn’t come into it!

foft wrote: ↑Fri May 14, 2021 9:14 pmBut 0xe0 isn't rom is it? ... checks memory map, hmmm perhaps I should put that first 512k here too.

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?

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.

Although I know it’s not just executed code since I tested the same binary with musashi and qemu. Musashi won massively!

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.

Would it be worthwhile trying to compile with SAS/c?

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...