midvunit.cpp linking (Cruis'n World, Cruis'n USA)

[modakuku]

There is no support for LAN Play on these classics, we should be able to link up to 4 players.
Info I could gather about how the LAN stuff works so far:
http://forum.arcadecontrols.com/index.php?topic=137697.80
https://www.mameworld.info/ubbthreads/showflat.php?Cat=&Number=379199

There are no warnings about LAN Play when starting these games so I'm assuming this is just something that not many people noticed.

[Hydreigon223]

Please disregard what I said years ago. At the time, I was in quite an angry mood figuring out its network system due to working with a sync related issue when linking these games with LCD monitors. I didn't give any accurate information then because I didn't look through things carefully. I had plans years ago to implement the 'NODEVICE_LAN' flag through a PR but personal problems prevented me from doing so.

What we know:

• Networking is controlled through a PAL located at U111 named 'A-19673' (address 0x997000-0x997008). The so called link PAL at U38 actually controls additional interrupts with the difference between the link PAL and non-link PAL adding the link interrupt. It links through a multidrop or bus style topology (see Bus network topology support? #9101) to link three or more pcbs for Cruis'n World and Off Road Challenge as Cruis'n USA can only link up to two pcbs.
• Network information sent to slave machines can also tell the GPU to adjust its sync/refresh rate on the fly. Most likely won't be a problem in emulation but is a problem on some LCDs temporarily losing the video signal should a slave pcb change its video signal.
• There was an old fork that attempt its networking but has its share of issues. The person who made this had to change some stuff in the main CPU, TMS320C31, source file, disable the sound and run all linked units in one instance. Judging by all these changes, the TMS320C31 core is most likely to blame.

Networking like this is just the tip of the iceberg.

[Risugami]

Main issue is that this link was designed around identical CPUs all running in sync, and MAME does a burst of instructions all at once for each CPU. Emulating each machine in one instance works if you can remove the burst and let each CPU step through each instruction. If you can figure out how other emulators implement their network link cables, that might prove useful here.

There also might have been one additional piece to the puzzle with a missing hardware interrupt, but would've only had evidence to it ever being used in early Cruis'n USA versions. As far as I could tell it went unused.

[Hydreigon223]

Main issue is that this link was designed around identical CPUs all running in sync, and MAME does a burst of instructions all at once for each CPU. Emulating each machine in one instance works if you can remove the burst and let each CPU step through each instruction. If you can figure out how other emulators implement their network link cables, that might prove useful here.

There was a commit around a month ago for UDP multicast support which would allow for 'many to many' communications similar to that of an ethernet hub where everyone receives everything simultaneously. Because V-Unit uses a multicast topology (compared to Sega and Namco using ring topology), this approach would greatly work in its favor.

Unfortunately, this commit got reverted due to compatibility problems and a new approach is being in the works right now. When this will get done is yet to be determined. You can view the full story here: #9744

[smf-]

Which emulator are you thinking of? It's not just a case of figuring out how they do it, but whether it would be useful.

…

On 29/06/2022 01:35, Risugami wrote:  If you can figure out how other emulators implement their network link cables, that might prove useful here. Message ID: ***@***.***>

[cuavas]

This isn’t really a network link cable, though. This is just a simple mailbox between the CPUs. You always get these kinds of issues when you have multiple reasonably fast CPUs that communicate with shared state and expect fast synchronisation. Sega 32X is another good example – pretty much every software emulator has timing issues because the software on the two SH2 CPUs communicates using simple semaphores in shared memory. Using a timeslice-based scheduler means the CPUs end up waiting for a lot longer to see the activity from the other side than they would in real life.

There are a bunch of ways to get around the issues, none of which are really practical to do in MAME:

• Make the timeslices really small, maybe short enough to allow no more than one or two instructions. This causes a lot of overhead going through the scheduler.
• Make a device representing the two CPUs and the shared memory/mailbox/whatever. This can interleave accesses properly. However it’s a pile of system-specific code for every case.
• Automatically take a save state at the start of every timeslice, and roll back and try a smaller timeslice if a data race is detected. This requires emulated shared memory accesses to go through an expensive trampoline to check for potential races. Saving/restoring state gets expensive for systems with a substantial amount of memory/state, too. You can also end up retrying a timeslice several times, which has a performance penalty.
• Use an FPGA with the CPU blocks in the same clock domain. Then your shared memory accesses are naturally interleaved properly. This is why the MiSTer 32X core doesn’t suffer from these issues. If you were going to choose a system that does magically work better in an FPGA emulator, 32X would probably be it.