05498: Many sets in mpu4vid.c: Gameplay stops at a "Serial Link Failure" screen

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	barcrest/mpu4vid.cpp
Version	0.153	Fixed in Version	0.159	Build
		Fixed in Git Commit		Github Pull Request #

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)
Github Commit

Flags
Regression Version	0.153
Affected Sets / Systems	Many sets in mpu4vid.c

Attached Files	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

No.11073 JWallace Developer 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.
No.11459 crazyc Developer 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".
No.11463 Haze 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 :-)
No.11467 JWallace Developer 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.
No.13342 Fujix Administrator Nov 9, 2016, 14:13	Compressed the error log file posted by JWallace.