Simulated netboard - future of linked play in Supermodel?

[Ian]

They probably don't occur at exactly the same time, but the connections are presumably full duplex, after all there is a separate fiber connection for sending and receiving.

[gm_matthew]

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?

Well we know that the data transmission and reception rates must be the same; no point sending data faster than the next netboard can receive it, or vice versa. If the data rate is around 8 Mbit/s, that means a gap of around 0.85 ms or around 10,000 CPU cycles between receiving data and re-transmitting it.

[buttersoft]

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... What version would you recommend?

I've been testing it out, and the only way i can get things to work is by using the complete dump gm_matthew posted on the first page - the one containing the master and slave diretories with complete setups already in each. Adding roms to that works fine for daytona. Adding the latest exe he posted today, and then adding lemans24 works fine. You can run each instance one at a time to set up, then run both.

Trying with R855 works fine as it comes, but adding any of the new networked supermodel.exe files just hangs for me. The window comes up and stays black and then has not responding on it after a few seconds, just like you posted.

The problem here is that gm_matthew seems to have updated his link, so you can't get the complete archive with the already-set-up master and slave directories, you can only get one of the updated exe's.

gm-matthew, are we ok to share that older archive, or would you prefer to update it first?

[gm_matthew]

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... What version would you recommend?

I've been testing it out, and the only way i can get things to work is by using the complete dump gm_matthew posted on the first page - the one containing the master and slave diretories with complete setups already in each. Adding roms to that works fine for daytona. Adding the latest exe he posted today, and then adding lemans24 works fine. You can run each instance one at a time to set up, then run both.

Trying with R855 works fine as it comes, but adding any of the new networked supermodel.exe files just hangs for me. The window comes up and stays black and then has not responding on it after a few seconds, just like you posted.

The problem here is that gm_matthew seems to have updated his link, so you can't get the complete archive with the already-set-up master and slave directories, you can only get one of the updated exe's.

gm-matthew, are we ok to share that older archive, or would you prefer to update it first?

I've updated the zip file to include the SDL2 DLLs, in case there's some kind of incompatibility going on with different versions of the DLLs. I'm not otherwise sure why it would be hanging at a black screen unless the network settings are not correctly configured.

Does my build placed into the existing SVN folder work when networking is turned off?

[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... What version would you recommend?

I've been testing it out, and the only way i can get things to work is by using the complete dump gm_matthew posted on the first page - the one containing the master and slave diretories with complete setups already in each. Adding roms to that works fine for daytona. Adding the latest exe he posted today, and then adding lemans24 works fine. You can run each instance one at a time to set up, then run both.

Trying with R855 works fine as it comes, but adding any of the new networked supermodel.exe files just hangs for me. The window comes up and stays black and then has not responding on it after a few seconds, just like you posted.

The problem here is that gm_matthew seems to have updated his link, so you can't get the complete archive with the already-set-up master and slave directories, you can only get one of the updated exe's.

gm-matthew, are we ok to share that older archive, or would you prefer to update it first?

I've updated the zip file to include the SDL2 DLLs, in case there's some kind of incompatibility going on with different versions of the DLLs. I'm not otherwise sure why it would be hanging at a black screen unless the network settings are not correctly configured.

Does my build placed into the existing SVN folder work when networking is turned off?

With the latest link you shared it will load with EmulateNet set to 0. The previous version would crash. The SDL files didn't appear to make any difference when I tested.

As I was pointed in the right direction if anyone else is stuck with it crashing when loading the rom you must have EmulateNet set to 1 and the ports configured and a minimum of two copys running!

matt this is AWESOME!!!!

[Bart]

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?

Well we know that the data transmission and reception rates must be the same; no point sending data faster than the next netboard can receive it, or vice versa. If the data rate is around 8 Mbit/s, that means a gap of around 0.85 ms or around 10,000 CPU cycles between receiving data and re-transmitting it.

Right but is there an IRQ generated when data is finished, prompting a transmission (which would still happen within the same frame)? Or do you think the transceiver operates in some sort of lock-step mode where it receives and transmits simultaneously on the same clock?

[MrThunderwing]

I've made a couple of ICO files you use if you're launch the games with batch files. I've attached them as Zip files to this post.

[gm_matthew]

Right but is there an IRQ generated when data is finished, prompting a transmission (which would still happen within the same frame)? Or do you think the transceiver operates in some sort of lock-step mode where it receives and transmits simultaneously on the same clock?

I reckon it's probably the latter. I'm positive that the netboard must be sending and receiving data simultaneously, because no other explanation makes sense. There are IRQs generated when sending/receiving data is complete (IRQ4 and IRQ6 respectively), but during the main data transfer neither Daytona 2 nor Le Mans 24 wait for one to complete before starting the other. Here's one of the send/receive subroutines from the Daytona 2 netboard code:

Code: Select all

0x00001438: 0x4238 0x0611                       CLR.B    0x611
0x0000143C: 0x4238 0x0610                       CLR.B    0x610
0x00001440: 0x1D7C 0x0080 0x001B                MOVE.B   #0x80,(0x1B,A6)
0x00001446: 0x1D7C 0x0080 0x0015                MOVE.B   #0x80,(0x15,A6)
0x0000144C: 0x1D7C 0x008C 0x0017                MOVE.B   #0x8C,(0x17,A6)
0x00001452: 0x3B78 0x0616 0x00C0                MOVE.W   0x616,(0xC0,A5)
0x00001458: 0x1D7C 0x008C 0x001D                MOVE.B   #0x8C,(0x1D,A6)
0x0000145E: 0x4E75                              RTS

It's hard to say exactly what the hardware does with each individual command, but what I do know is that a combination of writing 0x80 to ioreg[0x1b] and 0x8c to ioreg[0x1d] starts sending data, and writing 0x80 to ioreg[0x15] and 0x8c to ioreg[0x17] starts receiving data. The hardware fires an IRQ4 when data transmission is complete, and an IRQ6 when data reception is complete. (The emulated netboard doesn't exactly work this way.) Each IRQ exception handler sets a specific flag to let the main program know that an IRQ has occurred.

Here's a bit of the Daytona 2 netboard code where the main data transfer takes place:

Code: Select all

0x00001086: 0x007C 0x0700                       ORI      #0x700,SR          ; disable interrupts
0x0000108A: 0x6100 0x02F8                       BSR      *+0x2FA [0x1384]   ; set send/receive parameters
0x0000108E: 0x6100 0x03A8                       BSR      *+0x3AA [0x1438]   ; send and receive data (subroutine listed above)
0x00001092: 0x027C 0xF8FF                       ANDI     #0xF8FF,SR         ; enable interrupts
0x00001096: 0x6100 0x01CC                       BSR      *+0x1CE [0x1264]   ; wait until IRQ 4
0x0000109A: 0x4A38 0x0611                       TST.B    0x611              ; IRQ 6 check; branch if flag is set
0x0000109E: 0x6600 0x000C                       BNE      *+0xE [0x10AC]
0x000010A2: 0x4A38 0x0608                       TST.B    0x608              ; try again if no IRQ 5
0x000010A6: 0x67F2                              BEQ.S    *-0xC [0x109A]
0x000010A8: 0x6000 0x0010                       BRA      *+0x12 [0x10BA]    ; error - data not received

The CPU calls the subroutine to start both sending and receiving data, and only then does it wait for the IRQ4 flag to be set to check that data transmission is complete. It then checks the IRQ6 flag; it might not necessarily have finished receiving data (maybe the previous netboard had a small delay before starting its own data transmission) but as long as the data is received before the next IRQ5 happens, everything is fine.

[Bart]

Right but is there an IRQ generated when data is finished, prompting a transmission (which would still happen within the same frame)? Or do you think the transceiver operates in some sort of lock-step mode where it receives and transmits simultaneously on the same clock?

I reckon it's probably the latter. I'm positive that the netboard must be sending and receiving data simultaneously, because no other explanation makes sense. There are IRQs generated when sending/receiving data is complete (IRQ4 and IRQ6 respectively), but during the main data transfer neither Daytona 2 nor Le Mans 24 wait for one to complete before starting the other.

I wonder why two IRQs are needed if the operations happen simultaneously.

Here's one of the send/receive subroutines from the Daytona 2 netboard code:

Code: Select all

0x00001438: 0x4238 0x0611                       CLR.B    0x611
0x0000143C: 0x4238 0x0610                       CLR.B    0x610
0x00001440: 0x1D7C 0x0080 0x001B                MOVE.B   #0x80,(0x1B,A6)
0x00001446: 0x1D7C 0x0080 0x0015                MOVE.B   #0x80,(0x15,A6)
0x0000144C: 0x1D7C 0x008C 0x0017                MOVE.B   #0x8C,(0x17,A6)
0x00001452: 0x3B78 0x0616 0x00C0                MOVE.W   0x616,(0xC0,A5)
0x00001458: 0x1D7C 0x008C 0x001D                MOVE.B   #0x8C,(0x1D,A6)
0x0000145E: 0x4E75                              RTS

It's hard to say exactly what the hardware does with each individual command, but what I do know is that a combination of writing 0x80 to ioreg[0x1b] and 0x8c to ioreg[0x1d] starts sending data, and writing 0x80 to ioreg[0x15] and 0x8c to ioreg[0x17] starts receiving data. The hardware fires an IRQ4 when data transmission is complete, and an IRQ6 when data reception is complete. (The emulated netboard doesn't exactly work this way.) Each IRQ exception handler sets a specific flag to let the main program know that an IRQ has occurred.

These commented disassemblies and any notes you could write up (in due time, of course) will be super valuable to both MAME and Supermodel down the road if we decide to provide an emulation (which may end up not being necessary given your work unless there are some games that use a radically different variant of the net board driver).

I also wonder whether it would be possible to deduce the type of transceiver chip from the register layout. We may want to pass this documentation to Stiletto, who has handled this sort of datasheet archaeology for the MAME team. I'll bet that it's based on a standard chip but in all likelihood, it was something from a Japanese vendor like Fujitsu for which no data sheets exist anymore.

Re: the send and receive, triggering the send makes sense but I wonder what exactly it means to trigger reception. The hardware doesn't really have a choice as to when something comes down the wire (unless there is hardware-level signaling between senders and receivers, which I suppose is totally possible for point-to-point fiber links). Again, my lack of experience here shows. I should ask a friend of mine working on FPGAs in the trading space.

Here's a bit of the Daytona 2 netboard code where the main data transfer takes place:

Code: Select all

0x00001086: 0x007C 0x0700                       ORI      #0x700,SR          ; disable interrupts
0x0000108A: 0x6100 0x02F8                       BSR      *+0x2FA [0x1384]   ; set send/receive parameters
0x0000108E: 0x6100 0x03A8                       BSR      *+0x3AA [0x1438]   ; send and receive data (subroutine listed above)
0x00001092: 0x027C 0xF8FF                       ANDI     #0xF8FF,SR         ; enable interrupts
0x00001096: 0x6100 0x01CC                       BSR      *+0x1CE [0x1264]   ; wait until IRQ 4
0x0000109A: 0x4A38 0x0611                       TST.B    0x611              ; IRQ 6 check; branch if flag is set
0x0000109E: 0x6600 0x000C                       BNE      *+0xE [0x10AC]
0x000010A2: 0x4A38 0x0608                       TST.B    0x608              ; try again if no IRQ 5
0x000010A6: 0x67F2                              BEQ.S    *-0xC [0x109A]
0x000010A8: 0x6000 0x0010                       BRA      *+0x12 [0x10BA]    ; error - data not received

The CPU calls the subroutine to start both sending and receiving data, and only then does it wait for the IRQ4 flag to be set to check that data transmission is complete. It then checks the IRQ6 flag, but it might not necessarily have finished receiving data (maybe the previous netboard had a small delay before starting its own data transmission). As long as the data is received before the next IRQ5 happens, everything is fine.

This makes more sense actually. The send is triggered first, the receive is triggered right after. This seems to imply that they are pretty confident that the send will always precede the reception of new data, which maybe suggests that reception cannot be "requested" but that it just happens and has to be buffered by the device. I wonder if the device itself has memory and these are actually just the DMA transfers.

How big are these buffers?

[Ian]

If it would help make emulation easier i could do a bit more c++ magic and use std::function and some lambda pointers so you could basically setup the receive class to copy directly into the memory locations you want. Ie you supply the logic and it will get automatically executed. No polling or waiting required. Maybe a mutex would be required when the thread is writing.