• Please review our updated Terms and Rules here

Packet driver services in BIOS

B

BradN

Member
Joined
Aug 27, 2006
Messages
32
Hmm, I did a little looking and it seems packet drivers use their own interrupt and don't require DOS - would there be anything stopping me from implementing say, SLIP or a similar serial protocol as a BIOS service?
 
Packet drivers have two main functions:

  • Wait for the user code to request that a packet be sent. This is done when the user invokes the software interrupt that the packet driver installs.
  • Wait for the hardware to signal that a new packet is available and needs to be copied into main memory. The packet driver will transfer the packet to your application using a callback mechanism that you setup when the application first talks to the packet driver.

A packet driver generally doesn't require DOS when it is running. It just needs to get loaded, and it needs to know how to talk to it's particular hardware device. Lots of network devices in the past have used service routines burned into ROM - the original IBM PC Network cards had a ROM extension to do this.

In theory a SLIP or PPP driver in ROM are possible. Both use a serial port. But both require some 'state' information that would take up a bit of RAM as well. Especially PPP - that's very complex compared to SLIP. You'd also have to have some more RAM dedicated as a holding area for packets being sent or packets being received.
 
That's why I was thinking this would be a neat idea - Since I place the video RAM at 16KB, this creates a space in the beginning of RAM that's useful to hold the BIOS and I have about 8KB space (say 6.5KB once I add more features) left over that are useful for buffers or cache.

It will be the place to hold the disk track buffer when formatting disks, but if dynamic allocation is used, this space could be shared without causing large difficulties. If the BIOS needs buffer space for something, it can choke the rx and tx flow until the buffers are small enough then move them (provided the program and other endpoint don't refuse to receive data), and if disk buffers are ever used, they can just be evicted.

It seems like this would be efficient use of memory but it's only possible for a DOS environment when the same program manages all those together.

Do you happen to know offhand how much state is involved that can't be forced out of the buffers by blocking the flow? Is some per connection?
 
You must log in or register to reply here.
Back
Top