home *** CD-ROM | disk | FTP | other *** search
/ Vectronix 2 / VECTRONIX2.iso / FILES_01 / HSMODA04.LZH / MFP_X.TXT < prev    next >
Text File  |  1994-05-07  |  22KB  |  535 lines
  1. MFP.PRG, MFP_TT.PRG, MFP_FALC.PRG, MFP_BAST.PRG
  2. ***********************************************
  3.  
  4. (Note for the English reading people: The English version is appended on 
  5. the German, look for it!)
  6.  
  7. Dies sind Treiber für die mit MFPs (z.B. Schaltkreis MC68901 von 
  8. Motorola) ausgestatteten seriellen Schnittstellen der Ataris. Sie 
  9. funktionieren zusammen mit DRVIN.PRG oder einem gleichwertigen Ersatz. 
  10. Einführende Bemerkungen finden sich in 1_README.TXT.
  11.  
  12.  
  13. Allgemeines
  14. -----------
  15. Momentan besitzen alle MFP*.PRG die gleichen Einstellmöglichkeiten durch 
  16. SETTER.
  17.  
  18. Der serielle Teil des MFP, die USART, ist nicht ganz so leistungsfähig wie 
  19. beim SCC. Dadurch sind die MFP-Schnittstellen gegen Zeitknappheit der CPU 
  20. allergischer als die SCCs und reagieren leichter mit Zeichenverlusten.
  21.  
  22.  
  23. MFP.PRG
  24. -------
  25. MFP.PRG ist für den sogenannten ST-MFP gedacht, der ab Adresse $FFFFFA01 
  26. liegt und in ST, STE, MegaST, MegaSTE, TT, Stacy und STBook vorhanden ist. 
  27. Im Falcon ist dieser MFP ebenfalls vorhanden, der USART-Teil aber anders 
  28. (=nicht) benutzt, so da₧ MFP.PRG NICHT für den Falcon ist. Dieser Treiber 
  29. trägt sich als BIOS-Gerät 6 und mit dem Namen "MODEM1" ein.
  30.  
  31.  
  32. MFP_TT.PRG
  33. ----------
  34. MFP_TT.PRG unterstützt den sogenannten TT-MFP ab Adresse $FFFFFA81, der 
  35. bisher nur im TT vorkommt. Der Treiber trägt sich als BIOS-Gerät 8 und mit 
  36. dem Namen "SERIAL1" ein.
  37.  
  38.  
  39. MFP_FALC.PRG
  40. ------------
  41. MFP_FALC.PRG ist für die bastelfreudigen Falcon-Besitzer gedacht, die die 
  42. von Atari nicht herausgeführte serielle Schnittstelle des MFP 
  43. herausgeführt haben. Der Treiber trägt sich als BIOS-Gerät 6 und mit dem 
  44. Namen "MODEM1" ein.
  45.  
  46. Hier noch eine Mail, die ich aus der Mausgruppe Atari.Hard gefischt habe, 
  47. bezüglich Herausführung der MFP-Schnittstelle des Falcon:
  48.  
  49. -------------------Mailanfang-------------------------
  50. Gruppe: Atari.Hard
  51. #A5003@WI2 (So 26.09.1993, 08:18) MFP-Serielle im Falcon
  52.  
  53. Von: Martin Liebeck @ WI2
  54. Wg.: MFP-Serielle im Falcon
  55. Von : Martin Liebeck @ WI2 (Sa, 25.09.93 09:55)
  56.  
  57. Ein Tip für Alle, die gerne eine zweite Serielle an ihrem Falcon hätten:
  58.  
  59. die MFP-Serielle wird unter Port Nr. 6 vom TOS (4.01) unterstützt und kann als
  60. Dreidrahtschnittstelle verwendet werden. Atari hat hier wohl lediglich die
  61. Buchse und die Treiber gespart...
  62.  
  63. RXD liegt an Pin 10 des MFP und ist nach Masse gelegt. In meinem Layout wird
  64. hierzu eine ca. 3mm lange Leiterbahn auf der Platinenoberseite von Pin 10 zu
  65. einer Durchkontaktierung nach Masse verwendet. Diese muß vorsichtig (nicht zu
  66. tief, Multilayer!) unterbrochen werden. TXD bekommt man an Pin 9 des MFP.
  67.  
  68. Ich habe noch mit einer 1488/1489 Kombination auf RS232-Pegel gewandelt und die
  69. Pins 1 und 3 von Midi-in als Verbindung zur Außenwelt verwendet.
  70.  
  71. Garantie, insbesondere für ruinierte Boards, übernehme ich natürlich keine. Ich
  72. weiß auch nicht, wie höhere TOS-Versionen als 4.01 mit dem MFP verfahren. Am
  73. Besten erst mal an Pin 9 messen, ob ein Signal kommt. Viel Spaß beim löten, es
  74. lohnt sich.
  75.  
  76. Gruß Martin.
  77. ---------------Mailende-----------------
  78.  
  79.  
  80. MFP_BAST.PRG
  81. ------------
  82. MFP_BAST.PRG ist für die Bastler gedacht, die sich einen TT-kompatiblen 
  83. zweiten MFP in einen nicht-TT eingebaut haben. Dieser Treiber liegt 
  84. momentan nicht bei. Wer ihn braucht, möge sich bitte melden. Der Treiber 
  85. wird sich mit dem Namen "SERIAL1" auf das erste freie BIOS-Gerät 
  86. installieren.
  87.  
  88.  
  89.  
  90. Im Folgenden geht es hauptsächlich um MFP.PRG:
  91.  
  92.  
  93.  
  94. Dies ist ein Software-Beschleuniger und Patch für die serielle 
  95. Schnittstelle Modem1 der Atari-Computer. Es beseitigt nicht nur den auch 
  96. im TOS2.06/3.06 noch vorhandenen RTS/CTS-Handshakefehler, sondern erhöht 
  97. durch seine optimierten Routinen die mögliche Übertragungsrate wesentlich. 
  98. Spätestens wenn Fragen auftreten sollte man diesen Text komplett lesen und 
  99. erst danach seiner Umwelt oder mir die verbliebenen Fragen stellen. Bei 
  100. Updates und Zeitmangel zuerst einen Blick nach ganz hinten, Abschnitt 
  101. "Versionen"!
  102.  
  103.  
  104. Kompatibilität zu HSMODEM1
  105. --------------------------
  106. Wird MFP.PRG als letzter oder als einziger Treiber gestartet, so sollten 
  107. alle Programme, die mit den HSMODEM1-Versionen funktioniert haben, auch 
  108. mit diesen Treibern laufen, wenigstens wie bisher auf MODEM1.
  109.  
  110.  
  111. Einsatzmöglichkeiten, Voraussetzungen, u.v.m.
  112. ---------------------------------------------
  113. Mag!X
  114. Versionen ab 2.00 dieses multitaskfähigen Betriebssystems (es ist im 
  115. Gegensatz zum aktuellen MultiTOS nicht nur ein Aufsatz und wesentlich 
  116. schneller) haben korrekte Routinen zur Schnittstellen-Bedienung. Die 
  117. entsprechenden GEMDOS-Funktionen fehlen in Mag!X 2.00 aber noch. 
  118. Interessant ist das Mag!X-Multitasking auf 8MHz-STs bei 38400Bd-Empfang: 
  119. (mit einem NVDI ab Version 2.50 vom 28.10.1993) Man kann im Vordergrund 
  120. mit der Maus wirtschaften und einen Text schreiben (getestet mit Everest), 
  121. während im Hintergrund GSZRZ 3.5 fehlerfrei empfängt. Mit Mag!X ab Version 
  122. 2.00 sollte man die Interruptroutinenmodifikation im MFP.PRG abschalten, 
  123. da Mag!X bereits modifizierte Timerroutinen hat. Wenn MFP.PRG da noch 
  124. etwas einhängt, wird es ein bi₧chen langsamer.
  125.  
  126. Diese Treiber sind ein Ersatz für andere Patches (nicht nur für Modem1), 
  127. wie z.B. RS232ENC oder TURBOCTS.
  128.  
  129. Die Schnittstelle Modem1 kann ohne Zusatzhardware maximal 19200Bd 
  130. erreichen. Daran ändert auch MFP.PRG nichts. Es ersetzt aber die langsamen 
  131. und zum Teil fehlerhaften Routinen des TOS durch schnelle und hoffentlich 
  132. fehlerfreie. Mit Zusatzhardware, wie (dem von mir entwickelten) RSVE, 
  133. RS-Speed (von Stephan Skrodzki) oder anderen können höhere Datenraten 
  134. realisiert werden. Z.B. erlaubt RSVE auch die Einstellung von 38400, 57600 
  135. und 115200Bd. MFP.PRG sorgt dann im Rahmen der Hardware-Möglichkeiten für 
  136. einen wesentlich höheren Datendurchsatz (cps-Rate). Der komplette Bauplan 
  137. für RSVE liegt als RSVE.LZH in Mailboxen, auf jeden Fall in der Maus 
  138. Berlin (@B). Die Fertigversion von RSVE gibt es direkt bei mir.
  139.  
  140. Wenn jemand meint, allein mit Software Modem1 mit mehr als 19200Bd 
  141. betreiben zu können: Das geht im Synchronbetrieb des MFP (Abschalten der 
  142. Taktteilung /16). Dabei ist eine fehlerfreie Funktion aber ausschlie₧lich 
  143. beim Senden möglich, NICHT beim Empfang.
  144.  
  145. Ich arbeite mit einem 8MHz ST, ohne CPU-Beschleuniger. Ich halte wenig 
  146. davon, immer neue und schnellere Computer zu kaufen und diese durch lahme 
  147. Software bis zum Stillstand zu bremsen. Das TOS ist eine lahme Software, 
  148. kein Wunder, es ist inklusive der Interruptroutinen in C programmiert (es 
  149. sieht so aus). MultiTOS ist eine noch grö₧ere Systembremse. Mag!X ist 
  150. genau das Gegenteil.
  151.  
  152.  
  153. Fehler anderer Programme
  154. ------------------------
  155. Mit Rufus 1.11rel9 steht der Rechner nach dem Auflegen einiger Modems (RXD 
  156. und TXD leuchten beide, nichts geht mehr). Abhilfe: Rufus 1.20 oder neuer 
  157. benutzen.
  158.  
  159.  
  160. Wie schnell geht es?
  161. --------------------
  162. Das Problem bei einer seriellen Übertragung mit einer bestimmten 
  163. Geschwindigkeit (hier in Baud angegeben) ist nicht das Senden der Zeichen, 
  164. sondern deren Empfang. Der MFP puffert nur ein empfangenes Zeichen und 
  165. meldet es der CPU per Interrupt. Die CPU mu₧ dieses Zeichen für eine 
  166. fehlerfreie Übertragung aus dem MFP abholen, bevor er das nächste Zeichen 
  167. komplett empfangen hat. Wenn ich sage, der Betrieb bei ... ist zuverlässig, 
  168. so bedeutet dies, da₧ die CPU bei der maximal möglichen 
  169. Empfangs-Zeichendichte (keine Pause zwischen Stoppbit des vorigen und 
  170. Startbit des folgenden Zeichens) jedes Zeichen rechtzeitig abholt.
  171.  
  172. Ein 8MHz ST (RSVE eingebaut) kann mit TOS und HSMODEM1 eine fehlerfreie 
  173. Datenübertragung mit 38400Bd realisieren. Mit einem HSMODEM1 ab dem 
  174. 21.05.1993 funktioniert auch der Empfang (Senden sowieso) mit 57600Bd auf 
  175. 8MHz STs, wenn die Interruptroutinenmodifikation (FASTINT) eingeschaltet 
  176. ist.
  177.  
  178. Derzeit erreicht ein 8MHz ST mit GSZRZ Version 3.3 von Michael Ziegler bei 
  179. einer ZMODEM-Übertragung und 38400Bd mehr als 3600cps, wenn NVDI 
  180. installiert und der Blitter ausgeschaltet ist. Ohne NVDI sind es etwa 
  181. 300cps weniger, da GSZRZ lange an seiner Dialogbox zeichnen lä₧t. Den 
  182. Blitter kann man in den meisten Fällen auch zugeschaltet lassen. Sollten 
  183. aber Empfangsfehler auftreten, dann den Blitter abschalten. 
  184. ZMODEM-Übertragung über die Filefunktionen bringt mit einem GSZRZ ab 3.5 
  185. mehr als 5400cps bei 57600Bd.
  186.  
  187. Die angegebenen Datenraten gelten für direkte Rechnerkopplung. Für langsame 
  188. Modems und schlechte Telefonleitungen sind die Treiber nicht verantwortlich! 
  189. Zyxels können bei 16800zyx/v42bis und ASCII-Texten 3800cps erreichen, 
  190. Zyxel+ bei 19200zyx noch mehr. Andere 14400/v42bis-Modems liegen bei etwa 
  191. 3300cps.
  192.  
  193. Die von mir entwickelte Hardware ST_ESCC hat auch bei 115200Bd noch 
  194. keinerlei Probleme, selbst bei Tastaturtippen unter normalem TOS, da sie 
  195. über einen 8 Byte gro₧en Empfangs-FIFO verfügt. Sie beschleunigt aber 
  196. nicht MODEM1, sondern realisiert zwei zusätzliche schnelle Serielle.
  197.  
  198.  
  199. 57600Bd auf 8MHz und 16MHz 68000er über _MODEM1_
  200. ------------------------------------------------
  201. 57600Bd ist für Modem1 auf (Mega)ST(E) die magische Grenze, die 
  202. auch nur mit leichten Modifikationen im TOS erreicht wird. 115200Bd werden 
  203. wohl auch in Zukunft nur im Polling und nicht im Interruptbetrieb möglich 
  204. sein.
  205.  
  206. Bei mir funktionieren 57600Bd auf einem 8MHz-ST mit TOS2.06. Ich bin mir 
  207. aber nicht sicher, ob es auch mit anderen (älteren) TOS-Versionen 
  208. funktioniert.
  209.  
  210. Da ich immer wieder gefragt werde, wie man 57600 fehlerfrei erreicht: 
  211. Blitter aus, keine DMA-Zugriffe während Dateiübertragung (in den Filepuffer 
  212. des ZMODEMs mu₧ bei Empfang das ganze File passen), keine Joysticks mit 
  213. Autofire oder DCF-Uhren am Joyport. Dann testweise alle residenten 
  214. Programme und ACCs entfernen und nur die wieder benutzen, die nicht stören.
  215.  
  216.  
  217. Die Konfiguration
  218. -----------------
  219. Die Konfiguration erfolgt durch das SETTER.TTP. Zur Bedienung siehe 
  220. SETTER.TXT.
  221.  
  222. FASTINT:
  223. MFP.PRG kann den Timerinterrupt des TOS modifizieren, um so 57600Bd mit 
  224. 8MHz-68000 über MODEM1 zu ermöglichen. Sollte man auf TTs/Falcons und 
  225. unter Mag!X >=2.0 abschalten, ebenso bei Experimenten mit anderen 
  226. Betriebssystemen. Wenn man mehr als ein MFP*.PRG gleichzeitig nutzt, 
  227. sollte diese Option höchstens in einem davon eingeschaltet sein.
  228. Funktionsweise (für Interessenten):
  229. Es hat sich gezeigt, da₧ es ausreichend ist, wenn die Routine (GEMDOS-Uhr) 
  230. in NEXT_TIM (negative LineA-Variable) mit einem IPL < 6 aufgerufen wird, 
  231. um auf 68000/8MHz den 57600Bd-Empfang zu ermöglichen. Also hänge ich ein 
  232. Programmstück ein, da₧ den IPL auf 5 heruntersetzt. Diese Vorgehensweise 
  233. ist nicht völlig unkritisch, bringt aber nur Probleme, wenn andere 
  234. Programme ebenfalls derartige Fummeleinen anstellen.
  235.  
  236. RSVE:
  237. (Nur für Nutzer der RSVE-Hardware interessant. Andernfalls mit Nein 
  238. antworten.) MFP.PRG kann den Cookie RSVE anlegen und macht damit das 
  239. RSVE_SET.PRG überflüssig. Die Funktion von HISP wird automatisch mit 
  240. ausgelöst.
  241.  
  242. HISP:
  243. Dieser Konfigurationspunkt teilt die bei RSVE (und RS_Speed) möglichen 
  244. hohen Baudraten den Fcntl-TIOC?BAUD-Funktionen mit (anstelle der 
  245. 150/134/110).
  246.  
  247. REPL:
  248. MFP.PRG kann Baudraten umlegen. Dies ist nur zusammen mit RSVE oder 
  249. RS-Speed nützlich, falls Programme weder RSVE/RS_Speed kennen noch 
  250. 110/134/150Bd einstellen können. So kann man die Einschaltung von 38400Bd, 
  251. die bei ahnungslosen Programmen normalerweise durch Einstellen von 110Bd 
  252. erfolgt, auf das Einstellen von 19200Bd legen. Man gibt (wie es SETTER 
  253. beschreibt) zuerst die zu ersetzende alte Baudrate und dann (auf den 
  254. nächsten Platz) die dort hinzulegende hohe Rate an, und zwar ganz exakt. 
  255. Der erste als "ungültig" gekennzeichnete Platz beendet die Suche nach 
  256. Umbelegungen. Will man nichts umlegen, gibt man überall "u" an. Die 
  257. Baudraten 115200/57600/38400 liegen mit der Hardware RSVE ohnehin auf 
  258. 150/134/110, sie dorthin umzulegen ist sinnlos. Die Umlegungen sind für 
  259. Programme unsichtbar und erscheinen nicht in den Fcntl TIOC?BAUD.
  260.  
  261. DTR: (nur bei MFP.PRG)
  262. Das DTR(Data Terminal Ready)-Signal wird beim Start dieses Treibers 
  263. einmalig auf den hier angegebenen Wert gesetzt. Eine Aktivierung mit "Ja" 
  264. entspricht der Arbeitsweise des TOS, eine Deaktivierung mit "Nein" 
  265. verhindert das "ungefragte" Abheben eines entsprechend konfigurierten 
  266. Modems.
  267.  
  268. RBL:
  269. Wenn man hiermit nichts anzufangen wei₧, einfach 256 einstellen. Hier wird 
  270. die Empfangspufferlänge in Byte eingestellt. Sie darf maximal 65534 und 
  271. minimal 16 betragen. Werte au₧erhalb dieses Bereiches werden auf den 
  272. Standardwert von 256 gesetzt. Die Länge wird auf eine gerade Zahl 
  273. abgerundet. Die Wassermarken werden generell auf 1/4 (low water mark) und 
  274. 3/4 (high water mark) gesetzt.
  275.  
  276. TBL:
  277. Wie RBL, aber diesmal die Sendepufferlänge.
  278.  
  279.  
  280. Mögliche Probleme
  281. -----------------
  282. Lange DMA-Zugriffe können beim Empfang zu Datenverlusten führen. Ebenfalls 
  283. kritisch sind lange Verweilzeiten der CPU in einem Interruptprioritätslevel 
  284. grö₧er als 5.
  285.  
  286. Auf 8MHz STs ohne Mag!X >2.00 und ohne neues NVDI (mindestens Version 2.50 
  287. vom 28.10.1993): Bei mehr als 9600Bd Finger weg von Maus und Tastatur, 
  288. während GSZRZ empfängt. Sonst gibt es ein paar Übertragungsfehler (bei 
  289. MODEM1). Genauso können ein paar Zeichen verloren gehen, wenn im 
  290. Terminalprogramm gerade ein Text ankommt und der User die Tastatur oder 
  291. Maus bearbeitet.
  292.  
  293. Abspeichern empfangener Daten unter GSZRZ während des Empfangs führt bis 
  294. 38400Bd meist nicht zu Fehlern.
  295.  
  296. Man kann den Blitter so programmieren, da₧ er die CPU zu lange blockiert. 
  297. Das TOS und NVDI tun dies anscheinend nicht. Wenn Fehler beim Empfang mit 
  298. >= 38400Bd auftreten, erst mal mit abgeschaltetem Blitter probieren.
  299.  
  300. Es gibt einige ACCs und residente (AUTO-Ordner-)Programme, die irgendwelche 
  301. Interrupts umlegen und das System zu lange blockieren. Im Zweifelsfalle 
  302. einzeln rauswerfen und testen.
  303.  
  304. MiNT und besonders MultiTOS sind allgemeine Systembremsen, die sich 
  305. besonders auf 8MHz-Rechnern bemerkbar machen. Mag!X finde ich persönlich 
  306. wesentlich besser, da es wesentlich schneller ist.
  307.  
  308. DCF_TIME von Ralf Zimmermann @WI2 sollte in der Version 1.2 oder höher 
  309. verwendet werden. Aber nur die Abfrage über den RingIndicator macht keine 
  310. Probleme bei 57600Bd, über den Joyport gibt es sekündlich Ärger.
  311.  
  312. QFAX fri₧t sehr viel Rechenzeit und sollte bei Problemen zuerst entfernt 
  313. (nicht nur abgeschaltet) werden.
  314.  
  315.  
  316. Funktion des ...
  317. ----------------
  318. Siehe DRVIN.TXT, RSVE_COO.TXT, SERSOFST.TXT.
  319.  
  320.  
  321. Versionen
  322. ---------
  323. Diese Daten gelten für alle MFP*.PRG, wenn nicht anders vermerkt.
  324.  
  325. 1993-11-21  erste Veröffentlichung
  326. 1993-11-23  bleibt auch bei Installationsfehler resident allerdings passen 
  327. dann ser. Interruptroutinen und Bco* nicht zusammen. (besser als 
  328. Totalabsturz)
  329. 1993-12-15  bei den MFP*.PRG ohne Hardwarehandshakeleitungen: TIOCSFLAGS 
  330. verbietet RTS/CTS durch Fehlermeldung ERANGE. In diesem Fall werden die 
  331. Einstellungen nicht gesetzt!
  332. 1994-01-01  Fcntl TIONOTSEND und TIOCFLUSH implementiert, DTR-Signal 
  333. nutzerdefiniert bei MFP.PRG, Puffergrö₧en durch Nutzer einstellbar
  334. 1994-03-27  Fcntl TIOCFLUSH Nr.1,2,3 gehen jetzt endlich
  335. 1994-04-07  Empfangspuffer-High-Water-Mark korrekt initialisiert
  336.  
  337.  
  338. Harun Scheutzow, 21.11.1993 und später
  339. (Harun_Scheutzow@b.maus.de)
  340.  
  341.  
  342.  
  343.  
  344. MFP.PRG, MFP_TT.PRG, MFP_FALC.PRG, MFP_BAST.PRG
  345. ***********************************************
  346.  
  347. (The most important parts translated from German to English on 1994-01-08 
  348. by Harun Scheutzow. I have no time for translating all. If anybody 
  349. translates the remaining parts, I'm very interested in getting the result 
  350. for including it in the next version of this package. My native language 
  351. is German, I think a person whos native language is English would do a 
  352. much better translation. Thanks! (Send only mails smaller than 16kbyte to 
  353. my email address.))
  354.  
  355. These are drivers for the interfaces realized by MFPs (eg IC MC68901 
  356. manufactured by Motorola). They work together with DRVIN.PRG or an 
  357. equivalent replacement. 1_README.TXT contains an introduction.
  358.  
  359.  
  360. The general
  361. -----------
  362. Currently all MFP*.PRG have the same configuration possibilities.
  363.  
  364. The serial part of the MFP, the USART, is not as powerful as the one of 
  365. the SCC. That's why the MFP interfaces are more allergic against high CPU 
  366. load and lose more easy characters.
  367.  
  368.  
  369. MFP.PRG
  370. -------
  371. MFP.PRG is made for the so called ST-MFP, which lays from address 
  372. $FFFFFA01 up in every ST, STE, MegaST, MegaSTE, TT, Stacy and STBook. The 
  373. Falcon has this MFP too, but the USART-part is used in an other way (not 
  374. used). MFP.PRG is not for the Falcon. This driver provides the BIOS-device 
  375. 6 and the name "MODEM1".
  376.  
  377.  
  378. MFP_TT.PRG
  379. ----------
  380. MFP_TT.PRG supports the so called TT-MFP form address $FFFFFA81 up, 
  381. contained only in the TT until now. This driver provides the BIOS-device 8 
  382. and the name "SERIAL1".
  383.  
  384.  
  385. MFP_FALC.PRG
  386. ------------
  387. MFP_FALC.PRG is made for the users who modified their Falcon by drawing 
  388. out the serial interface of the MFP, unused in the original state. The 
  389. driver provides the BIOS-device 6 and the name "MODEM1".
  390.  
  391. (-- Mail is only in the German part --)
  392.  
  393.  
  394. MFP_BAST.PRG
  395. ------------
  396. MFP_BAST.PRG is not contained in this package. It shall support the TT-MFP 
  397. in non-TTs (for users who solder in their computers). Who is in need of 
  398. this driver, should contact me.
  399.  
  400.  
  401.  
  402. In the following I will describe principal the MFP.PRG:
  403.  
  404.  
  405.  
  406. This is a software speeder and patch for the interface MODEM1 of the Atari 
  407. computer. It removes not only the RTS/CTS-handshake bugs contained in the 
  408. TOS2.06/3.06 too, but increases with its optimized routines the possible 
  409. transfer rate.
  410. (-- something untranslated --)
  411.  
  412.  
  413. Compatibility to HSMODEM1
  414. -------------------------
  415. If MFP.PRG is loaded as the only one or the last driver, all programs 
  416. which run with HSMODEM1 should run with these driver to (on MODEM1).
  417.  
  418.  
  419. Suppositions, ...
  420. -----------------
  421. Mag!X
  422. Versions from 2.00 up of these multitask operating system (it is in 
  423. opposite to the current MTOS not only an addition to TOS) have correct 
  424. routines for the serial interfaces. The corresponding GEMDOS-functions 
  425. are absent in version 2.00. The Mag!X-multitasking on an 8MHz-ST during 
  426. 38400Bd-receive (eg ZMODEM) is very nice (with a NVDI form Version 2.50 
  427. form 28.10.1993 up): It is possible to work in the foreground with 
  428. keyboard and mouse (eg in a text editor, tested with Everest) while in the 
  429. background the ZMODEM-receive (GSZRZ) runs without any errors. Such 
  430. performance became true by intelligent programming. With Mag!X from 
  431. version 2.00 up the timer interrupt routine modification should be 
  432. switched off because Mag!X has its own nice routines.
  433.  
  434. These drivers are a replacement for other patches (not only for MODEM1), 
  435. eg RS232ENC or TURBOCTS.
  436.  
  437. The interface MODEM1 runs without additional hardware with a maximum of 
  438. 19200Bd. MFP.PRG can not change this. But it replaces the slow and in part 
  439. buggy routines of the TOS by fast and (I hope) error free ones. With 
  440. additional hardware as the RSVE (developed by me), or as RS-Speed (by 
  441. Stephan Skrodzki) or others baud rates higher than 19200 are provided. 
  442. RSVE allows 38400, 57600 and 115200Bd. MFP.PRG realizes in the range of 
  443. the hardware possibilities (CPU speed, MODEM speed, ...) for a higher 
  444. thruput. The complete documentation of RSVE lays in some mailboxes.
  445.  
  446. It is impossible to set the MODEM1 only by software to more than 19200Bd 
  447. in the _asynchron_ mode.
  448.  
  449. (-- something untranslated --)
  450.  
  451.  
  452. Bugs of other programs
  453. ----------------------
  454. (-- something untranslated --)
  455.  
  456.  
  457. How fast it can run?
  458. --------------------
  459. The problem of the serial transfer with a given speed (measured in Baud) 
  460. is not the transmission of the characters but their reception.
  461. (-- something untranslated --)
  462.  
  463.  
  464. 57600Bd on 8MHz and 16MHz 68000 CPUs on MODEM1
  465. ----------------------------------------------
  466. 57600Bd is the magic border of MODEM1 on (Mega)ST(E) which is achieved 
  467. only by small modifications in TOS (or by Mag!X). 115200Bd seem to be 
  468. possible by polling only.
  469.  
  470. (-- something untranslated --)
  471.  
  472.  
  473. Configuration
  474. -------------
  475. The configuration is done by using SETTER.TTP.
  476.  
  477. Because the explainations in the drivers are German I added an 
  478. abbreviation.
  479.  
  480. FASTINT:
  481. MFP.PRG is able to modify the timer interrupt of the TOS to achieve 
  482. 57600Bd on MODEM1 on a 8MHz-68000. Should be switched off on TT/Falcon and 
  483. under Mag!X >=2.00 and during experiments with other operating systems. If 
  484. more than one MFP*.PRG is used at the same time this option sould be set 
  485. only in one of them.
  486. Function (for interested users):
  487. (-- something untranslated --)
  488.  
  489. RSVE:
  490. (Only for users of the RSVE-hardware. Otherwise answer with Nein.) MFP.PRG 
  491. can create the cookie RSVE making the RSVE_SET.PRG unnecessary. The 
  492. function of HISP is done automatically.
  493.  
  494. HISP:
  495. This setting enables the high baud rates possible with RSVE and RS_Speed 
  496. in the Fcntl-TIOC?BAUD-functions instead of 150/134/110.
  497.  
  498. REPL:
  499. MFP.PRG can replace baud rates. This is useful only with RSVE or 
  500. RS-Speed if programs can't set 110/134/150Bd and don't know RSVE/RS_Speed.
  501. (-- something untranslated --)
  502. Enter on all six places u if you don't have RSVE or RS-Speed.
  503. (-- something untranslated --)
  504.  
  505. DTR: (only for MFP.PRG)
  506. The DTR(data terminal ready)-signal is set at the start of this driver on 
  507. time to the value given here. Yes corresponds to on and is equivalent to 
  508. the behavior of TOS, No corresponds to off and prevents most modems from 
  509. going off hook before a communication program has been started.
  510.  
  511. RBL:
  512. Use 256 as a default. Here the receiver buffer length in byte can be set. 
  513. It may be in the range of 65534 (maximum) to 16 (minimum). Values out of 
  514. this range are set to the default of 256. The water marks are set to 1/4 
  515. (low water mark) and 3/4 (high water mark).
  516.  
  517. TBL:
  518. As RBL, but for the transmitter buffer length.
  519.  
  520.  
  521. Possible problems
  522. -----------------
  523. (-- something untranslated --)
  524.  
  525.  
  526. Function of ...
  527. ---------------
  528. See DRVIN.TXT, RSVE_COO.TXT, SERSOFST.TXT.
  529.  
  530.  
  531. Versions
  532. --------
  533. The data is valid for every MFP*.PRG if there is no special note.
  534. (-- something untranslated --, see German part)
  535.