I guess this is really a question for Six, but I thought I'd ask the other experts here.

I've been testing the heck out of Six's netlib lately and have noticed something odd. Basically, around 3 out of every 4 packets are corrupted when they reach the C64's memory. I've looked at the packets with a PC running Ethereal and they're fine, so it's something to do with the read. Packets the netlib sends are fine too.

The corruption is usually extra two bytes inserted in the packet, i.e.

01 02 03 04 05 06

would appear as
01 02 03 04 03 00 05 06

or sometimes with some bytes swapped:
01 03 02 05 04 F4 06

This can happen anywhere, often in the MAC or IP header too.

For now I'm just ignoring the bad packets, but the sender has to retry several times before the packet goes through which slows the game down.

The odd thing is, I don't remember the netlib doing this when I first tested it months ago, and maybe it's my imagination, but it seems to get worse and worse as the day goes on (hardware related?).

So I'm wondering if any other coders have seen this behavior with your respective code - i.e,. if this is a common failure mode. Or could it be hardware-related?

I've been struggeling with the same problem for quite some time now. I only experience the problem on SX-64 (tested several).

I have been testing with RR+RR-Net and some test code.

When reading $de08 and $de09 (the RxTxData registers) something goes wrong. To my understanding reading $de09 should auto-increment the internal Data buffer counter of the RR-Net, so if you for some reason do NOT read that register when you "think" you do, you're in trouble and the result will be bytes swapped until the next BAD read.
According to Jens it's a clock related issue and I have been trying to figure out how to fix it in the SX.

One of my test programs looks something like this:



This should generate a blank screen with NO sound output on working systems. On systems with issues, you will hear clicking noises and see flickering on the screen. Somehow it sometimes works on faulty systems, but testing it 3-4 times while powercycling inbetween and waiting a couple of minutes will usually make it fail.
It seems that enabling the display and displaying full $d021 lines of alternating colours can make the problem even worse.
This little proggy makes weird songs on my SX machine and absolute silence on my C64c.

Edit: Come to think of it, the powercycling thing and the fact that it sometimes doen't make noise with my test proggy, may be because of whatever RAM/ROM/BUS value that gets read instead of the RR-Net register simply is or gets initialized to #$00 in those cases.

Further testing is definately needed, but you should consider if your HW is properly shielded.

God .. I'm so glad someone else has noticed this .. I thought I was doing something wrong and too dumb to figuire out what

Replacing the cartridge port cable often helps, using wide scsi ribbon cable allows plenty of ground wires.

I'm not so sure.. I've tried blocking the clock signals on the cart with tape and the connecting wires directly to the RR pcb. The result was MUCH nicer looking signals, but apparently it had no effect on the functionality.
But it's a good idea anyway

I forgot this: while you have your SX open, replace IEC cabling as well.

I think it's my hardware: I ran a test sending UDP packets from my PC to someone's C64 and RR-Net on the other side of the atlantic ocean and had no retries at all. (I've got a simple ACKing protocol implemented)

Whereas, if I run the same test from my PC to my C64 two feet away, I get 3-4 retries for every packets that gets through

The RR is on a 5-port expander so I can use the RR-Net and my IDE64 at the same time, maybe it's affecting the signals somehow (too long, too many connections, etc)

Yes! That will definitly affect the signal and the RR/RR-net is very sensitive. Not to mention how that poor underrated C= PSU is struggeling to provide the power. Remove the expander and I'm sure it will work fine.. I hope

Ah yes.. the lovely port expand0rz.. totally forgot about those, so I went digging and found one. I just tested with the code I posted above and on an old breadbin which ran that code without sound output, i.e. no problems whatsoever, it made wicked music when I put my portexpander inbetween.
So, it might be interresting to take some measurements with and without that expander to compare the differences..

Bleah. I need to have both hooked up, as I use PCLink to do my cross-assembly, and still need the RR-Net connected of course. Guess I'll just live with it for now. Can't wait for the IDE64 V4 with clock port!


This is why I use a C128 power supply.

Devia, thanks for the test code. I finally had a chance to try it.

With the Retro Replay and RR-Net alone, I get a small white flicker a couple of times a second.

With my normal configuration, IDE64 in Port 5 (farthest from C64) and RR (disabled)+RR+Net in Port 1, I got a screen full of blue (cyan?) lines.

Moving the IDE64 to Port 2 actually helped a lot, I now get a few blue lines per second, but not nearly as dense as with the original configuration.