I'm exploring the possibility of using ip65 in GEOS. After studying the
ip65 code, I've come up with this plan; maybe somebody can tell me if I'm
off base before I do more coding and testing.

1) I'd like to code my GEOS programs that use ip65 by using the traditional
GEOS tools (geoAssembler, geoDebugger, &c.), which means I'd want to build
ip65 as a single binary that could be loaded into the GEOS address space
and called into using a dispatcher (a la netboot65).

2) That means a custom version of ip65/function_dispatcher.s, which would
install an interrupt handler by hooking GEOS' intBotVector. The service
routine would call code like that in c64timer_nb65.s instead of mucking
about with the CIA timers.

3) I'd want to limit zero-page usage as much as possible by not including
routines that e.g. print to the screen and read from the keyboard. I'd
have to provide a geos.cfg file specifying that the user pseudo-registers
a2-a9 ($70-$7f) would be used for zero-page storage.

4) dhcp.s calls check_for_abort_key, which normally uses a ROM routine.
Since GEOS runs with the ROMs banked out, I'd have to provide a
drivers/geosinput.s to read the keyboard properly.

5) ip65_process (polling routine) would be called several times a second
by using a GEOS process. This would allow the timer to continue counting
during interrupts, as the process would run during MainLoop. The process
itself would have to be a wrapper that banks in the I/O registers first
and banks them out again after calling the polling routine.

6) I've gotten as far as a successful trial build of ip65 with these
changes; the map and listing files look OK. But I'm using a static load
address determined by trial and error; is it possible to tell the linkage
editor to build at "$6000 - the code length"? The idea would be to put a
jump to the dispatcher at the beginning of the file, then read the file's
load address at run time and save that as the address to call.

Any thoughts or advice?

_________________
"...and all watched over by machines of loving grace."

1) Cool! BTW any idea what changes would be need to the NB65 API and/or memory usage to make it possible to use as-is under geos?

2) As I'm sure you'll notice, there's a *lot* of opportunity for improvement in the function_dispatcher.s - it really should be table driven, it started as a quick 'proof of concept' hack that has now grown pretty hairy. If you come up with something neater here i'd be more than happy to push changes back into the main codebase.

3) one thing to note - I've ended up reusing some zero page variables in a pretty inconsistent manner, i.e. initially each routine had a seperate ZP location, then decided I to be frugal and ended up then reusing the same 2 (the copy_src and copy_dest from copymem.s) in pretty much everything new. Which has then caused some nasty bugs. So again i think there's a bit of cleanup possible here as well.

4) the check_for_abort_key could just be stubbed out - it's there (and also in the tftp/dhcp/tcp code) so you can kill something that's not working without having to wait for a timeout, but the timeouts are usually only a few seconds anyway.

5) the ip65 code is not designed to be re-entrant, so you should have a flag to that's set on entry and cleared on exit. otherwise weird things could happen.

6) what's the benefit over assigning a fixed load address?

Hopefully nothing more than what I've outlined, except possibly zero-page usage (see below). It would be nice if it were easier to build without TFTP and TCP, which in my test build accounted for over 2K.


The trick with all of this, of course, is to find something that could work in any environment: GEOS, Power C and other programming languages, cartridges, standalone programs, &c. without making assumptions about how much control you have over the machine. But it doesn't seem that ugly to me; it's a clearly defined API.


I noticed that. But keeping zero-page usage to a minimum increases the number of environments that ip65 can be ported to: you may not have a lot of ZP available, and it may not be contiguous.


I've got it stubbed out now, but it would be nice to have. Maybe something more generic that could be implemented in different ways, i.e. just "check_for_abort". The abort may be a mouse click or a routine to see if a flag has been set.


Do you mean that I must be careful not to let the polling run if the previous poll ran longer than expected and is still running? Good point, I hadn't thought of that.


Making every possible byte available to GEOS programs. Normally, GEOS programs load from $0400 to $6000, assuming they don't double-buffer the screeen. I ended up with ip65 loading at $3000, although I could have gone up to about $3600. It would be nice if I could figure out how to get the linker to build the code as high in the GEOS address space as possible.

Thanks for the advice; I'm going to go ahead with a proof of concept GEOS program and see what happens.

_________________
"...and all watched over by machines of loving grace."

I think you should just need to ifdef out the routines that call tftp_ functions in function_dispatcher, and the linker will take care of the rest (in the same way the tcp routines are defined in/out).




yes - since the eth_inp and eth_outp are fixed buffers, you'd get into all sorts of grief if one call to ip65_process where a packet was received was interupted by a 2nd call to ip65_process where another packet was received.

On further reflection - you will also need to be careful while another packet is being created - since there is only a single buffer for creating an outbound packet, that outbound buffer can be overwritten by packets generated within the call to ip65_process (e.g. if an ARP packet is received , the ip65_process generates a response).
If all your calls to any of the ip65 functions are routed through the function_dispatcher, then you should be able just to set the same flag that's checked when calling ip65_process.

Struggling but very interested . "eating popcorn"

_________________
Commodore 8bit Web Services http://cbm8bit.com
Try our new browser driven disk image editor.

Generally, it seems that ip65 will work with GEOS. I wrote my own dispatcher and added some constants to make it possible to call into the API with more granularity.

I've gotten as far as sending DHCP requests, but I get stuck early on. A packet trace and the GEOS debugger show the following events:

1) ip65 sends DHCP discover packets.
2) Router sends ARP "who has 192.168.1.109?": no reply seen in the trace. (This is normal because he's asking if anybody already has the address he's about to offer, right?)
3) Router sends DHCP offers to ip65's MAC, offering 192.168.1.109.
4) ip65 hears this and sets his own IP to 192.168.1.109.
5) ip65 tries to send DHCP request, but this triggers an ARP request (asking the router's IP address to send back its MAC), which appears to go unanswered.
6) ip65's DHCP status remains at 3 (ready to request).
7) My app eventually reports a DHCP timeout.

I don't think it's a network misconfiguration, because all the machines on my network are using DHCP. This is on my private network; the router is a Linksys WRT54G V2.2 running DD-WRT, and the firewall runs on the router. I do not have my polling routine running during all of this, since ip65's DHCP code does its own polling. The timer IRQ hook is running, and appears to be working normally.

Can anybody give any suggestions on how to resolve this? Networking is not my strong suit, but I have a good TCP/IP reference :)

P.S. Typo in a previous post:

That should be "assuming they double-buffer the screen". GEOS programs can use up to $8000 if they use the background screen for code, but some GEOS kernel routines use it (e.g. menus call RecoverRectangle to erase a menu when it's dismissed).

_________________
"...and all watched over by machines of loving grace."

@ ShadowM What network hardware are you running on your c64/128 running Geos. ?

What applications do you wish to end up running under Geos.

_________________
Commodore 8bit Web Services http://cbm8bit.com
Try our new browser driven disk image editor.

If I understand it right, ip65 sends an ARP request here instead of a DHCP request? Just a spontanteous thought: This is the second time that a packet is to be sent, right? Is there anything in the state machine that causes this packet to be sent incorrectly? Has the packet buffer been updated after the last incoming packet? Ip65 should already know the MAC of the router. Just a quick thought...

Can you post the packet trace (assuming it's with wireshark, you should be able to export as a .pcap file)

Is the MAC address in the ARP request definately the MAC address of the router?

BTW I have noticed some issues recently that cause me to suspect that memcopy may have an issue, particularly when there is a small amount of data to move, and the source block straddles a page boundary. I haven't yet debugged that issue fully.

Apparently not; this message board wants to fight me. But I put them on my site:
dump #1: http://lyonlabs.org/ip65-dump1.pcap
dump #2: http://lyonlabs.org/ip65-dump2.pcap
Dump #1 displays the problem I was having; #2 is after a change (see below).

I think I may have found it: the textbook I'm using says that a DHCP request should be sent as a broadcast (in case more than one DHCP server had responded with offers). I'm not sure if that means to set the DHCP broadcast flag or to send to the broadcast address, but I changed the code to send the request to 255.255.255.255 rather than the IP address that came back from the DHCP server, and it seems to work now (there's no need to send an ARP request). Why the ARP packet didn't work, I don't know...

_________________
"...and all watched over by machines of loving grace."

Can you send me a patch so I can merge that fix in to the main codebase?

Are you able to tx/rx data once DHCP is completed ? I'm particularly interested to know if the ARP issue is unique to the DHCP initialisation - from the trace it looks like it should be fine so not sure why your router wouldn't respond to it, even if it needs the DHCP request to be as a broadcast not unicast.

On another note, I've realised there is an issue with the way I handle incoming tcp packets that could cause the data in the very last packet in a tcp session to not be passed in to the calling client (there's a race condition which can be triggered if the remote end sends a packet that has data in it and the FIN flag set) I expect to be making some changes this weekend, one of the effects of which will be the way the end of a tcp transmission will need to move to a seperate flag, rather than being signalled by a length of $FFFF.

Cheers

Jonno

Patch sent privately.

_________________
"...and all watched over by machines of loving grace."

Although the DHCP request often works, sometimes it stalls, and breaking into the GEOS debugger repeatedly seems to show that he's looping between @waitspace and @gotspace in routine eth_tx (in cs8900a.s). Any idea what might be causing that? I notice a comment in that area indicating that a delay of a few microseconds was added (an extra JSR). I don't really understand what's happening in the hardware here... he's waiting for buffer space on the card to become free in order to send a packet? When this happens it's after the discover has been sent and the server sends his offers.

_________________
"...and all watched over by machines of loving grace."

I do recall once seeing some similar behaviour to what you described, and eventually I realised my problem was I was attempting to transmit more than 1500 bytes of data in a frame. Thats why I added these lines

lda eth_outp_len + 1
cmp #7
bmi :+
lda #NB65_ERROR_INPUT_TOO_LARGE
sta ip65_error
sec ; oversized packet
rts

But now I look at that error checking code, I think I'm actually checking the packet is under 7*256 = 1792 bytes which means if eth_outp_len is > 1518 and < 1792 bytes it will probably pass that check and then you'll get stuck in the loop you describe (where the onchip buffer is full, and the code is waiting for space to come available, but space won't be available till the frame is sent, but the code never actually asks for the frame to be sent coz it's stuck in that loop).

Also not sure what would happen if eth_outp_len was set to 0.