No dependency on Retro Replay in most software I guess.. it's a single write to $de01 and then the Clock Port is enabled. After that, only $de02-$de0f R/W access to communicate with RR-Net. So unless the software uses Retro Replay RAM or ROM stored routines, no problems!

UDPslave works just fine on my 10/100 autoneg switch at home. I don't have my C64 gear here, so I can't test the FAQ #24 workaround, but you can just add it to the source yourself. UDPslave also sets a MAC, if one isn't already set.

Use the source, Luke!

I haven't used UDPslave myself, but I'm pretty sure it only works with something that looks like an RR-Net. You need software that is specifically written for (or modified to work with) the TFE to test the TFE configuration.

Yes, only RR-Net mode will work. It should be easy to hack the source to support TFE mode though.

I think I got the cable issue figured out. I remember back when I originally ordered parts for these a few months ago I couldn't find anyone that had an isolation transformer with a 1:1.414 Tx ratio. The only ones I could find were 1:1 and 1:2.5. Well, I figured it would be safer to try 1:1 and ordered that part. Then I forgot that I did that. So, that is probably the problem. It lines up with problem of the link light working on the C64 but not on the PC. I spent some more time searching and I found that Mouser has a part that can work so I ordered it last night. It hasn't shipped yet so I don't think it will be here until the middle of next week.

While I'm waiting on shipping, I figured I'd see what kinds of final features I can/should have on this thing. I still have some decent PCB space to work with and I have one side of the 74139 that is unused, not to mention potential creative uses of the existing outputs on the side of the 139 I am using. So, if it doesn't raise costs by more than a few pennies, I'm thinking we might as well make use of this stuff.

People have asked about 128 compatibility. I don't know enough about 128 mode cartridge access to know if there is an issue. I've got "Mapping the 128" and schematics, so I'll start looking around for any hardware issues I need to change. As far as I can tell, there shouldn't be any CS8900A issues with 128 mode. I'm also going to start looking at the code for TCP/IP packages for the C64 to see if I can modify them to work in 128 mode if there isn't already a suite of applications that work. Anyone have some foresight into this before I get started?

Is 128 mode an issue with the currently available network cards? Do they not work with 128 mode or has software just not been written for it? Does the addressing need to change on the hardware to make it work? Basically, what are the issues we're facing with 128 mode for this thing and what do I need to do for you guys to be able to use this thing in 128 mode? If it's cheap and doesn't require much modification, I'll make it happen. If it's going to be expensive and require extensive modification, then I may hold off on that and make an R2 that can handle that later.

Also, I only include the option to change addressing between $df00 and $de00. The Net64 had the option of changing between $xx00 and $xx80. The FB-Net can change between #xx00 and $xx08 (or is that a typo?) So, does anyone want C64NIC address selection beyond the $de00/$df00 choices? If so, how big is that demand?

Another thing I'm going to do in the final design is add a silkscreen jumper table in the upper left corner above the LED resistors to notify the user what the jumper positions mean. Should any other silkscreen information be on the card? Most of the parts are surface mount so the bottom of the card is also available for a lot of this information. I've thought about leaving the C64NIC text on top but moving the existing text to the bottom anyway. I can put other information there if you think it is needed.

Any other requests for features before I finalize the design?

I took a look at my C128 Programmer's Reference Guide and it looks like the C128 polls the /EXROM and /GAME lines on pins 8 and 9 of the expansion port at boot time. If they are grounded, the C128 will boot into C64 mode. If not, the computer will boot into 128 mode (barring other 64 mode triggers) and the cartridge should be poll-able.

The C64NIC doesn't use these lines so it should be safe. In fact, the C64NIC shouldn't use these lines since there is no code to map into memory. This also allows it be more compatible with other cartridges. Cartridge compatibility may also be a good reason to add more addressing jumpers.

I'll leave pins 8 and 9 disconnected. I have a couple of C128s and 128Ds here and I'll try them out as soon as I am sure it's working in the C64 properly first.

Nice to see this thread suddenly come back to life.

Very professional looking board

There are a few clear cartridge case,s on eBay as we speak.

I would leave the rj-45 alone with the leds inside this looks great of coarse
if you can get it to poke its head out of the case this would be great.

Looking forward to the finished product.

_________________
Have Fun!!

I think the $xx08 for the FBNet just reflects the RR-Net compatibility since the CS8900 base adress has bit 3 EOR'ed on RR-Net.

About the I/O range, I think it should be enough for most people with just $de00/$df00, but there will always be some power users demanding more

Keep up the good work!

So what's this thing then? Seems even less useful than anything else.

The cartridge lines on a C128 are connected to the MMU chip and the resulting behavior of booting into 64 mode when a C64 cart is connected is purely a software feature (the respective input pins on the MMU are examined by a routine within the reset procedure and acted on accordingly).

_________________
Commodore 128 Programmer
City of Kouvola, Finland

http://mydarkgothvampiricplace.endofthe ... Commodore/

It's just a plain ol' ethernet card that is RR-Net and TFE/Net64 compatible and fits relatively easily in a Solakian cartridge case. Nothing flashy.

Less useful than anything else? That seems kinda harsh. What do you mean?

We understand that those lines are checked in software, but in this case the technicality that the software is firmware makes a difference. If those lines are pulled low, the C128 will boot into 64 mode. If those lines are tied to ground or otherwise pulled low, can the C128 be booted into 128 mode? Basically, I'd like to be able to plug this thing into a C128 and power it on without any trickery and let the computer boot into 128 mode, load software, and use the card.

Well, I already have 3 RR-Nets, so I won't be needing this. Nah, I was just teasing... I'm glad there are people working on new hardware. It's great. How much do you anticipate this to go for? Of course there is the additional plus that the user won't need a clockport emulator to connect this as it fits straight into the expansion port.

This kinda makes me ask for expansion port dividers. I am lucky enough to have gotten a good 4-slot expander from eBay some years ago, but now that there is a lot of new hardware out, could someone start making a new port expander? I'm sure many people would want one. Additional functionality could be added too!


Without modifications to the computer, no. The check is part of the reset routine in ROM and the only way to avoid it is to make a custom KERNAL ROM or use an autostarting C128 Function ROM that bypasses the normal reset. Do you have access to a C128? If not, you can see the KERNAL code in VICE.

The cartridge lines are mapped to bits 4 and 5 of MMUMCR, which is $D505. On a Commodore 128 these lines are actually bidirectional, ie. writing a zero into those bits will drive the corresponding line low while a 1 will allow it to be controlled externally due to the output from the MMU being open-collector.

The reset routine in a Commodore 128 is located at $E000 and pretty soon in the reset procedure a call is made to $E242, where these bits are checked. The code at $E24B puts the computer in 64 mode. You can start the built-in monitor from BASIC with the command MONITOR and then type DFE242 to see these routines.

There is really no need to ground /EXROM or /GAME, because this cart doesn't have any ROM, so both C64 and C128 will start normally. As you said, it would actually be wrong to do so. A passive peripheral should indeed leave unconnected those lines used to tell the computer that there is an external ROM at either $8000 or $E000.

_________________
Commodore 128 Programmer
City of Kouvola, Finland

http://mydarkgothvampiricplace.endofthe ... Commodore/

Sometimes you make me wonder which rock you're hiding under

Check this out: http://www.cbm8bit.com/fotios/fb3xp.php

Now http://fotios.cbm8bit.com click on the fd3xp page.


Great info on the C128 reset/cart.port procedure BTW!

He already stated in the thread - hopefully $55.00 - $60.00 + S&H. So a little cheaper than the RR-Net on its own.


That's the whole point of the cartridge - you don't need an MMC64 or Retro Replay or MMC Replay or IDE64V4 to use it. So it gets even cheaper.



http://www.cbm8bit.com/fotios/fb3xp.php ?

The part came in, is soldered, and I'm getting a happy link light and my 10/100/1000 switch is auto-negotiating with the C64NIC. I can run setmac just fine.

UDPSlave is a different matter. I run it, poke in the ip address of 10.0.0.64, and sys 52224. It seems to run fine but is not responding to pings or even arp requests. While pinging, I ran tcpdump and here's what I got:



Using -v or -vv or changing the grep from '10.0.0.64' to 'arp', does not change the output from tcpdump.

When the arp requests are going out, the link lights on the switch and C64NIC all light up. So it looks like it's getting the packet but is not responding.



Neither my Windows XP box or Linux box can talk to it. Any ideas?