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 owner, 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. specially 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 
increases appreciably 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 thruput (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 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 Mich„l Ziegler with ZMODEM transfer at 38400Bds. Without NVDI 
it is about 300cps less, since GSZRZ takes it's time drawing its 
dialogue 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 mamagement! 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 interupt 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 a 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 a 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 handicraft, 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, try first 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 rougue programs by testing all resident programs 
and ACCS and removing those that cause conflict.


MiNT and especially MultiTOS are generally system brakes,that is 
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 does no 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 
           younger. 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)
