From: naddy@mips.pfalz.de (Christian Weisgerber) Newsgroups: de.alt.folklore.computer,de.comp.sys.st Subject: Aufbau des ST (was: Re: 68k-Rechner) Date: 1 May 1996 00:24:37 +0200 Das Betriebssystem des Atari ST bestand aus - BIOS und XBIOS, warum die beiden getrennt wurden, weiss ich nicht, - TOS (im engeren Sinn), was etwa MS-DOS-aequivalente Dienste zu Verfuegung gestellt hat, und auf BIOS und XBIOS zurueckgegriffen hat, und aus dem Grafikaufsatz GEM, der sich wiederum in - VDI, das Graphic Primitives realisierte, und - AES, das auf Applikationsebene mit Fenstern, Events, u.ae., gearbeitet hat, spaltete. Die Gesamtheit dieser Komponenten wurde auch als TOS bezeichnet. "TOS" stand wahrscheinlich am Anfang einfach fuer "The Operating System", wurde aber allgemein als "Tramiel Operating System" aufgefasst. Im Vergleich zu den vorher verbreiteten Homecomputern a la C64 war TOS ein riesen Fortschritt, im Vergleich zu AmigaOS, OS9, oder richtigen Betriebssystemen ziemlich kuemmerlich. Es hat eine Weile gedauert, bis die Leute gelernt haben, dass man nun nicht mehr Programme fix an Adresse $xxxx in den Speicher klatscht, und dass man nicht auf private Variablen des Betriebssystems mit PEEK und POKE zugreift, etc. Ich erlaube mir einen Abriss ueber die Hardware des original Atari ST mit ein paar Kommentaren. Im Herzen sass ein 68000/8Mhz. Darum lagen vier Custom-Chips: MMU, Glue, DMA-Chip, und Shifter (Videochip), wobei die physische Zuordnung der Funktionen nicht notwendigerweise der logischen entsprach. Die CPU konnte alle vier Taktzyklen auf den Bus zugreifen, dazwischen war der Video-DMA untergebracht. Floppy/ACSI-DMA hat CPU-Buszyklen gestohlen. Ein Fast-RAM-Konzept gab es nicht, was aber beim urspruenglichen ST auch noch keine Rolle spielte. Die MMU konnte bis zu 4MB RAM verwalten. Erste STs wurden mit 512kB ausgeliefert (520), die zweite Generation mit 512kB (260) oder damals schier unvorstellbaren 1MB (520+). Von den Zugriffszeiten waren 120ns RAMs angesagt, 150er taten es aber oft auch. Das ROM umfasste 192kB in sechs 250ns-Bausteinen. Die ersten TOS-Versionen wurden noch auf Diskette ausgeliefert, weil sie zu gross waren, im Rechner steckten nur zwei 8kB BootROMs. In Anlehnung an die alten 8-Bit-Ataris war ein "Modulport" fuer ein 128kB-ROM-Modul vorhanden. Der wurde fuer seinen vorgesehenen Zweck eher selten, aber gelegentlich fuer Dongles, fuer verwegene I/O-Port-Konstrukte u.a. eingesetzt. Als Interruptcontroller kam ein MFP68901 zum Einsatz. Der hatte auch drei Timer drauf, eine serielle Schnittstelle, die als solche eingesetzt wurde, und mehrere Portpins, die bei verschiedenen Schnittstellen gelandet sind. Die MFP hat 16 IRQ-Quellen intern priorisiert und als Autovektorinterrupt 6 zur CPU gereicht. Ansonsten war Autovec Nummer 4 der V(ertical)BL(ank) Interrupt, Nummer 2 der H(orizontal)BL(ank). Die anderen Interrupt-Level wurden nicht genutzt. Als Floppy-Controller kam ein WD1772 zum Einsatz. Ein sehr einfacher, allgemein sehr beliebter Einchip-FDC, der sich in eine traditionsreiche Reihe anderer WD-FDCs einreiht. Ein bisschen dumm, ein bisschen inflexibel, aber ausreichend und zuverlaessig. Er hatte sehr interessante, fuer den allgemeinen Betrieb irrelevante Bugs, die fuer Kopierschutzzwecke ausgeschlachtet wurden. Der FDC war hinter den DMA-Chip geschaltet, und wurde sehr umstaendlich ueber dessen Register angesprochen. Ausserdem stellte der DMA-Chip als Harddisk-Port das sogenannte ACSI zu Verfuegung, eine Art kaputtgeschrumpftes SCSI. Die eigentliche DMA-Funktionalitaet steckte in der MMU. Der Shifter war relativ unflexibel und stellte fest drei Darstellungen zu Verfuegung: - 640x400, eine Bitplane, "monochrome", mit 72Hz Bildwiederholrate. Das flimmerfreie Bild war damals eine Sensation, zumal Atari auch passende Monochrom-Monitore (SM124) lieferte. - 640x200, zwei Bitplanes, und - 320x200, vier Bitplanes. Fernsehaufloesungen. Jeweils mit 50/60Hz (konfigurierbar) Bildwiederholrate. Die Pixelwerte waren Indizes in die 16 Palettenregister des Shifters, wo je drei Bit R/G/B verfuegbar waren. Die Bitplanes waren wortweise verschachtelt im Bildschirmspeicher abgelegt, der an beliebiger Stelle im Hauptspeicher stehen konnte. In den Farbmodis konnte man noch die Randfarbe getrennt festlegen. Es gab ueberhaupt keinen Support fuer Scrolling und keine Sprites. Fruehe Experten verkuendeten enttaeuscht, dass man auf dieser Maschine wohl nie Action-Spiele schreiben koennen wuerde. Daraufhin hat ein Englaender "Goldrunner" geschrieben, das vertikales Scrolling benutzte. Die Experten zogen sich darauf zurueck, dass es niemals horizontales Scrolling geben wuerde. Nun, das war eine haertere Nuss, aber auch das wurde trickreich realisiert. Die nur 16 Farben in der niedrigen (Spiele- und Demo)aufloesung hatte man schon frueh per Rasterinterrupts zur vollen 512er-Pracht aufgebohrt. Eine Cracker/Demo-Crew hat es dann geschafft, das dargestellte Bild nach unten zu vergroessern, "den unteren Rand aufzuklappen". In einem wilden Wettstreit fanden sich auch Wege Grafik in den rechten, linken, und oberen Rand zu bringen. Die Tricks dazu waren ziemlich absurd, nutzten wohl nie vorgesehene oder bedachte "Features" in der Videologik. Die spaeteren Demos (Union Demo, Cuddly Demo) waren verdammt eindrucksvoll, insbesondere, wenn man die fehlende Unterstuetzung der Hardware in Betracht zieht. Ich sage da nur The Exceptions (TEX), TNT, The Union, The Cuddly Bears (TCB), The Lost Boys (TLB), ... Der grosse Ehrgeiz war immer, besser als der Amiga zu sein, oder zumindest genauso gut. Da gab es fast Amiga-wertigen Samplesound, geklonte RSI-Screens, u.a. Einen Blitter gab es zunaechst nicht. Er sollte dann fuer alle ST-Besitzer zum Nachruesten nachgeliefert werden, "zu Weihnachten". Leider hatte Atari vergessen, das Jahr anzugeben... Spaetere Modelle hatten einen eingebauten Blitter. Der erfreute sich beim harten Kern der Demo- und Spieleprogrammierer aber keiner grossen Beliebtheit. Auch weil er eben nicht allgemein verfuegbar war, und weil man dann schon stolz war, dass man solche Dinge gar nicht brauchte. Fuer den Sound hatte man dem ST nur einen ziemlich kuemmerlichen Soundchip spendiert, dessen Bezeichnung mir entfallen ist. Das Ding war auch im Schneider CPC. Eine Art besserer Drei-Kanal-Piepser. Er hatte auch zwei 8-Bit I/O-Ports die zur Realisierung des Druckerports (keine Treiber dazwischen, notorisch empfindlich) und fuer Kleinkram wie Floppy-Drive- und -Seiten-Select dienten. Einige Wizards haben es spaeter tatsaechlich geschafft, erst unter sehr hohem, spaeter unter tragbarem CPU-Aufwand Sample-Sounds aus dem Ding zu druecken. Die Schnittstellenbausteine wurden von zwei ACIAs (6850) komplettiert. Einer realisierte eine MIDI-Schnittstelle, ein Gluecksgriff, der dem ST damals zum Durchbruch in der Musikbranche verhalf, am zweiten hing die Tastatur. Die wurde von einem Hitachi Einchip-Mikrocontroller, 6301 oder so, ausgewertet. Die Maus hing da auch noch dran. Der ST hatte rekordverdaechtig viele Schnittstellen, war aber eine abgeschlossene Architektur. Es gab keinen "User-Port" und keine Steck- karten. Eine grosse Schwaeche. GEM bzw. eine solche Klick-Oberflaeche, wie sie sich auch bei Amiga und natuerlich Mac fand, wurde damals als revolutionarer Fortschritt gepriesen. Die Realitaet so jedenfalls aus meiner Perspektive anders aus: langsamer Bildschirmaufbau, aetzend langsames Scrollen in den Fenstern, staendig die Hand von der Tastatur nehmen, um irgendwelche Funktionen in Menueleisten zu suchen und zu aktivieren. Tastaur- Shortcuts kamen auf dem ST erst Jahre spaeter in Mode. Mir haben diese Erfahrungen damals nachhaltig gezeigt, dass eine grafische Oberflaeche allein eine Anwendung noch lange nicht ergonomisch macht, und dass sie fuer viele Anwendungen ueberfluessig bis nachteilig ist. -- Christian 'naddy' Weisgerber naddy@mips.pfalz.de See another pointless homepage at . ---- From: harald@manowar.ka.sub.org (Harald Weidner) Newsgroups: de.alt.folklore.computer,de.comp.sys.st Subject: Re: Aufbau des ST (was: Re: 68k-Rechner) Date: 2 May 1996 12:56:09 GMT In article <4m63v5$jqu@mips.pfalz.de>, Christian Weisgerber wrote: >Das Betriebssystem des Atari ST bestand aus >- BIOS und XBIOS, > warum die beiden getrennt wurden, weiss ich nicht, Das BIOS war als hardwareunabhängiger Teil gedacht, dessem Programmier- schnittstelle auch dann unverändert bleiben sollte, wenn die Hardware und/oder Systemversion ändern. Es bestand im Wesentlichen aus Routinen zum Massenspeicherzugriff auf Sektorebene. Beim XBIOS war nicht garan- tiert, daß sich die Funktionen nicht bei neueren Systemversionen ändern. >- TOS (im engeren Sinn), > was etwa MS-DOS-aequivalente Dienste zu Verfuegung gestellt hat, und > auf BIOS und XBIOS zurueckgegriffen hat, Diese Ebene wird in der ST-Literatur meist als GEMDOS bezeichnet (auch wenn sie mit GEM nichts zu tun hat). >Im Vergleich zu den vorher verbreiteten Homecomputern a la C64 war TOS >ein riesen Fortschritt, im Vergleich zu AmigaOS, OS9, oder richtigen >Betriebssystemen ziemlich kuemmerlich. Wie man's nimmt... Das API war durchaus von Anfang an für einen moder- neren Unterbau geeignet, und sauber programmierte Programme von damals laufen auch heute noch unter MultiTOS o.ä. Die ersten Versionen von TOS waren halt auf die Hardwaremöglichkeiten aus den Anfangszeiten der 16- Bitter zugeschnitten. IMHO konnte man auf einem 68000er mit 8 MHz, 512 KB RAM auch ohne Festplatte unter TOS schon halbwegs vernünftig arbeiten, während das bei Amiga und Mac nicht und auch mit vergleichbarer PC-Hard- ware und ersten Windows-Versionen nur sehr begrenzt möglich war. >Es hat eine Weile gedauert, bis >die Leute gelernt haben, dass man nun nicht mehr Programme fix an >Adresse $xxxx in den Speicher klatscht, und dass man nicht auf private >Variablen des Betriebssystems mit PEEK und POKE zugreift, etc. Richtig. Es war ein großer (vielleicht sogar der große) Fehler von Atari, die Entwicklerrichtlinien nur im Bundle mit dem Alcyon-C-Com- piler zum Horrorpreis von 700.- DM abzugeben. Das hat viele Entwick- ler dazu bewogen, das System durch die Try-and-Error-Methode zu erkun- den. >Es gab ueberhaupt keinen Support fuer Scrolling Naja, die Anfangsadresse des Bildschirmspeichers im RAM ließ sich in gewisser Schrittweite verschieben. Zusammen mit einer Abfrage des ver- tikalen Bildrücklaufs war das sogar ein sehr leistungsfähiger Scroll- mechanismus. -- Harald Weidner ++ harald@manowar.ka.sub.org ++ Harald.Weidner@ira.uka.de