07892: sxeviousj: Inserting coin automatically start 2 player game with issues

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
07892	Gameplay	Minor	Always	Mar 1, 2021, 08:48	Aug 15, 2022, 10:51

Tester	Augusto	View Status	Public	Platform	SDLMAME
Assigned To	hackbar	Resolution	Reopened	OS	Linux (64-bit)
Status [?]	Assigned			Driver	namco/galaga.cpp
Version	0.229	Fixed in Version		Build	64-bit
		Fixed in Git Commit	a6addb1	Github Pull Request #	#9141

Summary	07892: sxeviousj: Inserting coin automatically start 2 player game with issues
Description	Insert one coin. Automatically start 2 player game not using the inserted credit. Solvalou goes totally to left without player input. When that gameplay end is possible start an new gameplay with correct control input. To play need insert one coin wait to both 2 player game end or insert coin and after reset. Only affect sxeviousj.
Steps To Reproduce
Additional Information
Github Commit

Flags
Regression Version	0.221
Affected Sets / Systems	sxeviousj

Attached Files

No.18502 Tafoid Administrator Mar 1, 2021, 11:16 edited on: Mar 1, 2021, 11:17	In particular, work done on April 25, 2020 seems to be the culprit. Namco custom chip improvements https://github.com/mamedev/mame/commit/3a6317b0f47a1596777537b7c7544818076f9397 Given the fact that it 'clears up' after the failed start tends to suggest a race condition as mentioned in the source text of one of the custom control chips. Note that Xevious has a potential race condition at 0xE9. It checks if the control register is 0x10 (chip disabled), then 4 instructions later acts on that check. If an NMI occurs between, it can crash. Why it only affects SXEVIOUSJ, it is unknown. All other tested xevious/clone sets do not exhibit this under testing.
No.19178 Haze Senior Tester Aug 26, 2021, 13:46	I've noticed a similar issue with xeviousa / xeviousb at least, sometimes you'll insert a coin, it will show FF credits, automatically start a game, and automatically move you to the bottom left (controls don't work) not sure if it's related.
No.19642 hackbar Tester Jan 6, 2022, 01:04	This is fixed by https://github.com/mamedev/mame/pull/9056 .
No.20446 Augusto Tester Aug 13, 2022, 01:51	That bug is happening again, but only with sxeviousj. Anyone can test in official build ?
No.20447 kmg Tester Aug 13, 2022, 03:39	It broke again with z80 changes. Commit: https://github.com/mamedev/mame/commit/44dae68dbb5cd5d9fbb56e919e7bb59644830d2c
No.20448 Haze Senior Tester Aug 13, 2022, 10:18	given how the Atari sets still randomly did it, I don't think it was ever properly fixed, just worked by chance most of the time for a while.
No.20453 Augusto Tester Aug 14, 2022, 07:12	All right.
No.20454 Haze Senior Tester Aug 14, 2022, 17:52 edited on: Aug 14, 2022, 17:54	why are we creating duplicate reports, it's the same bug come back / never properly fixed
No.20457 Augusto Tester Aug 15, 2022, 02:50	It was spoken for me create an new report. MCU problem ? japanese had protection or any IC not added in Atari versions ?
No.20458 Haze Senior Tester Aug 15, 2022, 10:51 edited on: Aug 15, 2022, 10:51	It's probably some strange timing thing like the Bosconian issue, tweaking things can make it work 'by chance' most of the time. Even when it was tweaked for the Japan sets to work most of the time, the Atari sets would still fail more often than not, probably because they were executing code at a very slightly different time. The hardware is, as far as we're aware, the same.