RR-Net 3 not working

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.

    Hi, I purchased a RR-Net Mk 3 this week along with a Turbo Chameleon 2. Unfortunately I am struggling trying to get it to work.


    I installed RR-Net into the cartridge slot and held down the commodore key at startup. It asks to enter an IP, which I do, and then I got the screen "CodeNet Server waiting for commands", like so:



    I've got C64 connected to my LAN network hub. My PC is connected to that hub as well. My PC has an IP 192.168.0.2.


    I've then downloaded WarpCopy64, and attempt to do "Write Image" via it, but it gives a "No reply" error.



    Debugging network connection via WireShark, I observe a UDP datagram leaving my PC over to C64:


    (I am not particularly worried about WireShark saying about the checksums being wrong, since I do have checksum offload enabled)


    This UDP message is immediately replied from 192.168.0.64 with the following ICMP packet:



    This IP packet has IP version field contain an odd value, 13. (when repeating the test, I see other odd values, like 12 and 7 appear as well).

    If I turn off the C64 and then click on "Write Image", I only see the first of the IP packets go out. That is, only the PC sends a message to C64, but I don't see a message coming back from 192.168.0.64. So that confirms that the 192.168.0.64 -> 192.168.0.2 message is coming back from the C64.


    Why would the C64 reply that the port is closed? This should not be the case?

    Thanks for the help!

    To troubleshoot, I followed this help https://manage.accuwebhosting.com/knowledgebase/2609/How-to-Allow-Pingor-ICMP-Echo-Request-in-Windows-Firewall.html to enable my PC to receive ICMP messages, thinking that might have been the problem.



    but naturally that is not the case, since iiuc WireShark would not see any Windows firewall blocked IP packets, and this ICMP message is rather saying that the C64 side blocked the message coming from the PC.

    Before you can write an image, you need to "send server" (button above write image). A program needs to run on the C64 for using WarpCopy, and it's easiest to send that over network instead of loading it from floppy. That's why we have the codenet server in ROM :-)


    Jens

    Hey, thank you so much. That worked. I had misunderstood that the codenet server in ROM was the same as the program. Now I understand.


    I was now able to write my RR-Net utilizing program over to a physical 5.25" disk, and run it from there.


    I have a couple of other questions if you might be able to answer.


    1) is there a way to easily copy files via from PC to the SD card of a connected Turbo Chameleon 2 carrier cartridge? Or some other way to quickly iterate on actual C64?


    2) I notice that my own program is unable to receive data from the network when RR-Net is connected to Turbo Chameleon 2, *unless* I enable the Retro-Replay cartridge. That is quite odd.


    That is, if I have the following settings enabled:



    Then when I load up my program from physical 5.25" disk, it never receives any IP frames.


    However, if I set the boot setting to



    i.e. enable default Cartridge to Slot 1, Retro Replay, then my program does start to receive network communication correctly.


    I developed my program originally in VICE using its RR-Net emulation settings, where the program does work correctly without any cartridges added to VICE.


    The one thing I am aware of is that with a carrier, I should OR memory address 0xDE01 with 1 to set bit 0 there to enable the clock port. I wonder if there might be any other gotchas that I should know of, that could affect this?


    3) A couple of other questions I got with Turbo Chameleon 2. I posted those over to the Chameleon area, at https://forum.icomp.de/index.php?thread/3336-turbo-chameleon-2-manual-and-copying-files/


    Thanks for the help!

    Quote from clbri

    is there a way to easily copy files via from PC to the SD card of a connected Turbo Chameleon 2 carrier cartridge?

    Nothing "wired" - you always have to remove the physical card and place it into the PC's card reader.


    Quote from clbri

    Or some other way to quickly iterate on actual C64?

    ChaCo (Chameleon Control tool) allows direct writing of a binary file into a memory location of your choice, while the C64 is running. I believe the API is open, so you could turn it into a step after compile/assemble in your equivalent of a make file.


    Here's where Tobias could help (he leads software development and documentation of the Chameleon project), but he's currently on sick leave. Might be a week or two until he's back in the saddle.


    Quote from clbri

    2) I notice that my own program is unable to receive data from the network when RR-Net is connected to Turbo Chameleon 2, *unless* I enable the Retro-Replay cartridge. That is quite odd.

    The key setting is the clock port and it's "enable" bit. While all the bit-wise details can be found in the Chameleon programming manual, not all of the registers should be accessed by any software. Again, Tobias should be able to help clarify what's considered good practise and what not.


    Quote from clbri

    The one thing I am aware of is that with a carrier, I should OR memory address 0xDE01 with 1 to set bit 0 there to enable the clock port. I wonder if there might be any other gotchas that I should know of, that could affect this?

    This enable-bit is located in the Retro Replay cartridge, so it's only logical that Chameleon ignores this bit when RR emulation is switched off. However, there may be a way to switch on the clockport without a specific user setting, using the Chameleon registers. And again, it may be considered bad practise to do so.


    Jens

    Hey, thanks for following up, super helpful.


    I did not flash the firmware manually after getting TC2 a couple of weeks ago. I've got Beta-9i it looks like:



    I find in http://wiki.icomp.de/wiki/Chameleon there is a Beta-9q image. Is that the latest?


    Following up on my own questions,


    > is there a way to easily copy files via from PC to the SD card of a connected Turbo Chameleon 2 carrier cartridge?


    I have been able to develop a custom tool to transfer files from my host PC to the floppy disk drive on the C64. (a custom RR-Net based UDP file transfer program)


    If there is a way to copy individual .PRG and .SEQ files from SD card to a real floppy drive connected on the C64, and in the other direction, that would be somewhat useful.


    The requirement to have Retro Replay cartridge active to use RR-Net slotted inside TC2 is fine, that was just an odd thing I struggled at first to understand. Assuming that is by design, then it works for me. Much of my getting started development was based on this page: http://wiki.icomp.de/wiki/RR-Net and it didn't mention this requirement, or I didn't understand it, so it was just a headscratcher to get going at first .


    Now I've been able to successfully get data flowing back and forth the PC and C64 for development, and have been a busy bee getting code built.


    One thing I find is that sometimes when I cold boot my C64, I get these odd sorts of startup screen glitches drawn on the TC2 boot screen. These form corrupted PETSCII characters - sometimes it seems like the boot cycle repeats a few times, and it then boots up proper. A couple of times it has failed to boot, but then just power cycling typically helps. I don't quite know what the issue is there, maybe I have something not perfect in my C64 power delivery (I haven't recapped it, but I am using a modern repro C64 PSU).


    It does not happen always, and tried to get a video recording now, but today it looks like it is not reproducing.