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|
|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|
Example sets: v4big40, v4sunbst, v4vgpok
Suspect breakage in r27839 (Rewritten 6850 commms)
|Affected Sets / Systems||Many sets in mpu4vid.c|
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.|
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.
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".|
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 :-)
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.
Nov 9, 2016, 14:13
|Compressed the error log file posted by JWallace.|