DModem V1.0 - User manual
                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~

Use as any other xpr-protocol, in any terminal bi-directional xfer will be
available when you FIRST choose what to download and then start uploading
something. Be aware that this first version is written only to use with
highspeed (14400bps) modems with error correction! You must also remember
that this is merely a test proto which I wrote only to check if 68000 can
handle bi-xfer... So there is no error-recovery at all -> dmodem simply stops
when it detects error.

Contact me if you want discuss about xpr or protocol specs. One should 
understand that I'm not aware how to make 'real' protocols and thats why
some things may seem little bit strange. I done this because there is no(?)
bidirectional protos available for Amiga. (And also wanted to add something
special that only DTerm user can have:-)

Some special notes about DreamTerm and DModem:

There should be major speedup if you use dmodem with DTerm -> this is because
internal double-buffering. Ie. dmodem uses double send buffer which is
invisible in any other terminal but because DTerm knows that dmodem uses
double buffers it set itselfs to new mode. It is almost same as old DB-mode
but data is NOT copied -> ie. dmodem knows that DTerm will wait when there
is one send waiting and other is executing. To disable this feature simply
set 'override' off.

Example: 

1. Dmodem sends 4096 byte block (a) / xpr_swrite
  - DTerm starts to send it and returns.
2. Dmodem sends 4096 byte block (b) / xpr_swrite
  - DTerm checks if a-block is sended and if not it will wait as long it
    sended, after that it will start to send b-block
3. Dmodem sends 4096 byte block (c) / xpr_swrite
  - same as 2

                               DModem commands
                              -----------------
biup yes/no  (i) - Uploader waits that receiver starts upload...
		   (Only BBS should use this! Ie. when user want to make
		   bi-xfer she/he first chooses what to dnload and then
		   starts to upload. Same time BBS starts uploading BUT
		   waits 60 seconds before starts actual upload. This means
		   that user has 60 secs to choose which files to send.)
key yes/no   (k) - Keystrokes are sended to bbs.
state yes/no (s) - No xpr_update, protocol will show all information in
		   terminal screen.
buffer <v>   (b) - Blocksize, maximum is currently 8192. If you use key
		   this should be about 128 or less. If this is not done there
		   is BIG delay before you keystrokes are sended to BBS and
		   vice versa.
dpath <path> (d) - download path, in bi-xfer you must suply this -> if not
		   received progs will be saved to upload-dir.

NOTE: Only DreamTerm can handle key/state commands. Well, normally bbs cannot
handle 'key' so you should set it to no, 'state' can be yes if you use DTerm.
If you connect to another DTerm you can set 'key' on and you're able to chat.
(Users must also set duplex to half) Remember that if key is yes state is
automatically no.

When I designed this proto I wanted to add some things and therefore I was
forced to somehow upgrade xpr2.0 specs. So, I added two commands to xpr_io
extension field. This is of course break of rules but... (This rule break can
be avoided using KN,SN initstring.)

#define XPR_EXTENSION 6L

long (*xpr_print)();      /* Print chars to screen    */ extension 5
long (*xpr_keystroke)();  /* Read keys                */ extension 6

; Flags returned by XProtocolSetup()

#define XPRS_NOUPDATE	0x00008000L

When this in setted terminal MUST NOT open xfer status screen. All status 
information is printed to screen by protocol.

#define XPRS_SMARTXFER	0x00010000L

When this is setted terminal should read keystrokes and save them to later
read by protocol. (use xpr_misc for example)

#define XPRS_DOUBLE	0x00020000L

Protocol uses double send buffer. Ie. xpr_swrite can return immediately if
there is only one write executing. When previous xpr_swrite is not done and
xpr_swrite is called again IT MUST WAIT till old is sended!!!

0.0.0    long  *xpr_print();
----------------------------

        This function is in the fifth extension field of the XPR_IO structure.
Only use this function if the value of the xpr_extension field is 5L or larger.
The calling sequence is:

        long status = (*xpr_print)(char, long size)
        D0                         A0    D0

This function prints ANSI chars to screen. It returns 0 on success, non-zero
on failure.

0.0.0    long  *xpr_keystroke();
--------------------------------

        This function is in the sixth extension field of the XPR_IO structure.
Only use this function if the value of the xpr_extension field is 6L or larger.
The calling sequence is:

        struct *key = (*xpr_keystroke)()
        D0

where:

struct key	{	long	count	; how many chars in ansiblock
			char	*ansiblock
		}

ansiblock	-- readed keys

This function returns pointer to key structure which holds the chars readed
(from keyboard) after previous call.


                              GENERAL WARNING!!!
                             --------------------

USE AT YOUR OWN RISK! CURRENTLY REAL CRC IS NOT CODED AND ERROR-DETECTING IS
POOR. IF THERE IS OVERRUN PROBLEMS WITH YOUR HARDDRIVE SET DOWNLOAD PATH TO
RAM:

Notes: You can test dmodem using AT&T1 and then starting upload -> I have
reached 10000cps without problems. Well, almost...:-) For some strange reason
you cannot reach maximum TXD with Amiga -> it can be a DTerm bug/feature or
some strange interrupt delay...