Simulated netboard - future of linked play in Supermodel?

[gm_matthew]

UPDATE 2: The simulated netboard has been officially added to the SVN! You can find the latest Windows build on the download page and the source is available at Sourceforge.

UPDATE: Looking for my latest experimental build? You can find it here - supports all games except Sega Rally 2.

Recently I've been taking an interest in Supermodel's network emulation, since it is still very much unfinished; some games do not work in linked mode, and those that do suffer greatly reduced performance compared to non-linked mode. Efforts to improve the netboard emulation have been largely fruitless, but during my efforts I observed how linked play in Daytona USA 2 and later Le Mans 24 worked: once the netboards had started up and completed self-testing, they pretty much ran by themselves sending and receiving data to/from one another.

It was at this point where I asked myself: couldn't I just replicate the same process directly within Supermodel? In other words, would simulating the netboard work?

The answer turned out to be a resounding yes! And it turned out to be much easier than I expected!

I have already got Daytona USA 2 and Le Mans 24 working with two machines linked together. Here's a screenshot of Le Mans 24 running in linked mode within my custom build of Supermodel:



One major advantage of simulating the netboard rather than emulating it properly is that the game can run at full speed. Also, multithreading now works fine which will further improve performance on less powerful systems. The disadvantage is that each game has to individually simulate the netboard in its own way, but since there are only nine unique games that actually utilize the netboard it shouldn't be too difficult to eventually get them all working.

To whet your appetites, I've uploaded a build of Supermodel that supports two machines linked together in Daytona USA 2 (both BOTE and PE) here; the link is valid for one week. If anyone would like, I can upload a separate build that supports two linked machines in Le Mans 24.

Please note that no other games will work in linked mode in this particular build, nor will Daytona 2 work with any more than two players. Also, the game can break if you enter and leave the service menu on one machine while the other is still running. This is an experimental build, so there may be other problems that I have yet to uncover; do not use this as a replacement for your existing version of Supermodel!

[Ian]

Simulation would probably work, although not sure what the differences are between each game. Maybe custom solutions are required.
It was only Spindizzi working on network emulation, and I don't think he has worked on it in some time.
The reason games work so slow is due to the way sending and receiving works. Games currently wait a full frame to receive the data, and are blocked in this state. So games are basically locked to 30fps. Maybe we are sending/receiving the data at the wrong point, I don't know.

I did at one point hypothesize that we could capture actual data between the 2 arcade units. Would have to be like a raw capture of the data, ie raw sampling of the light. Would then have to be de-coded. Would probably be something like manchester encoding. Anyway just random thoughts.

[xbrunox]

A version for Sega rally2?

[MrThunderwing]

To whet your appetites, I've uploaded a build of Supermodel that supports two machines linked together in Daytona USA 2 (both BOTE and PE) here; the link is valid for one week. If anyone would like, I can upload a separate build that supports two linked machines in Le Mans 24.

Well, this is cool, a full speed networked version of Daytona 2 is something I've been wanting to try out for ages now. How do you actually get this custom build linked up though? I've tried setting it up the same way I get the regular version of Supermodel to work as a network. As the zip didn't come with a config file, I just overwrote the custom build over two previous versions of Supermodel I had working in a 2P network. When I start up both versions of the emulator (via a batch file) they both load up but I get the 'network board not present' error screen. I've tried this with the EmulateNet option in the config set to both on (1) and off (0) but the result is the same either way in both versions of Daytona 2. Can you provide a little 'how to get it working' guide please? Thanks!

I'd definitely be interested in the Le Mans version too.
(Oh, and just noticed you're a fellow Bristolian! Alright me babs?)

[gm_matthew]

When I start up both versions of the emulator (via a batch file) they both load up but I get the 'network board not present' error screen. I've tried this with the EmulateNet option in the config set to both on (1) and off (0) but the result is the same either way in both versions of Daytona 2.

That's odd. It should at least acknowledge the presence of the netboard as long as EmulateNet is set to 1 and the netboard tag in the XML file is set to true.

If it helps, I've updated the zip file; it should now have two folders, master and slave. All you have to do is add the Daytona 2 ROM to each one and it should be ready to go.

(Strictly speaking I live 10 miles away from Bristol, but it's part of my postal address so I say it counts. Almost never heard anyone say "gert lush".)

[gm_matthew]

Simulation would probably work, although not sure what the differences are between each game. Maybe custom solutions are required.
It was only Spindizzi working on network emulation, and I don't think he has worked on it in some time.
The reason games work so slow is due to the way sending and receiving works. Games currently wait a full frame to receive the data, and are blocked in this state. So games are basically locked to 30fps. Maybe we are sending/receiving the data at the wrong point, I don't know.

Indeed the way sending and receiving works is part of the reason Le Mans 24 doesn't work with the emulated netboard. On real hardware, during the self-testing routine the master netboard would make multiple send and receive requests (64 to be exact) before it would actually receive any data, but Supermodel blocks after each receive request until the data is received. The data never arrives as the slave netboard makes its own receive request, causing a TCP deadlock.

Most likely each game will need its own initialization procedure to make the mainboard think that the netboard self-testing has completed successfully. After that it's mostly a case of sending and receiving the appropriate data each frame, but certain games may have additional requirements.

Here's a sample of the code I'm using to get Daytona 2 running:

Code: Select all

   switch (state)
   {
   case netboard_state_start:
      *(UINT16*)&ioreg[0x8a] = 0xe000;
      *(UINT16*)&ioreg[0x88] = 0;
      state = netboard_state_init;
      break;
   case netboard_state_init:
      if (*(UINT16*)&ioreg[0x88] & 0x8000)               // has main board changed this register?
      {
         *(UINT8*)&ioreg[0] = *(UINT8*)&ioreg[0] | 0x01;      // simulate IRQ 2 ack
         if (*(UINT16*)&ioreg[0x88] == 0xf000)
         {
            // initialization complete
            *(UINT16*)&ioreg[0x8a] = 0;
            *(UINT16*)&CommRAM[0x72] = 1;
            state = netboard_state_testing;
         }
         *(UINT16*)&ioreg[0x88] = 0;                     // 0 works for all init subroutines
      }
      break;
   case netboard_state_testing:
      // we skip testing and immediately return the results
      *(UINT16*)&ioreg[0x8a] = 2 * 0x20 + 0x2001 + RAM[0x400];      // 2 machine test
      *(UINT16*)&ioreg[0x88] = 0;                              // supposed to cycle between 0, 1 and 2; doesn't seem to matter

      *(UINT16*)&CommRAM[0x0] = *(UINT16*)&RAM[0x400];
      *(UINT16*)&CommRAM[0x2] = 1;
      *(UINT16*)&CommRAM[0x4] = *(UINT16*)&RAM[0x400];            // quick hack for 2 players
      *(UINT16*)&CommRAM[0x8] = 0x5004;
      *(UINT16*)&CommRAM[0xa] = 0x9f3b;
      *(UINT16*)&CommRAM[0xc] = 0x0001;
      *(UINT16*)&CommRAM[0xe] = 0xa03d;

      state = netboard_state_running;
      break;
   case netboard_state_running:
      *(UINT16*)&CommRAM[0x6] += 1;
      nets->Send((const char*)CommRAM + 0x100, 0x3214);
      auto& recv_data = netr->Receive();
      memcpy(CommRAM + 0x450, recv_data.data(), recv_data.size());
   }

At the moment I've hard-coded the values for two linked machines, hence why it won't work with any other number of machines; I just wanted to see if it would work with two. The proper way to do it would be to have the master send the number 1 and have each slave increment it, so that the master receives back the total number of machines linked together.

[xbrunox]

Man U are GREAT!

Daytona in LINK on my two cab works great! i can enable multythread too!

https://youtu.be/8kadnDNRjvM

[Bart]

Bravo! This is awesome! Nik had ultimately wanted to do something like this for performance reasons. If we understand the net protocol, it might be possible to try to mitigate latency with techniques like rollback, but that really depends on how exactly the protocol works and how the games are running their physics. It's quite likely that the games rely on the low latency fiber optic link to update themselves in lock-step.

It could also shed some light on a more accurate netboard emulation which would also be desirable for both preservation purposes but also because some people have expressed interest in linking real Model 3 boards against PCs (admittedly, this is a super niche use case).

[Ian]

With the current code tcp sending will start to block when the socket buffer is full. It needs the receiver to receive the data to unblock. We also used a blocking receive.

How can we improve things? How does it work on the real hw? It sends 64 requests? Does it just check once a frame to see if the data has actually been received?

[Jiterdomer]

Good job! Hopefully you can do this on Scud Race! Anyways, I opened up my channel called #model3-networking on Supermodel Discord to discuss anything related to WIP of the Model 3 Network Emulation and other stuff.