08667: All sets in topspeed.cpp: Coin counters increase at each boot up even though credits are not being added

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
08667	Misc.	Minor	Always	Jun 17, 2023, 05:23	Jun 21, 2023, 05:41

Tester	Balthier	View Status	Public	Platform	MAME (Official Binary)
Assigned To		Resolution	Open	OS	Windows 10/11 (64-bit)
Status [?]	Confirmed			Driver	taito/topspeed.cpp
Version	0.255	Fixed in Version		Build	64-bit
		Fixed in Git Commit		Github Pull Request #

Summary	08667: All sets in topspeed.cpp: Coin counters increase at each boot up even though credits are not being added
Description	When running a game, the coin counters numbers in the machine's cfg file will increase by 1 on each start up even though credits are not being added by the user.
Steps To Reproduce	1. run any of the affected games ( topspeed, topspeedu, fullthrl ). 2. let the game run for a little bit, just don't add any credits. 3. exit the game, go to your cfg directory and examine the game's cfg file. The coin counter numbers should be at 1 now. 4. run the same game and repeat step 2. 5. repeat step 3, and the counters will now be at 2.
Additional Information	Example fullthrl.cfg after one run, no credits added: <?xml version="1.0"?> <!-- This file is autogenerated; comments and unknown tags will be stripped --> <mameconfig version="10"> <system name="fullthrl"> <counters> <coins index="0" number="1" /> <coins index="1" number="1" /> </counters> </system> </mameconfig> Mame versions 0.120 to 0.149 add 2 coins to each counter at each startup, and 0.150 to current add 1. I didn't test with any versions before 0.120 so I don't know if these games always autoincremented. I'll also note that the 5 and 6 keys increment the correct counters in this case, if anyone happens to be curious.
Github Commit

Flags
Regression Version
Affected Sets / Systems	All sets in topspeed.cpp

Attached Files

No.21556 hap Developer Jun 17, 2023, 09:47 edited on: Jun 17, 2023, 09:47	Looks like subcpu writes 0,ff,0 at boot on purpose: 013D7E: 33FC 0004 0088 0002 move.w #$4, $880002.l 013D86: 33FC 0000 0088 0000 move.w #$0, $880000.l 013D8E: 33FC 0004 0088 0002 move.w #$4, $880002.l 013D96: 33FC 00FF 0088 0000 move.w #$ff, $880000.l 013D9E: 33FC 0004 0088 0002 move.w #$4, $880002.l 013DA6: 33FC 0000 0088 0000 move.w #$0, $880000.l 013DAE: 4E75 rts
No.21562 Balthier Tester Jun 17, 2023, 16:16	Why did it change how it incremented between versions 0.149 and 0.150? I wrote that it was adding 2 coins to each counter and then it switched to 1 each with 0.150. And why is this different to almost everything else with coin counting? I went through almost 500 cfgs across 160+ drivers and none do this normally.
No.21564 hap Developer Jun 17, 2023, 16:57	I haven't looked why it changed from 2 counts to 1, I don't think it's that important. (if it went from 0 to 1, then it would be) What do you mean it's different to everything else? You mean why this bug exists? Who knows, maybe triggering 0xff has a different function, or maybe it really did increment the coincounter at boot (aka BTANB).
No.21566 Balthier Tester Jun 17, 2023, 18:57	Yes, I'm curious why it is set up to add 1 at every boot versus how most other systems boot (but I'm not saying you need to answer that question or stress too much either lol). I get it that every system has different software and hardware right down to the buttons and switches, so the counter mechanism would be different on alot of them. The counters count coins, an operator would need to know how much money they made, and this seems like it would mess up the profit totals, unless I'm looking at this wrong. This whole exercise is interesting for me though, I feel like I am learning some things here that don't get brought up much concerning the counters and dip switches, and I've been using mame since the old days.