Behave just like the CS8900A driver: Both the CS8900A and the LAN91C96 dynamically share a buffer for received packets and packets to be send. If the chip is exposed to a network with a lot of broadcasts the shared buffer might fill quicker with received packets than the 6502 reads them (via polling). So we might need to drop some received packets in order to be able to send anything at all.
Of course one can just always call dns_resolve after dns_set_hostname. But an application might i.e. present a different user feedback depending on the fact if a name resolution is necessary at all. So given that DNS name resolution is already a two phase action it just seems natural to allow an application to read the already exsisting variable.
The pretty small check_for_abort_key is used by DHCP and DNS which means it is used by about every IP65 program. The pretty large get_filtered_input on the other hand is very seldom used so it makes sense to put the latter in a separate module to keep it from ending up in binaries unused.
The previous chip detection was inspired by the old IP65 driver code. For some reason it didn't work as expected. The new code is simpler and based on this statement in the chip datasheet: "The upper byte always reads as 33h and can be used to help determine the I/O location of the LAN91C96."
* CS8900A
The Contiki driver allows to adjust the chip base addr at runtime (which allows to support different slots in the Apple II) and removes received frames from the chip if there's no room to send frames.
* LAN91C96
The Contiki driver was used by IP65 more or less unchanged in the first place.
* W5100
The Contiki driver allows to adjust the chip base addr at runtime (which allows to support different slots in the Apple II) and stays clear from the W5100 hybrid mode. It presumes a fully functional W5100 register auto-increment and pre-calculates necessary W5100 frame buffer wrap-arounds and thus achieves the maximal 6502 <-> W5100 transfer speed.
I have no idea why this BRK was put there in the first place. At least nowadays it's pretty common to see IP packets that IP65 doesn't understand / need to understand. Just think of IGMP packets. We certainly don't want to crash on receiving those!
It's the very purpose of the DATA segment to consolidate all items that potentially need to be copied from ROM to RAM. So there's no need to / point in doing that on a per-item-base.
This file isn't technically related to ip65. It uses the W5100 IP stack to implement UDP frame RX/TX. The code heavily optimized for size (in contrast to speed).
- Added exit_to_basic symbol.
- Aligned linker config with C64 linker config.
- Made switch to lower charset compatible.
Allow all test programs to run with LANceGS card.
Aligned C64 input file name.
- Tab chars were partially used with the unusual width of two blanks. I removed them altogether.
- Line endings were inconsistent even iniside individual files. I normalized them.
- I introduced a consistent coding style regarding comment indenting and blank line usage.
- I removed trailing spaces.
- I removed newlines following unnamed labels.
- ...
- Simplify Makefile by allowing to use suffix '_tcp' to denote the requirement to link against TCP-capable IP65 lib.
- Remove 'test' or 'test_' prefix from test program names - every program in 'test' is a test program.
- Have some more test programs switch to lower case charset on the C64.
- I'm no Ruby guy so don't rely on Ruby for building disk images.
