Apparent bug in C and 32-bit x86 DRC back-ends affecting pm6100

[cuavas]

MAME version

0.274 (mame0274)

System information

Windows 10 Pro 10.0.19045 Build 19045 x86-64

INI configuration details

joystick                  1
joystick_deadzone         0.15
joystick_saturation       0.95
trackball_device          mouse
mouse_device              mouse
window                    1
maximize                  1

Emulated system/software

Power Macintosh 6100/60, System Software 7.5 (pmac6100 mac750)

Incorrect behaviour

There’s an apparent bug in the C and 32-bit x86 DRC back-ends affecting pmac6100.

• The C and 32-bit x86 back-ends are definitely affected.
• The x86-64 back-end is apparently unaffected.
• I don’t know whether the 64-bit ARMv8 back-end is affected as I don’t have a convenient way to test it.

MAME 0.274 is affected, as is the current tip of the master branch (9ba5d70 at time of writing).

The bug manifests in the jigsaw puzzle. If you drag a puzzle piece over another piece, the content of the piece underneath shifts slightly in the “cutout” areas of the piece on top.

Expected behaviour

The puzzle piece content should not move when another piece is dragged over it.

Steps to reproduce

1. Start mame -drc_use_c pmac6100 mac750 (or using a 32-bit x86 build, you can start mame pmac6100 mac750
2. Wait for the OS to boot
3. Start the Jigsaw Puzzle (it’s in the Apple menu)
4. Start a new puzzle if it’s in the solved state (Command-N or “Start New Puzzle…” from the “Options” menu, I chose “Medium” size pieces)
5. Find two “loose” pieces (i.e. not snapped into place) with plenty recognisable content, not just plain colour
6. Drag one piece so it partially covers the other piece and move it horizontally or vertically
7. The content of the piece underneath will shift slightly as you drag the piece over it

Additional details

No response

[cuavas]

To demonstrate, notice how Irian Jaya (aka West Papua) shifts/distorts as I drag the Antarctica piece over it (it might be easier to see if you open the screenshots in a slideshow viewer):

[cuavas]

Ping @rb6502 since this affects PowerPC/PowerMac, and @987123879113 since it seems to be caused by DRC back-end issues. I really have no idea where to even start looking for this. Does the Jigsaw Puzzle use QuickDraw regions to do mask the shape of the puzzle pieces and copy a pixmap using a region mask?

[987123879113]

Appears to happen on ARM too. I have no idea what the program is using so I can't comment there.

If it's confirmed that it didn't happen with the C backend before the changes but does happen on the C backend now then that narrows it down a lot. The C backend didn't change a whole lot, so it's probably something related to the changes to: the new way of calculating shift/rotate flags (flags are calculated even if shift is 0 now), the new way of calculating mult flags, or clearing registers.

The other alternative I can think of is the changes to the simplifier in src/devices/cpu/uml.cpp, but if that was the case then it'd happen on x64 too (are you positive it doesn't happen on x64? that'd narrow it down more).

[cuavas]

I haven't tested MAME 0.273 yet. It could have already been happening before your changes.

[rb6502]

It should be possible to just throw cpu/powerpc/* and apple/macpdm.cpp over a version prior to Windy's changes and see if the problem is actually a regression. My guess is that it probably isn't, but I wouldn't mind being surprised.

Once I land the PowerBook Duos (getting very close on that), I'll work on getting risu hooked up so we can test PPC opcodes against sequences logged on real hardware. Both DingusPPC and QEMU have used it to knock the corner case problems out of their PPC cores, which is good because OS X reportedly hits all of them.

[987123879113]

Hacky but here's how to master building without all of my recent DRC changes.

git checkout 581d5d7e749613a26985f6cf35f75673feede8fd src/devices/cpu/uml* src/devices/cpu/drcbec.cpp src/devices/cpu/drcbeut.cpp src/devices/cpu/drcbex64.cpp src/devices/cpu/drcbex86.cpp src/devices/cpu/drccache.cpp src/devices/cpu/drcfe.cpp src/devices/cpu/drcuml.cpp src/devices/cpu/drcumlsh.h src/devices/cpu/drcbec.h src/devices/cpu/drcbeut.h src/devices/cpu/drcbex64.h src/devices/cpu/drcbex86.h src/devices/cpu/drccache.h src/devices/cpu/drcfe.h src/devices/cpu/drcuml.h

581d5d7 is a recent commit before my changes.

Undefine NATIVE_DRC in src/devices/cpu/drcuml.cpp to make it force the C backend (probably easier to do it another way but I didn't want to rebuild from scratch again)

Change UML_MULSLW(block, R32(G_RD(op)), R32(G_RA(op)), R32(G_RB(op))); to UML_MULS(block, R32(G_RD(op)), R32(G_RD(op)), R32(G_RA(op)), R32(G_RB(op))); in src/devices/cpu/powerpc/ppcdrc.cpp

Still happens on the C backend so it's not an issue with the recent DRC changes.

[firewave]

Recording an input file and using the -drc_log_* options should help narrowing this down.