1. The Ethernet PHY MIIM registers now work, so you can find out if the ethernet port is connected, and at what speed, for example. This was not too tricky, except that I had the bus running at 2x the correct speed, because I read the 400ns edge-to-edge time, i.e., half-clock time, as being the clock cycle time. After that, it was all peachy.
2. MAC address filtering, including recognising broadcast and multi-cast ethernet frames.
This is basically an extension of the "allow bad-CRC" flag, together with adding registers to store the MAC address of the machine, so that ethernet frames can be filtered if the CRC is bad, if the frame is not broadcast, not multicast, and not addressed to the MEGA65. The broadcast and multicast checks can be independently disabled, if you really want to cut down on processing load, by only listening for packets addressed to the machine itself.
After chasing down the bugs introduced in the process, it now all works. LGB wrote a nice little ethernet test utility, that responds to ARP requests and PING. This now works very nicely, and I can ping the MEGA65 from my linux laptop:
$ ping 192.168.1.65
PING 192.168.1.65 (192.168.1.65) 56(84) bytes of data.
64 bytes from 192.168.1.65: icmp_seq=1 ttl=64 time=0.316 ms
64 bytes from 192.168.1.65: icmp_seq=2 ttl=64 time=0.304 ms
64 bytes from 192.168.1.65: icmp_seq=3 ttl=64 time=0.304 ms
64 bytes from 192.168.1.65: icmp_seq=4 ttl=64 time=0.336 ms
64 bytes from 192.168.1.65: icmp_seq=5 ttl=64 time=0.306 ms
^C
--- 192.168.1.65 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4085ms
rtt min/avg/max/mdev = 0.304/0.313/0.336/0.016 ms
$ arp -na? (192.168.178.1) auf 38:10:d5:29:66:ef [ether] auf wlp1s0
? (192.168.1.65) auf 02:47:53:65:65:65 [ether] auf enp0s31f6
$
Here we can see the program running on the MEGA65, with counters on the top line for the number of packets received (RX), transmitted (TX), ARP packets replied to (ARP), PING packets replied to (PING) and UDP packets seen (UDP).
Below that is the MAC address of the MEGA65 displayed three times over:
Great news ! Thanks that you've made the Ethernetcontroller working.
ReplyDeleteSo adding to previous discussions, we really might be able soon, to leave the SD-card in and access our home network for software or push from our PC ;-)
Thanks for the tests of it and M65-level great work and also for the AND #7 thinggy :) One thing: one should check my theory of ICMP checksum trick what I used ... As I don't want to do (I tried but it didn't worked, my implementation is buggy somewhere, and it also needs temp storage then, the direct buffer usage is not enough ... but anyway this is a simple test program only, not intended for implementing a fully capable TCP/IP stack over it, of course!), I only copied the echo request's IP payload, and use as the reply, with single byte modified (ICMP type). Now, the trick to avoid the 1's-complement checksumming what RFC1071 states, that in theory a single byte (well, word, since 16 bit based checksum) modification needs to "patch" the checksum to add the difference between old and new value, but do not do the 1's complement "carry-end-around" trick. I tried to do this, it seems it's OK, but who knows :-P
ReplyDeleteVery, very interesting! What will TCP/IP I/O be like from a software developer's standpoint, API-wise? Will you be able to access the Ethernet port from BASIC in C64 as well as M65 mode? If so, what will it look like? Also, what about assembler - have you considered compatibility with existing Ethernet solutions for the C64/128? Oh, and will there be native, official TCP/IP support in the native M65 GEOS platform?
ReplyDeleteSo many questions :) There is no included TCP/IP software or hardware acceleration. This will be upto the usual software to incorporate. We might add RR-Net emulation, although I find the ethernet IC used in that to be quite horrible and slow, but software supports it. There are some complications to achieving this, however. We will add support for it into Contiki at least, and likely into some GEOS programs. As for TCP/IP / UDP from BASIC, that's a whole other question that we have yet to explore, and would require quite a bit of work to achieve. It all comes down to how much time people have to help contribute to these sorts of things.
Delete