Well, setmac doesn't actually do anything on the network - it just pokes six numbers into 8900 config registers.



Then it's not receiving (good) packets. There are a few test programs in IP65 that you can assemble and run, including a packet dumper. That might give you an idea of what's going on.

Yeah, I know setmac isn't operating on the network. It was just to show that I hadn't taken any steps backwards after fiddling with the board. All is still well on that side of the chip.

I'll take a look at IP65 and see what I can get out of it. Thanks!

Uhm.. since you're playing around with setmac, I better mention this:

Before testing any IP stuff, make sure that the MAC address of your C64NIC is not known by your Win/*Nix OS by flushing the ARP cache.

..just a reminder

And this is done HOW ?

_________________
Have Fun!!

arp -d *

I guess another approach would be to set the arp statically on the XP box:

arp -s 10.0.0.64 <mac-address-digits-separated-with-dashes>

...and see if anything gets thru.

The whole point of my comment was that he "might" not be aware of which MAC his C64NIC had when it first communicated with his win/nix box.. simply clearing the cache results in renewed ARP-REQUEST/REPLY sets. There's no need to enter anything manually if you just clear the cache.

Yeah, I had done that. I listed the cache on both boxes and the C64NIC wasn't listed. I flushed it's ARP cache entry anyway and got no results. Then, I tried setting it manually on both boxes in case the ARP request was just not being understood for some reason. I got the same results on both boxes regardless of what I did to them.

I'm kinda wondering if I have a bad solder joint somewhere. I can still talk to the chip from the C64 but still have problems on the ethernet side. So, I'm going to look there this weekend for soldering problems. Getting a link light on both ends of the cable doesn't mean that the CS8900a is able to get its responses to the RJ45 jack. It doesn't even mean it is actually getting them, although the activity light blinking makes me believe it's getting *something*. I even got a 10Mbps hub from a buddy here and hooked it up last night just in case something was getting mangled in the auto-negotiation between the gigabit switch and the C64NIC. Still no luck.

So, I will see if I can dump tcp packets on the C64 and also check for soldering problems. I probably wont have time to work on this tonight, but I am off work Friday and will be hitting this all weekend until I get results. So keep the ideas coming in and I'll see if I can put them to work.

Thanks all!

If memory serves there is a PHY link register in the cs8900. You could read that register to see if it's acting correspondingly to the link LED. If not, then there's probably no connection.

Did you try with a crossed TP cable to make sure you didn't swap RX and TX?

RaveGuru, I will check into the PHY link register, but given the tests below, we are getting a connection.

Also, I did try with a cross over and straight cable. Actually, I was using a 10Mbit hub that also had a crossover button to which the C64NIC was connected so I could make sure I had that part working no matter what.

---

I compiled IP65 with appropriate IP config for my network and moved it to the C64. I am having some success with it but not 100%.

When I run testarp.prg on the C64 and send an arp request from my Linux box, I can see the full ARP packet dumped to the C64's screen and I can confirm it is a complete and valid ARP request. The arpcache on the Linux box is updated properly. The C64 doesn't respond to pings.

testarpcache.prg does however allow the C64 to respond to pings and a counter is updated but I don't see the arp tables getting updated on screen.

testping.prg works fine as well.

testudp.prg says "RR-Net init failed" when it receives a packet from my Linux box with 'nmap -P0 -sU --send-ip -p 3172 10.0.0.64'. After that message, I get some gibberish on the screen. It claims to receive and arp packet but doesn't give its size. nmap sees the port as open.

testudpsend.prg is working as far as I can tell without a process listening on udp port 3172 on my Linux box. tcpdump on the Linux box shows the packets coming in with a length of 15.

It's interesting to note that with testudpsend.prg running, the C64 was sending exactly 251 packets per second. Is that by design or is that just a hardware limitation?

I'm not sure what some of the other programs are supposed to do, like testtimer.prg.

It's worth noting that some programs did say "RR-Net initialized" so despite the "RR-Net init failed" error mentioned above, it seems like ip65 does recognize this as an RR-Net, not a TFE/Net64.

It looks like this is working reasonably well, but I still don't understand why udpslave isn't returning arp requests or pings while IP65 is. I also don't understand why the arp cache wasn't being displayed by testarpcache.prg. It was responding to pings, so it had to have known the MAC addy of the pinging host. And I don't know why testudp.prg gave me an error and went bonkers.

So, the problem seems to center around arp cache.

Just to make sure.. please read the second post of this thread: http://retrohackers.com/forum/viewtopic.php?t=193
Try that proggy out and see if you get noise or not.

Just to reiterate: Most programs only work with the RR-Net, and won't even attempt to detect TFE unless they are specifically written for it. IP65 is the same way IIRC.

Sounds like you're making some good progress though.

Devia, I'll try that program out here in a few.

Schema, I mention that to head off the "what config are you using" questions and because I saw a tfe.s driver in IP65 when I was poking around. I didn't see any other code that used it, but it was there. Looks like I could just pop it in instead of the RR-Net driver, recompile, and be good to go. Haven't tested it yet, but if that's the case, then this could be a good potential tool to test TFE mode. I might do that while still trying to troubleshoot this problem to see if it changes anything. It shouldn't, but if I get desperate enough, I'll milk a cow to see if it makes the NIC go.

OK, I tried that program. The screen goes black and I hear nothing and there's no flickering on the screen. I tried sending arp requests to the C64NIC too. Activity light got to blinking and still no noise or flickering. I tried power cycling 5 times and waiting random periods of time between power cycles and still nothing. Complete silence and no flickering. This is on an old bread bin C64. I've tried it directly plugged into cartridge port and in all three positions of my CMD 3-port expander. Same results in all cases. My Aprospand appears to be dead. It wont work with any cartridge so I can't test it. But that's another problem for another time.

I don't really expect noise to be an issue with the card. I ground planed the hell out of it. It should be alright in that department. I understand the test program was meant to test noise anomalies between the C64 and the card, not necessarily the card itself. But, I intentionally made this card with as many surface mount components as possible to help reduce noise as well. The only thing I didn't do for noise reduction was to toss a few extra vias on the board between the ground planes. Since the fastest signal on the board is 20MHz, I didn't think that was necessary. We don't really have to do that until we hit 50MHz or higher.

Another thing I wanted to do with noise was ground the unused lines coming in from the RJ45 jack. But I decided against it since there seems to be no real standard on what to do with those lines after they hit the jack. Working IT and troubleshooting networking devices, I've seen these lines be used for signals, pulled low (almost always the case,) and sometimes pulled high but delivering no real power. And, with PoE becoming trendy now, I figured it was best to just leave them disconnected. However, I can still put some decoupling capacitors on them if anyone thinks that will be an issue. I'm not sure that it will with the ground planing. To do it right, I'd have to add 4 - 8 capacitors to the design.

OK. I think I got the IP65 suite all working nicely now. I found that testarpcache.prg has it's own pingdest defined in source. Shame on you! Destination IPs and ports would be a good thing to put in common.i or config.s so all programs use the same destination. I changed pingdest in testarpcache.s and now it is working fine.

I'm not sure how or why, but after that change and recompile, testudp.prg is working.

So, it appears IP65 is working as far as I can tell. I still don't know why UDPSlave isn't working, but I'll deal with that a bit later. I'm going to grab some other programs and test those and let you know and post the results.