At least some of those words are "Why is antidote always busy?", and "Hey, this telnet client is <900 bytes.".

http://www.flickr.com/photos/43643094@N08/5129813558/
http://www.flickr.com/photos/43643094@N08/5129809730/
http://www.flickr.com/photos/43643094@N08/5129209309/

where's the pix?

(fixed picture links above)

sweet!

how soon till we can play with it?

didnt i post bitbreakers wiznet schematics a while ago? =)

_________________
http://hitmen.eu

This is a different project, groepaz - no RR or clockport required.

The cart in the pic is one of the Super Snapshot clones _dW designed for ECCC 2006.

If you check out Glen Holmer's pix from C4 back in May, that's when the first round of protos were assembled.

The basic IO lib is working out to around 1K, but I'm working on DHCP/DNS right now. The thing is pingable as soon as you initialize it. I'm hoping once I've optimized the lib, it can be around 1.5K with DHCP/DNS.

Would you consider implementing the Kipper API on top of wiznet?

That would make it possible to write a TCP client app that worked with either RR-NET or Wiznet.

geoLink also uses a slightly modified implementation of that API to split the ip65 code (which must be assembled with ca65) from the rest which is written with geoProgrammer, so a wiznet version of the Kipper API would probably facilitate a port of geoLink to your boars as well.

The Kipper API spec is http://netboot65.sourceforge.net/kipper ... erence.doc

Given that (AFAIK) there is a total of 1 implementation (KipperKart) of the API, and 1 app that actually uses that API so far (being WebNoter) we can modify that spec a bit if needed to get better compatability between implementations.

How are you handling timeouts? Can the Wiznet's hardware do that, or must it be in the API?

_________________
"...and all watched over by machines of loving grace."

uh yeah. well. an inverted addressline and a trivial change in decoding logic. but sure, its "different" =) (infact, bitbreaker had one connected straight to expansionport aswell)


i know .... speaking of that, i am still waiting for my prototype, and countzero aswell i guess =)

_________________
http://hitmen.eu

Unfortunately for me I didn't have the benefit of bitbreaker's design when I was originally working this out. If you think it's a better design, I'll give it a look. I definitely need to get away from the pre-assembled Arduino wiznet module.

Revision TWO of this prototype, May 2009 - Brain had to fix my ham-handed soldering, refine the logic, scold me about using 12 guage wire for protyping:

I was actually going to ask you the same thing. ShadowM has the on the other prototype of this design. I don't know if IP65 would adapt to this model well or not. You may want to roll a whole new wrapper for cards that handle their own stack. I've got a small lib I'm using to test things, but it needs a serious cleanup. I suspect someone with more time on their hands could get it down to <512 bytes for just init/send/receive over UDP.

The first thing I did was make a udpslave work-alike loader stub for it so I could move code easily, so UDP server mode is well tested.

I'm thrilled to learn this board supports UDP as well. Idea for realtime network games, and gets you away from the limitations of 4 maximum connections for TCP.

I have no free time to look at this, but am following the progress closely!

TCP should work well enough, though. I wouldn't go trying to make the 64 the server for a network game in any event.

I wish someone else would start building these out as prototypes so we could get some real development push behind this.

Well I'd be interested, but without a card, I'm kind of stuck



From what I can work out from the wiznet docs I can find online the functions exposed through the KIPPER API would actually map reasonably closely as they are all quite high level (e.g. look up a hostname, connect to an IP address, listen on a port) - the majority of the ip65 'low level' code (e.g. recieve an ethernet packet, do an ARP requeste, calculate an IP checksum), is hidden.

There may be some features of the wiznet stack you couldn't use, but what I had in mind would be a wrapper that implemented the KIPPER API that would be for "downstream" compatibility only, I'd expect it to be a supplement to, not replacement of, a wiznet 'native' lib. Some people may want to build a single client that can use an RR-NET or Wiznet card, but in doing so you would be consciously choosing to limit yourself to whatever works on an RR-NET ip65 stack (apart from anything else, you lose about 16KB RAM to the IP stack)

At ECCC, we did find that IRQ on the board has to be handled a bit special (It's not an OC pin, so you have to turn it into one, or it prevents IRQs of any kind from happening on the unit. And, I was adamant the design needed to support IRQ.

If there a bit of 8 bit baby or other proto-board stock available, more boards should be easy to make (essentially, using a '04 and '10 to create /WR and /RD, and a '06 for IRQ massaging. A rewire might allow cheaper ICs, or fewer (I cheated, dragged /CS low, and did all the signalling in /WR and /RD. But, it's probably best for /RD to be /(/R * PHI2) and /WR to be /(/(/R) * (PHI2)) and /CS = /IO1, with the C64 /IRQ being /(/(/INT)) using a '06. That would allow the use of '00 and '04 along with the '06. The '06 might be replaceable with a single transistor (PNP?), but I don't know.

Jim