Here are some pics:









First, a disclaimer: if I can provide this, I will not be providing the case as well. That would require modding a lot of cases. While I can do it, I really don't enjoy doing that and I would be selling these around cost so it's really a labor of love. I will see if I can get some good measurements and cutting instructions for a currently available Solakian case, but that's about it. The case in the pictures above is my old Koala Paint case to demonstrate that it does fit in a Solakian cart.

I also tested it in my old Simon's Basic case to see if it would fit well in a non-Solakian Commodore case and it fits nicely with two exceptions:

1) To use the side-facing ethernet jack, you'd have to remove the right rear case clip or at least part of it.
2) There is a LOT of wiggle. Inserting it into the cartridge port of the computer might case the PCB to slip towards the back of the case possibly making poor connections with the C64 and possibly causing problems with the reset switch and ethernet connection. A slight case mode would be required to secure the PCB in place in a Commodore case.

Oh and, uh, I haven't actually powered it on yet. That comes next. I'll keep you all informed of the testing progress.

Features:

- CS8900a ethernet controller
- RR-Net and Net64 compatible (via jumper settings)
- Reset switch
- Optional rear-facing RJ-45 jack mount point (you can swap after you get the part or specify when ordering)
- R8 and R9 will be left blank and are in parallel with resistors R1 and R2 respectively. So if you find the LEDs to be too dim, you may choose to add resistors R9 and R8 to adjust the brightness to your liking.

I did test the placement of the reset switch to make sure it would be accessible when plugged into a CMD RAMLink. It is accessible with room to spare. Not that the reset button is needed if you have a RAMLink, but at least it wont interfere physically.

Bad Joojoo:

- The hole in the middle is a little bit too big, but I just used the smallest standard drill size that was big enough for the hole and positioned it so it would fit alright in the case. If that's a problem, let me know and I'll see what I can do. I tested the PCB with a closed case and the features of the case keep it pretty secure so it doesn't wiggle much at all.

- The RJ-45 jack is a tiny bit too tall for a case, but since you'd have to cut a hole for it anyway, it would require cutting just a bit more than is ideal. I can try to see about getting a lower profile jack and possibly moving the LEDs out of the jack. This was the cheapest jack I could find that included LEDs (I thought it would simplify the design and hole cutting) and using another might raise costs. Also, moving the LEDs out of the jack would require more hole drilling.

- The RJ-45 jack also doesn't extend to the edge of the cartridge. This could be problematic for people with big fingers. I tried it out on this one and it isn't really an issue, especially since I would have to cut the top portion of the case to fit the jack anyway. Getting an RJ-45 jack that extends that far out from the board would probably end up being more expensive too. I could also try to extend the board there to make the existing jack work, but I don't know if adding a little jut like that will make the PCBs more expensive or not.

- A hole would have to be drilled into the case for the reset button.

- The jumpers are too tall for a case. Actually, before putting the RJ-45 jack in place, I was able to close the cartridge case completely with the jumpers in place, but I suspect it was stressing the PCB. I will see if I can locate shorter jumpers. If anyone can point me to a Digikey (or other vendor) part number for a shorter jumper, that would be great! I'm having trouble locating that.

- There is a solder bridge on IC4 that I will have to clean up on this guy. It's an easy fix and I don't anticipate it being a problem.

- I don't like the tiny line between the power pads on the edge connector. I would really like for them to be arranged as a single really wide pad, but when I try to do that, Eagle gives me errors. I'll have to see what I can do about that. I could just ignore the errors, I guess.

So, please give me your opinions, especially if you spot problems! I'll get these initial prototypes tested and I'll see about getting this thing produced (probably in quantities of 50 as demand allows it.)

Sorry for the poor quality of the photos. I'm no good with a camera in the first place and on top of that, I really don't know how to make good use of the one I have. Too many features and no time to learn how to use them!

I just took a look at RJ45 jacks with regard to getting a lower profile model or moving the LEDs out of the jack to make it short enough to not have to chop the top of a cartridge case. I don't think it's going to happen. To keep from having to cut the top of the case, I would need to shave about 3mm off the height of the jack. With the lowest profile jack I can find, I can only shave off about 0.5mm, even without LEDs built in. The LEDs are built in next to the tab space, so they really don't take up much real estate. So, if I can't get a jack that will eliminate the cutting of the top of the case, then it makes more sense to leave the LEDs integrated into the jack, not to mention it's cheaper than discrete LEDs.

I've been looking at the header/jumper issue. We have options:

1) I can turn the header over and try a shorter jumper, but I still can't find one with contacts low enough to work well (you *could* turn the jumper upside down if I get one with an open top.)

2) You can clip the tops off your headers (I wont do that) and use shorter jumpers.

3) I can use right angle headers. This could get pretty cumbersome if trying to change the jumper's position. If this is something that will not be done often, then this may be a good option. It might require repositioning of IC3 and Q1 to make it feasible, but I don't think that will be a problem.

Comments? Preferences?

Glad to see this is still in progress! A few comments and suggestions.

For the cases, have you tried the new cases from Individual Computers? I find they're a bit thicker than an original C64 cartridge case, and they're available new.

(I really want to out mine in a transparent case too).

http://www.protovision-online.de/catalo ... cts_id=106


I would be happy with right-angle headers. I don't expect I will need to change the settings very often. If I did, I would add a switch to the case and run wires to the header.


Is the reset button accessible when used on an SX64?


The price is right - on par with the FB-Net

Thanks for the fast response!

I have not tried the cases from individual computers. I will order some today so I can do that.

I'll see if I can get some right angle headers in this sucker and see if they fit well.

I don't know if the button is accessible on an SX-64. I don't have one. But, I did measure according to Devia's post:



I have exactly 40mm. I didn't mean to take it so literally, but I placed the part approximately where I thought it should end up. Then I measured in Eagle how far it was from the edge and it just happened to be spot on 40mm from the edge of the card so I figured I would go with it. I can still move it 1/16" away from the edge before it interferes with the case's side post if that is a problem.

I got the udpslave software transfered to the C64 via swiftlink and a null modem cable to my linux box. Then I tried to test the card and . . .

. . . it doesn't work. When I plug it in, I get gibberish on the screen.

Background information:

C64NIC has 2 headers with jumpers

- JP1 sets TFE/RR-Net mode and goes through an inverter
- JP2 sets $dexx/$dfxx addressing and goes through a 74139

Testing results:

- Removing the jumpers from both headers (JP1 and JP2) the C64 starts up just fine.

- Placing the jumper on header JP1 in any position without a jumper on JP2 lets the C64 also start up OK.

- Placing the jumper on header JP2 in any position regardless of JP1's status and the C64 spits out gibberish.

Looks like a problem with the 74139. Maybe a bad solder joint or maybe a bad chip. Should be pretty easy to salvage.

Good news is it didn't fry my C64! It still works with the cartridge removed.

I'm going to bed but I'll hit this tomorrow when I get home from work. Well, crap. I have people coming over tomorrow. I'll hit this after they leave if I have time. They stay late sometimes.

If you do fry your 64 (knock on wood) let me know. I have a few spares and I'll send you one.

Cheers.

_________________
Call me Golan; my parents did.

Actually, I have 11 C64s and C64Cs. 4 are here and the rest are in my parents' house somewhere. It's only an hour away so I can get them pretty quickly. But thanks for the support! I really do appreciate it.

This is a good news bad news post.

Good news: It's letting my C64 boot up. I made a mistake in the schematic. I used pins 2 and 3 as inputs on the 74139. In the schematic, I wired them to certain pins on the edge which made it easy on the schematic. Later, I found it was far easier in the layout if I swapped those pins. Of course, I didn't go back and fix the outputs of the 139 so that's botched. But, it's an easy fix on the prototypes and is now fixed in eagle so later boards will not suffer from this problem.

Bad news: It still doesn't work. I can load UDPslave and when I set it to look like anything but an RR-Net cart, it says device not found. If I set it to look like an RR-Net cart, it says OK. So that part looks good. I enter the IP address, and make the sys call to make udpslave restart and it still gives me the OK.

Of course, all of this is overshadowed by the fact I get no link light on the switch or the C64NIC. I am using a known good cable in a known good port on my switch (which is 10/100/1000 if that makes a difference. I don't know if this chip will work correctly with auto-negotiation on my switch.)

I don't know if there is a MAC address set by UDPSlave. Do I have to do that before using UDPslave? If so, do we have software to do that? I thought I remembered seeing something about that earlier in this thread but I scanned through it and didn't see it again. I'll go back over it with a fine-toothed comb, but I figured it might save time to just ask the question here first.

So, I guess what I need is a complete breakdown of all the steps I need to make UDPslave work with an RR-Net cart and I'll use that procedure.

Found it! setmac. It *KNEW* it was mentioned in this thread somewhere! I've downloaded it and will transfer it to my C64 in a few minutes and test.

setmac found that the ethernet chip already had a MAC address! Huh?! This thing is supposed to store a MAC address only in external EEPROM! How did it already have one? I thought maybe it was reading a memory location held by the RetroReplay cart but since I don't have one, I figured it was just giving me bytes from my C64's memory. But, when I ran it again, it read back the one that was programmed into it the first time. So it really is reading it straight from the LAN controller.

I powered down and unplugged the C64NIC from the expansion port. I plugged it back in and re-ran setmac. Lo and behold, I got the same address back! This is contrary to the datasheet. I know it's possible some capacitance could have held it, but that's still weird. One thing to note is that the chip is detected as "Crystal LAN CS8900A Revision E". Is this the same chip revision setmac detects on your systems?

After this, I'm still a no go. No link lights and I can't ping it. I'll try some other programs and see what luck I have. Any ideas would be appreciated.

Looks like an issue with autonegotiate. I just used a crossover cable between my PC and the C64NIC with the PC's NIC set to 10Mbps Full duplex and I got my link light.

By default, the chip itself doesn't work with NICs or switches that attempt to autonegotiate. But, according to the FAQ .pdf released by Cirrus, this can be handled elegantly in software:

http://www.cirrus.com/en/pubs/appNote/an205-2.pdf

FAQ #24 explains the situation.

Anyone want to tackle that one? It should give your drivers/libraries the ability to handle networks with 10/100 (possibly 10/100/1000) speeds. In my view, setmac could be expanded to include this pretty easily so at MAC initialization, it also sets this bit. If anyone gets any code written to do this, I'll test it out on the C64NIC.

This is all nice, but unfortunately my PC does not give me a link light. Windows thinks it is has no cable. I think this is because it cannot get full support from the C64 NIC for whatever it's looking for (gateway, perhaps.) I'll see if I can get around that so I can try to talk to the C64. If I can't, I'll see if anyone I know has a 10Mb hub. I'm sure someone around here is enough of a pack rat to still have one.

I'm not sure that the problem is with Windows. I tried the official MS version of how to disable Media Sensing in WinXP and it's bogus. It does nothing. So, I tried a few other things to test the connection:

I can use the cross-over cable to connect successfully from Windows to Linux and perform an sftp transfer with both NICs set at 10MBps Full Duplex. Both link lights are steady during this operation. So the cable is good.

While running UDPSlave on the C64NIC, I get these results:

With the cable plugged into the C64NIC and a Windows box with NIC set at 10Mb Full, WinXP says the cable is unplugged and the C64NIC link light is on. The link light of the NIC on the Windows box is off the whole time.

With the cable plugged into the C64NIC and a Linux box with the NIC set at 10Mb Full Duplex, Linux cannot ping the C64NIC and the C64NIC link light blinks at a steady rate regardless of what I am or am not doing on the Linux box. The link light of NIC on the Linux box is off the whole time.

I'm not sure exactly what the issue is. Any ideas?

Dunno about UDPSlave, but WarpCopy, iirc, will work properly with autoneg I think. At least it works when connected directly to my laptop, but then again laptop nics are über-autoneg, so it just migt try pulsing 10mb if all else fails.
Anyways, regarding SetMAC. This was made as a very simple program to set a MAC address in the CS8900A on request by someone. There is absolutely NO initialization of anything in that code, other that what's needed to properly detect an RR-Net adapter in an RR, MMC64 or RR+MMC64 setup and to read and store the MAC. I.e. no writes to LineCTL. I don't know the default values of bits 8+9 of LineCTL, since I never had any problems I always thought autoneg was enabled and working default. Then I just saw that application note, which sorta indicates something other than what I thought. hmm...
Just checked my switch at home and I suddently remembered that the first RR-Net stuff I ever tried out didn't work unless I disabled auto-neg on my switch and set it to 10Mbit... Of course I did this for all my C64 related switch ports ..great!
The fact that SetMAC works, indicates that the CS8900A is R/W accessible. Screw the link led!
For how long can your nic hold it's MAC without power? With RR+RR-Net it's only like 1-2 secs.
Oh, and Revision E sounds about right. That's what most (if not all) have. SetMAC will recognize revisions B, C, D and E or output '?' if the revision is not recognized.

Looks like it's holding it for about 8 - 10 seconds. Close enough that we can assume it's acting normally.

I was going to try to use UDPslave to get Warpcopy transferred to the 64, but I might just pull it over via zmodem.

It sounds like I don't need to run setmac before running UDPSlave. Since it already has a MAC addy on boot, it should be ok. UDPSlave's documentation is pretty minimal and I haven't looked at the code so I don't know exactly what it's doing, but I assume it's doing all the initialization I need. Is there initialization functionality provided by the RetroReplay cart for RR-Net that most software assumes is already done? If so, then I may not be able to make this thing RR-Net compatible. It may require its own init routine in software. That would be a bit of a downer.

I'm on the hunt for a 10Mb or managed switch/hub to see if it works any better. But it really sounds like I should have no problems connecting straight to a PC with a crossover cable.