04251: mspacman: Ghost tunnel behavior different than arcade

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
04251	Gameplay	Minor	Always	Feb 15, 2011, 03:22	Feb 22, 2011, 21:11

Tester	jpittman	View Status	Public	Platform	MAME (Official Binary)
Assigned To		Resolution	Open	OS	Windows Vista/7 (32-bit)
Status [?]	Confirmed			Driver	pacman/jrpacman.cpp
Version	0.141u2	Fixed in Version		Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	04251: mspacman: Ghost tunnel behavior different than arcade
Description	Grouped ghost/monster movement through the tunnels is not 100% faithful to the arcade. When leading a tightly-grouped set of monsters (i.e., Inky, Pinky and Blinky right on top of each other) through tunnels on an arcade machine, you will notice that going through the tunnel will shift the monsters' relative positions to one another slightly. A few times through the tunnel can produce quite a difference. In MAME, however, the ghosts retain the exact same position in reference to the other ghosts in the tunnels regardless of how many times you go back and forth. Here is a YouTube video demonstrating this "tunnel jump" (or "ghost creep") on an arcade machine: Note how the tight grouping slowly gets spread out over several trips through the tunnels. This discrepancy between MAME and an actual arcade machine has been verified by many elite Ms. Pac-Man players on the TG and CAG forums and is seperate from the "tunnel slowdown persisting when it shouldn't" issue that has already been addressed and resolved by the MAMEdev team. This would be a good TG thread to check out that specifically talks about this issue in detail: http://forums.twingalaxies.com/viewtopic.php?f=30&t=24928&start=0
Steps To Reproduce
Additional Information
Github Commit

Flags
Regression Version
Affected Sets / Systems	mspacman

Attached Files	mspac-18feb11.inp (366,384 bytes) Feb 18, 2011, 02:23 Uploaded by PacWhiz mspacman boards 10-14 tunnel chasing

No.07198 Fujix Administrator Feb 15, 2011, 08:18 edited on: Feb 15, 2011, 13:35	If we have a playback file (an inp file) recorded with the latest version of MAME, it will be helpful for other testers and developers. Please check 01954, the tunnel slowdown in later stages was to be a bug in this report and actually it was "fixed" in 0.126u3. Please visit http://maws.mameworld.info/maws/set/mspacman for the emulation history. I'm not enough skillful to confirm the issue, I used an invincibility cheat (Using a cheat to confirm a report is not allowed usually). I disabled the speed throttling and confirmed that the distances between those ghosts (Blinky, Pinky and Blinky) are always constant. I think this means there's no slowdown at the tunnel OR no speed differences among the ghosts in MAME. Thank you.
No.07201 jpittman Tester Feb 15, 2011, 13:54	I'm not skillful enough to create a good .INP file for you but I will ask some of the world-class players I know. I am aware "the tunnel slowdown in later stages" issue was "fixed". As I understand it, this problem was addressed by changing the return value of the pacman_read_nop() function from 0xff to 0xbf. This was to permanently turn off bit 6 during reads to undefined areas of memory due to a routine in the code that associates bit 6 with tunnel slowdown and doesn't work as expected when ghosts are offscreen. Here's some more info on that: When determining what speed a ghost is moving, the code reads a value from color ram (starts at 0x4400 in memory) for the tile that corresponds to the ghost's position and IF bit 6 is enabled slows the ghost down. There are four off-screen tiles that the ghosts move through in a tunnel. Now, for these off-screen tiles, the routine that figures out the proper address in color ram doesn't work right. For two of the tiles, it ends up using the very top of color ram, like around the high score area. For the other two tiles, it actually tries to read past the end of color ram, using addresses just a little beyond 0x4800. On an actual Ms. Pac board, those addresses don't map to any memory. So what value does the CPU get when it tries to read from there? MAME handles these unmapped memory reads with the pacman_read_nop() function and would cause the constant tunnel slowdown by returning 0xff (which has bit 6 enabled). The solution to always return 0xbf instead solved the perpetual slowdown issue and this is definitely preferred to the ghosts always slowing down in the tunnels. But returning any constant value for these unmapped memory reads may be the reason ghosts still behave slightly differently in MAME from a true arcade machine. It seems the unmapped memory reads on an arcade machine sometimes return a value with bit 6 enabled and sometimes not which would explain how individual ghosts occasionally change speed when traveling through tunnels. I have no idea how you would properly emulate these kinds of unmapped memory reads but I hope this may help developers understand why there's a difference between MAME and the arcade.
No.07204 phantomdj Tester Feb 15, 2011, 21:28 edited on: Feb 17, 2011, 18:02	It looks like something is wierd with MS pac on MAME...? Using the latest debug build available on mamedev ( mame0141b_debug.exe MAME 0.141 Windows command-line binaries (debug build). ) ... I loaded MS pacman. I set a breakpoint at 205D. Now, when it breaks here, some very wierd things are happening. Sometimes, it shows the mspacman patch line on 2060 2060 jp $366f And sometimes it shows the original pacman code on line 2060: 2060 jr nz,$2066 But in either case, it always seems to run the original pacman line. This might help explain the tunnel anomaly, as this part of the code is used for checking for slowdowns in the tunnel. [edit 2/16/2011] I just finished reading about how MsPac has these special "latches" that prevent the ROMS from being dumped easily. I suppose that this is the reason for this strange behaviour. I will check against the bootleg version of mspac to verify. [edit 2/17/2011] OK I just checked the MsPac bootleg and this behaviour does not happen there, so I assume it is due to the latches which are triggering for some reason in th debugger. I'm starting to suspect that the bug isn't related to this part of the code anyway. I will continue to investigate. Don Hodges
No.07222 jpittman Tester Feb 18, 2011, 00:20	I just uploaded an .INP file per your request made by an expert Ms. Pac-Man player. He recorded it with MAMEPlus 0.141u1.
No.07223 Tafoid Administrator Feb 18, 2011, 00:28 edited on: Feb 18, 2011, 00:46	No. Unfortunately, for it to be valid - you need to use MAME (command-line) available at http://mamedev.org/release.html (latest is 0.141) You can record your game with the following command-line mame mspacman -record mspacman.inp then playback with mame mspacman -playback mspacman.inp MAMEPlus and most other derivative builds adjust the core in ways that could easily lead to errors in emulation which do not show up in the baseline build. It's the ONLY reliable way the developers/testers can keep to a standard binary from original and un-altered sources only. Attempted playback with a source true version of 0.141u1 immediately comes up as "out of sync" and ends. EDIT: A reminder to not run the game with any type of -cheats. Such things can corrupt the ram/game program. All you need, really, is the Rack Advance (F1) to reach those post-Junior tunnels.
No.07224 jpittman Tester Feb 18, 2011, 00:33	Understood. I just forwarded your response to the person who made the .INP file. Hopefully he will make another one per your instructions and I'll get it uploaded ASAP.
No.07229 PacWhiz Tester Feb 18, 2011, 02:21	Ha didn't know you could upload here... (didn't see "attach file" underneath the note). Well i hope the file i'm gonna upload in a sec will be sufficient this time around. On the Junior boards I tried to send them all through the tunnels (well, the 3 main monsters), and sometimes ate them to change their order (didn't feel like grouping them lol) and then send them chasing MsPac through the tunnels once again... I also did that for the Chase boards, which might be helpful i dunno. Thx guys, will be interested to hear the results :) ~Aart
No.07230 jpittman Tester Feb 18, 2011, 02:32	Thanks again, Aart. It seems he has already uploaded the new .INP file (and I deleted the one I uploaded earlier that was incorrect). Hopefully this will be what you guys need for testing purposes.
No.07231 Fujix Administrator Feb 18, 2011, 08:10	Thank you for uploading the inp file. I confirmed it works ok and reproduces the issues properly.
No.07235 PacWhiz Tester Feb 19, 2011, 01:51	Hey good to hear, thanks to you guys as well!
No.07257 phantomdj Tester Feb 22, 2011, 21:11 edited on: May 31, 2012, 05:41	Here's another video an actual ms pac machine showing the tunnel creep. It was made by David Race.