Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
05498 Crash/Freeze Critical (emulator) Always Apr 9, 2014, 00:27 Nov 9, 2016, 14:13
Tester Tafoid View Status Public Platform
Assigned To crazyc Resolution Fixed OS
Status [?] Resolved Driver mpu4vid.cpp
Version 0.153 Fixed in Version 0.159 Build
Summary 05498: Many sets in mpu4vid.c: Gameplay stops at a "Serial Link Failure" screen
Description Gameplay stops at a "Serial Link Failure" screen
Steps To Reproduce
Additional Information Example sets: v4big40, v4sunbst, v4vgpok
Suspect breakage in r27839 (Rewritten 6850 commms)
Regression Version 0.153
Affected Sets / Systems Many sets in mpu4vid.c
Attached Files
7z file icon error.7z (2,105 bytes) Nov 9, 2016, 14:13 Uploaded by Fujix
(Compressed) Log of 6850 output - loops at the parity bit stage from here
There are no relationsihp linked to this issue.
User avatar
Oct 15, 2014, 09:14
edited on: Oct 17, 2014, 19:19
Looking into this further, all of the games appear to test the serial link straight away, and the test fails because the code jams up receiving the last bit. I suspect parity issues, but will post better logs soon.

All games report either serial link comms errors, or the Barcrest equivalent MPU4 communications breakdown.

Log now attached, this worked but was flaky before the revision stated.

User avatar
Feb 14, 2015, 03:28
With commit 6d541f19a2dbd1b8cd6dcf3f8882fddcd1e1f696 the sets that somewhat worked seem to be back to that state. The ones that hung at resetting now hang at "Invalid characterizer".
User avatar
Senior Tester
Feb 14, 2015, 16:10
really need an expert on devices to dig through the code of these games and work out why (for example) the inputs in v4mate / v4crmaze take a few seconds to respond, and the game ultimately ends up with a comms timeout / breakdown.. it's nasty stuff to trace, they've never really worked and always ran in slow motion because of this.

thanks for getting the initial problem fixed tho, long term regressions are some of the most irritating to see :-)
User avatar
Feb 16, 2015, 08:49
There's one main difference between how MAME runs the comms, and how MFME did (or at least, the released source did...) In the MFME driver, the RTS values for the ACIA on the 68k side were passed to *both* DCD pins (6809 side *and* 68k), whereas we just connect each to its opposite number. Just tried that out locally and it's still slow and error-laden though.

By this point, everything I know about that hardware is in the driver, so have at it.
User avatar
Nov 9, 2016, 14:13
Compressed the error log file posted by JWallace.