BNU Fossil Driver FAQ
Answers to frequently asked questions
 Q0:     Why this FAQ?
 Q1:     What is a FOSSIL?
 Q2:     What is BNU?
 Q3:     What does BNU stand for?
 Q4:     What is the lastest release?
 Q5:     Is this version 1.XX a proper version?
 Q6:     Can I use this beta version?
 Q7:     Where can I file request the latest version?
 Q8:     When will the next release of BNU be?
 Q9:     Can I lock the port at 57600 baud?
 Q10:    How can I get BNU to use IRQ5, 7 or 2?
 Q10a:   Can my serial card use IRQ 8 - 15?
 Q10b:   Can BNU share interrupts?
 Q10c:   Can I use IRQ 2 on an AT machine?
 Q11:    How can I get BNU to use a different port address?
 Q12:    Can I use BNU with a XXXX serial card?
 Q13:    What about BNU 1.70 and multitasking drivers?

* Q0: Why this FAQ?

BNU, from its modest beginning in mid-1988, written as an experemental driver for serial communications, then being made "FOSSIL compatible", and finally released for public use, has become used much more widely than expected. This FAQ represents a suppliment to the BNU 1.70 documentation, states things which should have been stated in that document and attempts to answer the many other questions which have been asked many times over the years.

* Q1: What is a FOSSIL?

A "FOSSIL" is simply a communications driver. It exists because MS-DOS and the IBM-PC BIOS provides very poor support for serial communications, and falls far short of the needs of any non-trivial communications task.

The term "FOSSIL" (which stands for Fido-Opus-SEAdog-Standard-Interface-Layer) is a communications standard which has become stable over the years, and is in wide use both in and out of FidoNet. It represents the work of several FidoNet sysops who felt the need to provide a standard API for use in an environment which makes use of several software packages.

The history of the FOSSIL standard itself, and all the technical details, may be found in the FTSC document FSC-0015.

*Q2: What is BNU?

BNU is a FOSSIL - See Q1.

*Q3: What does B.N.U. stand for?

The name "BNU" was originally a rip-off of AT&T's "BNU UUCP", and in that context meant "Basic Networking Utilities". I felt that the acronym was particularly apt for BNU's function.

*Q4: What is the lastest release?

As of this date, version 1.70 is the latest. Version 1.70 was released in October, 1989, and certainly hasn't suddenly ceased working for lack of any subsequent release. It has been proven stable on a wide variety of systems and, with specific exceptions, works better than any subsequent beta release (see Q5).

*Q5: Is this version 1.XX a proper version?

Subsequent to the release of version 1.70, there was an 'open beta test' arrangement, where specific systems around the world had permission to allow beta version drivers to be file requested, but distribution otherwise by automated means was prohibited.

The reason for this restriction is to prevent a user from using a beta release which causes problems on their system and with other software without them realising the status of the driver. Those specifically interested in testing the driver and reporting problems were allowed access. The system worked well for a while and required almost no administration.

Unfortunately, this system was withdrawn in 1991 because it became apparent that despite specific and very prominent notice in the documentation and archive comments, drivers were being placed on BBS systems for download and file request. This was further evidenced by the amount of mail being received regarding support for beta version drivers. It was clear that the 'open beta' system was not fulfilling the original aims. BNU is now in closed beta test only.

Versions after 1.70 are in the 1.7X and 1.8X range. The last released driver in the open beta scheme was version 1.89h.

If you discover a driver in the 1.7x or 1.8x range (and certainly all of the 1.8x version will identify themselves clearly as beta versions) then it is probably valid. There has _never_ been a driver released with a version 1.9x or 2.x identifier.

Beta versions, by their nature, are less stable than the 1.70 release. In particular, most of the version 1.8x range represents highly experimental code, testing various alternative methods of handling communications interrupts, multitasking systems, 80386 memory managers and shared IRQ cards. Many of them will not work on 8250 UARTs and require a 16550A or better.

*Q6: Can I use this beta version?

If you find a beta version, you assume all risks. They cannot be authenticated, and they are not officially supported by anyone. You are, however, welcome to use one if you find. I ask only that the terms of the original distribution be honoured - that is, do not make it available for file request or download and do not transmit it by any other authomated means (ie. on CD-ROM or via TICK etc). You are otherwise welcome to give the driver to others provided that the receiver is aware of the beta status.

*Q7: Where can I file request the latest version?

"latest version" in this case refers to beta versions. There are no restrictions on distribution of BNU 1.70.

If someone makes a beta driver available for file request, they are doing so against my wishes, and are therefore breaching copyright.

*Q8: When will the next release of BNU be?

It is unknown at this stage, but a new driver is being built and will hopefully see a public release sometime in the third quarter of 1998. The version number of that driver is as yet undecided.

The new release will represent a step beyond the 1.70 release, and will incorporate a new API for developers to take advantage of. It will also include a developers package and an interface library with sources and the new API specification. Features of this API have not yet been finalised, but an INT 14H "FOSSIL" compatible layer will certainly be provided, so it can still be used with existing software.

If you find any archive purporting to be a latest "release" of BNU than 1.70 which does not contain these items, it is NOT a valid release.

*Q9: Can I lock the port at 57600 baud?

Yes. Although undocumented, BNU provides for locked baud rates at both 57600 and 115200 baud:
  /L:57600            Locks at 57600
  /L:11520            Locks at 115200

*Q10: How can I get BNU to use IRQ5, 7 or 2?

Yes. BNU can use any combination of port and IRQ addresses. Internally, it has a table of 16 "slots", which represent logical port numbers, numbered 0 through 15, which normally correspond with COM1 through COM4 on the PC and 12 others.

These 16 slots are alternative configurations - it does not represent how many ports BNU can support concurrently. BNU 1.70 only supports 4 ports in use at the same time (this was changed in beta releases to allow support of up to 8).

The port configuration is maintained by the BNUPORT utility, provided with BNU 1.70. The standard configuration contains a setup for the standard DOS serial ports, COM1 though COM4, for ISA (AT) bus machines only.

The only "mysterious" part of BNU port is the meaning of "IRQ Vector" and "IRQ Mask". Both are linked to the IRQ number, as is shown in the following table, which lists the settings for all possible IRQ settings on an AT (286/386/486 ISA) class system. Numbers preceded by 'x' are in hexadecimal.

  IRQ Mask Vector Usually used for...
  --- ---- ------ -------------------------------------
  00  x01  x08    System timer
  01  x02  x09    Keyboard
  02  x04  x0A    AT=cascade, EGA/VGA, Network adaptors
  03  x08  x0B    COM2 & COM
  04  x10  x0C    COM1
  05  x20  x0D    unused   (LPT2, SCSI 8-bit, tape)
  06  x40  x0E    Floppy drive controller
  07  x80  x0F    unused   (LPT1, SCSI 9-bit, tape)
                  - Available on AT+ machines only -
  08  x01  x70    RTC Clock
  09  x02  x71    Redirected IRQ2
  10  x04  x72    unused
  11  x08  x73    unused
  12  x10  x74    unused
  13  x20  x75    unused
  14  x40  x76    Hard disk controller
  15  x80  x77    unused
Configurations using IRQ 0 through 7 used 0020 as the "8259 Port". IRQ 8 through 15 use 00A0.

The IRQ mask is the value used by BNU to enable the IRQ level on the Programmable Interrupt Controller (or 8259 chip).

The IRQ Vect value corresponds to the interrupt allocated to the IRQ level.

*Q10a: Can my serial card use IRQ 8 - 15?

Usually, no. Almost all serial cards are 8-bit only, and a 16-bit card is required to support the upper 8 interrupt levels available on AT class machines. Some PS/2 and EISA specific cards do support these interrupts, however, and there is no inherent reason why a 16-bit serial card built for an AT class machine would not work. However, most manufacturers don't make them for lack of demand - the 8250 family of UARTs (the chip used for serial I/O) are still only 8-bit devices.

*Q10b: Can BNU share interrupts?

This translates to:"can I configure two ports to use the same IRQ"?

The short answer is No.

The long answer is that there are two problems involved. The first one is support in hardware:

The design of the AT bus prevents any two cards from using the same interrupt. Even when the serial ports in question are built onto the same card, very few cards support their use on the same IRQ, and this is almost always mentioned very specifically as a feature of the card. If the documentation does not metion IRQ sharing, then it almost invariably won't work.

Some cards however, do support IRQ sharing - notably the AST 4-port, 4 and 8 port "dumb" DigiBoard and the Computer Decisions 4-port. There is also no problem sharing IRQ levels on a level triggered bus, such as provided by the MCA (PS/2) bus architecture.

The second problem is that BNU does not support IRQ chaining. It looks only at one port when servicing interrupts. However, interrupt sharing will be supported in a future release.

*Q10c: Can I use IRQ 2 on an AT machine?

Short answer - usually, yes.

(For the pedantic: this is a short, non-technical description, and therefore contains information which may be technically erroneous, but is stated in this manner for the sake of brevity)

Because the CPU hardware only supports 8 IRQ levels, only one interrupt controller (and therefore only 8 interrupt levels) have direct access to the CPU. When the AT286 machine was released, a second interrupt controller was added to service another 8 interrupt levels; and the upper 8 levels "cascaded" into the first interrupt controller's IRQ 2. So what occurs is that when an IRQ 8 - 15 occurs, the second (slave) interrupt controller causes an IRQ 2 as seen by the CPU.

This scheme would normally make IRQ 2 unusable to any device on an AT machine, because it is no longer wired to the bus, but to the other interrupt controller. To get around this, the bus IRQ 2 line was 'wired' to IRQ9, so that a device using IRQ2 would cause an interrupt at level 9 (and therefore 2 at the CPU).

Devices using IRQ2 may therefore be used on an AT+ class machine so long as the software is configured to use IRQ9. Well... almost. It may also be possible to configure software at IRQ2 because most BIOS chipsets automatically redirect any calls to the IRQ9 handler to the IRQ2 handler after resetting the second interrupt controller. However, some early BIOS chipsets don't support this properly and so may not work.

*Q11: How can I get BNU to use a different port address?

Certainly. Any 8- or 16-bit port address may be configured using BNU port. See Q10 for more information.

*Q12: Can I use BNU with a XXXX serial card?

BNU supports _standard_ UART configurations only. There are many cards on the market which use technology above and beyond this, some with their own on-board dedicated CPUs (from Z80s through 80286s) dual ported RAM, interrupt controllers and multiple UARTs. Basically, these cards are a mini-PC themselves, with CPU's dedicated to servicing communications only, relieving the main CPU of all interrupt handling save the copying of data from common RAM to the application.

Most of these cards are supplied with drivers for Xenix, UNIX and/or OS/2, and the MSDOS drivers work fine for access via DOS. Some even provide a BIOS compatible INT 14H interface. However, their use with FidoNet software is limited because no FOSSIL driver exists for them (at which I'm mildly surprised - the market is certainly big enough). If you wish to run one of these cards, you should try to convince the manufacturer of the worth of producing a FOSSIL compatible interface. This is the benefit of having the API in the first place.

*Q13: What about BNU 1.70 and multitasking drivers?

BNU 1.70 documentation mentions multitasking drivers. These have in fact been developed, but the driver interface changed since BNU 1.70 was released, and they are not compatible with the 1.70 release. Furthermore, they are only of benefit if you use software which is not itself "multitasking" aware, since all they do is detect when the driver is being "polled", and after a timeout automatically 'steal' time slices from the calling task and give them up to the system.

The use of these drivers is questionable when the vast majority of software already takes advantage of multitaskers and knows how to give idle time slices away. Applications software usually has a much better idea of when it is idle, and with the driver possibly giving time away when the application is doing likewise, the result can be that the application does not get sufficient CPU time for time critical communications, such as when establishing connections and so forth. This can cause difficulties if used incorrectly. Many problems reported with BNU 1.30 - which had this built into the driver itself - were due to problems of this nature.

Return to the BNU Home Page