English translation by Mick Lock verified by Peter West 1996,1997
-----------------------------------------------------------------


MFP.PRG, MFP_TT.PRG, MFP_FALC.PRG, MFP_BAST.PRG
***********************************************

These are drivers for the MFP serial interfaces (eg IC MC68901 
manufactured by Motorola). They work together with DRVIN.PRG or a similar 
equivalent. 1_README.TXT contains the introduction.


General
-------
Currently all MFP*.PRGs have the same configurability using SETTER.

The serial part of the MFP, the USART, is not as powerful as SCCs. This is 
why MFP interfaces are more likely to lose characters at high CPU loads.


MFP.PRG
-------
MFP.PRG is intended for use with the so called ST_MFP, that is found at 
address $FFFFFA01 in the ST, STE, MegaST, MegaSTE, TT, Stacy and STBOOK. 
In the Falcon, the MFP is also available, however the USART part is not 
used, so the MFP.PRG is NOT for the Falcon. This driver installs itself as 
BIOS-device 6 with the name "MODEM1".


MFP_TT.PRG
----------
MFP_TT.PRG supports the so called TT_MFP from address $FFFFFA81, which up 
until now only occurs in the TT. The driver uses BIOS-device 8 and 
installs itself with the name "SERIAL1".


MFP_FALC.PRG
------------
MFP_FALC.PRG is intended for the keen DIY Falcon owners who have modified 
it to use the normally unused serial interface of the MFP. This driver 
installs itself as BIOS-device 6 with the name "MODEM1".

Here is a mail message that I have fished out from the Maus-group 
Atari.Hard about bringing out the MFP interface port on a Falcon:

--------------Start of mail (in translation) -----------
Group: Atari.Hard
#A5003@WI2 (Su 26.09.1993, 08:18) MFP serial port in Falcon

From: Martin Liebeck @ WI2
Re: MFP serial port in Falcon
By: Martin Liebeck @ WI2 (Sa, 25.09.93 09.55)

A tip for all who would like to have a second serial port on their Falcon:

The MFP serial interface is supported as port No. 6 by TOS (4.01) and can 
be used as a 3-wire interface. Atari has only saved itself the cost of a 
socket and the drivers...

RXD is present on pin 10 of the MFP and is connected to earth. My layout 
uses a roughly 3mm-long track at the top of the circuit board from pin 10 
to a plated-through hole going to earth. This must be carefully broken 
(not too deep - multilayer pcb!). TXD is available on pin 9 of the MFP.

I have used a 1488/1489 combination to convert to RS232-levels, and used 
pins 1 and 3 of the Midi-in socket as interface to the outer world.

Naturally I cannot assume any guarantees, especially for ruined pcbs! Nor 
do I know how TOS versions higher than 4.01 deal with the MFP. It's 
probably best to measure pin 9 first to see whether a signal is present. 
Have fun with your soldering - it's worth it.

Regards Martin.
----------------End of mail------------

MFP_BAST.PRG
------------
MFP_BAST.PRG is intended for the DIY'er who has fitted a second TT-
compatible MFP into a non-TT computer. The driver installs itself with the 
name "SERIAL1" and the first available BIOS device number.

This DIY-MFP will be seen by the driver as a fully featured RS232 
interface with control lines. The connections are made as ST-MFP 
compatible as possible from the GPIP register of the DIY-MFP. The 
assignment is as follows:

IO1: DCD, input  (as ST-MFP)
IO2: CTS, input  (as ST-MFP)
IO3: RTS, output (at ST-MFP used by PSG)
IO4: DTR, output (at ST-MFP used by PSG)
IO6: RI,  input  (as ST-MFP)


The following describes mainly MFP.PRG:

This is a software accelerator and patch for the serial interface MODEM1 
of the Atari computer. It removes not only the RTS/CTS handshake bugs that 
are still present even in TOS2.06/3.06, but also appreciably increases the 
transmission rate through optimised routines. You should read this 
document completely and only then ask people - or me - about any remaining 
queries. With updates and shortage of time, take a look first at the very 
end, in the section "Versions".

Compatibility with HSMODEM1
---------------------------
If MFP.PRG is the last or only driver loaded, then all programs which run 
with HSMODEM1 should run with this driver, at least as MODEM1.


Assumptions, Requirements, etc
------------------------------

Mag!X
From version 2.00 (upwards) this multitasking operating system (it's 
different to the current MultiTOS, not only as a desktop but it is 
essentially faster) has correct routines for serial interface operation. 
But the corresponding GEMDOS functions are still missing in Mag!X 2.00. 
Mag!X multitasking on 8Mhz STs with 38400Bd reception is interesting: 
(with NVDI version 2.50 onwards). You can work in the foreground with the 
mouse, keyboard and a text editor (tested with Everest), whilst receiving 
error free in the background using GSZRZ 3.5. With Mag!X from version 2.00 
onward the timer interrupt routine modification in MFP.PRG should be 
switched off because Mag!X has already modified the timer routine. If 
MFP.PRG also hooks in here, then operation will be a bit slower.

These drivers are a replacement for other Patches (not only for Modem1) 
e.g. RS232ENC or TURBOCTS.

The interface Modem1 can reach a maximum speed of 19200Bds without the 
need for any additional hardware. Using MFP.PRG can't change this, but it 
does replace the slow and partially faulty routines of TOS making it fast 
and hopefully error free. With additional hardware, such as RSVE 
(developed by me), RS-Speed (by Stephan Skrodzki) you can achieve higher 
data rates. e.g. RSVE allows you to set up 38400, 57600 and 115200Bds. 
MFP.PRG allows you to achieve higher throughput (cps rate) within the 
capability of your hardware. The complete construction details for RSVE 
can be found in mail boxes under the name RSVE.LZH, always on Maus Berlin 
(@B). The latest version of RSVE can be got directly from me. If you 
thought you could operate Modem1 above 19200Bd only using software, you 
can: In Synchronous operation using MFP (switch off the time division 
/16). But here error free operation is only possible in Send NOT Receive.

I work with a 8MHz ST without a CPU accelerator. I don't believe in always 
buying newer and faster computers and then slowing them down almost to a 
standstill with sluggish software. TOS is sluggish software, which is no 
wonder as it is programmed in C, even the interrupt routines (and it looks 
like it). MultiTOS slows the system still further. Mag!X is exactly the 
opposite.


Bugs with other programs
------------------------
With Rufus 1.11rel9 the computer freezes after hang-up with some modems 
(both RXD and TXD light up but nothing works). Remedy: Use Rufus 1.20 or 
later.


How fast will it go?
--------------------
The problem with serial transfer at certain speeds (measured in Bauds) is 
not the sending of characters, but their receipt. The MFP only buffers a 
received character and reports this to the CPU via an interrupt. The CPU 
must pick up this character from the MFP before it completely receives the 
next character for an error-free transfer. When I say that operation with 
... is reliable, it means that at the greatest possible reception rate (no 
break between the stop-bit of the previous character and start-bit of the 
following one) the CPU must receive every character in good time.

An 8MHz ST (with RSVE built in) can accomplish error-free data 
transmission at 38400Bd with TOS and HSMODEM1. With HSMODEM1 from 
21.05.1993 onwards it is also possible to receive at 57600Bd (sending was 
always possible) on 8MHz STs when the interrupt-routine modification 
(FASTINT) is switched on.

At present, rates of more than 3600cps have been reached with an 8MHZ ST 
with NVDI installed and the Blitter turned off using GSZRZ version 3.3 by 
Michl Ziegler with ZMODEM transfer at 38400Bds. Without NVDI it is about 
300cps less, since GSZRZ takes it's time drawing its dialog box. The 
Blitter can in most cases be switched on, however should you get a recieve 
error, switch the Blitter off. More than 5400cps has been achieved with 
GSZRZ 3.5 at 57600Bd using ZMODEM transfer.

The given data rates are valid for direct computer connections. The driver 
is not responsible for slow modems or poor telephone management! Zyxels 
can achieve 3800 at 16800zyx/v42bis and ASCII texts, Zyxel+ with 19200zyx 
can achieve even more. Other 14400/v42bis modems achieve about 3300cps.

The hardware ST_ESCC, developed by me, has no problems at 115200Bds even 
during keyboard input under normal TOS (with Mag!C 220000Bds is 
achievable), as there is an 8 Byte receive FIFO buffer and a 4 Byte 
Transmit buffer. However, this does not accelerate MODEM1, but adds two 
additional high-speed serial ports to ST/STe and MegaST computers instead.


57600Bd on 8MHZ and 16MHZ 68000 CPUs on MODEM1
----------------------------------------------
57600Bd is the magic limit of Modem1 on (Mega)ST(E)s that is achievable by 
easy modifications in TOS. 115200Bd will be achievable in the future, but 
only by polling and not by interrupt operation.

57600Bd fuctions for me on a 8MHZ-ST with TOS2.06. I am not sure if it 
will also work with other (older) TOS-versions.

I am always asked time and again, how to achieve error free 57600Bds: 
Blitter Off, no DMA-access during file transfer (the ZMODEMs file buffer 
must receive the whole file), no Joysticks with autofire or DCF-clocks on 
the Joyport. Then by testing all resident programs and ACCS remove those 
that conflict.


The Configuration
-----------------
Configuration is achieved using SETTER.TTP.  See SETTER.TXT.

RSVE:
This should only be of interest to old programs that recognise the 
existence of the RSVE hardware exclusively by this Cookie. In addition the 
high Baud rates available with RSVE (and RS_Speed) are notified to the 
Fcntl-TIOC?BAUD functions (in place of the 150/134/110 rates).

REPL:
MFP.PRG can reassign Baud rates. This is only useful in conjunction with 
RSVE or RS_Speed, in cases where programs neither know RSVE/RS_Speed nor 
can set 110/134/150Bd. In this way one can assign switching to 38400Bd, 
which is normally done in unsuspecting programs by selecting 110Bd, to the 
19200Bd setting, for instance. As described in the SETTER documentation, 
one first inputs the old Baud rate (that is to be replaced) and next to it 
the high rate that is to be assigned to that position. This has to be 
specified exactly. The first position marked "u" (for unchanged) ends the 
search for rates to be redefined. If one does not want to reassign 
anything one can input "u" everywhere.  With the RSVE hardware, the 
Baud-rates 115200/57600/38400 occupy the positions of 150/134/110 in any 
case, so there is no point in reassigning them there. The reassignments 
are transparent for programs, and do not appear in the Fcntl TIOC?BAUD.

DTR: (only with MFP.PRG)
As this driver starts the DTR (Data Terminal Ready) signal is set once to 
the value specified here. Activation with "Yes"  corresponds to the way 
TOS works, deactivation with "No" prevents an "unrequested" reply from a 
correspondingly configured modem.

RBL:
If you don't know what to do with this, simply use 256. Here you set the 
receive buffer length in Bytes. You may set a maximum of 65534 and a 
minimum of 16, values outside of this range will install a default of 256. 
The length will be rounded to an even number. The water marks are 
generally set to 1/4 (low water mark) and 3/4 (high water mark).

TBL:
As RBL, but this time sets the transmit buffer length.


Speeder-Recognition (RSVE, RSVECHIP amongst others)
---------------------------------------------------
The driver tries to automatically recognize if an interface accelerator is 
installed. The result of its recognition will be displayed during 
installation, currently in the third line directly under the "(C)...". 
However this is not an intensive MFP UART test, so a faulty MFP or faulty 
connections are not neccesarily recognised, or can lead to output of 
messages other than "...defective???".

Here follows the possible displays:

"MFP-UART defective???"
The UART of the MFP behaved strangely when testing it at 1200 bps. The 
actual data rate is apparantly well below 1200 bps. It is possible that a 
Speeder I don't know could produce this output - if so please send me a 
message. It is probably a defective MFP or the connections between the pin 
TDO and TC.

"MFP without additions"
A normal MFP without Speeder-Hardware was found, which behaved normally at 
1200 bps and 110 bps.

"Fixed speedup or Analog PLL"
Presumably the MFP-UART was set from a fixed external clock source to 
38400 bps or more, or a PLL is multiplying the UART clock. In any case the 
actual data rate for the 1200bps test was way above this value.
###At the moment I have no desire in getting nearer to discovering these 
type of Speeders.###

"RSVE or compatible found"
Presumably it has an RSVE or RSSPEED or a compatible Baud rate changer 
installed. The test at 1200 bps ran normally, 110 bps was however strongly 
accelerated.

"RSVECHIP found."
My latest handiwork, that RSVEChip, has been recognised. 1200 bps was 
normal, however 110 bps was changed to a RSVEChip-typical value.

If any accelerator is recognised, then the GEMDOS functions for 38400, 
57600 and 115200 bps are automatically entered. Should somebody have an 
accelerator that is not recognised, but for a program needs these high 
GEMDOS bps rates, you should configure "RSVE" with a "yes" answer! This 
function took some hard thinking to work out, until I found the method 
used here that measures the real speed (bps rate) without outputting 
rubbish at the TXD output of the interface.


Possible problems
-----------------
Long DMA access can result in data loss. Also critical are long delay 
times of the CPU in an Interrupt priority level greater than 5.

On 8MHZ STs without Mag!X >2.00 and without the new NVDI (at least version 
2.50 dated 28.10.1993): at more than 9600Bd, keep your fingers away from 
the mouse and keyboard during GSZRZ receive. Otherwise you'll get 
unspecified errors (with MODEM1). The same as when you get data loss 
through using the keyboard or mouse whilst receiving inside a terminal 
program.

The saving of received data under GSZRZ during reception does not usually 
lead to errors at speeds up to 38400Bd.

It is possible to program the blitter so that it blocks the CPU for too 
long a time. TOS and NVDI apparently don't do this. If you get receive 
errors at >= 38400Bd, first try switching off the blitter.

There are some ACCs and resident (AUTO-folder) programs that alter some 
interrupts and block the system for too long a time. In case of doubt 
single out the rogue programs by testing all resident programs and ACCS 
and removing those that cause conflict.

MiNT and especially MultiTOS are generally system brakes, that are 
especially noticable on 8MHz computers. Mag!X I personally find to be 
better as it is essentially faster.

Only use DCF_TIME by Ralf Zimmermann @WI2 version 1.2 or greater. The 
question about the Ring Indicator doesn't create a problem at 57600Bds, 
however the Joyport gives secondary trouble.

QFAX swallows a great deal of computer time, so in case of problems it 
should be removed (not only switched off).


Function of the...
------------------
See DRVIN.TXT, RSVE_COO.TXT, SERSOFST.TXT.


Versions
--------
The data is valid for all MFP*.PRGs, if not otherwise stated.

1993-11-21     First publication
1993-11-23     Remains resident even with installation errors, though 
               serial interrupt routines and Bco* do not fit together 
               (better than total crash).
1993-12-15     For MFP*.PRG without Hardware handshake connections: 
               TIOCSFLAGS inhibited RTS/CTS due to error message ERANGE. 
               In this case settings will not be set!
1994-01-01     Fcntl TIONOTSEND and TIOCFLUSH implemented, DTR-Signal user 
               defined with MFP.PRG, buffer sizes adjustable by user.
1994-03-27     Fcntl TIOCFLUSH Nr.1,2,3 now work at last.
1994-04-07     Receive buffer High Water Mark correctly initialized.
1994-06-17     ATTENTION! Installation block adapted for the MagiC3 
               standard. Only use drivers and DRVIN together that are from 
               1994-06-17 or newer. Versions before 1994-06-17 will not 
               run with the later versions.
1994-08-18     FASTINT moved into DRVIN.PRG
1994-08-25     Enhancement in bconout for MC68040 (Medusa)
1994-09-27     Transmit register-empty checking sorted (Medusa)
1994-10-03     Some errors in MFP_TT removed (spoke to ST-MFP), TIOCCTLGET 
               altered (CTS inquire, DTR will be supplied with *GET (RTS 
               too, but still concealed, not placed in *MAP)), Byte4Bit0 
               in the RSVF, MFP_BAST carried out.
1994-10-24     TIOCM_BRK and TIOCM_RER (overrun, parity, frame error 
               together) with Fcntl TIOCCTLGET
1995-01-03     Fast Bconout-parameter passing changed (and 
               MAPT_APP/MAPT_OVE function numbers), Cache-Flush for 68040, 
               optimised
1995-02-02     New errors with Ring Indicator query in MFP.PRG and 
               MFP_BAST.PRG removed again.
1995-06-26     Errors removed that caused frame or parity error which 
               locked up receive (until the next Baud rate change)
1996-03-28     For 75 and 50 can now really be adjusted to 75 and 50, 
               nobody needs this TOS error.
1996-04-08     Configure HISP, automatically Speeder recognition, also 
               RSVECHIP

Harun Scheutzow, 21.11.1993 and later
(Harun_Scheutzow@b.Maus.De)
