wifi notes dump



Port 244

seems to be for forcing the side-effects of IRQs?

bit6: ??? seems to fuck up MP replies
bit7: ??? no effect on TX_SEQNO
bit12: when set, TX_SEQNO increases in an erratic way (starts slow then goes superfast)

the following code was found:
which seems to fake an IRQ12 or something like that


Port 118 -- CMD_COUNT

"when it reaches zero, CMD packet is transferred" -- wrong. it's transferred before the timer reaches zero.

seems the transfer starts ~2ms after the counter starts decrementing
but my observations show that a LOC1 transfer also has similar delays, it fluctuates. probably depends on whenever it can find a window where nobody else is sending shit. apartment complex = quite a few wifis around, so yeah.

so chances are the transfer is meant to start immediately, or rather, as soon as possible.

CMD_COUNT is the window during which the transfer is possible. if there isn't enough time remaining when it tries to send, it marks it as failed (sets first word of TX header to 0x0005) and triggers IRQ12.

in that case, CMD_COUNT is 0xA at the time IRQ12 is triggered.

also, TXSEQNO is incremented. seems IRQ12 does that. IRQ7 also does it except when it's for the CMD ack.

if clients fail to reply, CMD transfer will keep retrying until the time runs out. final attempt is marked by IRQ12 -- any previous attempts only get IRQ1.

but seems in that case TXSEQNO is incremented upon IRQ1??

also, for CMD transfers, TXSTAT bit0 is only set when the transfer completes properly (ie. gets replies). otherwise, bit0 is cleared/not set(?), but bit1 isn't set.


Port 210 -- TX_SEQNO

incremented under the following conditions:

* when starting a transfer (except for CMD ack)
* upon IRQ1 when retrying a transfer (atleast with CMD)
* upon IRQ12



Port 008 -- TXSTATCNT

bit0-7: effect unknown, but they fuck things up
bit8-11: unknown, no effect observed
bit12: trigger IRQ1 and set TXSTAT bit8-11 to 0x4 when MP reply transfer is done (doesn't apply to default-empty replies)
bit13: trigger IRQ1 and set TXSTAT bit8-11 to 0xB when MP ack transfer is done
bit14: trigger IRQ1 and set TXSTAT bit8-11 to 0x8 when MP cmd transfer is done
bit15: trigger IRQ1 and set TXSTAT bit8-11 to 0x3 when beacon transfer is done



Port 268 -- RXTXADDR

when sending default (empty) MP reply: random, seems to be left untouched from previous RX
when sending MP ack: reads 0xFC0



Multiplayer transfer sequence

1. host sends data via CMD, clients receive it normally
2. host waits for clients to reply, clients reply automatically (which seems to be completely transparent to their operation and only needs port 094 configured), host receives client replies normally
3. host sends ack, which is automatic (albeit signalled by IRQ7), clients receive the ack like a normal packet

may not be right, but experiments with a modified NSMB ROM showed that:
* client-reply transfers don't trigger IRQ7 and don't seem to trigger IRQ1 either wrong
* the client (Luigi) wants to see the final ack

____________________
Kuribo64

as far as I could see in desmume, enabling the TXT hack or using OpenGL fixes the text

in melonDS, no issues with the text

____________________
Kuribo64

Under Linux you'll have to run it from a terminal.

____________________
Kuribo64

Ok so the DSPhat arrived a while ago. The top surface is crapoed (nothing bad), but aside from that, it works fine, which is all I care about.


Was interesting to see how that model feels. It feels a little less sturdy than the DSLite. The screens seem to have a little less lag than the DSLite's, but the colors are more washed out.


I have yet to see if there are any undocumented differences in the wifi device.

____________________
Kuribo64

TXBUF_REPLY latching

This is how port 094 goes into 098, which is (I think) required for sending multiplayer replies.


There is code for manual latching, but a) said code needs a value already set into 098 and b) experiments hinted that manual latching wasn't required.


From what I observed, the client only sets 094 once the auth/assoc completes.


The RX start IRQ handler stores 098 somewhere, then clears bit15 of it, then waits until it's done receiving shit (by checking RFPINS bit0-1), sets bit6 of 244 to 1 then 0, then sets 228 to 8 then 0, then puts the previous 098 value back into it via latching.

weird.


So, potential places auto-latching could occur:
* RX start
* RX end
* maybe only when receiving a multiplayer data frame
* when messing with 244/228? haven't observed anything

____________________
Kuribo64

is it really worth having a subreddit for a particular emulator that is still in early stages?

____________________
Kuribo64

can't say how this will go, but I'll try my best

____________________
Kuribo64

so upon RX end, it checks the status of the MP reply packet

if TXheader[0] has bit0 set, or if the value in 098 isn't ((packetaddr>>1)|0x8000), it disconnects



unformatted finding dump


oh also, it seemed that RXCNT bit15 also controls sending (wasn't possible to send shit when it was cleared)

____________________
Kuribo64

Capture card just arrived, and I immediately set to work.


Everything went nicely. The only thing I have to say is that the board I received didn't have the white marks for aligning it to the DS mainboard, but that hasn't been much of a problem.


I did a quick test with the capture software and it's working flawlessly. And as expected, I'm getting 18-bit color. All is perfect!

____________________
Kuribo64

interesting

seems if no reply is configured when one is needed, it sends an empty reply frame

the rxheader[0] type for the empty reply frame is 0xF, type for non-empty frames is 0xE


also, when sending a MP reply, the hardware sets the header duration field, dunno the exact formula tho, but it depends on the reply size

____________________
Kuribo64

welcome aboard

____________________
Kuribo64

Thank you, but this board's language is English

谢谢你，但这个董事会的语言是英文

____________________
Kuribo64

question.

why didn't you ask this via PM or IRC?

____________________
Kuribo64

yeah, not like you're on IRC at this very moment

____________________
Kuribo64

So this is it.


On the technical side, wifi is mostly done. There are still bits of the hardware that aren't emulated, but they don't seem to be crucial. Some (better error handling, power management, etc) would be nice to have. Some (RF/BB chips) aren't necessary.


But on the user interface side, this is far from finished.


What testing has revealed for now:

* Binding the socket to INADDR_LOOPBACK works best under Windows, but doesn't work under Linux.
* Binding the socket to INADDR_ANY works under both, but not as well (Pictochat runs into issues where one or more players can't send). INADDR_ANY also theoretically allows playing on separate computers over LAN, but I can't test it. Better have a strong network, it sends a lot of packets.


Considerations:


* option to choose between INADDR_LOOPBACK and INADDR_ANY (hopefully make both work under Linux)


* add blocking RX check for multiplay acks, may help


* option to set the maximum duration for blocking RX checks -- more time means more possible slowdown, less time means more chance of missing MP reply packets or receiving them too late


* option to choose the interval for regular (non-blocking) RX checks -- currently fixed to 512 microseconds. Checking more often may reduce ingame lag but put more strain on the host system.



Also, a user might want to run melonDS instances using different config files and firmwares, so we need to think of a good way to cover that.



Opinions are welcome and wanted.

____________________
Kuribo64

footage of NSMB MvsL, courtesy RicBent

note that it needs some adjustments to work under Linux

Posted by MeaningOfLifeIs42

Quick question, is it / will it be possible for MelonDS and a real DS to connect?

perhaps, time will tell, but it'll require damn good sync

maybe lag inherent to OS abstraction and drivers/firmwares will make it impossible

____________________
Kuribo64

it's not an error, you can ignore it

besides, when I tried following their recommendation, it was a shitshow, so I kept it this way because it works best

____________________
Kuribo64

nice


I'd avoid mentioning the history with zeromus though, just to avoid inciting shitslinging against desmume

as a note on that, precision: what was sabotaged was WFC/internet more specifically

____________________
Kuribo64

reporting spelling/grammar errors is cool but no need to be a dick. StarTrekVoyager is French.

____________________
Kuribo64

MKDS seems to be one of the worst offenders. I tried, managed to select characters but it disconnected afterwards. It also lagged like crazy.

____________________
Kuribo64