Running WarpCopy64 on an emulator

Question

I'm interested in IP networking capabilities of the Commodore 64. I learned there is a tool called WarpCopy64 that can be used to run a simple file server on the Commodore. The server can be accessed over the network by special client software running on a Windows computer. I'm wondering if I could build an experimental WarpCopy64 setup on a single Windows computer running both the client and (a C64 emulator with) the server. I understand this might differ a bit from running the same setup on actual hardware but it would provide a cheap way to get started with networking experiments on the platform.

I tried the following. I downloaded Npcap 1.10 ( nmap.org ), VICE 3.5 ( sourceforge.io ) and WarpCopy64 0.6 ( oxyron.de ). I completed the npcap-1.10.exe installer and extracted GTK3VICE-3.5-win64.7z and warpcopy06.zip packages. I also downloaded the disk image for the C64 demo Fantomas ( scene.org ) and extracted the fantomas_by_siesta.zip archive.

I then ran bin\x64sc.exe from the extracted VICE archive to run VICE and opened the settings menu. Under Peripherial devices, Ethernet I selected \Device\NPF_{...} (Intel(R) Ethernet Connection (2) I219-V). Then under Cartridges, Ethernet Cartridge I select RRNet and check the checkbox Enable ethernet cartridge. I then close the settings.

At this point VICE says READY. to indicate that it is waiting for me to perform operations. I attach the Fantomas disk to drive 8 by selecting File, Attach disk image, Drive #8 and selecting the file Siesta_FANTOMAS.d64 from within the Fantomas archive. I then go to File, Smart attach disk/tape/cartridge ... and select file WARPCOPY06.PRG from the extracted WarpCopy64 archive. VICE tells me it is loading the file. I then wait until VICE tells me READY. the second time. I then type run and press return. This starts the server program within the emulator.

The server is now running and displays me a banner telling me to press N to change network address. I open Windows cmd.exe and type ipconfig /all this listing seems to contain the network device together with an 192.168.0.x IP address that has been assigned to the network device for use on my LAN. I then press n within the WarpCopy server to change network address. I proceed by entering 192.168.0.x in the server that is running in VICE and press return to confirm. The server responds with IP address/port: 192.168.0.x:6644.

I then run the client app warpcopy.exe from the extracted WarpCopy archive and enter the corresponding IP address there. I then click on the Directory button. The client responds with a popup that says Error!, No reply from 192.168.0.x:6644.

Since using 192.168.0.x did not work, I tried using the default IP address 192.168.0.64 for the server. In this configuration the behavior on client side remained the same but the server told me ARP request from 192.168.0.x. I wonder if the static IP address conflicts somehow with the DHCP configuration my LAN is using.

I though I'd also try using \Device\NPF_Loopback (Adapter for loopback traffic capture) to avoid a possible DHCP issue. However, I'm unable to check Enable ethernet cartridge with the loopback device selected. VICE tells me VICE Error, Failed to initialize PCAP library, cannot use ethernet based devices. On Windows make sure the pcap DLL is installed, on UNIX make sure to run VICE as root, on MacOS you're on your own.

The WarpCopy client seems to communicate with the server using UDP packets. I was able to verify this by using WireShark.

I'm able to send some network packets to the server by scanning it with Nmap as follow nmap -sU -p 6642-6646 -Pn 192.168.0.64 --disable-arp-ping. Nmap tells me port 6644 is open|filtered while the other four ports are closed. WarpCopy prints an error message for the four packets received on unexpected ports.

In addition to the official WarpCopy64 client, there seems to be a 3rd party effort to build another client. Luigi Di Fraia writes about the development effort on his blog. His blog posts seem to contain some details of the WarpCopy protocol. However, I was unable to locate the source code or a release of the 3rd part client.

Answer 1

WarpCopy64 uses the RR-Net cartridge, which is emulated in VICE 2.2 and up. Detailed set-up instructions can be found here, which should be a starting point.

Except: I just tried it, an on my WinVICE 3.2 installation, the device dropdown remains empty. So you might have to try different versions of VICE.

Answer 2

Using VICE 3.4 on Linux, I am able to activate the Ethernet cartridge peripheral in the emulator and launch the WarpCopy64 server.

To fully test, I'd just need a Windows machine on my LAN to run the client, but it ought to work fine.

NOTE: One likely "gotcha" in getting communications working between the client and the server is the way VICE Ethernet emulation functions. VICE uses libpcap and libnet to sniff-and-inject packets. This at least requires administrative privileges on the host machine. It may also prove difficult to route packets across the network to Vice because the destination address is unknown outside the local host.

Answer 3

I had this problem on a genuine C64. Turns out, that the MAC-id: 00:00:00:00:00:00 is the problem. It needs to be set to something. There's a program called setmac, or macset, distributed on the d64 disk image for 64nic+ that does this. After setting the MAC, ping replies in WarpCopy. My problem, though, and the reason I found this thread, is that I can't find any settings in my Linux VICE 3.4 to add RR-NET anywhere. There is no ethernet settings or any RR-NET cartridge.

Answer 4

After some serious debugging I was able to pinpoint the problem to IP header checksum. I had hardware acceleration turned on for the checksum header calculation. Because of this the IP packets were created with a 0x0000 checksum. WarpCopy64 was ignoring all the correct messages because of this. I was able to remedy the issue by turning of IPv4 Checksum Offload in my network interface card settings. There is a Stack Overflow thread explaining the problem in greater detail. Would be nice if there was some way to make the loopback device work. Turning off the offload is an ugly workaround that lets me use external network for an internal connection.

One thing to note is that I was able to reach the server with Nping before I turned off the offloading. Here is the command nping 192.168.0.64 -c 1 --udp -p 6644 --data \xc9\x0f\xda\xa2\x01 that I used. I believe this works since nping builds raw network packets bit by bit ignoring available high level APIs.