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