God .. I'm so glad someone else has noticed this .. I thought I was doing something wrong and too dumb to figuire out what
| retrohackers.org https://www.retrohackers.org/ |
|
| Corrupted packets with RR-net and netlib64 https://www.retrohackers.org/viewtopic.php?f=5&t=193 |
Page 1 of 1 |
| Author: | Schema [ Tue Nov 07, 2006 3:57 pm ] |
| Post subject: | Corrupted packets with RR-net and netlib64 |
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? |
|
| Author: | Devia [ Tue Nov 07, 2006 5:03 pm ] |
| Post subject: | |
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: Code: start:
sei lda #$01 sta $de01 lda #$00 sta $d011 loop: lda $de08 lda $de09 sta $d418 sta $d020 jmp loop 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. |
|
| Author: | Bones [ Wed Nov 08, 2006 9:12 am ] |
| Post subject: | |
God .. I'm so glad someone else has noticed this .. I thought I was doing something wrong and too dumb to figuire out what
|
|
| Author: | tnt/beyond force [ Wed Nov 08, 2006 11:14 am ] |
| Post subject: | |
Devia wrote: According to Jens it's a clock related issue and I have been trying to figure out how to fix it in the SX.
Replacing the cartridge port cable often helps, using wide scsi ribbon cable allows plenty of ground wires. |
|
| Author: | Devia [ Wed Nov 08, 2006 12:00 pm ] |
| Post subject: | |
tnt/beyond force wrote: Devia wrote: According to Jens it's a clock related issue and I have been trying to figure out how to fix it in the SX. 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 
|
|
| Author: | tnt/beyond force [ Wed Nov 08, 2006 12:30 pm ] |
| Post subject: | |
Devia wrote: tnt/beyond force wrote: Replacing the cartridge port cable often helps, using wide scsi ribbon cable allows plenty of ground wires. But it's a good idea anyway I forgot this: while you have your SX open, replace IEC cabling as well. |
|
| Author: | Schema [ Wed Nov 08, 2006 3:56 pm ] |
| Post subject: | |
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) |
|
| Author: | RaveGuru [ Wed Nov 08, 2006 4:20 pm ] |
| Post subject: | |
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 
|
|
| Author: | Devia [ Wed Nov 08, 2006 5:11 pm ] |
| Post subject: | |
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.. |
|
| Author: | Schema [ Thu Nov 09, 2006 4:32 pm ] |
| Post subject: | |
RaveGuru wrote: Yes! That will definitly affect the signal and the RR/RR-net is very sensitive. 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! Quote: Not to mention how that poor underrated C= PSU is struggeling to provide the power.
This is why I use a C128 power supply. 
|
|
| Author: | Schema [ Sun Nov 19, 2006 5:54 pm ] |
| Post subject: | |
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. |
|
| Page 1 of 1 | All times are UTC [ DST ] |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|