06507: coleco [heist]: Demo and Game won't play.

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
06507	Misc.	Major	Always	Feb 18, 2017, 11:52	Jan 7, 2023, 04:46

Tester	Yonah	View Status	Public	Platform	MAME (Official Binary)
Assigned To	palazzol	Resolution	Fixed	OS	Windows Vista/7/8 (64-bit)
Status [?]	Resolved			Driver	coleco/coleco.cpp
Version	0.182	Fixed in Version	0.227	Build	64-bit
		Fixed in Git Commit	af1c5e7	Github Pull Request #

Summary	06507: coleco [heist]: Demo and Game won't play.
Description	The title screen displays OK, but if the game is started or the demo is allow to play, the game resets back to the title screen after displaying "- Level 1 -".
Steps To Reproduce
Additional Information	The same rom works fine if running from the Coleco Adam. Heist.rom CRC32: 6F2E2D84
Github Commit

Flags
Regression Version	0.153
Affected Sets / Systems	coleco [heist]

Attached Files

No.17275 pgimeno Tester Dec 14, 2019, 16:17	The game is doing an uninitialized memory access of memory address 7248h . When 7248h contains 0FFh at start, the game crashes. This access can be witnessed by adding a breakpoint at memory address 9611h; single-stepping for a few instructions will then end up in a jp (hl) that jumps to an invalid address. Therefore, this problem is caused by the pre-initialization of the Coleco RAM to all 0FFh. As of writing this, OpenMSX suffers from the same problem.
No.17311 pgimeno Tester Dec 31, 2019, 14:13	The problem has just been fixed in OpenMSX. https://github.com/openMSX/openMSX/commit/b8994ef5ddc57b0e6de699e66c7204cbebaeabb8 https://github.com/openMSX/openMSX/commit/7088cb11fba6e34102888cc0a80d4b5a089ca33f While I'm here: The byte at 7248h acts like a flag. There's another byte at 724Ah used as an index to a jump table with 3 entries. I guess that if the second byte is in range (between 0 and 2) it might not crash even if the first one was FF. The description above was simplified.

No.17275

pgimeno

Tester

Dec 14, 2019, 16:17

The game is doing an uninitialized memory access of memory address 7248h . When 7248h contains 0FFh at start, the game crashes. This access can be witnessed by adding a breakpoint at memory address 9611h; single-stepping for a few instructions will then end up in a jp (hl) that jumps to an invalid address.

Therefore, this problem is caused by the pre-initialization of the Coleco RAM to all 0FFh. As of writing this, OpenMSX suffers from the same problem.

No.17311

pgimeno

Tester

Dec 31, 2019, 14:13

The problem has just been fixed in OpenMSX.

https://github.com/openMSX/openMSX/commit/b8994ef5ddc57b0e6de699e66c7204cbebaeabb8
https://github.com/openMSX/openMSX/commit/7088cb11fba6e34102888cc0a80d4b5a089ca33f

While I'm here: The byte at 7248h acts like a flag. There's another byte at 724Ah used as an index to a jump table with 3 entries. I guess that if the second byte is in range (between 0 and 2) it might not crash even if the first one was FF. The description above was simplified.