Lets actually try Hybrid Emulation

[NovaCoder]

Cool to see such fast progress

If you want another thing to test with then you can try my port of ZDOOM which runs on all CPUs.

http://aminet.net/package/game/shoot/ZDOOM_AGA

http://aminet.net/package/game/shoot/ZDOOM_RTG

[LamerDeluxe]

My Candy Factory Pro software also has versions for all types of CPUs and shows the time it took to render an image.
It was commercial software but can now be downloaded for free here: https://www.amigafuture.de/app.php/dlex ... id=5116%3f
(you need to register at that site to be able to download it)

[kolla]

There is no JIT option for qemu, I guess?

[foft]

qemu is jit, that is why it gets like 500000 dhrystones.

You can see the code translation if you run with -d in_asm,out_asm

[foft]

Something really weird...

Cold boot -> newcli -> software:benchmarks/sysinfo -> sys info. This gives 4000 dhrystones.
Cold boot -> gui -> software:benchmarks/sysinfo -> sys info. This gives 74000 dhrystones.

[foft]

A couple of icon clicking crashes...

chipROM::UNKNOWN tb at 0xb2a69200
INT 4369: Level 3 Interrupt(0x6c) pc=00f9693a sp=401a0a34 sr=0014:Trace 0: 0xb2a665c0 [00000000/00f81354/0x2000]
0x00f947ea: movew #64,%a0@(156)
0x00f947f0: movel %a1@(58),%d0
0x00f947f4: beqs 0xf947e8

0x00f947f6: btst #1,%a1@(169)
0x00f947fc: beqs 0xf947e8

0x00f947fe: moveal %a1,%fp
0x00f94800: moveal %d0,%a1
0x00f94802: tstb %a0@(2)
0x00f94806: btst #6,%a0@(2)
0x00f9480c: beqs 0xf94826

0x00f94826: tstb %a0@(2)
0x00f9482a: bclr #7,%fp@(169)
0x00f94830: bnes 0xf94858

0x00f94832: movew %a1@(12),%d0
0x00f94836: bpls 0xf9484e

0x00f9484e: moveal %a1@(4),%a5
0x00f94852: jsr %a5@ -> jsr to space...

chipROM:0x00001120: orib #0,%d0
0x00001124: orib #0,%d0
0x00001128: orib #0,%d0
---

chipROM::UNKNOWN tb at 0xb2b69200
INT 2079: Level 3 Interrupt(0x6c) pc=400083aa sp=401a0ad8 sr=0014:Trace 0: 0xb2b665c0 [00000000/00f81354/0x2000]
0x00f947ea: movew #64,%a0@(156)
0x00f947f0: movel %a1@(58),%d0
0x00f947f4: beqs 0xf947e8

0x00f947f6: btst #1,%a1@(169)
0x00f947fc: beqs 0xf947e8

0x00f947fe: moveal %a1,%fp
0x00f94800: moveal %d0,%a1
0x00f94802: tstb %a0@(2)
0x00f94806: btst #6,%a0@(2)
0x00f9480c: beqs 0xf94826

0x00f94826: tstb %a0@(2)
0x00f9482a: bclr #7,%fp@(169)
0x00f94830: bnes 0xf94858

0x00f94832: movew %a1@(12),%d0
0x00f94836: bpls 0xf9484e

0x00f9484e: moveal %a1@(4),%a5
0x00f94852: jsr %a5@ -> jsr to space...

chipROM:0x00000028: 0370
0x0000002a: bset %d5,%a2@(248)
0x0000002e: bset %d5,%a4@(248)
0x00000032: bset %d5,%fp@(248)
0x00000036: bset %d5,%a0@(fffffffffffffff8,%d0:w)

[foft]

Normally it goes here:
0x00f96a1c: moveb %a1@(22),%d0

[kolla]

So JIT and MMU? In other 68k emulators those have been mutually exclusive - either super fast JIT or relatively slow “non JIT”, but with MMU.

[kolla]

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

Where do I find the sources for this module?
As I wrote earlier, I build my own kernels, and hence the "magic version" is different than the "official" kernel

Code: Select all

/root# insmod /media/fat/Amiga/minimig_module/minimig-irq.ko
insmod: ERROR: could not insert module /media/fat/Amiga/minimig_module/minimig-irq.ko: Invalid module format

Dmesg output:

Code: Select all

[Wed May  5 22:42:32 2021] minimig_irq: version magic '4.19.0-socfpga-r1 SMP mod_unload ARMv7 p2v8 ' should be '4.19.0 SMP mod_unload ARMv7 p2v8 '

[foft]

Here is the kernel module source, please excuse the mess!

[foft]

So JIT and MMU? In other 68k emulators those have been mutually exclusive - either super fast JIT or relatively slow “non JIT”, but with MMU.

Yeah that is with the uae jit. I plan to try that too but haven't worked out how to plumb it in yet.

[Caldor]

I have been testing a bit with the newest updates. Still seems unstable. I tried using the 3.1.4 ROM from Hyperion and the Workbench that comes with it, but it still had the problem with clicking icons even though the install disk should have a 68040 library.

I will wait for it to be more stable I think. Unless there is something that needs testing maybe that I can help with.

[foft]

I have been testing a bit with the newest updates. Still seems unstable. I tried using the 3.1.4 ROM from Hyperion and the Workbench that comes with it, but it still had the problem with clicking icons even though the install disk should have a 68040 library.

I will wait for it to be more stable I think. Unless there is something that needs testing maybe that I can help with.

Yes its very unstable right now.

The kind of testing I'm keen on now is really people familiar with 68k machine code, 68k testing tools and amiga rom internals. I'm more familiar with the Atari 8-bit since I never developed on the Amiga.

[kolla]

I tried using the 3.1.4 ROM from Hyperion and the Workbench that comes with it, but it still had the problem with clicking icons even though the install disk should have a 68040 library.

OS 3.1.4 does NOT come with 68040.library, you are supposed to install CPU libraries from CPU card provider - or the CPU libraries from ThoR (MMULib).

Running AmigaOS on 68040 or 68060, "real" or not, without having CPU library installed, is bound to cause various problems.

[NovaCoder]

Yes like I said before, the logical way to test this new 040 core is to first set up a working (verified) workbench installation under winuae (obviously emulating an 040). Once you have a validated workbench installation you can then switch to the MiSTer for a comparison.

I recommend using a base OS 3.9 installation with just boing bags 1 and 2 installed and no other 3rd party patches, this will give you a very clean and stable installation.

It seems that the people developing this core are not really Amiga workbench people, if you need some guidance please ask over on the English Amiga board and you will get lots of help setting up workbench.

http://eab.abime.net/index.php

[foft]

From my googling, a crash on doubling clicking icons on workbench can be CIA related.

So despite it just jumping to random memory, I wonder if the root cause is timing.

[toastboy]

OS 3.1.4 does NOT come with 68040.library, you are supposed to install CPU libraries from CPU card provider - or the CPU libraries from ThoR (MMULib).
Running AmigaOS on 68040 or 68060, "real" or not, without having CPU library installed, is bound to cause various problems.

I restored an A4000 last year with 68040 cpu card and 3.1.4 ROM.
When 3.1.4 workbench boots from a clean install, you get a prompt on boot about the lack of 68040 libs.
Then it crashes a lot, but at least it told you so.

[kolla]

The cause for the crashes (8000 000B) are the mathlibs, which may try to use calls for the 68881/68882 that isn’t available. 68040.library traps those calls that aren’t available on 040 and perform them in software instead (essentially 68881/68882 emulation).

There are mathlibs that do not use FPU, and hence will not cause such problems - I wonder if perhaps the 3.9 ones are such, would need to look it up. (I have them for use with FEMU, the software FPU emulator, which uses the math libs for FPU emulation, and hence cannot rely on an FPU… which they emulate, catch 22)

[foft]

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.

I put the library in from the link I posted before and no longer have the instability warning now.

I wonder if its a double click issue rather than anything workbench specific. I'll try that...

[kolla]

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

[robinsonb5]

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.

[foft]

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.

[foft]

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

[foft]

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

[foft]

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

[foft]

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

[kolla]

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.

[foft]

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?

[kolla]

Yes

[bbond007]

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