home *** CD-ROM | disk | FTP | other *** search
- ─ 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)
-