And by coincidence, I've just been working on an updated release for netboot65 (now available at https://sourceforge.net/project/showfil ... _id=250168 ) that includes a RR-NET compatible cartridge image.

The readme for the C64 client can be viewed at http://netboot65.svn.sourceforge.net/vi ... iew=markup

It's kinda working - the biggest limitation is you can only d/l files up to about 22K.

Would it help if the image size was allowed to go to 16kB? I've determined that you can have a 16kB cart image, but still access all the RAM underneath if needed, so I've wired the design for 16kB images.

Jim

Just a note that I sent the schematic to Bil Herd (yes *that* Bil Herd) on request, and he sent me a version back with some good changes (sure to make the cart more robust for all CBM variants). I'm reworking the design a bit to accomodate them.

I know, it was done, but when Bil suggests improvements, it's probably best not to ignore them.

Jim

Well it certainly wouldn't hurt

At the moment ethernet+IP+UDP+DHCP+TFTP takes up around 5k, so I reckon even with TCP it would still be under 8Kb. But adding an another 8KB on top of that might allow for some built in net-enabled apps (e.g. telnet, ftp).

Jonno

Can't believe you got Bill Herd involved. This is so cool! Could you get his autograph for me?


What is the reason for this? Is the code+memory footprint really 40k ?

The code is currently about 5.5K, that's in a cartridge starting at $8000. There is also about 4K of memory required, consisting of an input and an output buffer (both the size of an ethernet frame i.e. 1518 bytes) and about 150 bytes of other variables. In the current image, the buffers and other variables are all being stored in the space from $6000..$7FFF

When you d/l a prg, the tftp code looks at the first 2 bytes to see where the file should be placed, which is almost always at $801. Then the d/l starts filling up from there. And 22527 (i.e. $6000-$801) bytes later, you hit $6000 and start trashing the IP stack variables.

Having the variables live in another fixed location is easy, not sure where else to put them though. Having them be relocatable is some major surgery on the ip65 library

A (hopefully) final update:

I won't repost the pics, but there are here: http://www.jbrain.com/vicug/gallery/nic

• Revamped logic based on conversations with Bil Herd (redid it twice, to incorporate better ideas).
  
  • Switched '138 address decoder to '85 4-bit magnitude comparator. This allows complete access of any 16 byte bank in the 256 bytes address space
  • On Bil's suggestion, moved as many address signals off the switches as possible (he noted they act like antennas)
  • Gated Read and Write with Phi2, to better support C128 machines in FAST mode.
• Added switch to support EPROMs in C128/C128D mode
• Expanded EPROM footprint to directly support 2764 to 27C020 (2Mb) EPROMs. 8Mb (27C080) will fit as well, but users will need to handle the 2 higher address bits on their own.
• Support for flat and right angle hexadecimal rotary DIP encoder switches, to allow selection of any 16kB image in the 2Mb address space
• Support for 8kB EPROMs (cut two jumpers)
• Support for 64/128 switch to select EPROM bank. (Basically, cut JP5 jumper and solder the other side. This will make the 64/128 mode switch also toggle the lowest bank bit in the EPROM. After this, even banks will have 64 apps, odd banks will be 128 apps, and the 64/128 switch will select between the two.

I think it's done. I'm verifying one thing (I have IO1/IO2 going into AEN on the CS8900A as a chip select, and I need to verify that, as most designs simply tie it to ground. If someone has a 64NIC or a spare Ethernet cart with a CS8900 they'd be willing to loan me to test, I'd appreciate it. I'm 99% sure it's right, but it always pays to be 100% sure.

Jim

Gating in Phi2 was what I was sort of hinting at in my question about addresses/data hold time earlier.. but since you already gated that in now, I guess it doesn't matter
Regarding AEN, it's difficult to say how it's supposed to work, as the datasheet is somewhat unclear. It's an active high input, which should be set low for I/O operations, but the I/O timing chart only refers to it as high, which sort of makes one not trust the timing in that sheet
Using a comparator for the CS is sort of neat - and in light of the unclearyness of AEN and lack of testing, I'd simply tie it low and just rewire the comparator to factor in the IO1/IO2 signal.
But yes, it "should" work as it is now.. you should have around 180ns from cpu sets address to the Phi2 positive transition, which should be enough even for IO1 to propergate and trigger AEN in time.

Well, you and Bil think alike. In my defense, the CS8900A datasheet shows AEN as a chip select, but I had to agree with Bil the datasheet was unclear and it was something that no other designs were doing. Bil suggested using the final 'HCT10 gate as an inverter and feeding the inverted IO1/IO2 output into the A=B input on the comparator. So, I made one final revision, adding that in. I made a few other minor changes to pullups, but nothing to the logic.

There is one hazard on the board that I cannot completely eliminate. The EPROM socket supports both 28 pin and 32 pin devices. Thus, A17 of a 32 pin footprint is Vcc in a 28 pin footprint. I put a 3 position JP4 surface mount jumper to help, but if someone solders both sides, there is a hazard that the rotary encoder will try to drag Vcc low. I put a warning on the silkscreen.

So, final revisions are on the web site. They've lasted a day without any changes, so I'm working on a BOM for production.

Jim

Uhmm.. why not just put a diode between jp4 and the rotary thingies?

To work, the diode would have it's anode on the rotary switch side, cathode on JP4. That would prevent the hazard, but it would also prevent the switch from dragging the line low, which would negate the value of the switch.

Jim

hehe.. yes, think my brain drifted a bit there

You still need to borrow a C64NIC? I can probably get you one. I know that I've got a few that are fried but I'll check to see if I can scrape together a working one.

Great work Jim and everybody!


I agree. Cramming them in below $0801 is usually the only hope, which raises the frame buffer problem. With some smart programming though the frame could be read sequentially from the NIC instead of downloading the entire frame (which rarely uses the full frame size anyway, especially with the right packet options set, i.e limiting the packet size). Also you don't really need two frame buffers, one should suffice. Another option is to use the scratch pad RAM in the cs8900 at the cost of speed of course. The rarely used RR-RAM actually comes in pretty handy here =)

Do you care to elaborate a bit on that?