continua (next page) Index of UNOFFICIAL Circumvesuviana Home Page Linux pages main index In the beginning of 1994 I created an RS232 driver for use in MS/DOS (mainly for BBS software), highly optimized, featuring a very small footprint (because DOS people knew that "640k had to be sufficient for everyone"), and "FOSSIL chart 5" compliant.

It was published as "freeware" with no source included.

I think that now the source can be released as well.

You are free to use it (or part of it) in your projects, on the condition that you mention my name in the "credits" pages of your work.

It was my last MS/DOS software: soon after releasing it, I entered the Linux world.

Assembler source is here, documentation is below.

          = = = = ==   ====                   .  ==
        = = = = =  =  =     ===   ====  ====  =   =
      = = =  ====  =  ==== =   = ====  ====   =   =
    = = = =     = === =     ===   ====  ==== === ===

                   by AlfonSoftware Unlimited
              version 1.00 - released on 12-Feb-94

!--  Important information

This document is quite little and contains only the *really
needed* user information, so you should (hm!;-) read it entirely
(except for the "technical" sections if you aren't planning any
fossil-based software). If you really read this textfile, you
probably will never need *any* extra technical support or help.
I didn't write all this boring stuff just to get an archive file
a little bigger, do you agree? ;-)

Summary of chapters...              ...and who should read them:
* what is AlFossil;                                 ...all users
* AlFossil features... or limits?                            all
* installation;                                              all
* configuration: command-line parameters;                    all
* run-time command-line parameters;                          all
* suggested configurations;              first-time fossil users
* meaning of "status" informations;                          all
* errorlevels returned;                  batchfiles-maniac users
* hardware compatibility;                      experienced users
* software compatibility and "fossil level 5"        programmers
* AlFossil history and philosophy;                    some users
* where you can get support & help;                   spare time
* licensing, freeware and registration info;                ALL!
* a little note for Japanese users;              Japanese users.

I assume you have decent knowledge of DOS, serial ports, modems,
etc. Since this isn't the only software including an user manual,
*please* RTFM (Read Those Fantastic Manuals): you'll know more
than needed and surely you'll solve a lot of problems.


!-- What is AlFossil?

AlFossil is a FOSSIL-driver. That is, a "Fido / Opus / Seadog
Standard Interface Layer" (*), a communications driver extending
standard PC BIOS services. "Driver" means that as a stand-alone
program AlFossil simply does nothing, but it is normally needed
by a lot of BBS application software.

AlFossil can work with 8250 and compatible serial I/O devices.
These include 16450, 16550, 82c450, 82510, etc, and *true*
compatibles (normally, a PC-compatible, it is likely that
contains one of these devices). Warning: some features (like
FIFOing, for example) are not available on all devices; see also
"compatibility" chapter.

AlFossil is intended for use mainly under BBS, point and other
communications software, almost surely involving a modem. It has
been designed to get the littlest possible overhead (memory and
cpu) at run-time, so it's a little rude and crude, but - I hope
- 100% functional.

Even if I tested it for all its functions, I can guarantee only
that it will consume a little of your precious disk space, so...
"use it at your own risk".


!-- AlFossil features... or limits?

AlFossil needs at least a 80186/80286 processor. It doesn't use
(and can't run in) protected mode. If you need a fossil driver
for your 8088/8086-based computer, or for a 32-bit with virtual
memory and multiple instruction multiple data massive parallel
processing computer, please consider another fossil driver.

AlFossil supports only *one* serial port. I think that at least
99% of you don't need more than one port. Who really needs more
than one serial port? Sysops with two or three lines of their
board on a single computer? How many are they, compared to
single-line boards and point-systems? ;-)

This driver ignores speeds below 1200 baud. Hey guys, we're in
1994, not 1984. We now need something like 57600 and 115200 baud
speeds. In addition to standard fossil speed replacements for
obsolete 50 to 150 baud, the code for 300 baud has been replaced
by 57600 baud speed, and the code for 600 baud has been replaced
by 115200. If you need 300 or 600 baud, please consider another
fossil driver, something of 1989 or before :-). (Perhaps a lot
of you won't even notice this... a 115200-locked modem can
still handle 300 baud connects, needing no extra fossil or
local hardware/software configuration).

AlFossil supports only "8/N/1" parameters. In over seven years
of BBS'ing I've never used different settings. And I don't want
to get AlFossil just 20 bytes bigger to tell you that it
supports an useless "7/E/1" or another weird configuration.
AlFossil doesn't support Xon/Xoff software handshaking. It would
need more than just 20 bytes, and I still don't know at least
*one* software or hardware (BBS & modems) needing that.
AlFossil doesn't support "watchdog" and other strange functions,
perhaps almost never used. If you *really* need them, ask them
to me and I'll put them in the next release. At least I will
know someone using them ;-).

For more detailed information about "missing" standard level 5
features, read the "compatibility with standard fossil drivers"


!-- Installation

AlFossil doesn't require any install directory, configuration
files, paths, configuration programs and other strange things
like that. All informations needed to work will be specified in
the command-line. Now just place anywhere in your disk the
ALFOSSIL.COM file and you get it "installed".

AlFossil is a TSR (terminate and stay resident) driver. You have
to load it only once, before any applications' use. Normally it
is sufficient to load it from your AUTOEXEC.BAT file.

Once in memory, AlFossil doesn't play any "strange trick": if
you like, you may load it in "high" memory (using LH, LOADHIGH,
etc), but *warning*: at speeds above 2400 baud you may loose
characters during serial I/O. Feel free to try... at your own
risk. Surely you can load it high if you have a 386/40 and a
2400 baud modem, but you should expect any kind of problems if
you have a 286/12 and use 115200 baud speed... Anyways, if you
encounter problems, retry loading it in "low memory" (that is,
in the "conventional 640k" block; AlFossil is decently little
and will not steal too much of your precious "low RAM").
When you don't need it more, AlFossil can be "unloaded" to free
the little memory block it used.

AlFossil replaces PC BIOS INT 14h. Any call made to INT 14h will
be ignored if it doesn't involve the fossil port specified at
installation. Fortunately almost no software uses standard INT
14h functions to get decent communications services, so this
shouldn't be considered a "bug".

If you execute AlFossil without parameters, it will display a
summary of the command-line parameters. If AlFossil is already
installed in memory, it will display the current status (see
"status" chapter).


!-- Configuration: command-line parameters

When you load AlFossil in memory, you have to specify all
hardware and software parameters (serial device information and
software information):

name  meaning                accepted values
  p   port number            1 to 4 for com1...com4
  a   port address           1 to 6 for 3f8h/2f8h/... see below
  i   irq number             2 to 5 for irq2...irq5
  s   speed (baud rate)      1 to 5, 9 and 0, see below
  f   general flags          0 to 7, bit-encoded, see below
  t   transmit buffer size   1 to 7, see below
  r   receive buffer size    1 to 7, see below

example:  alfossil p=1 a=3 i=4 s=3 f=1 t=1 r=3

You must supply *all* these parameters (no one is optional, no
default is provided), in upper or lower case. You must also
respect the above order, that is, P is the first and R is the
last parameter.

A quick parenthesis about port numbers...

Fossil ports are numbered from 0 to 7. This isn't my choice,
this is the standard. Port "0" is the first port, port "1" is
the second, etc. Applications generally refer to them by using
numbers from 1 to 8 instead of 0 to 7, or, worse, from "com1"
to "com8". That is, port "1" (or "com1") of the application
software means port "0" of the fossil driver. You can configure
a fossil port with any possible address and irq information. If
you configure the AlFossil port "0" with address 03e8h (address
of the standard "com3"), you'll get a fossil port "0", that is
port "1" (or "com1") in application software, that is port "3"
(or true "hardware com3") of the computer. There's nothing of
strange in this, just keep in mind. If AlFossil seems not to
be "active" and address and irq are correctly specified, you
probably have incorrect port number settings in the application

Command-line parameters in detail:

* the P parameter specifies the port number. AlFossil will use
  buffering and the other "extended" services only when the DOS
  or the application software specifies that port.
  The P parameter needs a port number from 1 to 4, like the
  one needed in the application software. Other ports aren't
  supported. If you specify 1, AlFossil will react when the
  applications request services for "fossil port 0" (generally
  standing for "application port 1"). This should avoid
  confusion... I hope!

* the A parameters specifies the base I/O address of the port.
  The values are 1 for base at 3f8h (standard hardware "com1"),
  2 for 2f8h (standard "com2"), 3 for 3e8h (standard "com3"),
  4 for 2e8h (standard "com4"), 5 for 3220h (standard "com3"
  on IBM PS/2(*)), 6 for 3228h (standard "com4" on PS/2).
  If you are in doubt, try the same value of the P parameter.

* the I parameter specifies the irq (interrupt request) line
  that will be used to get and send bytes thru the serial port;
  "com1" at 3f8h and "com3" at 3e8h almost always require irq4;
  "com2" at 2f8h and "com4" at 2e8h almost always require irq3;
  on PS/2 models, "com3" at 3220h and "com4" at 3228h also
  require irq3. All other combinations are intended for some
  non-standard serial devices.

* the S parameter specifies the initial speed of the port. The
  valid values are: 2 for 2400 baud, 4 for 4800, 9 for 9600,
  1 for 19200, 3 for 38400, 5 for 57600 and 0 for 115200 baud.
  Note that AlFossil supports also 1200 baud speed but at the
  start-up can't be initialized at that speed.

* the F parameter specifies some general flags about the port:
  value   locking          irq sharing       16550 FIFOing
    0     port unlocked    irq not shared    disabled
    1     port locked      irq not shared    disabled
    2     port unlocked    irq shared        disabled
    3     port locked      irq shared        disabled
    4     port unlocked    irq not shared    enabled
    5     port locked      irq not shared    enabled
    6     port unlocked    irq shared        enabled
    7     port locked      irq shared        enabled

  If port is locked, every future request of "change baudrate"
  from the applications software will be ignored, and CTS/RTS
  hardware handshaking is used (and can't be disabled). This
  is used mainly with high-speed modems and modems supporting
  compression/correction protocols like mnp5 and v42bis. If
  port isn't locked, the "change baudrate" and "change flow
  control" commands will work normally. If you "lock" AlFossil,
  don't forget to "lock" also the application software that
  uses AlFossil.

  If you have two serial devices using the same irq line (for
  example com1 and com3 on irq4), one of these used by AlFossil,
  almost surely you'll need to use one of the "irq sharing"
  options. The serial I/O routine connected to the irq line
  will leave the control to the other device driver as soon as
  it finishes "working". For example if you have a mouse on com1
  and a modem on com3 and use AlFossil for com3, to let the
  mouse driver "live", you must use irq sharing.
  Warning: since irq sharing slows a bit serial I/O, I
  recommend its use only when you really need it.

  On 16550-type chip (and *true* compatibles), you can enable
  the FIFO feature. This saves interrupts and general overhead,
  letting an external interrupt to process up to 16 characters
  at a time. See "hardware compatibility" chapter for more

* the T parameter specifies the transmit buffer size (from now
  on, tx-buffer), from 256 to 2048 bytes: 1 for 256 bytes, 2
  for 512, 3 for 768, 4 for 1024, 5 for 1536, 6 for 2048 and 7
  for 3072 bytes. You should keep this value not too high: this
  will increase a bit the general system overhead but will make
  faster error recovery in a lot of software transfer protocols,
  like Zmodem(*), for example.

* the R parameter specifies the transmit buffer size (from now
  on, rx-buffer), from 512 to 16384 bytes: 1 for 512 bytes, 2
  for 1024, 3 for 2048, 4 for 3072, 5 for 4096, 6 for 8192 and 7
  for 16384 bytes. Keep this value a little high: noone can
  trust a 16800 baud modem using only a 1024 bytes buffer (for
  example, the receive buffer would fill in only 0.6 seconds of
  1700 character-per-second throughput). Perhaps normally only
  slow systems (using old hard disks, etc) should need buffers
  of more than 4096 bytes.
  Generally the value of the R parameter should never be less
  than the value of the T parameter.

The above example:  alfossil p=1 a=3 i=4 s=3 f=1 t=1 r=3

means:  p=1  setup fossil port 0 (application port "1"/"com1");
        a=3  base address is 03e8h (standard hardware "com3");
        i=4  irq line used is irq4 (my "com3" uses irq4);
        s=3  initial speed is 38400 baud;
        f=1  port is locked; application can't change baudrate;
        t=1  transmit buffer size is 256 bytes;
        r=3  receive buffer size is 2048 bytes.


!-- Run-time command-line parameters

When AlFossil is resident in memory, you can call it again for:

alfossil s      display current AlFossil status (see "meaning of
                status informations" chapter); this is the
                default when AlFossil is already in memory;

alfossil z      as above, display current AlFossil status, but
                soon after zeroes all statistic counters; this
                is useful to keep "daily/weekly statistics"
                using a command like:
                        alfossil z >laststat.txt
                see also "meaning of status informations"

alfossil h      display a short help text about command-line
                parameters; this is the default when AlFossil
                is not in memory; see the "configuration and
                command-line parameters" chapter;

alfossil e      display a short help text about AlFossil
                run-time commands;

alfossil o      display a short licensing information text and
                display code/data sizes in bytes;

alfossil u      unload the resident AlFossil from memory; this
                is possible only when AlFossil main interrupt
                (int 14h) wasn't hooked by other software (in
                this case, unload the other software first) and
                AlFossil port isn't active (use "alfossil d"
                before); unloading just frees the little block
                of RAM used by AlFossil and tells you how much
                time it ran;

alfossil i      initialize AlFossil communications; this is
                needed by some software that directly "use" the
                fossil routines without initializing the driver
                (e.g. those requiring fossil "hot" at start-up);
                this call is equivalent to the software call
                "initfd (04h or 1ch)" to the fossil driver by
                the application software;
                after this call, serial I/O is possible; any
                incoming characters will be stored in the
                receive buffer, etc;

alfossil d      deinitialize AlFossil communications; this is
                the complement for the preceding initialization
                this call is equivalent to the software call
                "deinit (05h or 1dh)" to the fossil driver by
                the application software;
                after this call, serial I/O is not possible,
                until next initialization (by "alfossil i" or
                via software call);
                note that when not initialized, AlFossil isn't
                reliable for sending/receiving characters.

alfossil c...   change dtr state; this command lets you to
                raise/lower dtr: if you use c0 the dtr signal
                will be lowered ("off" state), if you use c1
                the dtr will be raised ("on" state). This is
                generally useful only with some particular
                modems that assign to dtr special functions
                (some modems go on-hook/off-hook depending
                from dtr state);

alfossil r      show contents of rx-buffer and empty it;
alfossil w...   send out a string; these two commands let you
                to send strings to the modem and get answer;

                c:\> alfossil wAT&C1&D2
                c:\> alfossil r
                c:\> ...

                the 'w' command needs obviously AlFossil already
                initialized (via software or via an "alfossil i"


!-- Suggested configurations

Here are some suggested configurations for a lot of popular BBS
and point configurations (port1/com1/irq4/addr=3f8h assumed):

* 2400 baud modem, without error correction:
    alfossil p=1 a=1 i=4 s=2 f=0 t=1 r=2

* 2400 baud modem with MNP5 error correction:
    alfossil p=1 a=1 i=4 s=4 f=1 t=1 r=2
  ...and add the parameters "locking=yes, speed=4800 baud" in
  the configuration of your BBS/point software;

* 2400 baud modem with V42BIS error correction:
    alfossil p=1 a=1 i=4 s=9 f=1 t=1 r=3
  ...and add the parameters "locking=yes, speed=9600 baud" in
  the configuration of your BBS/point software;

* 9600 baud modem with MNP5/V42BIS
    alfossil p=1 a=1 i=4 s=1 f=1 t=1 r=4
  ...and add the parameters "locking=yes, speed=19200 baud" in
  the configuration of your BBS/point software;

* 14400/16800/19200 baud modem with MNP5/V42BIS
    alfossil p=1 a=1 i=4 s=3 f=1 t=1 r=5
  ...and add the parameters "locking=yes, speed=38400 baud" in
  the configuration of your BBS/point software;

* some 19200 baud modems and 21600 (and even more) baud modems:
    alfossil p=1 a=1 i=4 s=5 f=1 t=2 r=6
  ...and add the parameters "locking=yes, speed=57600 baud" in
  the configuration of your BBS/point software; if your software
  doesn't support that speed, use "locking=yes, speed=300 baud":
  AlFossil will treat the "300 baud" requested speed as 57600
  baud speed; warning: this may cause some timeout calculation
  problems (surely not related to normal AlFossil's serial I/O).


!-- Meaning of "status" informations

When AlFossil is already resident in memory and you call it
without parameters, or with "alfossil s", it will display some

* general informations:
- date/time (when you loaded it in memory; if you loaded it
  from AUTOEXEC.BAT, you get a decent information "since when
  my system is up");
- total memory used (in bytes) and start/end addresses (in hex);
  if "loaded high", the start address is "after" 9fff:0000;
- "re-hooking" of interrupt 14h: if another software hooked the
  fossil control interrupt, a little extra slowdown may occur
  on slow machines like old 286's; warning: some software, like
  DESQview(*), *must* hook interrupt 14h in order to run
  normally; another software hooking control interrupt means
  also that you cannot unload it using "alfossil u" command;
- transmit and receive buffer sizes as set at loading time;
- address, irq, speed, locking, sharing informations as of
  loading/installing time; warning: port speed may be changed
  if port wasn't locked;

* activity information:
- bytes "really" sent: the number of bytes really sent "out";
- bytes "really" received: the number of bytes really got
  from "out";
  these two informations don't depend from the "purge"/"flush"
  operations and "buffer full" events; they tell you exactly
  how many bytes the 82xx/16xxx chip said to have "received"
  and "sent";
- total interrupts received: the number of times the serial
  device had activity (receiving a character, completion of a
  character transmit, modem status change). This may be less
  than the sum of the preceding two counters because AlFossil
  always tries to optimize interrupt requests (trying to send
  another character at every "receive" call, for example).
  Warning: these counters are 32-bit unsigned integers so after
  about 4 gigabytes of "counted" characters/interrupts, they
  will be reset to 0 :-).

* critic events:
- rx-buffer full: how many times AlFossil lost a character
  because the receive buffer was full and the application
  software didn't ask to read or purge. If this value is quite
  high, probably your rx-buffer is too little. This counter
  stops at 65535 and is never reset; massive serial input may
  easily take this value quickly high;
- initializations/deinizializations: how many times AlFossil
  was initialized and deinitialized. These values count in
  general the start/end of the "activity" of the applications
  software; if the two numbers are not approximately the same,
  then probably some of your software has bugs in initialization
  and/or deinitialization section; these counters stop at 65535
  and are never reset.

The activity information and critic events counters can be
reset to 0 using the "alfossil z" command.


!-- Errorlevels returned

Even if you just want to know if AlFossil was loaded or not,
AlFossil returns some more information via DOS errorlevels, that
you can check in your .BAT files:

0  no errors: AlFossil was correctly loaded and installed in
   memory as a TSR;
1  no errors; AlFossil displayed only the help-screen and wasn't
   loaded and installed in memory as a TSR (only if you called
   it without command-line parameters if it wasn't installed,
   or using commands "h");
2  AlFossil was already resident in memory and a status screen
   was displayed (only if you called it without parameters and
   it wasn't installed), or "alfossil e" or "alfossil z" or
   "alfossil s" or "alfossil o" was executed;
3  execution stopped for incorrect DOS version (DOS 1.x? :-)
   or incorrect CPU type (8088/8086? :-)
4  command-line request failed (read/write requests)
5  any command-line parameter error
6  impossible unload AlFossil from memory, or AlFossil wasn't
   resident in memory, or was active       (only unload request)
7  AlFossil was unloaded from memory       (only unload request)
8  command-line request correctly executed (init/deinit, dtr
   change, read/write)


!-- Hardware compatibility

AlFossil can't recognize exactly the type of serial device
present in your system, so it trusts all informations got on
command-line. For example, if the FIFO feature is available
but was not requested, it won't be activated.

If you use an 8250 chip, the maximum "guaranteed" baud rate
should be 19200. Using higher baud rates (38400 and above) may
create problems like "characters lost". You surely experienced
at least once, a little error (one character lost?) in an
8k-Zmodem block, needing up to 10 seconds at 9600 to resync the
block transfer. 82xx family should support speeds up to 57600
baud, but I heard of people having problems even at 19200.
Since three years I use an 82c450 locked at 38400 without any
problem, but I cannot guarantee this for all of you. Beware,
it's a *hardware* problem that we are simply trying to fix at
*software* level, keeping not too high the locking speed.
16550A-type chips *really* support speeds up to 115200 baud,
and are pin-to-pin compatible with 8250's, so if you encounter
serious problems, consider substitution of the old 8250-type

AlFossil may use the FIFO feature of NS16550A-type devices. This
boosts system performance saving a great number of interrupts;
perhaps you may not immediately notice it. As of this version,
the FIFO features weren't fully tested, so I can't guarantee
them as 100%-reliable. As soon as I'll get decent documentation,
I will complete FIFO support in AlFossil.

Locking a modem at the extreme highest baud rate isn't always
the best choice. Sometimes you can get good results just
lowering the locking speed; this may be needed also on "slow"
systems: generally fossil drivers use some cpu-time to get
incoming characters, and a lot of other cpu-time is spent by
application software to read and process them. In some cases,
having a "good" serial device isn't enough to process speeds
above 19200.


!-- Software compatibility and "fossil level 5" standard

AlFossil was developed to "almost fully" respect the fossil
standard "level 5" (fossil chart 5, 11-Feb-88, Rick Moore).
I already explained in this text why I did so; the following is
just a detailed summary of what there *isn't* in AlFossil for
which one couldn't consider this as a "true level 5" fossil

function       differences between AlFossil and "true" level 5
07h / timers   system timer params: doesn't any calculation;
               returns directly AH=12h, AL=08h, DX=0037h, which
               are correct for 99.99% of PC and compatibles :-)
0fh / flowct   flow control: the xon/xoff handshaking protocols
               of the fossil chart level 5 aren't supported:
               only rts/cts hardware handshaking is implemented,
               the other bits in AL are ignored;
10h / ctrlck   not supported; fossil chart level 5 needs:
               ctrl-c/ctrl-k checking (actually not implemented)
               start/stop transmitter (actually not implemented)
               this function always returns 0 (ctrl-c/ctrl-k
               "never detected", transmitter start/stop feature
14h / watchd   watchdog: not supported; will be supported in
               future versions only if someone requests it to
               me; perhaps it seems too "rude and crude" and
               quite useless;
16h / ttickc   timer tick chain: not supported; will always
               return 0FFFFh, meaning "operation unsuccessful";
               will be supported in future versions if someone
               requests it to me;
7eh / appg7e   not supported; will always return 0FFFFh, meaning
               "install appendage: unsuccessful";
7fh / appg7f   not supported; will always return 0FFFFh, meaning
               "remove appendage: unsuccessful".

The following list is a summary of what isn't implemented
because wasn't strictly required by fossil chart level 5
(because all these features were listed as "optional"):

function       differences between AlFossil and "true" level 5
00h / stbaud   parity and stopbits information are ignored and
               are always substituted with "8/n/1";
03h / st_req   only the bits documented in level 5 specs are
               defined and readable; the others are used
04h / initfd   ^C flag-byte subfunction (BX=4f50h) is ignored;
0dh / peekhd   this functions works correctly *only* if no
               special "extended keyboard buffer" utilities
               are loaded, because it uses 0000:041ah/041ch
               pointers; returns 16-bit "INT 16h style" codes;
0eh / readkb   uses INT 16h;
11h / cursor   issues INT 10h, subfunction 02h, without any
               "sanity check";
12h / rdcurs   issues INT 10h, subfunction 03h;
13h / writea   issues INT 21h (DOS), subfunction 02h (write
               character (thus not using INT 29h, DOS "fast
               console I/O"); it uses Ansi driver if there is
               one; it isn't re-entrant;
15h / writec   issues INT 10h, subfunction 0eh.

Note that all "chart 5" functions checking for DX=00ffh are also
ignored (because AlFossil doesn't do any "CRT init/deinit").
All other functions and sub-functions are exactly as documented
in the fossil chart 5 named above. The functions 04h and 05h
(initfd and deinit) are duplicated in the functions 1ch and 1dh,
as suggested by Raymond Gwinn. At initialization time, AlFossil
will return "fossil level = 5, max function = 1dh" information
to the application software.


!-- AlFossil history and philosophy

"If it doesn't seem quite reliable, do it yourself". Lots of
beta-releases, total (or almost total) lack of user support,
lots of RAM robbed (huh? 10 kbytes? :-), lots of documentation
files, lots of external utilities (almost all useless stuff),
lots of... bleaaaah!

AlFossil has been written from the scratch; the only thing I
used was an indecent page of documentation about "the 8250 and
its interrupts" :-). Fortunately this is not my first serial
port driver; four years ago I wrote a [custom and commercial]
RSMODULE for AISEuropa thermal-transfer serial printers (on
which AlFossil will refuse to install ;-). So you can sleep
without nightmares ;-).

AlFossil is 100% assembler programming. Yes, 1994 and there is
still people using assembler. It's not my fault. We are in 1994
and PCs still have only "unbuffered" BIOS functions for serial
ports. But this is also my philosophy. You simply can't imagine
how one can re-manage code to save even a dozen of bytes. And
even one byte. Someone would have used 200/300 bytes more than
me to write the same procedures. Do you think it's too much? ;-)

Some people will hate me for this "rude developing". Yep, this
is an "incomplete" software, with 500 bytes more it would be a
"true level 5" driver, but why do you need always 100%-featured
software? This surely doesn't mean "always use the littlest code
and data". If I returned "OK" and "ERR" instead of decently
self-explaining messages and errorlevels, would you still use
it? ;-). So here's the final point: let's save some bytes... by
just ignoring some stone age functions. Hard disks and RAM (now
"always insufficient") will be again "a bit more than needed".

Since one can't always optimize for "littlest and fastest", I
did my best to have the littlest code at a decently fast speed
(saving code, saving data, saving interrupts, saving overhead),
especially for the runtime module (the code remaining in memory
after calling it from AUTOEXEC.BAT). AlFossil can be still
optimized, and I'll do it as soon as I'll understand how to do
and how it really "improves".

AlFossil won't be a "yet added another feature, let's increment
the version number" software. This may be even the final release
(if noone reports bugs or gives me some good 16550 docs ;-).
Yep, a "two-kilobyte" fossil driver (including buffers! ;-),
"almost level 5", how can you still ask more from your life? :-)

Have fun!


!-- Licensing, freeware and registration information.

Yes, this is "freeware". You can use it without paying for it.
You can freely distribute it and make it available to other

...BUT *remember*: this stuff IS NOT PUBLIC DOMAIN.

"Freeware" *doesn't* and *will never* mean "public domain", so
read carefully:

1-  you can't modify in *any* manner the files contained in the
    original distribution archive file (ALFOS100.ARJ); this
    includes *also* adding those useless BBS/comment/ads files;

2-  you can't use it as part of any *commercial* software (like
    an rs232 driver for your own applications), or part of any
    **commercially-sold "any-ware"** (like CD-ROMs containing
    software), without written express permission of the
    author - see below how to contact me for agreements;

3-  you can't *charge* for distribution, except for diskettes
    or media costs; you can't use it for any "money-oriented
    purposes" (like giving it in a [hm!] "pay for download"
    file-area of your BBS);

I didn't create this software to help any jerk earning money.
I myself don't ask money for it, why should someone other do?!!

Other important notes:

4-  you can't distribute modified or incomplete copies;
    disassembly and reverse-engineering is also prohibited;
    you can't distribute this software after compressing it
    with PkLite(*), LzExe(*), etc;

5-  this isn't "DemoWare", neither "ExpireWare", nor
    "CrippleWare": the version in the ARJ(*) archive is the
    complete final version;

6-  the ONLY thing that I can guarantee about using AlFossil
    is that it will need a little of your precious hard disk

7-  source code isn't (and won't be) publicly available.

Anyway, if your conscience makes your life impossible, and you
want to "thank" me for this software (for spending some nights
awake and for write other "freeware" like this), you can send me
a postcard of your city, at this address:

     Alfonso Martone
     via xxxxxxx...

Instead, if you do not know where to find a postcard now, and/or
if you are anime/manga fans, you can call my board and get the
latest version of this software and other news that I wrote
while you are reading this, in free-download even for new-users:

  board name:          <FantOZZY> - la "barracca"
  phone number:        +39-81-87015xx   (Italy)
  parameters:          zyxel19200/v32bis/v42bis/mnp5/fax/vmbx
  PNet address:
  users/voicemailbox:  from 7:00 to 23:00 GMT

Here you can also report bugs, send suggestions, ask for help,

(*)  IMPORTANT. All copyrighted/trademarks names mentioned in
     this textfile appear for identification purposes only.


* Finally (^_^;) a little note for Japanese users (JIS/SJIS
  viewer required):
(Japanese greetings follows)

Click here for index page.

send e-mail - continua (next page)