Views: 129,525 Homepage | Main | Rules/FAQ | Memberlist | Active users | Last posts | Calendar | Stats | Online users | Search 01-22-18 09:30 AM
Guest:

0 users reading wifi notes | 1 bot

Main - Development - wifi notes New reply


StapleButter
Posted on 06-06-17 07:06 AM (rev. 16 of 06-21-17 03:15 PM) Link | #180
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:
u16 curseqno = SEQNO;
PORT244 = 0x1000;
for (int tries = 100; tries >= 0; tries--)
{
if (SEQNO != curseqno) break;
}
PORT244 = 0;
then it calls the IRQ12 handler
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

StapleButter
Posted on 06-10-17 06:43 PM Link | #185
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

StapleButter
Posted on 06-13-17 05:57 AM (rev. 4 of 06-14-17 08:36 AM) Link | #192
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
// MP REPLY
//
// all this happens when AID_LOW matches the packet's client bitmask (might cause spurious interrupts when receiving regular data frames? or does it check the destination addr?)
//
// transfer start is signalled by IRQ7 always, no matter what 098 is set to. no IRQ12.
// TXSEQNO is always incremented upon that IRQ7
// the reply packet is only sent if 098 has bit15 set, tho.
// TXBUSY doesn't say shit.
// RFSTATUS is 8 and RFPINS is 0046.
// if TXSTATCNT bit12 is set: IRQ1 happens and TXSTAT is set to 0x0401
// txheader[0] is updated to xx01 but that seems to happen when receiving the next frame, right before 094 is latched
// 094 is latched into 098 and reset to zero, seems to happen upon IRQ0
// 098 is untouched after transfer

// frame 0208 and 0228 -> C

// TXSTATCNT bit0-11 fuck things up


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

StapleButter
Posted on 06-15-17 07:33 PM (rev. 2 of 06-17-17 07:46 PM) Link | #196
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

StapleButter
Posted on 10-16-17 10:18 PM Link | #397
MP retry mechanism

after each round: (after ack is sent)
txheader[2] is updated, bits are cleared when the corresponding client responded fine
if the packet needs to be resent, the clients that responded fine aren't polled again (client mask in the frame body isn't updated tho)

seems the frame body client mask is copied to txheader[2] at the beginning, regardless of what the initial value is

SEQNO is incremented normally for retries, as if they were separate transmits

StapleButter
Posted on 01-02-18 09:46 AM (rev. 7 of 01-04-18 05:54 PM) Link | #478
theory on txheader[4]:

the byte there would be incremented after sending a packet

which would be fitting with what GBAtek describes

needs verifying


so, txheader[4]

values >1 cause the sequence number not to be changed

this seems to be a retry counter, but it works differently for MP replies

LOC1/2/3

seems it's not incremented at all.

maybe setting a bit somewhere can change that?

CMD

the byte is incremented after each send attempt, upon the ack IRQ1. it is not incremented when the transmission is successful on first try

maybe reset to zero? but doesn't seem so.

it stops incrementing when it reaches 0xFF

values above 2 don't seem to cause transmit errors...? it's still sending, might be setting some error/whatever bits somewhere tho?

the sequence number for the ack is always taken from TX_SEQNO (and causing it to be incremented)

however it seems that the client doesn't receive retransmit attempts...? it doesn't receive the retransmitted frame (doesn't expose it) but does receive the ack. probably the retransmit thing is setting bit11 in the frame control, or something

REPLY

seems to be incremented upon IRQ0 (after receiving the MP cmd frame)

other than that, rules are the same as for CMD





reply:

changing port 098 between IRQ0 and IRQ7 has no effect. all the decision is taken upon IRQ0.

framectl values that trigger the autoreply: 0208, 0228, 0248


Main - Development - wifi notes New reply

Page rendered in 0.023 seconds. (2048KB of memory used)
MySQL - queries: 28, rows: 83/83, time: 0.014 seconds.
[powered by Acmlm] Acmlmboard 2.064 (2017-11-20)
© 2005-2008 Acmlm, Xkeeper, blackhole89 et al.