Hi All!

In my search for some simple and inexpensive I/O devices, I ran across a few sites that sell ethernet adapters suitable for use with 8 bit embedded processors and microcontrollers.

Has anyone successfully put a 65c02 on a TCP/IP based network?
Anyone (besides me) interested in doing so?

Here are the links to the hardware. There is some software available from some that could be used to build a 65c02 version.

http://www.edtp.com/
http://www.embeddedether.net/

Daryl

Hi Daryl,

Andre Fachat has done something similiar to this with his 'Gecko OS'. Try His WebSite.

I would be interested to see how much code it would take to
implement a basic TCP/IP system on the '02' or '816'.

Keep us up to date, Wally
[/list][/quote]

I found a wealth of information and some interesting apps developed for the C-64 on this web site. This is a very good place to start.

http://dunkels.com/adam/index.html

Daryl

I'm (finally) getting the code done to drive a Realtek 8019 based ISA network card. At the moment it's being done on a Mitsubishi 38067 (740 family) but shouldn't be too hard to port to any other 6502 cored device.

So far I can get the connection LED on (on both the card and my hub) and the heartbeat status reads correctly.

Next the hard stuff - reading packets. 8^)=

Lee.

Things progress...

I've now got to the stage where ARP and ICMP now work!

It's mostly written in EhBASIC and takes 3 seconds to reply to an ICMP request (AKA ping) but it was so sweet seeing that 'reply from' message.

I spent the last half hour before work looking for an electric doorbell I know I have somewhere to wire up to a spare port pin.

Well it has to be done. 8^)=

Lee.

Three seconds?!?! Good grief -- what in the world is that thing doing? That's an eternity for ARP and ICMP messages (BTW, not all ICMP requests are ping requests). ICMP is a very low-level protocol, and is often managed "in-stack," meaning it it's rare to find explicit ICMP daemons. I can't fathom why it'd ever take three seconds to reply -- even for a 1MHz processor.

--
Samuel A. Falvo II

It's running an interpreted language. Printing out the packet stats for each packet to a 9600 baud serial port alone is a killer, converting a floating number to a string and outputting it takes anything up to 15000 cycles to perform.

And it has to reply to the ARP before the first ICMP echo request, after that it takes about 2300mS per ping.



It would seem not, DOS ping waits about 10 seconds as the default timeout so 3 seconds is within the expected delay, or so it seems.



Because it's written in an interpreted language, which is actually quite fast as implementations of BASIC go. On a 1MHz processor it would take about 12 seconds to do the same thing. I guess you'd be looking at 15+ seconds on a BBC micro or similar.

Lee.

You're doing a lot of processing between the time you receive a packet and the time you respond to it. Printing over a 9600bps connection is what's killing it. If you don't print, I'm willing to bet you, it'll go at least an order of magnitude faster.

Also, floating point numbers has a lot to do with it too.

That probably has the most to do with it.

However as this is 'proof of concept code' I don't really care if it takes .3 seconds or 3 seconds, just that it works.

It's much easier to debug BASIC interactively than to have to try and work out what went wrong in the assembly code every time the new EPROM doesn't work.

It also saves on EPROMs.

Off to finish the TCP code now.

Lee.

Lee,

I agree that debugging in a high level language is easier. When I'm debugging my assembly code, I have it built in RAM and use the xmodem routines that I wrote to download it directly to RAM. As a bonus, the xmodem code takes the TASS object files without modification, so its really easy to edit your assembly file, compile it with TASS, then call the xmodem routine and presto, your new code is ready. Also, since its in RAM, you can make simple changes using your monitor program.

Anyhow, keep up the work on your code. I just picked up an ISA network card based on the RT8019 also ($4.95 US), and would love to see your code when your are ready to share it.

Cheers!

Daryl

I'll see if I have time to do some pages with the circuit and probably the code for ARP and ICMP echo this week.

TCP is proving a little troublesome as by the time it's replied to the first SYN packet two or three repeats are waiting in the queue. From there it all goes a bit pear shaped.

I guess if I can get this to work in EhBASIC the assembly version should be rock solid!

Cheers,

Lee.

Lee.

Let us know when its ready!

I found an ethernet I/O board called the packet wacker based on the RT8019AS with drivers written in C for a PIC 16F877. The web site address is:

http://www.edtp.com/

They also have some technical documents and schematics.

Good luck!

Daryl

I saw the packet whacker but really need to understand what I'm doing so I'm working from the following documents I've collected ..

new-8019as.pdf - the realtek chip data sheet.

DP8390D.pdf - The 8390 is the ethernet chip, this document has lots of usefull info about packets and programming.

RFCs ..

791 - IP, you'll need this.
792 - ICMP, about the easiest usefull thing to do.
793 - TCP, a must have.
1180 - TCP/IP tutorial

I'm now at the stage where PING left running works reliably without lockups, dropouts, missed bytes etc. One test, while I was at work, reported only two replies lost out of 15000+ and those were timeouts.

Lee.

I've converted the packet wacker driver's C code to 65C02 assembly. I hope to get my 65C22<->ISA connections made this weekend. Then the testing can begin. If all goes well, I'll post it to my web site.

Daryl

The thing that goes ping now also serves those who sit and wait, and wait, and wait......

Three web pages were successfully served today by my microcontroller, with Realtek PC network card, running an EhBASIC program. It's not fast, taking about 45 seconds to reply to the ARP request, establish the TCP connection and deliver the page, and it does just drop the TCP connection without waiting for the FIN ACK afterwards, but them's just details.

So there's just the TCP state machine to finish, a tidy up of the code and comments and the writing up of the web pages to do.

This is going to take ages. 8^)=

Then there's the .asm version to get done.

I'll let you all know when there's something to see.

Cheers,

Lee.