I think you have to try to think like the people who built these programs / protocols...
For example..
What kinds of things would you need to communicate with the other machines to make everything work?
What kinds of things could cause problems with communications?
What effects would happen from missed data?
What kinds of things could you do to remedy such problems.. keeping the game functionally usable?
I think that there is an internal timer that each game checks, and communicates with each other. That way, even if somehow a packet was lost, lagged, or corrupted.. the system would know how to piece the information together to make things work properly.
It would seem that if theres some sort of lag in one machine.. the others try to compensate by pausing or tossing out data. ?? Causing the flicker frame issues.
By changing the data, the game goes ape, probably because the values are tied into each other. It might be trying to reverse engineer what actually took place and fix that with a certain process. Each time theres a communication break, its going to do Something.. because the game needs to know what things are where, to process collisions and keep accurate race positions and finish-line status.
I would guess that if a systems link got totally busted while multiple racers were at it... after a series of missed connections, it would eventually either give up and create an error / reboot.. or would carry on and start making artificially intelligent assumptions about where things were supposed to be based on last know data... and eventually may realize it would just need to take full control as if it were a single player game. (either having the cars auto drive at a set pace, cars coast to a stop as if the driver fell asleep, using AI to drive them competitively, or remove them completely)
Other things to think about... is that if all the machines were turned on at different times... wouldnt that mean that the scanline timing between all of them would possibly be different between each monitor? As such, trying to tie things into frames may be an issue. Especially since even if a game isnt displaying whats happening.. things are still taking place.
As such, precise data about 'times' is going to be very critical, and stamped and tied into everything that is done.
Some other things to consider...
- They may take into consideration things like slower cpu processing, due to overheating issues. IE: clogged fans, thermal paste drying out, and or failing caps / components. Thats common with pc based equipment.. but, not sure how much a factor it is with non pc based machines... or at least, games that are much older that probably didnt have those kinds of issues.
- Check out other Sega (and non sega) game link protocols... (especially from that time period) and or look up the programmers that worked on these games.. and see what other games they have dabbled in. I think one of the guys who worked on a sega game was from the usa.. and did a lot of custom AI coding.
- Remember that in many Sega games... game timers are different from CPU / motherboard timers. Game-Time may be completely inaccurate to real-time seconds for example. The clock could also conceivably speed up or slow down a bit, depending on many factors.. from problems to an actually designed feature. While each timer may be used differently.. each is also critical in different ways to the way the programs use them.
Im not a programmer.. as Im not good enough with the abstract thinking and complex math... but the basic foundation of programs are usually rooted in basic logic and reasoning. The biggest hurdle for arcade games programs, may be in understanding the hardware enough to know why certain things are 'logical and reasonable'... heh