Network code

[Ian]

Spindizzi,
I had a look at lemans24. In nik's version it doesn't even send anything at all. Although the code thinks its transmitting then you get a network error straight away.

Anyway with ours I am pretty sure send_offset could be wrong. Currently we are just sending totally empty packets ie 0x000000000 since the memory is empty
If we dumped the entire memory we should be able to find where the actual send buffer is (assuming it's in the memory). The network data has a very particular pattern followed by 0xFF to terminate the packets.

[Bart]

Haven't dug into how you guys are emulating the network board but are you attempting a high level emulation or are you trying to emulate the network device? Presumably, a pointer is supplied to some device that DMAs the data out?

[Spindizzi]

I'm pretty sure the offset is correct
however, it misses something maybe in init, because I saw at least one time or two, some bytes at this point (00 00 00 ff) or (00 00 ff 00) can't remember exactly
lemans (and von2) start network negociation with
send offset = 0xf000
send size = 0x4
recv offset = 0xf010
recv size = 0x8
(notice : the addresses are the same for dirtdvls but not the size)
actually, master send 00 00 00 00, and slave receive that, but never understand what it is and can't change some byte to answer, it expects 00 00 ff 00 or 00 00 00 ff to give a good answer to the master, (I suppose). So Master and slave wait for packet for now

A thing I can't understand : apparently slave wants to send from 0xf010 and not from 0xf000 like master, that's fooling me because all others games have different address for recv and send (and master and slave have the same)

I use cheat engine to see the memory when running instance without debugger, very handy tool to inspect memory in real time

----

High level, I don't know! 68k cpu is implemented and runs it's own program (the netcode). All registers, memory are modified by 68k cpu or ppc cpu.
Absolutly don't know about direct memory access
I think Nik doesn't add a 68k cpu to the emulation but only changes values in memory himself as result of solicitation (assumption). In fact he has a better understanding of the process because he knows what to answer when events happen

[Bart]

I think Nik was actually emulating the 68K.

[Ian]

If Nik was emulating the 68k he obviously found a way to modify the 68k code to work multi threaded.
Spindizzi,
Yeah I see now It appears to be sending totally empty packets at boot. Since they start with 0xFF ? and then 3 more bytes of nothing

I'm pretty sure the offset is correct

Yes I think you are right. I did a brute force memory search to look for the first occurrence of 0xFF since from my limited poking it seems that marked the end of a packet. Starting from address 0 i got a first hit with the address ‭0xF000‬ which is right where we are sending. So it looks right.

A thing I can't understand : apparently slave wants to send from 0xf010 and not from 0xf000 like master

Maybe each client doesn't need to send the whole buffer? Just sends data from its slot.

it expects 00 00 ff 00 or 00 00 00 ff to give a good answer to the master, (I suppose).

With a send size of 4, I would expect it to send 00 00 00 FF.
FF always marks the packet end? Maybe try just returning that.

[Spindizzi]

The data packet we discuss actually, is the machine count process (with eventually a sync process) I call this frame type 1
As soon as all the machines have responded correctly, there is a reconfiguration of the recv-send address and recv-send size. This allows to receive-send the real datas packet game. I call this frame type 2
ie:
for frame type1 dirtdvls (2cabs)
send off=0xf000 send size=0x10 recv off=0xf010 recv size=0x18
for frame type2 dirtdvls (2cabs) and raw data before treatment (see code)
send off=0x0001 send size=0x801c recv off=0x000f recv size=0x001c

for frame type1 harley (2cabs)
send off=0x0080 send size=0x07 recv off=0x0090 recv size=0x0b
for frame type2 harley (2cabs) and raw data before treatment (see code)
send off=0x0001 send size=0x003a recv off=0x0009 recv size=0xff37

for frame type1 lemans (2cabs)
send off=0xf000 (M) send size=0x04 recv off=0xf010 recv size=0x08
send off=0xf010 (S)
for frame type2 lemans (2cabs)
unknown for now but certainly this
send off=0x0001 send size=0x8??? recv off=0xc00d recv size=0x????

Maybe each client doesn't need to send the whole buffer? Just sends data from its slot.

this is entirely possible, but this also means each game work differently...

I do not put my hand to the fire saying packet will be terminated by 0xff and we don't care, because all is based on packet/slot size
I think it's only predetermined data with only 2-3 bytes of real datas in the case of type1 frame
this is an example of type1 frame exchange between 2 cabs(scud, skichamp and some others) aka machine count frame exchange
the values of 0x90 and 0x68 are fixed
M : 90 00 00 68 00 00 00
S : 90 00 00 68 01 00 01
M : 90 00 09 68 00 00 00
S : 90 00 09 68 01 00 01
M : 90 00 ec 68 00 01 00
S : 90 00 ec 68 01 01 01

the 0xff for lemans would certainly acts as 0x90 and 0x68 for the other games

[Ian]

What is the master waiting for, to go further?

[Spindizzi]

Good question, if I knew that....
may be the same thing that it sends

[Ian]

How hard would it be to see trace the assembly to see what it expects?
I guess it will read those values out of common ram and do a comparison somewhere

[Ian]

Finally got a chance to try Spindizzi's updated network code
And ..

https://i.imgur.com/21tEFF6.jpg

Might have to disable EmulateNet in the ini to setup the network part
But once it's setup seems to mostly work