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


SCC.PRG, ESCC.PRG, ST_ESCC.PRG
------------------------------
These are drivers for use with SCC or ESCC serial interfaces (e.g. IC's 
Z8530, Am85C30 and Z85230) and also for the additional hardware serial 
interface ST_ESCC. They work together with DRVIN.PRG or a similar 
replacement. 1_README.TXT contains an introduction.


General
-------
I only call the Z85230 and the Am85C230A an "ESCC". These IC's have an 8 
byte receive FIFO and a transmit FIFO no smaller than 4 bytes. An ESCC 
contains all functions of the SCC.

The possible configurations of the individual *SCC*.PRG's differ slightly.


Clock rate and baud rate
------------------------
A SCC can use different clock sources for the generation of baud rates, 
the system clock PCLK being the most common. The PCLK is 8MHz (=8000000Hz) 
in a normal (as supplied by Atari) MegaSTE, TT and Falcon. This is a good 
number, but unsuitable for the generation of the high standard baud rates 
required. The high baud rates in MegaSTE, TT & Falcon's are generated from 
other time sources. My hardware extension ST_ESCC is clocked at 
14745600Hz.

It is possible to modify the MegaSTE, TT or Falcon with a quartz 
oscillator and a bit of wire to make PCLK =14745600Hz (suggestion from 
Franz Sirl). If you only wish to add 57600, 115200 and 230400 Bd to 
MODEM2, a simpler modification is possible using a single wire. More 
detail can be found in the section "MODEM2 of the TT using 57600, 115200 
and 230400 Bauds" of this document.

The drivers detect automatically whether there is a PCLK clock frequency 
of 8MHz or 14745600Hz and display the rate in their installation messages.

With a PCLK of 8MHZ the following Rsconf-Baud rates are possible:

 (new - old)

SERIAL2:
230400 - 200
115200 - 150
 57600 - 134
 38400 - 110

MODEM2:
 38400 - 110
153600 -  75
 76800 -  50

Additional speeds on MODEM2 when using a MegaSTE or Falcon (TT after 
modification):

230400 - 200
115200 - 150
 57600 - 134

With a PCLK of 14745600Hz the following are possible on MODEM2 and 
SERIAL2:

 (new - old)

230400 - 200
115200 - 150
 57600 - 134
 38400 - 110
153600 -  75
 76800 -  50

If you use the GEMDOS-Fcntl TIOC?BAUD, there is no problem because the 
possible baud rates are displayed in plain text as "bit per second".

ST_ESCC always contains an ESCC. MegaSTE,TT & Falcon's only contain a ESCC 
if someone has changed the original IC. The  driver for the SCC will run 
with an ESCC as well, but the reverse is not possible.


SCC and ESCC
------------
A repeated reminder: I only call the Z85230 and the Am85C230A an "ESCC". 
ST_ESCC always contains an ESCC. Normally in the MegaSTE, TT & Falcon 
there is a SCC. To reduce CPU loading and improve data security (low 
probability of character loss when receiving) it is possible to put in an 
ESCC in the PLCC-case. SCC and ESCC are pin compatible.


SCC.PRG
-------
This is the driver for MODEM2 and SERIAL2/LAN of the MegaSTE and TT as 
well as for the only RS232 interface that Atari brought out on the Falcon 
(labelled as MODEM); because of its similarity it's also called MODEM2 in 
this text.

On the TT (and Falcon, when fitted with an accelerator with FastRAM) 
SCC.PRG should under NO circumstances be loaded into the FastRAM, 
otherwise you will get problems (bombs, loss of characters, spurious 
behaviour) because of the fast access to the SCC. These drivers must be 
loaded into physical RAM, they must NOT be loaded into virtual RAM.


ESCC.PRG
--------
See SCC.PRG. This driver is only for the user who has fitted either a 
Z85230 or a Am85C230A. The SCC drivers work with the ESCC but don't make 
use of its advantages. The ESCC driver is unsuitable for the SCC!


ST_ESCC.PRG
-----------
This driver is a dedicated one for my hardware ST_ESCC which provides two 
additional fast serial interfaces on ST, STE & MegaST's. 115200 Bauds runs 
without any problems on a 8MHz/68000 machine under TOS. That's quite an 
achievement!


Configuration
-------------
Configuration is achieved using the SETTER.TTP program. For operating 
details see SETTER.TXT.

USE4C
This question only appears in the ESCC.PRG and the ST_ESCC.PRG. Should a 
receive interrupt occur only after four characters have been received? I 
call this mode, which only triggers an interrupt after 4 characters have 
been received, "4ZI". 4ZI radically reduces the loading on the cpu in both 
"RTS/CTS" and "No" handshake modes. Using the "XON/XOFF" handshake 
automatically switches the 4ZI mode off because the exception-handling 
overhead would swamp any potential savings. Another side effect is that 
4ZI reduces the length of the receive FIFOs from 8 to 4 characters. This 
means that after an interrupt message from the ESCC to the CPU, the latter 
must react within 4 instead of 8 characters to ensure loss-free reception. 
Normally 4ZI should be switched on by answering the prompt with "yes", 
because 4 characters are sufficient and the gain in CPU time due to the 
reduction of the receive-interrupts by a factor of 4 is considerable. If 
you use dirty programs then in most cases you will have to turn 4ZI off by 
replying "No". These dirty programs manifest themselves by various slow 
downs: In terminal mode you will only see what you've typed after each 4 
characters. Dirty transfer protocols will cause the system to hang 
intermittently or even permanently, forcing a reboot specially at the 
start or end of a transfer.

M2TT
The default setting "u" shouldn't cause any problems, because the TT is 
detected by the _MCH cookie thus making 57600Bd and 115200Bd unavailable 
on MODEM2. A "0" will force 57600/115200 to be made available, This is 
only for TTs that have had the wire modification installed. A "1" does the 
opposite, preventing 57600/115200Bd from being available. When using 
ST_ESCC.PRG this question is not asked. If a PCLK clock of 14745600Hz is 
detected the answer to this question is meaningless.

M1EMU
The default setting "u" shouldn't cause any problems because of the 
automatic computer type detection using the _MCH-cookie. This function was 
added for Falcon owners and users of old programs. The normal user can 
skip the remaining text about this configuration parameter.

If you switch M1EMU on, then don't load a MFP*.PRG for MODEM1 because you 
will get collisions. The MODEM1 connection is unusable when M1EMU is 
active.

M1EMU, the MODEM1 emulator, replaces the BIOS routines of channel 6 
(MODEM1) with the BIOS routines of channel 7 (MODEM2). Also the current 
BIOS device (AUX) is set to 6, placing the BIOS routines not only in the 
MAPTAB but in the xco* vectors too.

"u" activates M1EMU only on the Falcon.
"0" disables M1EMU on ALL computers.
"1" activates M1EMU on ALL computers.
"2" activates M1EMU in special mode. MODEM1 is routed through SERIAL2 or 
    LAN.

On the Falcon
... You can use programs that normally only work to AUX (channel 0) or 
channel 6. As the RING signal (of MODEM2) is anyway connected to the same 
place as that for MODEM1 on an ST, such programs may detect RING directly 
from the hardware (MFP, Bit6). Instead of the DCD signal (carrier detect) 
of MODEM1 (as found on the ST) on Bit 1 of the MFP you will unfortunately 
find the /ACK input from the printer port (pin 10), foolishly without a 
pull-up, so that this signal may swing wildly if there is no printer 
connected or if it is turned off. If the printer is on, /ACK should be 
HIGH most of the time and old programs interpret this as "NO CARRIER".

Remedy: Break the connection from the printer to pin 10 of its plug and 
bridge pin 10 of the printer port to pin 25. This will ensure that old 
programs always get a "CARRIER" signal.

With MegaSTE/TT and ST_ESCC
... one can also run old programs via MODEM2 that access the signals RING 
and DCD directly and go over the BIOS for the other functions. However, 
these programs must not access the receive/transmit register directly. You 
have to connect the RING line and DCD line of MODEM1 with the 
corresponding pins of MODEM2. A fully plugable solution may consist of 3 
SUB-D-connectors. RING is pin9 on a 9pin-SUB-D and pin22 on a 25pin-SUB-D. 
DCD is pin1 on a 9pin-SUB-D and pin8 on a 25pin-SUB-D.

LANBIT
Here, "Yes" permits the switching of the sound-chip port bit PA7 to be 
used to change over the level-converters between SERIAL2 and LAN. But this 
should only be allowed on the MegaSTE and TT, which is why the default is 
"No", so isn't influenced by the sound chip. On the MegaSTE and TT after a 
reset PA7 is normally set to SERIAL2.

LANEXT
"Yes" generates two entries, SERIAL2 and LAN, in the Maptab (BIOS 
channels), in the RSVF Cookie and in GEMDOS. With this setting a MegaSTE 
has 4 Maptab entries instead of the normal 3 and the TT 5 instead of 4. 
But this could confuse some "not so clever" programs. Therefore the 
standard setup is "No", with which there is only one entry, either SERIAL2 
or LAN. Presumably you will always use only one of the two channels 
anyway, so I suppose that "No" is the most likely used setting required.

LAN_S2
Here is where channel A of the ESCC is preset: If it is to be used for LAN 
choose "0", if for SERIAL2 (as will normally be the case) choose "1". If 
LANEXT has been set to produce only a single entry in the Maptab, then the 
choice made here is not only the pre-set that becomes active as soon as 
the driver is loaded, but also the final decision whether a SERIAL2 or LAN 
driver is to be available. "u" is the default setting, in which normally 
SERIAL2 - but LAN on the Falcon - is used as a pre-set.

DTRM2:
The DTR (Data Terminal Ready) signal of the MODEM2 interface is set to the 
value given here once when this driver starts. "Yes" corresponds to ON and 
is equivalent to the behaviour of TOS, "No" corresponds to OFF and 
prevents most modems from going off the hook before a communication 
program has been started. Some programms which know nothing about these 
drivers and are produced according to Atari's developers documentation 
(which is catastrophically wrong), don't work with "No" (hang up during 
data transmission).

DTRS2:
As DTRM2, except for the SERIAL2 interface.

M2DRI:
This question does not appear in the ST_ESCC.PRG. It is only meaningful 
for the MegaSTE, which has no RING input on MODEM2 interface. However it 
does have a very rarely used DSR input available. The setup "yes" makes it 
appear that the DSR input is a RING input, letting requesting programs 
know of the existence and state of an incoming RING to MODEM2. "No" is the 
usual setup - that is, the interface has a DSR, but no RING. In order to 
use "yes" meaningfully, you must connect the RING from the modem to the 
DSR of the computer. Modify the 9 pin SUB D plug of the modem cable that 
will be plugged (for use, not for soldering) into the MODEM2 socket: do 
not solder in the MODEM2 socket: Cut the wire to pin 6 (DSR) and isolate 
the wire end. Disconnect the wire from pin 9 (RING) and solder to pin 6.

S2DRI:
This question does not appear in the ST_ESCC.PRG. The SERIAL2 interface of 
the MegaSTE and TT has no RING input, however it does have a very rarely 
used incoming DSR available. The setup "yes" allows the incoming DSR to 
work like an incoming RING would, letting requesting programs know of the 
existence and state of an incoming RING to SERIAL2. "No" is the usual 
setup - that is, the interface has a DSR, but no RING. In order to use 
"yes" meaningfully, you must connect the RING from the modem to the DSR of 
the computer. Modify the 9 pin SUB D plug of the modem cable that will be 
plugged (for use, not for soldering) into the MODEM2 socket: do not solder 
in the MODEM2 socket: Cut the wire to pin 6 (DSR) and isolate the wire 
end. Disconnect the wire from pin 9 (RING) and solder to pin 6.

RBLM2:
If you don't know what to do with this, simply use 256. Here you set the 
receive buffer length of the MODEM2 interface 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 that control handshaking are generally set to 1/4 (low 
water mark) and 3/4 (high water mark).

TBLM2:

As RBLM2, except this sets the transmit buffer length.

RBLS2:

As RBLM2, except this sets the SERIAL2 interface.

TBLS2:

As RBLM2, except this sets the transmit buffer length for the SERIAL2 
interface.


MODEM2 of the TT using 57600, 115200 and 230400 Bauds
-----------------------------------------------------
(Only for experts)
The track between pin 17 of the TT-MFP (MC68901) and pin 32 of the SCC 
(Z85C30) should be cut (or pin17 of the TT-MFP should be isolated with a 
plastic strip from its socket). Pin 32 of the SCC should then be linked 
with pin 13 of the SCC. To the corresponding question (M2TT) in the 
configuration of the ?SCC.PRG you then have to reply that you are using a 
MegaSTE/Falcon, i.e. with "0"


MegaSTE with MODEM2/SERIAL2 Errors
----------------------------------
With some MegaSTE's, during data transmission over MODEM2 or SERIAL2 and 
simultaneous DMA access of the hard drive or floppy disks, files are 
destroyed. This usually shows up when, after using, say, ZMODEM for 
receiving (or sending) archives (e.g. LZH, ZOO, ZIP) they can't be 
unpacked (error message from the packer). This error is caused by a faulty 
PAL in the control logic of the SCC. Franz Sirl has developed a GAL that 
replaces the PAL and in our experience removes the error. The listing for 
the GAL can be found in mailboxes as archive FSER096B.LZH.

LAN Support
-----------
This has again made a whole amount of work and is still not as complete as 
I had planned. It would be nice, though, if the (potential) users would 
give their opinions from time to time.

The LAN interface and the SERIAL2 interface use the same channel in the 
SCC, channel A. This channel A is just connected to a different 
level-converter in each case. Thus SERIAL2 and LAN can not be operated 
simultaneously. In the MegaSTE and TT, the changeover between the 
level-converters is performed via the soundchip port bit PA7 and the 
output lines of the inactive level-converter are forced to an inactive 
level(??). In the Falcon there is no switchover because only the LAN 
level-converter is present. There is no switchover either with the 
1*RS232+1*LAN level-convertor for the ST_ESCC. The Mega-ST_ESCC version 
provides a possibility to fit a mechanical DIP changeover switch (with 
appropriate components), which can however be replaced by a connection to 
the soundchip as in the TT. In contrast to the TT, however, the 
Mega-ST_ESCC switches the output lines of the inactive interface to not 
active.

This PA7 bit in ST's, (sometimes in the MegaSTE and TT) is connected by a 
wire bridge to the printer port for controlling scanners. The owner of the 
computer should be aware of this and act appropriately.

I am of the opinion that one normally uses only either LAN (a mix of RS422 
and RS423) or SERIAL2 (RS232). The driver is also flexible enough to allow 
alternate use of both interfaces without having to reboot. The change 
takes effect exclusively through the Fopen (GEMDOS-function) at U:\DEV\LAN 
or U:\DEV\SERIAL2 and remains even after Fclose. The BIOS/XBIOS functions 
are not switched over but use the settings made by GEMDOS.

The LAN interface has no RTS connection, so that normally there is no 
possibility of RTS&CTS hardware handshake (Hwhs). On the Mac it is usual 
to have bi-directional Hwhs of DTR&CTS. In place of the RTS connection the 
DTR connection is used. I have implemented this here, Hwhs on the LAN 
interface means DTR&CTS instead of RTS&CTS.

RTS is used internally to switch transmit to high resistance. In 
SERSOFST.TXT a corresponding possibility is foreseen - perhaps I will 
include this sometime in the future (via I/O lines). ##########

At the moment it's always the case that when changing to LAN, no DTR is 
available in the I/O lines, which I will possibly change so that DTR 
unavailabilty will only happen when Hwhs is switched on.############

There is yet another essential difference between the serial interfaces of 
the Macintosh and the (to some extent compatible) Atari LAN: With the 
Atari the RXD+ and RXD- are connected via a 100 Ohm resistor (terminator) 
and the GPI input is linked to GND through 100 Ohms. On the Mac these 
resistors are not present and are only provided through the small boxes at 
the ends of a LocalTalk network. So it would appear from this that you 
should only connect 2 Ataris together, unlike Macs where you can connect 
almost any number by LocalTalk.

Pinouts of the 8 pole Mini DIN socket:

   --***--
 / 8  7  6 \
 |5    4  3|
 \  2   1  /
   ------- 

Pin Name   Description

 1  HSKo   Output Handshake,      DTR-signal from the SCC
 2  HSKi   Input Handshake     or External Clock, CTS-Signal to the SCC
 3  TXD-   Transmit Data -,       Transmit data inverted
 4  GND    Signal Ground
 5  RXD-   Receive Data -,        Receive data inverted
 6  TxD+   Transmit Data +,       Transmit data pos
 7  GPI    General Purpose Input, DCD-Signal to the SCC
 8  RxD+   Receive Data +,        Receive data pos

If you want to connect the LAN(RS422/423)-interface with an RS232, as in a 
null-modem using Hwhs, you should connect:

LAN            RS232

HSKo           CTS
HSKi           RTS
TXD-           RXD
TXD+   open
RXD-           TXD
RXD+   GND
GND            GND

Interestingly enough, all level-converters invert, except for HSHi/CTS. 
Naturally this is taken into account in the driver.


Receive problems with the LAN interface
---------------------------------------
The two 100 Ohm resistors mentioned in the previous section give rise to 
reception problems for some users if the LAN interface is also used as an 
RS232 interface for connecting modems. In part these errors appear only in 
Zmodem transfers, though independent of the set data rate.

As previously stated, if you have the Mac model, these resistors don't 
exist on the Mac, which can be treated as the prototype. The problem can 
be removed by unsoldering both resistors.

One can find the two 100 Ohm resistors by following the RXD+, RXD- and GPi 
tracks on the circuit board from the LAN socket. First one should find a 
22 or 27 Ohm resistor in the track, then a capacitor of about 220 pF to 
ground (GND). A 22 or 27 Ohm resistor in the track follows. Now the RXD+ 
and RXD- tracks are bridged via one of the 100 Ohm resistors to be 
unsoldered. In a similar way GPi is connected via the other 100 Ohm 
resistor to be removed with ground (GND).
        

For the Programmer: The IOREC
-----------------------------
Desist from establishing the readable number of bytes by the IOREC! This 
method will fail if 4ZI is switched on in ESCC and ST_ESCC After all, this 
interrupt mode reduces the system load considerably. Use the function 
Fcntl FIONREAD or Fread, both work correctly in these drivers. Bconstat 
works correctly too.

If the cookie RSVF exists and the RSVF list contains the interface you can 
rely on the correctness of FIONREAD. The MiNT user may sabotage this, but 
then he has only himself to blame.

As long as the Fcntl function is not implemented for modifying the buffer 
length, it is always legal to change the buffer length and the watermarks 
in the IOREC structure. In this instance, and only in this instance, I 
consider it legal and necessary to reset both the read and write pointer 
in the IOREC to zero. After all, one doesn't expect any more data 
transmissions during this switch-over.

It is conceiveable that some time in the future the IOREC will be dropped 
and replaced with a more meaningful data structure. Backward-running 
pointers would, for instance, save some time. However, for compatibility 
reasons a redundant IOREC may remain. Those who want to program really 
cleanly should test the return value of the XBIOS function IOREC, or the 
value of the pointer in the MAPTAB, if they wish to directly access the 
IOREC. If the value is zero or odd then there is no IOREC.


For the Programmer: Supported functions
---------------------------------------
All drivers support the TIOCCTL(MAP/GET/SET) functions as described in 
SERSOFST.TXT. They might not support all signals without callbacks, but 
this can be easily established via TIOCCTLMAP. Which other Fcntls are 
supported by a particular program can also be determined by calling these 
functions.


For the Programmer: Treatment of Receive errors
------------------------------------------------
The ESCC makes error handling really difficult or slow, which would lower 
the data rate, if you use its receive FIFO meaningfully. Therefore the 
receive error checking via TIOCCTLGET has still NOT been implemented. 
Incorrectly received characters, except for receive overrun, in other 
words parity and frame errors, are for the sake of simplicity accepted by 
the receive buffer. The MFP driver on the other hand removes all 
characters with receive errors.


Versions
--------
Unless otherwise stated, the data is valid for all *SCC*.PRG.

1993-11-25	Now also 115200/57600 on MODEM2 with a MegaSTE/Falcon.
               ST_ESCC has nothing meaningful to configure, 
               correspondingly the report is silly.
1993-12-01     TIOCM_RNG to MODEM2 with TT/Falcon/ST_ESCC, TIOCM_RNG to 
               SERIAL2 for ST_ESCC, slight slowing down for Siegfried 
               Hartmanns TT built in.
1993-12-27     Fcntl TIONOTSEND implemented, with ESCC and ST_ESCC the 
               4-character interrupt can be switched off.
1994-01-01     TIOCM_DSR available in TIOCCTL*, Fcntl TIOCFLUSH 
               implemented, DTR-signal user predefinable, buffer sizes 
               user definable.
1994-03-27     Fcntl TIOCFLUSH Nr.1,2,3 now working at last.
1994-04-07     Receive buffer High Water Mark correct initialisation.
1994-06-12     M1EMU (MODEM1 emulation through MODEM2) is possible, all 
               ?TB?? configurations in a table.
1994-06-17     ATTENTION! Installation block adapted for MagiC3. Only use 
               drivers and DRVIN from 1994-06-17 or newer together. Older 
               versions will not run with newer ones.
1994-07-11     New configuration parameter LANBIT.
1994-08-13     LANBIT, LANEXT, LAN_S2 changed, Byte4.Bit0 in the RSVF.
1994-08-20     M2TT provides machine autodetect.
1994-08-27     Configuration parameter PCLK replaced with autodetect.
1994-10-09     DTR with TIOCCTLGET rereadable (RTS too, however still 
               concealed), CTS readable.
1994-10-29     TIOCFLUSH corrected, tinkered around a little, 230400Bd.
1994-12-25     Configuration parameter M2DRI, tinkered with a little, 
               among other things for 68040 with writeback cache setup.
1995-01-04     Fast Bconout parameter passing changed  (and 
               MAPT_APP/MAPT_OVE Function number), ...
1995-01-15     XON/XOFF receive error when receive buffer length != 
               Transmit buffer length, removed.
1995-02-20     No more bus errors if random characters are received at 
               SERIAL2 in a very short period during booting.
1996-01-31     Configuration parameter S2DRI added.
1996-06-08     Configure M1EMU: New parameter value 2, always AUX=#6 
               instead of 7.

Harun Scheutzow
(Harun_Scheutzow@h.maus.de)
