I'm trying to build the UDP Listener example code from the IP65 website, http://ip65.sourceforge.net/ I did build a test code for the UDP client, using one I found in this forum. I left out the pre-processor section from the test code below to keep it short. I hope that someone can help clarify a few things about this code.

Basically , I get an error about the "zp_data" variable that's not defined in the example code. I'm not sure yet on how it's used. I could use some help to clarify on what's being done with this. I thought it might have been a variable used in the IP65 code, but a search in that code comes up empty.

I understand that while it calls 'ip65_process' and a packet arrives, it will call 'gotpacket'. I'm just not entirely sure of the purpose for the steps being used in this section of the code.

I see that 'udp_inp' points to the UDP packet. It seems that 'zp_data' is the message which I can print to the screen. But the offsets being
used in here for 'udp_inp' doesn't seem right.

From looking at the upd.s in the IP65 source, the UDP Length is offset +4, and 2bytes long. And the payload data is offset +8.
But the line ' lda udp_inp + 1' tells me its pointing to the LoByte of the Source Port addr in the UDP Header. And the line 'ldx udp_inp + 2' tells me that's pointing to the HiByte of the Dest.Port addr in the UDP Header. So i'm not sure what is supposed to be stored at 'zp_data' in memory.

I see in the 'copy:' section is where it should extract the data from the UDP packet. But line 'ldy udp_inp + 3' tells me it's pointing to the LoByte of the Dest Port Addr. Shouldn't this point to the UDP Length at offset +4, but since only one byte is used here (I guess for short messages), maybe use the LoByte at offset +5, so then 'ldy udp_inp + 5'

And on line 'lda udp_inp + 3,y' should this point the the beginning of the payload data at offset+8, 'lda udp_inp + 8,y'. And then the loop should decrement the length byte until it reads the entire message. And I can then use the print call in the kernal rom to display it on the screen.

I'm not sure of the significance of using the zero page addr $01 in the 'gotpacket' section, after the sei, since this normally affects the memory configuration for the Ram.

Dan

_________________
=Dan
http://www.rogtronics.net/

I haven't looked into this but it looks to me that zp_data is just a Zero Page pointer for the copying UDP data in this case? Not knowing IP65 I would assume that it's up to the user to define what ZP location to use, since it depends on the program and RAM/ROM environment used. IIRC using $FB should be safe in most cases but check Mapping the C64 for ZP reference to be sure.

The code above is from the GangED monitor and paint program, which lets you push data over to the C64 for display. The editor sends UDP packets on port 60064 with one byte for the $01 value, two bytes for the address, and one byte with the length of the data, followed by the data. You will need to allocate zp_data in zeropage to assemble the receiver. You can send a test packet to it with:

This should make the screen border pink if your C64 is using 192.168.0.64.

What is the exact error message you are getting? ca65 is quite counter-intuitive sometimes.

It might be as easy as using ".importzp zp_data", assuming the variable is exported elsewhere by the IP65 library.



Exactly. The idea, I believe, is to ensure that the rest of that section is copying received data from RAM, rather than any ROM that may be overlaid over top. It looks like that setting is specifically set by the client though.