I also like the idea of keeping the Ethernet and AVR on the user port as this will allow it to provide a nice Ethernet interface for use with the Ethernet lacking 1541 Ultimate.

I also have 40 pin DIP Atmega32 to play with. My Digikey box arrived yesterday.

Don't too shy asking questions or for help.

Jim

Why not do kind of a "FOSSIL" driver for the TFE/RRNet devices, which makes old software use a "software-modem" to do communication through the Ethernet hardware? So one can use original c64 BBS and other serial based software through the TFE/RRNet devices, prepping the original software for the 21st century (through telnet). Just an Idea - a real visionary one, I must admit!

_________________
LOAD ":*",8,1
READY.
RUN

The problem is that most (if not all) communication software on the c64 uses non-uniform direct access to the hardware, unlike (for instance) the x86 platform where the communication software made extensive use of uniform BIOS calls which could be easily redirected to new functions. The exception is c64 software that are using the Kernel RS232 functions, but they are since long (even measured in C64 time-space) obsolete. (IIRC the Kernel functions only supports 300 bps).

I suppose a "middle way" is to make a sort of RS232/Modem to TCP wrapper which interprets AT commands and takes care of the connection/session handling, and then patch/hack the RS232 routines in the communication software to call those wrapper functions instead. Shouldn't be that hard ...

Hi, I too would like to see a cheap RR-Net like option. But one that uses the C64 Serial Drive Din connector that the 1541 plugs into.

I'd much rather see devices use this bus then the user port as I already use and feel it should be reserved for a RS232 interface.

.-.-.

Uhmp... That's an interesting oppinion. The way the IEC bus is implemented on the C= makes it very slow and complex to interface. Building a network interface for the IEC bus would first require a compatible controller to be built to emulate a file device. Although this is theoretically possible it would in the end render a netowork device so slow that it would be useless without some kind of custom IEC protocol (similar to a "FastLoader"). Further on it would be pure pain to program for it using sequential access.

IMHO the Userport is device-wise closer to a Network interface than the IEC bus. Although the hardware and software required is still too complex for easy and efficient use, viewed from a software perspective.

The Cartridge port has exactly what is needed for a Network device (direct memory mapped access) and is in its design intended for peripheral expansion. In other words: adding hardware capabilities to the C= such as a Netowork interface.

Of course the problem is that we want many such devices hooked up simultaneously, but it seems to me that most of those needs can now be solved either by port expansion or "all-in-one" cards like the 1541UE, MMC Replay, etc.

That said, I would still be the first in line to support a IEC or Userport enabled Network device project

Over at PETSCII forums, someome is considering an IEC-based solution that uses the sd2iec firmware and an Ethernet controller to do ethernet over IEC.

JiffyDOS would address the speed issue.

Jim

I think it's a goofy idea.

_________________
Call me Golan; my parents did.

I'll take a wait and see approach. Having Ethernet on SD2IEC/uIEC would allow one to treat the Internet as a large drive, without any compatibility issues. load"http://ftp.zimmers.net/pub/cbm/games/mygame.prg",10 would be neat.

If you constrain IEC devices to the serial port only, then the idea of a general purpose ethernet adapter on the IEC bus would be non-optimal. But, uIEC will no doubt sprout a parallel cable option at some point, so it can better compete with IDE64. At that point, uIEC would be able to transfer the same amount of data (more, actually) than RR-NET or ETH64, as it could assume some of the lowest IP layer workload.

Jim

It would be neat but how would one achieve compatibility if they can't control timing? If compatibility isn't important then a net-disk is just as possible with a user port (a wee bit slower) or an expansion port (a wee bit faster) ethernet solution. (I'm fairly certain the latter has already been done actually.) Anyway, my point is that with a ready supply of ethernet options, engineering one for the IEC bus seems like an awful lot of work for very little payoff.

_________________
Call me Golan; my parents did.

yes :)

Yep, the final replay has netdrive, http://www.oxyron.de/html/freplay.html

This idea really shows a LOT of potential for networking on the C64 and I love it!

Nice thing about doing this over IEC is compatibility. If you have a program you want to load from a net drive device and you require an expansion port cartridge to do it, what happens if the program you want to use is not compatible with the cartridge? What if you want to use a cartridge that is incompatible with your network cartridge while using a program loaded from net drive?

Nice thing about using the IEC for this is that all ethernet functionality would be offloaded from the C64 so you get:

1) compatibility
2) performance (C64 memory and CPU don't get taxed to use ethernet)

Furthermore, with an IEC device, you can use this with other computers like an unexpanded Vic 20 or C128. Worst case scenario is that these machines would require a little extra work inside the IEC-based device but I imagine that work could be included in a later firmware upgrade if needed.

I think the IEC-based ethernet device is an awesome idea. It opens up other possibilities for C64 web browsing, where a link to a page could be translated by the browser to a LOAD command and it merely loads the page into memory. This would be made even better with an REU. For HTTP file downloads, it becomes disk I/O commands to download it to a floppy or hard drive as if it's copying the file from one drive to another and it requires nothing more than a stock C64 with one more "drive" attached to the IEC bus.

The only other thing I would like to see would be this in a cartridge form factor with an IEC adapter so you could plug into it from the IEC bus. The expansion port interface and IEC interface would be separately enabled/disabled at will so you get either solution (or both at the same time) as you wish. For IEC use, it would have to have it's own on-board ucontroller which would be perfect for cartridge use as well. It's my opinion that even a cartridge-based networking solution should be offloading the TCP/IP stack workload so the C64 merely tells the cartridge to go get stuff on the network and leave the C64 free to process the application running. With most micros running at speeds of 8MHz or so, this would allow better handling of TCP/IP anyway and these micros are cheap!

To go to the extreme, you can also pipe the userport over to this device and offer the modem->ethernet capability discussed earlier. Best of all worlds.

I'm not sure I understand the concern. Just like a real CBM drive, sd2iec receives the DOS request, holds the bus while the correct sector is loaded into RAM, and then transfers the sector to the CBM machine until strict timing requirements. If there is latency/lag on the Ethernet channel, sd2iec will simply hold the bus a bit longer until either a timeout/error occurs, or the 256 byte sector is received.

• Adding the same level of support provided by Ethernet carts is trivial, though I will agree that implementing the higher level protocols takes more work. Still, someone wants to work on it, and it's trivial for me to interface an Ethernet IC to uIEC to create a development board. If nothing comes of it, oh well.
• As another thread on this board notes, the CS8900-based ICs and the required support circuitry can get expensive and drive the cost of an Ethernet cart up. In comparison, the ENC28J60 is 1/3 the cost and contains a lot of the required support on-board, driving the ratio even lower.
• I've seen a lot of people lament that they would like to interface Ethernet with the CBM, but have no desire to move to Contiki or other options in order to do so. An IEC-based device could be used in BASIC: open1,10,4,"#1":print#1,"GET / HTTP/1.0";chr$(13);chr$(13);:rem read the buffer here and get your HTTP response. Sure, it won't be as fast as ASM, but I think it will allow lots more folks to create "Internet apps". The more apps, the more buyers, the more buyers, the more incentive developers might have to create apps.
• With a uC at our disposal, it's easier to offer a higher level interface ("load "http://....",10,1, for example). The purists can still use the lower level interface, while others could take advantage of a higher level interface without worrying about low level TCP/IP details.
• This design could be enhanced to support the "Ethernet/RS232" idea from an earlier thread. On powerup, the two serial ports could listen for Hayes commands from either the user port or the expansion port, and tcpser could be ported to the uC to support existing apps that expect a modem-interface. A special Hayes command could allow Ethernet direct access. I'd want to ensure the design was not C64/128 specific, but that's a moniro detail.

When I said compatibility I was mostly thinking about software that reprograms the drive. A net-based drive via an IEC-based ethernet device wouldn't work with an awful lot of games unless it was able to full emulate a 1541.

_________________
Call me Golan; my parents did.