Supermodel Forum

Sorry for the lack of explanation
The previous post is an emulated netboard on the r858
The frame rate is low because multithreading is disabled

Google Translation

I did a bit of debugging to see how the sends/receives are happening
Didn't realise each machine is doing 3 send/receives per frame (well scud is)
Quick log

machine 1

send duration 0ms
rec duration 0ms
send duration 0ms
rec duration 0ms
send duration 0ms
rec duration 58ms
send duration 0ms
FrameComplete

machine 2

send duration 0ms
rec duration 0ms
rec duration 0ms
send duration 0ms
send duration 0ms
rec duration 54ms
rec duration 3ms
send duration 0ms
FrameComplete

You can see machine 2 is doing, double sends/receives. This is probably where the delay is happening. Again causing some kind of TCP deadlock until machine 1 loops around and sends data again.

Ian wrote:I wonder if the send and receive commands are swapped over. There must be some reason why the emulation blocks for an entire frame waiting for the data to arrive. If we can figure this out it should work at basically full speed.

I’ve figured out exactly what’s causing the slowdowns, at least in Daytona 2 and Scud Race: it’s due to the netboards being slightly out of sync. I’ll post details later this evening.

I was actually thinking the same. One board is executing network code whilst the other is doing rendering or something. So the first netboard is blocked until the other starts sending. The question is how to sync them? How is it done on the real hardware?

I have an idea as to how to keep the netboards synchronized properly.

My idea involves having Supermodel perform the actual send/receive functions at fixed intervals. When the netboard makes a send/receive request, we do not perform it straight away; we continue executing 68K cycles and we fire an IRQ4/IRQ6 after the actual send/receive operation is performed. If the netboard isn’t actually sending any data, then we send an “empty” packet. If the netboard makes a receive command but we receive an “empty” packet, we don’t fire an IRQ6 so the netboard has to keep waiting. Here’s what the loop could look like:

Code: Select all

if netboard is sending data
    send data packet
    fire IRQ4
else
    send “empty” packet
receive packet
if netboard is receiving data and packet is not “empty”
    copy data into CommRAM
    fire IRQ6
execute cycles

Since the games I’ve analyzed so far perform two send and receive operations per frame, we would need to run this loop multiple times per frame. This way, we would no longer be dependent on IRQ5 for synchronization so we could fire IRQ5 just once per frame as on real hardware.

That should work. Normally sending an empty packet will kill the connection as if recv returns 0 it means the tcp connection has closed. But we append a header which is the data size. Might have to modify the receive class a bit to handle this but it should work. So your idea is to sync them with a blocking receive call?

How does syncing happen on the real hardware?

Ian wrote:That should work. Normally sending an empty packet will kill the connection as if recv returns 0 it means the tcp connection has closed. But we append a header which is the data size. Might have to modify the receive class a bit to handle this but it should work. So your idea is to sync them with a blocking receive call?

How does syncing happen on the real hardware?

I'm pretty sure that IRQ5 must not occur while data is being sent/received so IRQ5 must happen at around the same time on all linked netboards, but if one system were to run just 0.0001% slower or faster than the others they'd go out of sync within five hours of operation. I'm afraid I don't know exactly how the linked systems avoid this.

Also, there's a mistake in my suggested loop in that it would not scale well with more players; each successive machine would lag behind by one additional cycle, increasing the amount of time the master netboard has to wait for a response. I'm sure I'll figure out a better way of making it work.

The renderer on the model3 has a sort of hard 60fps (57.5fps) lock.
Basically even if the frame hasn't completed rendering it'll just swap buffers and present the image regardless. It also had some way to mitigate the damaged cause by incomplete frames. If it detects what's known as an overload condition, it can auto switch to lower LOD models, or not render them altogether. In ocean hunter in attract mode, there is a place where the entire sea surface doesn't render. It shows up in the emulator, but not on the real hardware. I'm pretty sure this is triggering an overload condition on the renderer, just due to the sheer number of polys it is pushing in this particular scene.

Anyway once in synced they should stay in sync. Vsync must happen at regular clock intervals.

My concern with one machine running 0.0001% slower or faster isn’t about the video board falling behind with rendering graphics; the vsync signal happens regardless. My concern was that ultimately, vsync must be derived from the pixel clock which is defined as 16 MHz - what if, due to age, temperature variations or something else, one system has a pixel clock speed of 16.000016 MHz? That would cause the 0.0001% drift I’ve been talking about.

Maybe Sega used especially accurate clock crystals. Maybe they have some means of compensating for frequency variations. I am certainly not an electronics expert; my theories as to how the netboard works are mainly down to studying the disassembly of netboard code.

On a modern PC it doesn’t matter so much anyway as neither TCP nor UDP require precise timing like the real netboard does.

I dunno, I wouldn't worry about such clock drifts. Sure they do happen but nothing a reboot can't fix lol