09371: coolmini: Sound test crashes (emulated system stops responding) when moving part stage 4 BGM

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
09371	Gameplay	Minor	Always	Jan 11, 2026, 03:38	12 hours ago

Tester	cuavas	View Status	Public	Platform	MAME (Official Binary)
Assigned To	Tourniquet	Resolution	Reopened	OS	Windows (Arm)
Status [?]	Confirmed			Driver	misc/vamphalf.cpp
Version	0.284	Fixed in Version	0.290GIT	Build	Arm64
		Fixed in Git Commit	1405b3a	Github Pull Request #	#16370

Summary	09371: coolmini: Sound test crashes (emulated system stops responding) when moving part stage 4 BGM
Description	If you go to the setup menu, select the sound test, and try to select a BGM track beyond STAGE4, the game program crashes and the system stops responding to joystick and button inputs. If you started a BGM track, the music will continue to play. Soft reset (F3) will stop the music, but the screen will not update and the game will not respond to inputs. It needs a hard reset to get out of the crashed state. This happens with both -drc and -nodrc. I haven't debugged what's actually happening, so this may actually be an original game bug. If anyone has an original board it would be good to get confirmation of whether it happens. In a debug build you'll get the following assertion failure when the crashed program writes an invalid value to the Memory Control Register (MCR, G27): Assertion failed: which < 4 \|\| which == 7, file ../../../../../src/devices/cpu/e132xs/e132xs.cpp, line 672 If you recompile with verbose logging, you can see it somehow get into a loop that writes invalid values to the MCR: ':maincpu' (0000191A): Set MCR = 0xfdd881ea, entry map in MEM0, reduced output voltage, input threshold for VDD=5.0V IRAM normal mode, refresh every 128 cycles MEM0 16 bit fast page DRAM, bus hold break disabled MEM1 16 bit, bus hold break enabled MEM2 16 bit, bus hold break enabled MEM3 8 bit, bus hold break enabled ':maincpu' (00001928): Set MCR = 0xfd9881ea, entry map in MEM0, reduced output voltage, input threshold for VDD=5.0V IRAM normal mode, refresh every 128 cycles MEM0 16 bit fast page DRAM, bus hold break disabled MEM1 16 bit, bus hold break enabled MEM2 16 bit, bus hold break enabled MEM3 8 bit, bus hold break enabled entering power down ':maincpu' (0000191A): Set MCR = 0xfdd881ea, entry map in MEM0, reduced output voltage, input threshold for VDD=5.0V IRAM normal mode, refresh every 128 cycles MEM0 16 bit fast page DRAM, bus hold break disabled MEM1 16 bit, bus hold break enabled MEM2 16 bit, bus hold break enabled MEM3 8 bit, bus hold break enabled ':maincpu' (00001928): Set MCR = 0xfd9881ea, entry map in MEM0, reduced output voltage, input threshold for VDD=5.0V IRAM normal mode, refresh every 128 cycles MEM0 16 bit fast page DRAM, bus hold break disabled MEM1 16 bit, bus hold break enabled MEM2 16 bit, bus hold break enabled MEM3 8 bit, bus hold break enabled entering power down ':maincpu' (0000191A): Set MCR = 0xfdd881ea, entry map in MEM0, reduced output voltage, input threshold for VDD=5.0V IRAM normal mode, refresh every 128 cycles MEM0 16 bit fast page DRAM, bus hold break disabled MEM1 16 bit, bus hold break enabled MEM2 16 bit, bus hold break enabled MEM3 8 bit, bus hold break enabled ':maincpu' (00001928): Set MCR = 0xfd9881ea, entry map in MEM0, reduced output voltage, input threshold for VDD=5.0V IRAM normal mode, refresh every 128 cycles MEM0 16 bit fast page DRAM, bus hold break disabled MEM1 16 bit, bus hold break enabled MEM2 16 bit, bus hold break enabled MEM3 8 bit, bus hold break enabled entering power down ':maincpu' (0000191A): Set MCR = 0x00475adf, entry map in reserved, reduced output voltage, input threshold for VDD=3.3V IRAM test mode, refresh every 16 cycles MEM0 8 bit fast page DRAM, bus hold break enabled MEM1 8 bit, bus hold break disabled MEM2 reserved, bus hold break enabled MEM3 8 bit, bus hold break disabled ':maincpu' (00001928): Set MCR = 0x00075adf, entry map in reserved, reduced output voltage, input threshold for VDD=3.3V IRAM test mode, refresh every 16 cycles MEM0 8 bit fast page DRAM, bus hold break enabled MEM1 8 bit, bus hold break disabled MEM2 reserved, bus hold break enabled MEM3 8 bit, bus hold break disabled entering power down
Steps To Reproduce	1. Start mame coolmini 2. Press the TEST button to enter the "Setup main menu" 3. Press 1P Button1 to select "Test devices" 4. Press 1P Down twice to move the cursor to "Audio device" and press 1P Button1 to select it 5. Press 1P Down to move the cursor to "BGM" 6. Press 1P Right to change to "STAGE4" (game is still responding to inputs at this point) 7. Press 1P Right one more time (emulated game crashes at this point)
Additional Information
Github Commit

Flags
Regression Version
Affected Sets / Systems	coolmini

Attached Files

No.24051 Robbbert Moderator Jan 11, 2026, 06:51 edited on: Jan 11, 2026, 06:53	In the PCM test, most of the samples do not play, and show an error in the log - no idea if this is ok. Confirmed that it stops responding to inputs, but there's no dump and mame doesn't freeze - it continues to execute code. At this point, pressing INS shows around 10'000%, but after a while it suddenly goes into what might be weeds, many unmapped reads appear in the log, and the speed drops dramatically.
No.24056 Haze Senior Tester Jan 11, 2026, 22:19	a lot of Semicom games have incomplete / broken test modes, honestly I wouldn't be surprised if this one was too.
No.24758 cuavas Administrator 13 hours ago	Crash/freeze is for things that crash or freeze the emulator, not the emulated program crashing. It's also not critical as most people would never see it, given it only seemed to trigger if you did specific things in test mode.
No.24759 Tourniquet Developer 12 hours ago	This must be a BTANB. Claude: "I’ve traced the bug: a second resume of the idle loop with a mismatched FP/FL causes its L9 register to overlap with another task’s saved return PC, corrupting the MCR write. Before confirming it’s a game bug, I’ll check whether the scheduler code at 0x1B0A–0x1A04 was actually supposed to write the idle task’s own SR into that slot, which would instead point to an emulation issue. This is the scheduler working as written. At 0x19FA it builds the resume PC itself (SUM L2, PC, ... ; $187B, i.e. 0x187A with S set), then sets the interrupt lock and clears H in L3 (ORI L3, $8000, ANDNI L3, $20). Then RET PC, L2 resumes the idle loop with the SR of whichever task yielded. So the idle loop always runs on the yielding task’s frame. When that task had FL ≥ 10, L9 was safe. The task for the track after STAGE4 yields from a CALL L5 frame with FL=5, so an interrupt saves its return PC into L9. Checked against the CPU manual, this is a bug in coolmini’s own code, not in MAME’s CPU emulation. Every frame change in the trace follows the Hyperstone E1-16XS/E1-32XS user manual: How the crash happens: The idle loop’s assumption: the idle loop (0x187A–0x1928) keeps the MCR value in L9, so it assumes a frame of at least 10 registers. The yield: selecting the BGM entry after STAGE4 runs code that yields (TRAP 33) from a frame with FL=5. The resume: the scheduler resumes the idle loop on that frame, as shown above, so L9 sits outside it. The interrupt: the loop clears the interrupt lock, and the next interrupt’s task (0x75AD0) executes TRAP 37. Per the manual, TRAP saves its return PC at FP + FL, which is exactly the idle loop’s L9. The bad MCR write: the idle loop writes that saved PC (0x75ADF) into MCR, which moves the trap vectors, and the game dies."
No.24760 Tourniquet Developer 12 hours ago	As above. I think this is almost certainly BTANB, but not confirmed on a real PCB.