RaveGuru wrote:
This is starting to get really interesting. It would be great to make this a general purpose API to be put in for instance 64NIC+ ROM and RR hence producing:
1) A consistant API for (inter)networked applications
That's pretty much the design goal for the NB65 API
RaveGuru wrote:
2) Offloading most of the TCP/IP code from RAM
kind of - I would like to allow for NB65 drivers being loaded into RAM, with a way for applications to
know whether or not they can safely use the $8000-$9FFF RAM space (and either exit gracefully if they need
that space, or operate in a diminished capacity if they can do without it). This is what the 'NB65 Bank Support'
variable ($800E) signifies.
RaveGuru wrote:
3) A uniform way to detect the various NIC soultions currently available
Well the idea really is that an application doesn't need to know what the NIC is at all. That should make
it possible to easier to develop new NICs based on different chipsets e.g. a wifi device with an SPI interface)
In fact if someone was motivated enough they could probably write a PPP or SLIP driver that implemented the
NB65 API.
If someone is really keen to know what the underlying hardware is, they can call the NB65_GET_IP_CONFIG function
which returns a structure that contains (amongst other strings) a pointer to an ASCIIZ string that describes
the NIC hardware. But I would really only see this as the sort of thing someone might need to know when debugging
an issue with their application, I wouldn't expect the application itself to need to behave any different based
on what the NIC is.
RaveGuru wrote:
TCP would need to be implemented though.
Yes, but I think it will be a "v2.0" feature - I've been focused on trying to get a 1.0 in line with the 64NIC
going out, since slipstreaming that project will hopefully get enough copies of the API
out in the wild for people to be motivated to develop some apps for it.
The two things I'm struggling with on the TCP implementation are
1) a couple of kid free days to get a clear run at it, and
2) what the API should be for calling apps. The normal API for TCP is to abstract away the flow of packets
and present data as a byte stream. But if I implement it that way, then there's likely to end up being 3 buffers
with copies of data in each direction. For example, for incoming data there will be
- the buffer with the incoming ethernet frame, containing ~ 1500 bytes of data
- the TCP buffer (of say 4Kb?) into which the data needs to be copied out of the ethernet frame, put in
the right order, and kept until the client asks for it. To support multiple concurrent connections, you'd
need multiple TCP level buffers.
- (most likely) a client side buffer that the client app will copy data into (1 byte at a time) out of
the TCP buffer, until it gets whatever application level "chunk" it expects to see.
For UDP, there only needs to be 1 buffer - effectively the calling app looks directly at the ethernet buffer whenever
a UDP datagram arises (ip65, which netboot65 is built on top of takes some shortcuts and doesn't support re-assembly of IP fragments)
Maybe a reasonable compromise here is to implement a TCP API that uses callbacks similar to how UDP is done, so the IP stck only needs
to manage the single ethernet buffer, and the calling app can decide if & how to string multiple datagrams together into a bytestream - I would
probably provide some example apps doing this so developers didn't need to start completely from scratch.
The IP stack would however garuantee that data is only sent to the calling app 1 time, and in the right order (i.e. it would detect duplicate and out of order
packets).
RaveGuru wrote:
Keep it up!
Thanks!
Login
FAQ
Search
