Simulated netboard - future of linked play in Supermodel?

[gareth_iowc]

daytona.PNG (29.51 KiB) Viewed 169 times

[ Global ]

EmulateNet = 1
port_in = 1970
port_out = 1971
addr_out = 127.0.0.1

Am I missing something?

[MrThunderwing]

daytona.PNG

[ Global ]

EmulateNet = 1
port_in = 1970
port_out = 1971
addr_out = 127.0.0.1

Am I missing something?

I had this error message when I tried overwriting the new Supermodel EXE from the zip files over a fairly old version of Supermodel. Are you using the most up-to-date version of 'normal' Supermodel to generate your congig file and XML document?

[gareth_iowc]

Thanks yes it looks like the copy I had was quite old and it did not include the SDL files that I had previously sourced.

So starting again I have deleted my old copies.

Downloaded the SVN 855 Release and tested without the modified supermodel 3 file and it's working fine but with the modified version it crashes on both 32 and 64bit

Capture.PNG (47.71 KiB) Viewed 157 times

What version would you recommend?

[PDNEJOH]

Thanks yes it looks like the copy I had was quite old and it did not include the SDL files that I had previously sourced.

So starting again I have deleted my old copies.

Downloaded the SVN 855 Release and tested without the modified supermodel 3 file and it's working fine but with the modified version it crashes on both 32 and 64bit

Capture.PNG

What version would you recommend?

For the network-modified build to actually loads, you'll have to run at least 2 or more of instances of it.
Also, make sure each instances is configured correctly (port in, port out, ip addresses)

[njz3]

Big thanks to gm_matthew and others (spindizzy, Ian, ...) who helped directly or not to this major breakthrough.
Just tried running 8 instances of Daytona 2 on same PC, this is just beautiful and exciting!
Impatient to get Scud Race, Dirt Devil and Sega Rally 2 too !

[delo]

Thank you very much for this work !!

I've just tried Daytona 2 successfully with two different PCs connected by lan and it works very great it's amazing. No lag (or not noticeable).

Hopefully sega rally 2 and scud race soon but congratulation for your work

[MrThunderwing]

Yup, what he said. You're going to need to change the settings in your Master and Slave config ini files to match the port in and port out information in the picture and make sure the emulatenet option in both is set to '1'

[gm_matthew]

There had been one small thing bugging me about my implementation of the simulated netboard: each machine transmits its own data, plus most of the data it received during the previous frame. This would mean in an 4 machine link-up for instance, machine #4 transmits its own data, plus the data it received from machine #3 one frame ago, which includes the data from machine #2 two frames ago and the data from machine #1 three frames ago. This means the machines are not exactly synchronized; if one machine sends a command to return to the attract sequence, each successive machine will lag behind by one additional frame. With higher numbers of linked machines, it starts to become noticeable.

But this evening it occurred to me that the real netboard sends and receives data at the same time! In Daytona 2, while a netboard is transmitting data from 0x100, it is receiving data into 0x450. This means when the netboard starts transmitting from 0x450, it is transmitting the new data it has just received, not the old data that was already there! This means when a machine transmits its own data, it manages at least one full loop through all of the other machines, allowing them to be perfectly synchronized with each other.

Here is the code that I was using:

Code: Select all

const int send_size = 848 * (numMachines - 1) + 100;
nets->Send(CommRAM + 0x100, send_size);
auto& recv_data = netr->Receive();
memcpy(CommRAM + 0x450, recv_data.data(), recv_data.size());

And here's what I've changed it to (allowing machines to remain perfectly synchronized):

Code: Select all

for (int i = 0; i < numMachines; i++)
{
   nets->Send(CommRAM + 0x100 + (i * 0x350), 0x350);
   auto& recv_data = netr->Receive();
   memcpy(CommRAM + 0x450 + (i * 0x350), recv_data.data(), recv_data.size());
}

I've included this change in the new build here. Mind you, the new build might have slightly worse performance since each instance now performs multiple smaller send/receives rather than one big send/receive.

I'll take a look at Ian's new asynchronous TCP code soon; I'm hoping I'll be able to use it to improve performance.

[gm_matthew]

Right now the network emulation works by having all of the netboard code run after all of the mainboard code. Nice and simple, but perhaps not optimal for performance.

It would be better to be able to have the netboard code running at the same time as the mainboard code, because then it could take up to 16ms to run all by itself each frame without hurting performance. However, what if the mainboard were to write to a part of memory that is currently being transmitted, or read from memory that is currently receiving data? Any decent programmer who creates multi-threaded programs knows about data races and how problematic they can be.

I think this is why the netboard uses two banks of memory; one is accessible by the mainboard, while the other is used for data transmission/reception. Each frame the IRQ5 handler switches the two banks so that the data written by the mainboard during the previous frame can be transmitted, and data received during the previous frame can be read by the mainboard. All of a sudden it makes perfect sense!

In my next build I'll probably implement bank-switching to allow the mainboard and netboard to run simultaneously without having to worry about any data races.

[Bart]

But this evening it occurred to me that the real netboard sends and receives data at the same time! In Daytona 2, while a netboard is transmitting data from 0x100, it is receiving data into 0x450. This means when the netboard starts transmitting from 0x450, it is transmitting the new data it has just received, not the old data that was already there! This means when a machine transmits its own data, it manages at least one full loop through all of the other machines, allowing them to be perfectly synchronized with each other.

How are they doing this? This would have to be precisely timed. Presumably it is IRQ-driven. Is there a regularly-timed IRQ that occurs as data is being received, causing data to be pulsed out at in lock-step?

I think Nik once noticed there was a reference to a carrier signal in the ROMs, which can mean a number of things. Is it possible that the carrier signal in this case is some sort of a clock pulse that drives this process?