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.