the microchip ENC28J60 isn't a parallel bus chip and as such not easily interfaced to a 6502 (unless you use megawin 6502 core microcontrollers, which can directly interface to that, but are more suitable to build usb keyboards, usb joysticks, led scrollbars, or anything else 'not a computer', as they don't interface to a parallel bus -at all-).
the CS8900A (make sure it's the 5v input compatible version, the 3.3 volt versions have a '3' in the type field) would be (comes in a 100+ pin smd kinda package, most of which are not used in 8 bit mode, (the rest is for hooking up pc boot roms, on pcb storage of mac addresses, and having the thing do it's own full address decoding, all of which don't apply in 8 bit mode) better order it pre-fab on some experiment board pretending to be a dip chip with magnetics, traces with the correct impedance, and connector already in place, there are several suppliers for those.
as for most control systems a full tcp/ip implementation isn't nessesary you can just send a raw broadcast ethernet packet containing a 'fake' udp header from basically any random ip address to 255.255.255.255. maintaining compatibility with operating systems that can't (easily do) raw sockets or specific ethernet frame type numbers, as non-root/admin users, so programs on your linux and windows systems can just open a udp broadcast socket and send and receive dataframes.
the 6502 or microcontroller doesn't have to bother with 'arp' 'maintaining a mac address table' obtain or store an ip address of it's own, or any of that.
it is somewhat limited to single-packet-at-a-time communications, it will not be routed to other vlans without some extra configuration of your routers, and it's advisable to keep the total number of packets under 5% or so of your total port capacity or udp broadcast storm control will kick in in most (proper) switches in their default configuration, but for turning on the lights or opening the fence without requiring programs to be root and sniff interfaces and such on your workstations, get status messages from your temperature control, heating or airco systems it's more than good enough. it even works with microcontrollers that don't have enough ram to store a full size ip packet payload (the ethernet and ip headers other than the ip desination port aren't interesting anyway so those can be skipped and not stored/parsed) (although obviously in that case the message size is also limited to what they can store in ram for parsing)
code that does just that is likely to fit in a few 100 bytes of rom at most. including detecting and initializing the ethernet controller and with or without static strings for both the ethernet header and ip header (although those mostly being 'FF's can also be inserted into the ethernet controller with an X or Y counter loop every time saving some more space
the CS8900A in the 5v input compatible version is the chip of choice for 6502 systems although IRQ's don't work in 8 bit mode on those. (so no switching off the 65C02 until an irq occurs) it's literally used in every single ethernet card out there for the c64 and others (all of the ones that are production models have the address lines swapped so the register blocks are 'up side down'. would be practical to maintain that setup for compatibility with c64 ethernet code. they also all have them at DE00 (they can be reconfigured but the going standard is DE00) but you can literally use any 8 bit or 16 bit isa ethernet card (pretty much all of the 16 bit ne2000 compatible ones WILL work in xt 8 bit slots (the '16 bit extension' part of the bus is detected by measuring some voltages on those pins, if they are not present the cards drop into 8 bit mode), they just stick out at the back) and just hardwire it or keep using it's internal address decoder (keep in mind that the pc has a seperate 64K 'io' memory segment with ior and iow lines used by the OUT and IN opcodes on the iAPx86 family (not MOV), a 6502 doesn't have that so it's in normal ram and addressed with LD?/ST? and therefore the approriate lines on the isa connector also have to be properly wired to make it think the selected address would be in io space. using pc isa cards also could require supplying it with additional voltage rails.
there is also this 'wiznet' chip thing but that's basically a microcontroller running the ip stack for you. (which as a result of that comes with it's very own security problems, obviously).
as for tcp: after stripping out all of the not-needed stuff generally present in ip stacks (most of which just facilitates espionage, such as 'ping (icmp echo)' and all 'icmp bla bla exceeded/unreachable' stuff and is thus better not implemented at all anyway) you're still left with a mac address table slurping up ram (6 byte mac address, usually your gateway's, 4 byte ip address, + some timeout/cleanup counter), a full implementation of ARP, 'sockets structs' for tcp sessions (on linux these are 4kb each but that's probably a bit overdone and includes a lot of stuff not strictly nessesary
gotta keep track of source and destination port and address, window size, sequence number, connection status, run the checksums, etc. it's actually more ram and cpu cycle intensive than rom. ofcourse a 6502 can do it... the entire internet was designed so even the most lousy 8 bit computer at that time could do it. (the concept code examples usually include things like the pdp-11 and the motorola 6800, which in those days most definately would not have had 64kb ram to work with in most cases
aaaaand then, you wanted to run http over that. which is all nice and well as long as you limit it to http 0.9 or 1.0, don't support partial/file offset gets, probably just check the command for the letter G, forget the rest of the "GET", and ignore the rest of the url and the HOST: header and simply always poop out the same file and an (the same) error in all other cases. also.. this part has to be 'multitasked' as 1 client can just 'disappear' halfway through or deliberately delay the tcp session so completely serving them one by one isn't good. they all have to be served simultaniously. so on top of keeping track of the tcp session details for each client, and the arp table entry for each client, you also need to keep track of the status of the http session for each client. (that, and http isn't the easiests of protocols to handle, lots of undefined stuff, lots of more or less 'free form' crap in random order that can or cannot be present, with 'one or more' spaces in between, multiple types of carriage return/linefeeds, etc) it's not as nicely chunked up into blocks with fixed formatting and commands that actually are byte sequences rather than strings, as we're used to from communicating with diskdrives and such for 6502 systems. basically the only thing that always is there (for document requests anyway) is the GET at the start
so the easiest way is to just tell anything that doesn't start with GET to go to hell, and serve all 'GET' guys the same page with status 200 and no further databloat. still have to run the 'state engine' for all of them and can't finish one before serving another unless your entire page fits in one ip packet's payload (and that packet also fits the mtu of the entire network inbetween although routers can refragment it on their own as long as you make sure the DF flag is 0) as the client may well disappear after you have sent them packet #1 and not wait for packets #2 and #3. adding http as well makes things needlessly complicated. the 6502 -can- do it but wether it's desirable for it to do it (at all, on any system) is another matter. for most things one would want to do (control tasks) sending and receiving single packets with or without confirmation and/or challenge response auth is more than enough. http widely gets abused for such things but it's not really suitable for it in the first place. stuff should just work by plugging it in with their mac address alone. nothing to 'configure' and no 'dhcp'. that's another thing. you'll also need mac addresses of your own (or just pick some random ones not in use anywhere else on that same vlan or any vlan any of your routers is connected to at the same time on a different interface) the 'reserved for owners of ip address ranges' blocks only seems to apply to the 5 byte mac addresses not to the 6 byte ethernet ones so that's no go. you'll need a real block. (as do we btw
none of those lose ethernet chips comes with a mac address of it's own like a normal network card would. despite the internet protocols being very old and designed with smaller systems of those days in mind, they actually are -very- resource demanding compared to let's say ax.25 running over bpq in ethernet II framing, offering simular functionality (virtual circuits on a packet switched network) with a far smaller memory footprint, and also far better mechanisms for resends on unreliable links (as it was intended for long range radio links). although the linux code seems to be partially broken. as in last time i tried it i could not get it to connect or accept a virtual circuit the 'normal way' without using raw frames. or it did but never disconnected it again
also the 7 byte callsign+ssid seemed to crash certain interface drivers (tap drivers which should work fine) just broadcast beacons and single packets. (some people appear to have been messing with it that use it for different purposes such as location data tracking and probably broke it as it worked before
most of the code is 20 years old by now tho. as getting whatever your 6502 system talks to communicate with something else is a requirement, having the same protocol stack on both ends in a working condition would help lol. acorn econet also would be a very good and lightweight ethernet alternative (just replace it's normal wiring with canbus or fiber tranceivers) but the required motorola 6854 isn't on the market atm. and also econet was removed from the linux kernel alltogether (guess they were more concerned with supporting usb coffee cup warmers again
Login
Register
FAQ
Search
