Beijing Paradise BBS Backup/PARADISE.ISO/software/BBSDOORW/BNUFAQ.TXT

Text File | 1976-11-24 | 16KB | 341 lines

─ BNU FOSSIL Echo (1:106/2000) ─────────────────────────────────────────── BNU ─
 Msg  : 29 of 34
 From : david nugent                        3:632/348       Fri 16 Apr 93 14:57
 To   : All                                                 Sun 18 Apr 93 19:09
 Subj : FAQ time - part 1
────────────────────────────────────────────────────────────────────────────────
 BNU FOSSIL: Answers to frequenstly asked questions

This document represents information which answers most of the questions I am
most often asked about BNU, both in netmail and in the FidoNet BNU echomail
conference. Hopefully, the regular posting of this document into the BNU
conference weil help curb the repetitive traffic. This document, as updated,
will be included in the BNU documentation in all future releases.

The complete list of questions answered in this document are:

 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 1993. 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<port>:57600            Locks at 57600
  /L<port>: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.


 Q14:   ...

--- MaltEd/2 1.0.b6
 * Origin: Unique Computing Pty Ltd (3:632/348)