Datasheet - link - remaining "features" - Sending DATA?

Okay so a lot of the links herein still take you to the 1.0.0 version. This is NOT the latest.

THIS is the latest

Its still a train wreck but it MUST be better than 1.0.0.
For instance: getting this thing to work with these RING buffer - RX/TX buffer - and “MASK” hoo-haa means the memory map info is important.
Like this:

Then of course there is THIS:

Um : TX?

Um: Do I need to solder a ram chip on top of the W5100S?
(0xC000 ??? That’s over in the neighbors yard )

Um: Sn_TX_MASK. I know (NOW anyway) This is NOT a REGISTER you poke a value into. But isn’t the format sort of HINTING that it “IS”? It made me LOOK for one…

I’m hooked to the WIZ810SMJ (W5100S device) and writing/reading registers. There is NO SNEAKY INVERTERS in the SPI enable on THIS module. Working Parallel AND SPI using burst mode where desired. ( Unlike the W5100 that doesn’t support burst SPI ). I can ping it. So not only do my writes work, I also do get good READS.

Sending Network data. Just a blind transmit test… Now there’s a head spinner. SO I use my W5300 experience, Socket 0 and the power up 2K defaults. AND! The train wreck data and -
Poke in a DESTINATION IP and PORT, starting at 0x040C - 0x0412 (Burst)
Poke in 32 bytes of detectable STUFF (My_Data) starting at 0x4000 (Burst)
Poke in 0x0020 starting at 0x0424 (SIZE! Right? Wrong? Who knows )
Poke in 0x20 at 0x0401 (SEND command to socket command register )

Watching wireshark the entire time shows me [ nothing from my IP address ]

So I can write and read EVERYTHING as a further test - But I thought I was past that. I’m SPI and in the 100KHZ Super Safe Speed Range ( for now ) so no need for THAT suggestion.

Where am I off track please? The datasheet leads me to the weeds.

Can someone please help me understand not being able to read/verify the Sn_DIPR and SN_PORTR
registers? Within the forums I see it is a common misunderstood issue.
I’m using UDP, just trying to generate a blind transmit for now.
Socket reports OPEN in UDP mode. No pending Interrupts.

Thank you very much for a timely reply please

Timely replies here are AMAZING! It’s like this person is inside my head :thinking:

Well as usual I can now send messages on the network side. Amazing what a difference contiguous time on one fire can reveal. Mostly goofs on my side. The source data pointer to the data I wanted to send to the Sn_DIPR and Sn_DPORTR registers was getting whacked. I need to try re-reading those and see if I get what I expect. I hadn’t done that yet because I was so happy about seeing the network message I was wanting to send, I quit right there - on a high note- for the weekend. I’ll see if I can remember to try that later and post here since it might be comforting to someone else heading down this path.