Well, I should say FLASH was used loosely. The CS8900a has a built in means to use EEPROM chips for storing config data. It will do it pretty much automatically if a supported chip is present and the EEPROM support circuitry is housed inside the CS8900a so there will be minimal cost to adding it. The problem is that this is unavailable in 8-bit mode. That means a lot of extra support circuitry, PCB real estate, and code. It's probably not going to make it into the design.

The RAM idea would probably not work out too well as the CS8900a already has 4 KB of built-in RAM for buffering. The chip does provide the means to do DMA but only in 16-bit chunks making this an expensive idea to implement. So, I'm probably going to throw that idea out because it would probably just add too much expense and very little gain.

With those ideas thrown out, there isn't much need of a header/passthru anymore.

I like your LED positioning idea. And, I would prefer drilling holes because I would like the LEDs to be visible to the user, otherwise they become useless. The transparent case might be a good idea, or at least, a case that has a transparent section, if they make them like that. With the low production numbers we could anticipate, it would be reasonably easy to tool up a dremel tool on a stand that could be used as a drill press to insert a cartridge case and drill the holes in the same location every single time. This then becomes a trivial thing to do.

Ah yes, if you can order the cart with ready made case then I would go for that option!

When could you have this in production and could you give us an estimated price? We know that roughly 50 units or more have already been "booked" by people and retailers here on retrohackers alone.

It's too early for me to tell. I just started on the schematic yesterday. While I'm spitting out a schematic, I'll be researching component and PCB costs. I'll gather the information and as soon as I have a reasonably close estimate, I'll post it.

I'm looking up components and to be honest, it's a pretty cheap, easy, and clean route to go if I just use an RJ45 jack with built-in LEDs. If I made sure the LEDs were on the top side of the jack (the lock tab of the cable would be facing up and the tab would be flanked by LEDs) would that be good enough? That would let you easily see the LEDs if your cartridge is plugged straight in to the computer or into an expander. Plus, it eliminates the need to drill holes in the case or user a transparent case.

A request was made in another thread to make this TFE compatible too. If the only difference with the RR-NET and TFE compatibility is the single address line inversion, I can add this feature for the price of a DPDT switch.

Any ideas/comments about this?

As long as it's cheap enough as I don't know the cost of a DPDT switch. Would this be controlled by a jumper then?

No Jumper. The switch replaces the jumpers that would normally do this so it can be mounted on the outside of a case and the user doesn't have to open the case to mess with jumpers. It would be a sliding switch. One position: RR-Net, the other, TFE. The cost would be about an additional dollar or two, maybe less.

What about a switch to move it between $DExx and $DFxx?

fantastic !!!
i will buy one (or maybe two) for sure! Just keep it reasonable cheap, i don't need any extras like RAM, Flash etc... if you could just make a stand-alone ethernet adaptor i'd be happy! the switch for TFE/RR-Net sounds great though!
Go ahead! Please!

Who uses dfXX and why? To be honest, after reading most of the feedback since my first post in this thread, I've gotten the sense that minimal is better. If this is a feature used by only one or two people, I might leave it out or make it a pair of jumpers instead because it will be simpler and cheaper. It would just require the geekiest of us to open the case.

IO space selection might come handy if and when your cart collides with another one. Depending on PCB layout you might be able to use simple solder pads for power users. They can add jumper pins or switch later if needed.

For non-volatile memory you could use serial EEPROM. You need some extra logic to produce I2C signals, so cost will be a bit higher than plain memory chip. As a bonus you would have "free" I2C bus to add RTC or whatever.

I guess the question is, does anyone actually use the deXX/dfXX toggles? Do the existing netlibs support this? If not, will they?

I'll probably not worry about an I2C bus or memory. It seems like there are a lot of other products out there acting like expansion boards that provide all kinds of features. It also looks like the demand is for the simplest ethernet cart that is TFE/RR-Net compatible. So, adding other features that don't directly affect ethernet functionality would blow the project up into another full featured expansion card with ethernet as just an added bonus.

And I might be misunderstanding the demand. Is the demand for a new cart that is compatible with existing implementations of TFE and RR-Net, or is the demand for a full Net64 cart with RR-Net compatibility? If it's the former, I need to know what people are doing. If it's the latter, I'll just add the switch for deXX/dfXX and the inverter and switch for RR-Net compatibility and be done with it. If it's something else completely, then I'll have to get a lot of feedback to make it.

I've been a bit slow to getting to this. I just now updated cirrus-2.lbr with the CS8900A device. I've uploaded it to CadSoft as cirrus-v1.0.2.lbr but I don't know how long it will be until the webmaster updates the download page. I should be able to start getting to work on the full schematic now.

Oh. Does anybody want/need/use the reset button for this? I see the Net64 cartridge provides one but RR-Net doesn't. If this isn't going to be used, then I wont include a reset button in the design. I imagine that a number of carts will be used with this cart, so I imagine there will already be reset buttons out there and this would be redundant and only add needless parts and complexity.

Good point!
The reset button is absolutely necessery IMHO. I'm so used from having the reset button on RR that I haven't even reflected over the fact that this will have to be included with the Net64 design.

I think the RR/TFE switch is a great feature for only 2 bucks, but I strongly agree on keeping this as cheap and thereby simple a cart as possible. Sure, if the design allows it, put some solderpads for the hardcore hackers to play with, but don't start populating the cart with all sorts of candy that 1% of the buyers will find interesting.

Another thing: Upon resetting RR/RR-net (as in hardware reset) we've noticed that the CS8900 keeps the MAC address. I don't know if this is the way CS8900 works or if there is something to the RR-net design that makes this happen. Because of this the current practice when coding for RR-net is to first check if there is already a valid MAC address (set by another program), and if not then set a valid one. This allows you to maintain the MAC address while resetting and/or loading another RR-net application, so it's kind of important from a software point of view.

i don't exactly understand what you mean with that $dfXX stuff but i would definitely NEED REU-compatibility, so $dfXX should be available! If that's not the case, there'd be not much use for me for a new cartridge.

OK. Looks like I'll just have to include a reset button and a switch for deXX/dfXX register relocation.

If all goes well, I should be able to complete the first draft of the schematic this weekend. If there are any other wish list items, now's the time to get them posted. I can't promise I'll implement them, but if they're cheap and simple and will be used by many, then I'll give it some serious consideration.