Over the past couple of days I have been giving some thought to a new project. My problem is connecting my C64 to the network. I have a RR-Net setup but that does not work with most old software. They use the user port serial interface.

I think it would me nice to be able to use the user port serial interface but my problem is I don't have anything to connect it to. My PC doesn't even have a serial port.

So the solution would seem to plug my Ethernet cord into my user port no? This of course is easier said than done. First you need a Ethernet chip. Then you need to interface it with the c64 somehow. You have to design a PCB deal with surface mount chips, voltage drivers Ethernet plugs, etc. There are the Lantronix devices but new they are very expensive and I have gotten burned buying them used on Ebay.

Then it struck me.

There exists embedded Ethernet boards with micro controllers and plenty if I/O lines. There are also tiny Ethernet boards with DIP connectors that interface via SPI for around $40. Or a tiny 28 pin DIP Ethernet chip from PIC for $3-$4. (ENC28J60)

So given this, it seems like a simple job to interface a micro controller to the c64 rs232 user port and the Ethernet module/chip to the SPI interface of the same micro controller.

The micro controller's job would be to emulate a commodore 1670 modem, maybe with optional enhanced bit rates above 1200 like 2400 and maybe 9600. Of course it will need also need to translate the serial communication to/from UDP packets and Telnet protocol.

THATS RIGHT! A Commodore compatible "modem" with an Ethernet plug.

Also the micro controller will be connected to the 8 bit parallel port of the c64 user port so high speed drivers/programs/patches can be used to transfer data at several kilobytes per second.

This is what I think is needed so far:
*A Ethernet board or chip that is as cheep as possible, can be plugged into a bread board and interfaces via SPI. It needs to run at 5 volts or we need to run it and the micro controller at 3.3 or whatever.

*A micro controller PDIP for easy soldering. This unit will interface with the c64 so it's I/O needs to be 5 volt tolerant if it is necessary to run it at a lower voltage for the Ethernet interface. Of course the whole thing will run at 5 volts if at all possible.

*C64 user port connector. These are easy enough to come by.

*A board to mount these three components on. With everything being relatively low pin count and through hole design the PCB should be very small and very cheep and easy to solder together.

Proposed components:
28 pin PDIP ARV Atmega8. (I happen to have a few laying around.)

Ethernet board:
This is a tough one I have not found anything below $40. On the other hand PIC makes a (ENC28J60 ) $3-$4 28 pin DIP SPI Ethernet chip! Just add Jack, LEDs, 25mhz crustal. A MagJack with built in magnets and LEDs runs about $5. For now this seems the way to go.

So with these components we can make kits for what? $30-$40?

A few extra options:
*Header for IEC to load over the network with c64 kernal.

*A small speaker or audio header to emulate modem sounds. Dial tone if there is basic net connectivity. Touch tones using the ip/port numbers. Modem screeching if the server responds. Just like the good old days.

So the 1670E (E for Ethernet.) What do you think? (Sorry for writing a book and thanks for reading!)

There are also RS232 to Ethernet devices that, with appropriate PC side software, might get what you're looking for with existing RS232 devices... Here's just an example of one: http://www.picotux.com/indexe.html They are commonly used in the enterprise to provide remote access to RS232 device consoles.

Not quite. First you have to build/buy an rs232 interface, then you have to buy that thing for over $130 dollars.

My idea is for a $30-$40 kit that is:
Tiny.
Plugs into the user port.
2 inexpensive low pin count DIP chips.
Less than 10 components, all through hole and low pin count.
Emulates a C64 modem and is compatible with all C64 software that uses a standard modem interface.
Can also use 8bit parallel feature of the user port.
Easy for anyone with a soldering iron to build!

This project is very ambitious for me but using a lot of off the shelf AVR TCP/IP software, I think it may be simple enough for even me to pull it off.

Has anyone had experience interfacing a AVR to the C64 user port? Is it a simple port to port connection?

I agree with your idea, though I had a few additions.

My main issue with the RR-NETs and such was/is the lack of emulation compatibility. You need new SW to use these devices.

So, I have a project folder here with the working title of EthLink, which is pretty much what you describe, though here are the actual features:

user port connector, for 16XX modem compatibility
expansion port board, for T232 and Swiftlink compatibility
6551 on board for the T232/SL function (the long term plan is to replace with something else, but I decided to concentrate on other things right now
AVR (one with 2 USARTs) to deal with the two serial connections.
Ethernut (or something similar) on the backside, to talk Ethernet

My idea has been cooking for a while, since this is the reason I wrote tcpser (a Hayes modem emulator) (written all in C, so it could be ported from the PC to the AVR)

I didn't include the sound stuff (not saying it is a bad idea, just that it wasn't imperative for the function)

The idea is that on startup, the unit looks and acts like 2 modems (in reality, there is but one modem emu core, but you can access it from both USART ports.
But, if you +++ and do a special AT command, then it switches into a packet format, that would let C64 apps use the complete Ethernet protocol and have multiple streams open, but not have to deal with the specifics of TCP and UDP (and ICMP, and DHCP, etc.)

On the IEC front, I actually had not thought of including it, but another of my projects, which I am working on at present allows using the IEC protocol over serial to a PC. It could be easily reworked to run over TCP/IP.

After I got tcpser done, I found there was not a lot of call for such a device, so I started playing around in other areas. But, I still believe there is a market for such a device.

My main problem right now is the Ethernet side. I have not done the research you have on Ethernet ICs, nor have I played with uIP. And, since the rest I have alreayd completed or does not require much more thought, those pieces are the main ones yet to work on.
With that in hand, I could quickly add tcpser and my IEC code to it. On the PCB front, I could very easily merge in EZ232 and Link232 for the RS232 pieces.

So, if you are interested in working on the prj, I'm happy to help with what I have to offer. On the other hand, if you want to go it alone, all of my stuff is GPL, so it's yours for the taking. I mainly want such a device done.

An M8 is a good start, but I really think that by the time you get uIP, some IEC code, tcpser, and a few other goodies in there, you'll be in M16 land. Once you are there, I'd recommend the M644P. It has 64kB of Flash, 2 serial ports, lots of IO, and lots of other goodies, and it's in DIP format. The same code will run on the M644, if someone decides to make a surface mount option.

As well, I had little interest in supporting the 1650/1660 modems, as they don't do Hayes, and would take additional IO to support (1650 needs some more digital IO, 1660 needs more digital IO and some ADC channels to handle the DTMF digits from the SID). Just FYI.



Jim

That's a damn good idea! I say go for it. When I mentioned the ENC28J60 in the thread about the C64NIC, I was thinking of using an Atmel for the SPI interface and even doing it over the user port (to avoid fighting over cartridge addressing when using multiple carts,) but I had never thought of doing modem emulation. That's just cool! If you want help working on this, I'd be more than happy to lend a hand.

Be careful with the Microchip ethernet controller. Your component count is going to go up. That chip can only accept power from 3.1V to 3.6V. So, you will need to provide power (probably 3.3V.) While some Atmel micros provide an internal 3.3V regulator, you must check their current sourcing ability. I don't believe the ATmegas provide a regulator. I have worked with the 8, 16, and 32 and haven't seen one that does. Even the non-mega ones that I have seen that do provide a regulator only source 100mA although some might provide more. The ENC28J60 requires a minimum of 120mA to be active while not transmitting packets. It requires a typical 160mA and maximum 180mA to transmit. So, you will need to provide a voltage regulator that can provide at least 200mA of power. I would use one that provides at least 300mA just to be safe. And you may need to check into a heat sink for this, but it depends on the regulator you use and it's casing/package. Even non-adjustable regulators usually require some external support components like capacitors and biasing resistors. So check around. You should be able to do it easily in 5 components or so.

While the ENC28J60's inputs are 5V tolerant, it's outputs are still 3.3V CMOS. So keep this in mind when selecting your AVR and it's power source. The ATmegas are CMOS units that will use CMOS levels on their I/O pins which vary based on the voltage used to power the chip. So, if you power the AVR at 5V, you will be able to talk to the C64 without shifting the logic level since the C64 is TTL, but you'll need to shift the logic level between the ENC28J60 and the AVR. The ENC will spit out 3.3V CMOS logic levels and the AVR will expect 5V CMOS logic levels. A similar problem occurs if you power the AVR at 3.3V. You will be able to talk to the ENC28J60 just fine, but will need to shift the logic level between the AVR and the C64.

One thing to note is that a 300mA 3.3V regualtor should be able to provide enough power to operate the AVR chip *AND* the ENC28J60. So, it is really your choice where you shift the logic level. I haven't used them much so I don't know what choices are all available, but I have seen them in hex packages (6 shifters in one IC) so it would take 2 ICs to provide shifting between the C64 and the AVR if you want to provide a possibility for 8-bit interface. There are only 2 pins to shift between the ENC28J60 and the AVR, so it would require only one shifter. However, shifting between the C64 and the AVR could make a "clean" shift between the C64 and the whole board meaning any other components that get added would not have to worry about it. The whole board would essentially operate at 3.3V making other design work easy if it becomes an issue. This could also help reduce power drain of other components on board if they all operate at 3.3V.

I've never interfaced an AVR to the C64's user port. But, you should be able to quite easily use a port on the AVR to talk to the C64's 8-bit interface while using other AVR pins to talk to the C64's serial interface in conjunction with the on-board USART.

Now it's time for questions. Do you plan on providing a JTAG port to do flash updates via hardware? If not, do you plan to provide the ability to perform flash updates from the C64?

Jim,

You bring up some excellent points. Is the 1670 backwards compatible with the 1660 in that it will accept SID DTFM? If that is the case then that will be a problem I am not sure I want to deal with. How many old programs can only dial using the SID? Maybe it would be best to start with RS-232/Hayes and move to 1670 support if/when needed/possible.

I am glad you have worked on some code and I will need a LOT of help in that area if this project makes it that far.

The M644P 40 pin PDIP package is huge compared to the 28 pin PDIP package so I hope it will not be necessary go there. I know going surface mount will give a much more reasonable package size but I really don't want to venture out of through hole land. Although if feature creep takes hold I suppose a big footprint AVR is not out of the question. Some people might want to cram an IEC to network drive in there, or something crazy like that.

Depending on how big we want the board to be maybe we can put in place the layout for both the Ethernet and RS-232 connections and let the user decide what parts to solder onto the board. Or maybe having both would be a better fit on a surface mount board (something I am hesitant to try to solder.)


eightbits,

Thanks for the words of support. The current draw could be a problem as I am hoping to power this device through the user port. How much current does it allow for? The specs I have say 100mA max. The old Commodore modems had to draw more than that, right? A switching regulator for the 3.3v would help, but they are too expensive. A don't want to spend more than a buck or two on the regulator.

The ENC28J60 is the enabling technology for me, I wouldn't even think of trying this with a million pin surface mount IC as I am going to be building this myself and my soldering skills are not good.

To keep the chip count down I will likely shift between the AVR and the ENC28J60. Shifting between the AVR and the C64 would require at about two more ~24 pin chips.

As far as interfacing the AVR to the C64 CIAs, it has been done with many other projects so that should not be a problem, I agree.

I was planning to programming the AVR with the 6 pin ISP interface using the AVR ISP mkII. Putting a 6 pin header on a production board will be a good idea. I will also look into routing the respective pins to the C64. However I am not currently interested in making a flash program for the C64.

Now for some questions of my own.
I am going to be placing a parts order soon. Any ideas on good parts to use for the 25mhz crystal, Voltage regulator, Ethernet jack with built in magnets, level shifter. All must be through hole especially for this early prototyping phase.

To find the power available to us at 3.3V over the userport, we need to convert the figures to mW. So, 100mA @ 5V is 500mW. 500mW/3.3V is 151mA at 3.3V. You will also need to consider the power draw of the regulator you use. You can probably find one that will take microamps converting 5V to 3.3V. But to be safe, let's take 5mA off for that and another 5mA off just for robustness. That leaves 141mA @ 3.3V.

So, good call! You're going to need more power. There is 9VAC at 50mA riding that port. That's 450mW RMS which is good for 136mA RMS before conversion. Conversion from AC to DC will take a bridge rectifier (which can be found in a single part) and regulation from that DC voltage (which will probably be somewhere around 12VDC) to 3.3VDC will take a little more power than 5V to 3.3V. Let's estimate that we can get 400mW out of it. That will get us 121mA @ 3.3V. If you add that to the 141mA we got earlier, we're looking at 262mA @ 3.3V.

That's probably good enough.

But that's a lot of extra components. I guess the question is, do you prefer a blackbox solution or is it OK to draw power from outside sources? If this is meant to be a design that people can solder on their own, it might be acceptable to slap a 5V-to-3.3V regulator and a power input jack on the board. This will let people use 5V wall warts to supply 3.3V power. 5V wall warts are very common. Most people have one they're not using laying around somewhere I imagine. If not, they're cheap. I know I'm not opposed to running extra power to my C64 from external sources. I think most people who are going to solder their own boards probably wont either.

Crystal:
http://search.digikey.com/scripts/DkSea ... me=X231-ND

Regulator:
http://search.digikey.com/scripts/DkSea ... 21611-5-ND

I've only ever tried the discrete ethernet jack for the C64NIC. I know nothing about the jacks available, but I'll start looking around and see what I can find.

I've never seen a through-hole CMOS logic level shifter, but I'm sure they're out there. I'll do some more looking and get back to you.

Another word of advice. Don't worry too much about the surface mount soldering bit. I understand the need to breadboard with DIP parts, but you have options. For instance, I've seen people solder short 22 gauge wires to the pins of surface mount parts so they can be breadboarded. Don't let surface mount disuade you. The CS8900A is the only surface mount chip I've ever had difficulty soldering. Also keep in mind that the CS8900A is an ultra fine pitch part. You can get surface mount parts that are not ultra fine pitch or fine pitch and are just as easy to solder as DIP components. The trick is to get some fine solder wire and purchase a small tip for your iron. For all parts, even through hole parts, I use this solder:

http://search.digikey.com/scripts/DkSea ... =KE1303-ND

It's a very fine wire and it doesn't spew flux everywhere. It's nice and clean and works extremely well on surface mount components. Don't let the price of that solder fool you. It's a TON of solder! It will last you a very long time.

You may also want to consider getting a "Helping Hands" unit. This is a small stand with two alligator clips on a series of ball joints that is very flexible. It can hold parts for you and it also has a magnifying glass to help you see smaller stuff. This is an example of one and is almost identical to the one I use:

http://www.amazon.com/Dual-Helping-Hand ... B0002BBZ2Y

So, if you can solder wires to your surface mount ICs for breadboarding, then soldering the surface mount components on a finished PCB wont really matter as long as they're not BGA, fine pitch, or QFN. If you stick with SOIC parts, you will probably find them easy to solder.

morning ladies
Since one week i am the proud owner of a small linux embedded device called "nslu2"
this device is usually used to connect a usb storage devices to the ethernet. nevertheless it features a little ttl 232 port on the pcb

since brains java modem emulator should work under linux you have a working 65 euro solution... not quiet 30-40 but half way there .


just my 5 ct.

regards.
nils

Hi eightbits,

The "helping hands" unit is almost identical to the one I use too. I couldn't live without it.

Ok, you talked me into it. I will use surface mount packages where the leads are big enough to work with.

As far as the power goes, the dual power source seems way too complicated (or I am lazy.) So, I pulled apart a 1670 modem I have sitting here and it look like it is pulling current from the 5vdc and the 9vac are not connected at all. The wall jack traces are tiny so the modem is not sneaking any power from that either.

I still have no way of knowing the power draw of the modem though. Anyone have any idea? It has 2 c49 micro controllers, one ROM looking chip and all the other various typical analog phone devices. I guess the only real way to tell is to measure the current draw.

I do not nave a authoritative source for the current limit of the user port. Just some random web page I googled that has a pin out listing.

Does anyone know what the 100ma limit on the 5vdc of the user port is due to?

Ok, I am totally obsessing on this power issue. Why only 100ma aah!

Hi, masterhit,

That is a very good idea, and I think it would make a fine solution. It does not fit with my design goal of making it as small and simple as possible, however.

1670 does not support the SID DTMF, so you're OK there.

This link http://skwirl.com/coco/ethernet/ is using an M8, and he's at 6kB with a simple Ping app. Thus, I think you're going to be hard pressed to implement a TCP/IP app of any substance in an M8. 40 pins is a lot bigger, but the 6551 is 28 pins, and it's common in Swiftlinks and T232s

I don't think SMT is required, at least for a first run. A 6551 and a M644P can both fit on a regular cartridge case.

I think power may be a hairy issue.

The C64 has two sources of 5V power. One straight from the power supply at the power plug, and another that gets rectified and regulated internally from the 9VAC from the power supply. That is regulated by a 7805 without a heatsink. Without a heat sink, the 7805 typically can only source about 100mA so I suspect that's where the user port's +5V is coming from. Not 100% sure since the schematic in the C64 PRG doesn't make that clear. If we need to, we can probably crack open a C64 and find out, but I think we can trust the engineers on this one.

If we rectify and regulate the 50mA @ 9VAC to 3.3V, this is what it would take:

1. Bridge rectifier
2. Two capacitors
3. 3.3V regulator
4. BJT transistor
5. Resistor

Bridge Rectifier:
http://search.digikey.com/scripts/DkSea ... %2F51GI-ND

3.3V Regulator:
http://search.digikey.com/scripts/DkSea ... -1731-5-ND

If you want to use different components, that's cool. Those are just examples. Just keep in mind that the 3.3V regulator you choose must be able to accept at least 13V on its input. But that's pushing it. I would make sure it can handle at least 15V for some head room. Many 3.3V regulators do not accept input voltages that high. This one allows 20V. It must also be rated to provide 200mA or more.

What we do is use the 3.3V regulator in a high current configuration with the transistor's emitter connected to the user port +5V line and its base connected to the bridge-rectified output from the 9VAC line. The transistor will have to be selected based on it's beta as calculated for the power. The resistor value will have to be calculated from this too. The LM7805 datasheet has good reference material for this.

That would give us a single 3.3V power source with all the power that the 5V and 9VAC power lines can provide. We still get to use the 5V line for the 5V ICs in the circuit. I think that's about the best we're going to be able to do here. Of course, this method of regulating 9VAC down to 3.3VDC is going to take some current, so we're probably not going to get even 250mA out of this. Heck, I'd be surprised if we break 200mA with this circuit. If that can't give us the power we need, then I don't see how we're going to be able to do this without external power or modification to the C64.

Ok I took a look at my C64c non-working board. The 5vdc for the user port traces to the 5vdc bus that runs along the front bottom of the board. This is the same source the cartridge port uses. So we shouldn't have a problem with the regulator The trace to the user port goes a lot thinner in one area though.

As for the 9vac, the traces are the same size as the signal traces on the rest of the board. So I doubt it would be wise to source power from that. The 5vdc trace is at least 3 times wider in it's thinest part.

Maybe the board could be set up so the user can decide to power it internal or external.

Well, that thinner trace is probably the problem. I don't think it would be unsafe to grab power from the 9VAC line. The caveat is that if it's the traces that limit the current draw through the user port, then we risk burning them up if we draw too much current. I don't think there is any over-current protection circuitry anywhere on the external 5V line and I don't think there is on the 9VAC either. To be completely safe, we'd need to also provide current limiting.

Another idea is that the C64 PRG says two different things in two different places about the user port 9VAC. It looks like it says 50mA in one place and 100mA in another. It's possible we could get 100mA at 9VAC safely. I guess we'd need to take a closer look at what's really going on inside.

But it really sounds like we may want to get the 3.3V from an external power source. It sounds like the simplest and most robust way to do this. We can still get the +5V power from the user port, though. No reason to change that.

If you want to provide the ability for the user to select the power source, then you're adding even more parts to the card.

Before you look for complex power solutions, you shuld verify that you will need more than the expansion port can deliver. The expansion port can deliver quite a bit of power.

Jim

The problem is that The Beck is looking to use the userport instead of the expansion port. I may have been mistaken in my numbers, but it looks like he'll need 180mA @ 3.3V for the ENC28J60 and a few more milliamps for the other components. The user port only delivers 100mA @ 5V per the C64 specs. Is that number wrong? It wouldn't surprise me, but I have no other sources of of information that tell me differently.

If that number is correct, then the ethernet chip's typical current draw already exceeds that value. If we're getting these numbers wrong, please let us know what they should be.