Atari 8-Bit-Heimcomputer

Welche Atari-Heimcomputer diese Seite behandelt

Mit „Atari-Heimcomputer“ ist hier die zusammenhängende 8-Bit-Familie gemeint, die mit Atari 400 und Atari 800 begann und über 1200XL, 600XL, 800XL, 65XE und 130XE bis zum XE Game System weiterentwickelt wurde. Gemeinsam sind diesen Rechnern die 6502-basierte CPU-Familie, ANTIC, CTIA beziehungsweise GTIA, POKEY, ein Atari-Betriebssystem im ROM und das SIO-Peripheriekonzept.

Die Geräte unterscheiden sich bei RAM, Gehäuse, Tastatur, Anschlüssen, ROM-Versionen und Erweiterungsschnittstellen, bilden aber eine außergewöhnlich langlebige Software- und Hardwareplattform. Viele Programme aus der 400/800-Zeit laufen auch auf späteren XL- und XE-Modellen; vollständige Kompatibilität ist wegen geänderter Betriebssystem-ROMs und einzelner Hardwaredetails dennoch nicht garantiert.

Atari 2600, 5200 und die spätere ST-Familie werden nur zur Abgrenzung behandelt. Der 2600 ist eine andere 6507/TIA-Konsolenarchitektur, der 5200 ist technisch mit den 8-Bit-Rechnern verwandt, aber als Konsole anders organisiert, und der Atari ST gehört bereits zur Motorola-68000-Generation.

Aus der Spielhallen- und Konsolenerfahrung zum Heimcomputer

Atari kam aus einer Welt, in der Spezialhardware für bewegte Grafik, Joysticks und schnelle Bildausgabe selbstverständlich war. Diese Erfahrung prägte die 8-Bit-Heimcomputer stärker als bei vielen zeitgenössischen Mikrocomputern, die zunächst als allgemeine CPU mit relativ einfacher Videoausgabe entstanden.

Die Architektur wurde von Beginn an so angelegt, dass Spezialchips Aufgaben übernehmen, die sonst den 6502 stark belasten würden. ANTIC liest selbstständig Bildschirmdaten per DMA, CTIA/GTIA erzeugt Farben und Player/Missile-Objekte, POKEY kümmert sich um Audio, Tastatur, Potentiometereingänge, Zufallszahl und serielle Kommunikation.

Das Ergebnis ist kein Rechner mit einem einzelnen „Grafikchip“, sondern ein Verbund mehrerer spezialisierter Bausteine. Gerade diese Arbeitsteilung erklärt viele Fähigkeiten der Familie und zugleich ihre besondere Programmierweise.

Die Modelllinie von 1979 bis XEGS

Die ersten verkauften Systeme waren Atari 400 und Atari 800 ab Ende 1979. Anfangs waren kleine RAM-Ausstattungen üblich; der 800 konnte über interne Module bis 48 KiB ausgebaut werden. Die 400er-Familie zielte mit Folientastatur und einfacherer Ausstattung stärker auf den preisgünstigen Heimmarkt, während der 800 eine vollwertige Tastatur und bessere Erweiterbarkeit bot.

Ende 1982 folgte der 1200XL mit 64 KiB RAM und neuem Gehäuse. 1983 vereinfachten 600XL und 800XL dieses Konzept und integrierten Atari BASIC fest ins ROM. 1985 wechselte die Produktlinie zur XE-Gehäuseform; der 65XE blieb bei 64 KiB, der 130XE erhielt 128 KiB. 1987 verpackte Atari die gleiche Grundarchitektur als XE Game System mit abnehmbarer Tastatur und stärkerem Konsolenmarketing.

Damit blieb die Plattform über fast ein Jahrzehnt am Markt, obwohl sich Gehäuse, Preispunkte und Vertriebsstrategie mehrfach änderten.

Atari 400 – der robuste Einstieg

Der Atari 400 besitzt eine flache druckempfindliche Folientastatur. Sie ist gegen Schmutz und Flüssigkeiten robuster als eine offene mechanische Tastatur, eignet sich aber deutlich schlechter für längere Texteingabe. Für Spiele und BASIC-Einstieg war dieser Kompromiss Teil des günstigeren Konzepts.

Frühe Geräte wurden mit 8 KiB RAM angeboten, später waren 16 KiB verbreitet. Das Betriebssystem liegt in 10 KiB ROM. Ein Modulschacht nimmt Software-Cartridges auf. Vier Controllerports erlauben bei passender Software echte Mehrspieler-Konfigurationen mit vier Joysticks.

Technisch besitzt der 400 bereits dieselben entscheidenden Spezialchips wie der 800. Der niedrigere Preis entsteht daher nicht durch eine völlig abgespeckte Grafik- oder Soundarchitektur, sondern vor allem durch Tastatur, RAM-Ausbau und mechanische Ausstattung.

Atari 800 – modulare und aufwendige Ursprungsmaschine

Der Atari 800 ist das hochwertigere Ursprungsmodell. Eine vollwertige Tastatur, zwei Cartridge-Slots, vier Controllerports und interne Steckplätze für RAM-Module machen ihn deutlich ausbaufähiger als den 400.

Die maximal übliche RAM-Ausstattung des ursprünglichen 800 beträgt 48 KiB. Ein Teil des 64-KiB-CPU-Adressraums wird für ROM, Hardware und Cartridge-Bereiche benötigt, weshalb 48 KiB damals eine sinnvolle Vollausstattung darstellten.

Der 800 ist aus heutiger Sicht besonders interessant, weil seine modulare Konstruktion die Architektur physisch sichtbar macht: CPU-/Systemboard, ROM- und RAM-Module sowie Abschirmung sind stärker getrennt als bei späteren kostensparend integrierten Modellen.

CTIA zu GTIA – frühe Rechner bekamen später mehr Farbmodi

Frühe Atari-400/800-Geräte wurden in bestimmten Märkten zunächst mit CTIA ausgeliefert. Später ersetzte Atari diesen Baustein durch GTIA. GTIA bleibt zu den normalen CTIA-Funktionen kompatibel, erweitert die Farbauswertung aber um zusätzliche Darstellungsmodi.

Mit GTIA stehen 256 mögliche Farb-/Helligkeitskombinationen im Palettenmodell zur Verfügung. Die bekannten GTIA-Spezialmodi erlauben beispielsweise 16 Helligkeiten eines Farbtons oder 16 Farbtöne bei gemeinsamer Helligkeit. Die Darstellung ist breiter gefächert als die normale Zahl gleichzeitig verfügbarer Playfield-Farben.

Software, die ausschließlich die klassischen ANTIC-/CTIA-Funktionen verwendet, bleibt dadurch kompatibel. Programme, die GTIA-Modi voraussetzen, benötigen dagegen ein entsprechendes Gerät.

1200XL – technisch interessant, kommerziell nur kurz

Der 1200XL führt 64 KiB RAM, ein flacheres Gehäuse, zwei Controllerports, Funktionstasten F1 bis F4 und eine überarbeitete Betriebssystemgeneration ein. Er markiert den Übergang von der ursprünglichen 400/800-Bauform zur XL-Familie.

Die neue OS-Version verbesserte und veränderte interne Routinen. Programme, die dokumentierte Betriebssystemvektoren verwendeten, kamen damit besser zurecht als Software, die feste Adressen innerhalb des alten ROMs ansprang. Genau hier zeigt sich die Bedeutung sauberer System-APIs.

Der 1200XL besitzt noch kein fest eingebautes Atari BASIC. Er blieb nur relativ kurz im Markt und wurde durch 600XL und 800XL ersetzt.

600XL – kompaktes 16-KiB-Modell mit PBI

Der 600XL übernimmt die neue XL-Architektur in einem kleineren Gehäuse und besitzt ab Werk 16 KiB RAM. Atari BASIC ist nun im ROM integriert und kann beim Start automatisch aktiv werden, wenn kein anderer Bootpfad gewählt ist.

Der Parallel Bus Interface macht Erweiterungen möglich, die tiefer in den Systembus eingreifen als normale SIO-Geräte. Atari bot mit der 1064 eine RAM-Erweiterung an, mit der der 600XL auf 64 KiB gebracht werden konnte.

Regional unterscheiden sich Videoanschlüsse und Varianten. Für eine Archivbeschreibung sollte daher die konkrete PAL-, NTSC- oder SECAM-Ausführung des Geräts dokumentiert werden.

800XL – das prägende XL-Modell

Der 800XL verbindet 64 KiB RAM, integriertes Atari BASIC, XL-Betriebssystem, SIO, zwei Controllerports und den Parallel Bus Interface. Er wurde zu einem der bekanntesten und am weitesten verbreiteten Rechner der Familie.

Gegenüber Atari 800 ist die Hardware stärker integriert und kostengünstiger aufgebaut. Softwareseitig bleibt die Plattform eng verwandt, doch das XL-ROM und veränderte Speicher-/I/O-Details können alte Programme stören, wenn diese nicht dokumentierte Interna voraussetzen.

Für viele spätere Programme wurde der 800XL faktisch zu einem Referenzmodell: 64 KiB RAM, GTIA, ANTIC, POKEY und eingebautes BASIC bilden eine robuste gemeinsame Basis.

65XE – 64 KiB im neuen XE-Gehäuse

Der 65XE überträgt die 64-KiB-Konfiguration in die kantigere XE-Gehäusefamilie. Die Softwareplattform bleibt eng mit dem 800XL verwandt, einschließlich GTIA, ANTIC, POKEY, Atari OS und integriertem BASIC.

Je nach Produktionszeit und Markt existieren Unterschiede bei Erweiterungsanschlüssen und Platinenrevisionen. Deshalb ist es sinnvoller, ein konkretes Gerät anhand seiner tatsächlichen Rückseite und Platine zu dokumentieren, statt alle 65XE pauschal identisch zu beschreiben.

Für normale 64-KiB-Software ist der 65XE im Wesentlichen Teil derselben XL/XE-Kompatibilitätsbasis.

130XE – 128 KiB auf einer 16-Bit-Adressmaschine

Der 130XE besitzt 128 KiB RAM, obwohl der 6502-basierte Prozessor nur 64 KiB gleichzeitig adressieren kann. Die zusätzlichen 64 KiB werden deshalb bankgeschaltet in ein Fenster des normalen Adressraums eingeblendet.

Besonders interessant ist, dass CPU und ANTIC je nach Konfiguration auf unterschiedliche RAM-Bänke zugreifen können. Dadurch lassen sich beispielsweise Bildschirmdaten im erweiterten Speicher halten, während die CPU in einem anderen Bereich arbeitet.

Programme müssen die Zusatzspeicherlogik ausdrücklich verwenden. Ein normales 64-KiB-Programm wird nicht automatisch schneller oder größer, nur weil es auf einem 130XE läuft.

800XE – regionale XE-Variante

Der 800XE ist im Kern eine 64-KiB-XE-Variante, die besonders in Teilen Europas und Osteuropas verbreitet war. Gehäuse und Plattform gehören zur XE-Familie, die Speicherausstattung entspricht jedoch nicht dem 128-KiB-130XE.

Bei Sammlungs- und Softwareangaben sollte 800XE nicht mit 800XL verwechselt werden: Beide besitzen typischerweise 64 KiB, stammen aber aus unterschiedlichen Gehäuse- und Produktionsgenerationen.

XE Game System – Konsole und Heimcomputer zugleich

Das XE Game System von 1987 verpackt die Atari-8-Bit-Technik in eine konsolenartige Form. Mit 64 KiB RAM und kompatibler Grundarchitektur kann es zahlreiche XL/XE-Programme nutzen; eine abnehmbare Tastatur erweitert die Konsole zum vollwertigeren Heimcomputer.

Missile Command ist im System integriert. Cartridge-Spiele lassen sich ohne klassische Computerarbeitsweise starten, während mit Tastatur und SIO-Peripherie wieder die bekannte Atari-Heimcomputerumgebung entsteht.

Das XEGS ist damit kein völlig neues Spielsystem, sondern ein spätes Repackaging derselben Architektur für einen veränderten Markt.

1400XL und 1450XLD – geplante, aber nicht regulär etablierte Modelle

Atari plante innerhalb der XL-Generation weitere Modelle mit zusätzlichen Kommunikations- und Komfortfunktionen. Besonders 1400XL und 1450XLD tauchen in der Entwicklungsgeschichte auf, erreichten aber nicht die Rolle regulärer Massenmodelle der Serie.

Solche Prototypen sind für die Technikgeschichte interessant, sollten jedoch von tatsächlich breit verkauften 600XL- und 800XL-Systemen getrennt dargestellt werden. Einzelne Prototypen und Vorseriengeräte können sich zudem in Details unterscheiden.

6502 und SALLY – gleiche ISA, Atari-spezifische Buskontrolle

Die Plattform basiert auf der MOS-6502-Befehlssatzfamilie. Frühe 400/800-Systeme verwenden 6502-Varianten; spätere Systeme nutzen Ataris angepassten Prozessor SALLY, der in älteren Unterlagen teilweise als 6502C bezeichnet wird.

SALLY ergänzt eine HALT-Steuerung, mit der ANTIC die CPU für DMA-Zugriffe kontrolliert anhalten kann. Das ist keine neue Programmiersprache oder völlig neue ISA: Für normale Software bleibt das 6502-Programmiermodell maßgeblich.

Der Systemtakt liegt bei NTSC-Systemen ungefähr bei 1,79 MHz und bei PAL-Systemen ungefähr bei 1,77 MHz. Die tatsächlich verfügbare CPU-Zeit hängt zusätzlich davon ab, wie viel Speicherbandbreite ANTIC für die aktuelle Bilddarstellung per DMA beansprucht.

6502-Registermodell und Zero Page

Der 6502 besitzt Akkumulator A, Indexregister X und Y, Stack Pointer, Program Counter und Statusregister. Die geringe Registerzahl führt zu einem anderen Programmierstil als beim Z80 des CPC.

Besonders wichtig ist die Zero Page von $0000 bis $00FF. Viele Instruktionen können dort kürzer und schneller auf Daten zugreifen. Betriebssystem und Anwendungen konkurrieren deshalb um besonders wertvolle Zero-Page-Adressen.

Der Hardware-Stack liegt im Bereich $0100 bis $01FF. Diese feste Architektur prägt Assemblerroutinen, Interruptbehandlung und Betriebssystemkonventionen.

ANTIC, GTIA und POKEY – drei Spezialchips neben der CPU

Ataris eigene technische Dokumentation betont die ungewöhnliche interne Organisation: Neben CPU, RAM, ROM und PIA arbeiten drei große Spezialbausteine. ANTIC organisiert die Bildspeicherzugriffe, CTIA/GTIA erzeugt die sichtbare Grafik- und Farblogik, POKEY übernimmt Audio und zahlreiche I/O-Funktionen.

Diese Trennung erlaubt eine bemerkenswerte Parallelität. Während der 6502 Programmcode ausführt, liest ANTIC selbstständig Displaydaten. GTIA setzt diese Daten in Pixel, Farben, Prioritäten und Player/Missile-Ausgabe um. POKEY kann gleichzeitig Ton erzeugen und serielle Kommunikation steuern.

Wer die Atari-8-Bit-Hardware verstehen will, muss deshalb weniger nach einem einzigen Hauptchip suchen als nach dem Zusammenspiel dieser Einheiten.

ANTIC – ein programmierbarer Display-Prozessor

ANTIC steht für Alpha-Numeric Television Interface Controller. Der Chip liest eine eigene kleine Programmliste im RAM, die Display List. Diese Liste sagt ANTIC zeilenweise, welche Darstellungsart verwendet, wo Bildspeicher gelesen und ob Scroll- oder Interruptfunktionen aktiviert werden sollen.

Damit ist die Bildschirmstruktur nicht starr. Text- und Grafikmodi können innerhalb eines einzigen Bildes gemischt werden. Unterschiedliche Zeilen können unterschiedliche Pixeldichten, Zeichensätze oder Speicherbereiche verwenden.

ANTIC führt diese Display List unabhängig von der CPU aus und holt die benötigten Daten per DMA. Das ist einer der Gründe, warum die Atari-Grafikarchitektur ihrer Zeit so flexibel wirkt.

Display List – ein Programm für den Bildschirmaufbau

Eine Display List besteht aus ANTIC-Instruktionen. Einige erzeugen leere Zeilen, andere wählen Text- oder Bitmapmodi. Eine LMS-Instruktion – Load Memory Scan – setzt eine neue Adresse, aus der ANTIC anschließend Bilddaten liest.

Der normale Atari-OS-Bildschirm wird aus solchen Listen erzeugt. Programme können die Liste aber verändern oder vollständig ersetzen und damit Layouts erzeugen, die mit einem einzigen BASIC-GRAPHICS-Befehl nicht erreichbar wären.

Diese programmierbare Rasterstruktur ist konzeptionell näher an einer kleinen Video-DMA-Sprache als an einem simplen linearen Framebuffer.

Vereinfachtes Prinzip:

Display List im RAM
    ↓
Blank-Zeilen / Moduswahl / LMS
    ↓
ANTIC liest Bildschirmdaten per DMA
    ↓
GTIA interpretiert Playfield + Player/Missile
    ↓
Videoausgabe

CPU und ANTIC teilen sich dabei den RAM-Zugriff.

DMA – ANTIC nimmt sich Speicherzyklen

ANTIC benötigt Speicherbandbreite für Display List, Zeichensatz-, Bildschirm- und Player/Missile-Daten. Dafür führt der Chip DMA-Zugriffe aus und hält die CPU bei Bedarf kurz an.

Ein aufwendiger Bildschirm kann deshalb mehr CPU-Zeit kosten als eine einfachere Darstellung. Programmierer können diesen Zusammenhang bewusst ausnutzen: weniger Display-DMA schafft mehr Rechenzeit, zusätzliche Grafikfeatures kosten Speicherzyklen.

Die nominelle CPU-Taktfrequenz allein beschreibt daher nicht die reale Rechenleistung eines Atari-Programms.

ANTIC-Modi – Text und Bitmap zeilenweise kombinieren

ANTIC kennt mehrere Text- und Bitmapmodi mit unterschiedlichen horizontalen Auflösungen und Farbbitbreiten. In Bitmapdarstellungen sind grob 40, 80, 160 oder 320 Bildpunkte pro Zeile möglich, abhängig vom Modus und der Interpretation durch GTIA.

Textmodi lesen Zeichencodes aus dem Bildspeicher und Glyphendaten aus einem Zeichensatz. Dadurch benötigt ein Textbild wesentlich weniger RAM als ein vollwertiger Bitmapbildschirm.

Weil die Display List den Modus zeilenweise wählt, kann eine Anwendung beispielsweise oben hochauflösenden Text, in der Mitte farbige Grafik und unten wieder Text darstellen, ohne mehrere getrennte Videosysteme zu benötigen.

GTIA – Farbe, Prioritäten und sichtbare Pixel

GTIA übernimmt die von ANTIC kommenden Playfield-Daten und kombiniert sie mit Player/Missile-Grafik. Farbregister bestimmen, welche Palette sichtbar wird, Prioritätsregister steuern, ob Spielfiguren vor oder hinter bestimmten Playfield-Elementen liegen.

GTIA verarbeitet außerdem Kollisionsinformationen. Software kann feststellen, ob Player, Missiles oder Playfieldbereiche einander berührt haben. Damit werden viele Spielmechaniken hardwareseitig unterstützt.

Die PAL- und NTSC-Farbdarstellung unterscheidet sich systembedingt; SECAM-Varianten besitzen nochmals eigene Einschränkungen. Eine konkrete Farbpalette sollte deshalb nicht ohne Video-Norm angegeben werden.

GTIA-Spezialmodi 9, 10 und 11

Mit GTIA kamen zusätzliche Interpretationen hochauflösender ANTIC-Daten hinzu. GRAPHICS 9 kann 16 Helligkeitsstufen eines Grundfarbtons darstellen, GRAPHICS 11 16 Farbtöne mit gemeinsamer Helligkeit. GRAPHICS 10 verwendet mehrere frei wählbare Farbregister gleichzeitig.

Diese Modi arbeiten mit geringerer horizontaler Detailauflösung als der feinste monochrome ANTIC-Modus, ermöglichen dafür auffällige Farbflächen und Verläufe.

Rasterinterrupts und Registeränderungen können die sichtbare Farbzahl über einen ganzen Frame nochmals deutlich erhöhen, ohne dass dadurch ein normaler statischer Modus plötzlich 256 frei wählbare Farben pro Pixel hätte.

Die berühmte Atari-Farbpalette richtig verstehen

GTIA wird häufig mit „256 Farben“ beschrieben. Gemeint ist die Kombination aus 16 Farbtönen und 16 Helligkeitsstufen im NTSC/PAL-GTIA-Farbmodell. Das bedeutet nicht, dass jeder normale Bildschirmmodus 256 Farben gleichzeitig darstellt.

Wie viele Farben gleichzeitig sichtbar sind, hängt vom ANTIC-/GTIA-Modus, den Farbregistern und möglichen Rasteränderungen ab. Der klassische Vorteil liegt in der großen Auswahl aus Farbton-Helligkeits-Kombinationen und der Möglichkeit, Register während des Bildaufbaus umzuschalten.

Frühe CTIA-Systeme besitzen einen kleineren Farbumfang und keine drei GTIA-Spezialmodi.

NTSC-Artifacting – Farbe aus hochauflösenden Bitmustern

Bei NTSC-Geräten können hochauflösende Schwarzweiß-Pixelmuster durch die analoge Farbcodierung als zusätzliche Farben erscheinen. Programme und Spiele nutzten dieses Color Artifacting bewusst, obwohl im Speicher formal nur ein hochauflösendes Bitmuster liegt.

Welche Farben entstehen, hängt von Phase, Gerät und Videoausgabe ab. PAL-Systeme zeigen dieses Verhalten anders und häufig wesentlich schwächer beziehungsweise mit anderen Effekten.

Deshalb können manche amerikanischen Spiele auf PAL-Rechnern farblich anders wirken, obwohl dieselben Bilddaten ausgegeben werden.

Player/Missile Graphics – Ataris Hardware-Sprites

Die Atari-Terminologie nennt bewegliche Hardwareobjekte Player und Missiles. Vier Player und vier schmale Missiles können unabhängig vom normalen Playfield dargestellt werden. Die vier Missiles lassen sich außerdem funktional zu einem zusätzlichen breiteren Objekt zusammenfassen.

Die Horizontalposition wird über Hardware-Register festgelegt. Vertikale Formen liegen als Bitmuster im RAM und werden von ANTIC per DMA geholt. Dadurch sind Objekte vertikal flexibel, aber anders organisiert als die vollständig registerbasierten Sprites mancher anderer Systeme.

Breite, Priorität und Farbe lassen sich steuern; Kollisionen zwischen Objekten und Playfield werden hardwareseitig erfasst. Für Spiele reduziert das den Aufwand für Figuren, Schüsse und Kollisionsprüfungen erheblich.

Player/Missile-Speicher und DMA

Player/Missile-Grafik benötigt einen im RAM ausgerichteten Speicherbereich. Je nach Auflösungsmodus liest ANTIC die Player- und Missile-Bitdaten in definierten Abständen.

Ein gesetztes Bit bedeutet, dass an der entsprechenden vertikalen Position ein Teil des Objekts sichtbar wird. Die horizontale Lage kommt separat aus Positionsregistern. Dadurch kann dieselbe Bitform sehr schnell nach links oder rechts bewegt werden, ohne die Formdaten zu kopieren.

Für viele Spiele ist genau diese Trennung zwischen vertikalem Speicherbild und horizontalem Hardwarepositionieren ein charakteristisches Atari-Programmiermuster.

Hardware-Kollisionsregister

GTIA führt Kollisionsinformationen zwischen Playern, Missiles und Playfield. Software kann diese Register auslesen und erkennen, ob sich definierte Objektklassen während der Bildausgabe überlappt haben.

Die Register melden Hardwareüberdeckung, nicht automatisch eine vollständige Spielregel. Ein Programm muss selbst entscheiden, ob eine Kollision einen Treffer, Punktgewinn oder gar nichts bedeutet.

Kollisionsregister können zurückgesetzt werden, damit anschließend ein neuer Beobachtungszeitraum beginnt.

Priorität – wer liegt vor wem?

GTIA kann bestimmen, ob Player/Missile-Objekte vor oder hinter bestimmten Playfield-Farben erscheinen. Diese Prioritätslogik ermöglicht komplexere Szenen, obwohl alle Elemente im selben Videosignal zusammengeführt werden.

Ein Spieler kann beispielsweise hinter einem Vordergrundelement verschwinden, ohne dass dessen Grafik in einen vollständigen Software-Framebuffer eingerechnet werden muss.

Zusätzliche GTIA-Optionen erlauben, Playerfarben und Playfielddarstellung auf spezielle Weise zu kombinieren.

Display List Interrupts – Code mitten im Bild

Eine ANTIC-Instruktion kann einen Display List Interrupt auslösen. Die CPU springt dann während des laufenden Bildaufbaus in eine Interrupt-Routine. Dort können Farbregister, Playerpositionen, Zeichensatzbasis oder andere Parameter rechtzeitig für nachfolgende Rasterzeilen geändert werden.

So entstehen Farbbänder, mehrere Zeichensätze in einem Frame, Statusbereiche und viele Demoscene-Effekte. Weil nur wenige CPU-Zyklen zwischen Rasterpositionen zur Verfügung stehen, ist exaktes Timing wichtig.

Ein DLI ist damit die programmierbare Verbindung zwischen ANTIC-Raster und 6502-Code.

Vertical Blank Interrupt – regelmäßige Systemarbeit pro Bild

Während der vertikalen Austastphase erzeugt das System einen Vertical Blank Interrupt. Das Atari-Betriebssystem nutzt diese Zeit unter anderem für wiederkehrende Aufgaben und die Aktualisierung bestimmter Shadow-Register.

Programme können eigene VBI-Routinen installieren. Damit lassen sich Animation, Timer, Soundsteuerung oder Eingabe regelmäßig ausführen, ohne im Hauptprogramm ständig die Bildposition abzufragen.

Zwischen Immediate und Deferred VBI beziehungsweise verschiedenen Systemphasen bestehen technische Unterschiede, die für hardwarenahe Programmierung relevant sind.

Hardwareunterstütztes Fine Scrolling

ANTIC unterstützt horizontales und vertikales Feinscrolling. Display-List-Befehle markieren scrollbare Bereiche; HSCROL- und VSCROL-Register verschieben die Darstellung in kleineren Schritten als eine vollständige Zeichen- oder Speicherzeile.

Für kontinuierliches Scrolling kombiniert Software feine Hardwareverschiebung mit gelegentlichem Nachsetzen der groben Speicheradresse. Dadurch müssen nicht bei jedem Pixel alle Bildschirmdaten verschoben werden.

Seitwärts- und Vertikalscroller gehören deshalb zu den klassischen Stärken der Atari-8-Bit-Grafik.

Umdefinierbare Zeichensätze

ANTIC-Textmodi lesen Glyphen aus einem Zeichensatz im RAM oder ROM. Über die Zeichensatzbasis kann Software auf eigene Zeichenformen umschalten.

Ein Spiel kann dadurch Landschaftsteile, Symbole oder Animationen als Zeichen statt als vollständige Bitmap speichern. Das spart RAM und erlaubt schnelle Änderungen durch Austausch einzelner Glyphen.

Display List Interrupts können innerhalb eines Frames sogar die Zeichensatzbasis wechseln, sodass verschiedene Bildschirmbereiche unterschiedliche Zeichensätze verwenden.

POKEY – Soundchip und viel mehr als Sound

POKEY steht für Potentiometer and Keyboard Integrated Circuit. Der Chip erzeugt vier Audiokanäle, liest Tastatur und analoge Potentiometereingänge, stellt Timer und Zufallszahlfunktionen bereit und bildet einen wesentlichen Teil der seriellen SIO-Hardware.

Damit ist POKEY stärker als ein reiner PSG mit dem gesamten Rechnerbetrieb verflochten. Sound, Eingabe, serielle Peripherie und Zeitgeber teilen sich denselben Spezialbaustein.

Diese Mehrfachrolle ist einer der Gründe, warum POKEY-Registerkenntnis sowohl für Spieleprogrammierer als auch für Systemsoftware wichtig ist.

Vier POKEY-Kanäle, Teiler und Verzerrungsmodi

POKEY besitzt vier Audiokanäle mit programmierbaren Frequenzteilern und Lautstärken. Verschiedene Polynomial- beziehungsweise Distortion-Einstellungen erzeugen reine Töne, Rauschen und charakteristische digitale Klangfarben.

Kanalpaare können für höher aufgelöste Frequenzteiler gekoppelt werden. Dadurch steigt die Tonhöhenpräzision auf Kosten unabhängiger Stimmen.

Die resultierende Klangästhetik unterscheidet sich deutlich von SID und AY. Sie ist besonders durch harte digitale Teilungsverhältnisse, Rauschpolynome und schnelle Registermodulation geprägt.

Digitale Samples über Lautstärkeregister

POKEY kann über schnelle Änderungen der Lautstärkeregister auch digitalisierte Audiodaten wiedergeben. Dabei wird der Chip gewissermaßen als einfacher Digital-Analog-Wandler missbraucht.

Diese Technik benötigt erhebliche CPU-Zeit und Speicherbandbreite, ermöglicht aber Sprach- und Sampleeffekte, die über normale Tonkanäle hinausgehen.

Demos und Spiele kombinierten solche Verfahren später mit normaler POKEY-Klangsynthese.

Stereo-POKEY als spätere Erweiterung

Die Serien-Heimcomputer besitzen normalerweise einen POKEY und damit vier Hardware-Audiokanäle. In der Enthusiasten- und Erweiterungsszene entstanden später Umbauten mit einem zweiten POKEY.

Solche Stereo-POKEY-Konfigurationen liefern zusätzliche Kanäle und getrennte Stereoseiten, gehören aber nicht zur unveränderten Atari-Standardhardware.

Software muss eine solche Erweiterung ausdrücklich erkennen oder voraussetzen.

PIA – parallele Ein-/Ausgabe und Systemsteuerung

Der Peripheral Interface Adapter übernimmt parallele Steueraufgaben. Dazu gehören Funktionen rund um Controllerports und – in späteren Systemen besonders wichtig – Speicher- und Betriebssystemumschaltungen über Port-B-Leitungen.

Beim 130XE hängen Teile des erweiterten Speicherbankings an dieser Steuerlogik. Das zeigt, wie ein ursprünglich allgemeiner I/O-Baustein in der weiterentwickelten Plattform zusätzliche Systemaufgaben erhält.

Der 64-KiB-Adressraum des 6502

Der 6502 sieht Adressen von $0000 bis $FFFF. RAM, ROM, Hardware-Register und Cartridge-Bereiche teilen sich diesen Raum. Welche Bereiche tatsächlich RAM liefern, hängt vom Modell und von Speichersteuerbits ab.

Bei XL/XE-Systemen liegt Atari BASIC typischerweise im Bereich $A000–$BFFF, wenn es eingeschaltet ist. Hardware-Register befinden sich im $D000-Bereich, das Betriebssystem-ROM belegt den oberen Adressraum. Durch Abschalten von ROMs kann darunterliegendes RAM sichtbar werden.

Der logische 64-KiB-Raum ist deshalb nicht mit „64 KiB frei für BASIC“ gleichzusetzen. Betriebssystem, Bildschirm, Variablen und ROM-Einblendungen reduzieren den unmittelbar nutzbaren Bereich.

Vereinfachte XL/XE-Sicht:

$0000  Zero Page / RAM
$0100  Hardware-Stack / RAM
...
$A000  BASIC-ROM, wenn aktiviert
$C000  RAM bzw. systemabhängige Bereiche
$D000  Hardware-I/O und Cartridge-/ROM-Fenster
$D800  OS-ROM-Bereich
$FFFF  Ende des 16-Bit-Adressraums

ROMs können teilweise ausgeblendet werden; darunter liegt RAM.

Shadow-Register – RAM-Kopien von Hardwarezuständen

Das Atari OS verwaltet für zahlreiche Hardware-Register sogenannte Shadow-Register im RAM. Anwendungen ändern einen RAM-Wert, und das Betriebssystem überträgt ihn während eines geeigneten Systemzeitpunkts in das echte Hardware-Register.

Das vereinfacht BASIC- und Anwendungsprogrammierung, weil der direkte Rasterzeitpunkt nicht immer selbst kontrolliert werden muss. Für DLI- oder zeitkritischen Code ist dagegen oft der direkte Zugriff auf die Hardwareadresse erforderlich.

Die Unterscheidung zwischen Shadow und echter Registeradresse gehört zu den ersten wichtigen Lektionen beim Atari-Assemblerprogrammieren.

Atari OS – das Betriebssystem steckt im ROM

Atari 400/800 besitzen ein 10-KiB-Betriebssystem-ROM; XL/XE-Systeme verwenden größere, überarbeitete ROM-Versionen. Das OS stellt Bildschirmeditor, Tastatur, Drucker-, Kassetten- und SIO-Funktionen sowie zentrale I/O-Abstraktionen bereit.

Dieses Atari OS ist nicht mit Atari DOS gleichzusetzen. Der Rechner kann ohne Diskettenlaufwerk und ohne DOS starten, weil wesentliche Systemfunktionen bereits im ROM vorhanden sind.

Programme, die dokumentierte OS-Vektoren und CIO-Schnittstellen nutzen, sind tendenziell robuster gegenüber ROM-Revisionen als Programme, die interne ROM-Adressen direkt anspringen.

CIO – einheitliche Geräte-I/O über Handler

Central Input/Output, kurz CIO, ist eine zentrale Abstraktion des Atari OS. Geräte werden über logische Namen und Handler angesprochen, etwa Bildschirmeditor, Tastatur, Drucker, Kassette oder Diskettenhandler.

Eine Anwendung kann dadurch Ein- und Ausgabe anstoßen, ohne jedes Hardwareprotokoll selbst zu implementieren. Neue Handler können zusätzliche Geräte in dasselbe Modell integrieren.

Diese Architektur ist für einen Heimcomputer erstaunlich systematisch und erklärt, warum viele Programme Standard-I/O relativ sauber nutzen konnten.

IOCBs – Kontrollblöcke für Ein-/Ausgabe

CIO verwaltet I/O Control Blocks im RAM. In ihnen stehen unter anderem Befehl, Gerätenummer, Pufferadresse, Länge und Zusatzparameter.

Ein Programm bereitet einen IOCB vor und ruft CIO auf. Das Betriebssystem leitet die Operation anschließend an den passenden Device Handler weiter.

Dieses tabellarische Modell verbindet BASIC, Assembler und DOS-Gerätezugriff mit derselben Systemarchitektur.

SIO – Ataris serielle Peripheriekette

Serial Input/Output, kurz SIO, ist eine der elegantesten Eigenschaften der Plattform. Diskettenlaufwerke, Drucker, Kassettenstationen, Modems und weitere Geräte können über eine serielle, durchschleifbare Verbindung an den Rechner gekoppelt werden.

Geräte besitzen Kennungen und reagieren auf Kommandoframes. Viele Peripheriegeräte enthalten eigene Controllerlogik und Firmware. Der Computer muss deshalb nicht jeden Schrittmotorimpuls eines Diskettenlaufwerks selbst erzeugen.

Das SIO-Konzept macht die Peripherie für den Benutzer vergleichsweise modular: Kabel werden verkettet, Geräte erhalten Nummern, und das Betriebssystem spricht sie über ein gemeinsames Protokoll an.

Daisy Chain statt einzelner Spezialkabel

Typische Atari-SIO-Geräte besitzen Ein- und Ausgangsbuchsen, sodass mehrere Peripheriegeräte hintereinander verkettet werden können. Das reduziert die Zahl unterschiedlicher Anschlüsse am Rechner.

Ein Diskettenlaufwerk kann beispielsweise vor einem Drucker oder Modem in der Kette liegen. Die logische Geräteauswahl erfolgt nicht durch eine exklusive physische Buchse, sondern über das Protokoll und die Gerätenummer.

Für historische Erhaltung gehören funktionierende SIO-Kabel deshalb ebenso zur Plattform wie Rechner und Laufwerk.

Standard-SIO und spätere High-Speed-Verfahren

Das originale SIO arbeitet mit einer für die Zeit brauchbaren, aber aus späterer Sicht langsamen seriellen Datenrate. Besonders Diskettenzugriffe wirken dadurch träger als bei parallel angebundenen Laufwerken.

Spätere DOS-Versionen, Laufwerks-ROMs und Szeneerweiterungen entwickelten High-Speed-SIO-Verfahren. Sie erhöhen den Durchsatz, bleiben aber Erweiterungen über den ursprünglichen gemeinsamen Nenner hinaus.

Für Archivkompatibilität ist deshalb wichtig zu unterscheiden, ob eine Diskette normales SIO oder einen speziellen Beschleuniger voraussetzt.

Atari 410 Program Recorder – Kassette als Einstiegsspeicher

Der Atari 410 Program Recorder speichert Daten auf Compact Cassette. Für frühe Atari-400/800-Nutzer war dies der preisgünstigste Massenspeicher, bevor ein Diskettenlaufwerk hinzukam.

Kassettenzugriff ist sequenziell und deutlich langsamer als Diskette. Das Atari-System kann jedoch über SIO Motorsteuerung und Datenübertragung koordinieren.

Spätere 1010-Recorder führen dieselbe Medienwelt in der XL-Ära fort. Kassettendateien werden heute häufig in CAS-Images archiviert.

Atari 810 – das klassische 90-KiB-Laufwerk

Das Atari 810 ist das frühe 5,25-Zoll-Diskettenlaufwerk der Plattform. Im verbreiteten Single-Density-Format stehen ungefähr 90 KiB pro Diskettenseite zur Verfügung.

Das Laufwerk ist ein intelligentes SIO-Gerät mit eigener Steuerung. Der Rechner übermittelt Sektor- und Statuskommandos, während das Laufwerk die eigentliche Mechanik kontrolliert.

Mit Diskette wird DOS relevant: Das ROM-OS liefert SIO und CIO, aber Dateiverzeichnis, Dateinamen und freie Sektoren werden durch das von Diskette geladene DOS verwaltet.

Atari 1050 – Single und Enhanced Density

Das Atari 1050 wurde zum typischen Laufwerk der XL-Generation. Neben dem bekannten 90-KiB-Single-Density-Format kann es Ataris Enhanced-Density-Format mit ungefähr 130 KiB pro Seite verwenden.

Enhanced Density ist nicht dasselbe wie die gewöhnliche 180-KiB-Double-Density vieler Drittanbieter-Laufwerke. Die unterschiedlichen Formate unterscheiden sich bei Sektorgröße und Sektoranzahl.

Gerade deshalb sollte bei historischen Diskimages immer Format und verwendetes DOS dokumentiert werden.

XF551 – spätes Laufwerk mit doppelseitiger Nutzung

Das XF551 gehört zur späten XE-Ära und kann 5,25-Zoll-Disketten doppelseitig sowie in höherer Dichte verwenden. Damit steigt die Kapazität gegenüber 810 und 1050 deutlich.

Die genaue Kompatibilität hängt von DOS und Format ab. Eine Diskette, die physisch in das Laufwerk passt, ist deshalb noch nicht automatisch für jedes Atari-DOS lesbar.

Für Archive ist die logische Sektorstruktur wichtiger als eine pauschale Kapazitätszahl.

Atari DOS – von Diskette geladen, nicht Teil des OS-ROM

Atari DOS ergänzt das ROM-Betriebssystem um Dateisystem, Diskettenverzeichnis, Befehlsmenü und Disk Device Handler. Ohne DOS kann das ROM-OS trotzdem SIO-Kommandos ausführen und bootfähige Sektoren laden.

DOS 1, DOS 2.0S, DOS 2.5, DOS 3 und DOS XE markieren unterschiedliche offizielle Entwicklungsstufen. Daneben entstanden verbreitete Drittanbieter-DOS wie MyDOS und SpartaDOS.

Die Dateisysteme sind nicht untereinander vollständig identisch. Besonders Atari DOS 3 verwendet ein anderes Format als DOS 2.x und ist daher kein bloßes Menüupdate.

DOS 2.0S – prägendes Standardformat

DOS 2.0S wurde zu einem der wichtigsten gemeinsamen Nenner der 8-Bit-Diskettenwelt. Es verwaltet Single-Density-Disketten mit Verzeichnis, VTOC und verketteten Dateisektoren.

Dateinamen folgen einem 8.3-artigen Schema ohne moderne Unterverzeichnisse. Ein Verzeichniseintrag verweist auf den ersten Sektor und enthält Status- und Größeninformationen.

Viele spätere Tools und Emulatoren orientieren sich deshalb an DOS-2.x-kompatiblen Images.

DOS 2.5 – Enhanced Density für die 1050

DOS 2.5 erweitert die vertraute DOS-2.x-Bedienung um Unterstützung für das 1050-Enhanced-Density-Format. Damit lässt sich mehr Kapazität nutzen, ohne vollständig auf das umstrittenere DOS-3-Dateisystem zu wechseln.

Für 130XE-Nutzer enthält DOS 2.5 zudem Hilfsprogramme, die erweiterten Speicher als RAM-Disk verwenden können.

Das zeigt, wie DOS nicht nur Dateiverwaltung, sondern auch plattformspezifische Erweiterungsfunktionen bereitstellt.

SpartaDOS – eher kommandozeilenorientierte Systemwelt

SpartaDOS und spätere Varianten gehen über das einfache Atari-DOS-Menü hinaus. Unterverzeichnisse, Kommandozeile, Zeit-/Datumsfunktionen und leistungsfähigere Dateiverwaltung orientieren sich stärker an größeren Betriebssystemen.

Damit wird der Atari zu einer deutlich systemorientierteren Arbeitsumgebung. Gleichzeitig steigt die Abhängigkeit von spezifischen DOS-Funktionen und gegebenenfalls erweiterten Laufwerken.

Für Archivierung muss deshalb neben dem eigentlichen Programm auch die benötigte DOS-Umgebung bekannt sein.

ATR – das verbreitete Diskimage der Emulation

ATR ist heute eines der wichtigsten Imageformate für Atari-Disketten. Ein ATR enthält einen kleinen Header und anschließend die logischen Sektordaten der Diskette.

Das Format eignet sich sehr gut für normale DOS- und Bootdisketten. Extrem ungewöhnliche Kopierschutz- oder Timinginformationen einer physischen Diskette lassen sich damit jedoch nicht in jedem Fall vollständig abbilden.

Eine seriöse Archivierung notiert daher, ob ein Image ein logisches Sektorabbild oder eine tiefergehende physische Erfassung darstellt.

XFD und sektorbasierte Rohimages

XFD-Dateien speichern Sektordaten ohne denselben ATR-Header. Dadurch ist das Format einfach, aber Metainformationen über Geometrie müssen aus Dateigröße oder Kontext abgeleitet werden.

Für den praktischen Austausch ist ATR häufig bequemer, XFD bleibt jedoch Teil der historischen Emulator- und Toollandschaft.

CAS – Kassetteninhalte digital bewahren

CAS-Dateien repräsentieren Atari-Kassettendaten für Emulatoren und Archivwerkzeuge. Sie bewahren logische Datenblöcke beziehungsweise Timinginformation abhängig von Format und Erzeugungsweg.

Wie bei Disketten gilt: Ein einfaches Programmdump ist nicht automatisch dasselbe wie eine vollständige Erfassung des ursprünglichen analogen Kassettenbands.

Für seltene Originale sollten Rohaufnahme und daraus gewonnene CAS-Datei getrennt aufbewahrt werden, wenn eine möglichst vollständige Dokumentation gewünscht ist.

Cartridges – ROM sofort im Adressraum

Software-Cartridges machen Programme ohne Ladezeit verfügbar. Atari 400 besitzt einen Modulschacht, Atari 800 zwei. Spätere Modelle verwenden einen einzelnen kompatiblen Cartridgebereich.

Einfache Module blenden ROM in definierte Speicherbereiche ein. Größere spätere Module verwenden Bankswitching, um mehr ROM unterzubringen als gleichzeitig in das normale Cartridgefenster passt.

Für digitale Archivierung werden ROM- beziehungsweise CAR-Images verwendet; die genaue Mapper- beziehungsweise Bankswitching-Variante muss erhalten bleiben.

Startreihenfolge – ROM, Cartridge, BASIC und Diskette

Nach Reset initialisiert das Atari OS Hardware, RAM-Vektoren und Geräte. Abhängig von Modell, gedrückten Konsolentasten und eingelegter Cartridge entscheidet sich anschließend, ob BASIC, ein Modul oder ein bootfähiges SIO-Gerät die Kontrolle erhält.

Diskettenboot bedeutet, dass das OS Bootsektoren über SIO lädt und ausführt. Das eigentliche DOS kann sich daraus weiter initialisieren.

Diese Schichtung erklärt, warum defekte oder fehlende DOS-Dateien nicht dasselbe sind wie ein defektes Betriebssystem-ROM.

Atari BASIC – Cartridge zuerst, später fest eingebaut

Bei Atari 400 und 800 wurde Atari BASIC typischerweise als 8-KiB-Cartridge genutzt. 600XL, 800XL und XE-Systeme integrieren BASIC direkt ins ROM. Der 1200XL gehört noch nicht zu dieser eingebauten BASIC-Generation.

Atari BASIC verwendet tokenisierte Programmzeilen und besitzt eigene Besonderheiten bei Zeichenketten, Arrays und Speicherverwaltung. Die Sprache ist eng mit dem Atari-OS und dessen Grafik-/I/O-Funktionen verzahnt.

Mit BASIC-Befehlen lassen sich Grafikmodi, Farben, Joysticks, Sound und Dateien nutzen, für maximale Grafikleistung bleibt Assembler entscheidend.

Warum 64 KiB nicht 64 KiB BASIC-Speicher bedeuten

Auf einem 64-KiB-Rechner sind OS-ROM, BASIC-ROM, Hardwarefenster, Bildschirm, Betriebssystemvariablen und Programmdaten gleichzeitig zu berücksichtigen. Deshalb meldet BASIC deutlich weniger freien Programmspeicher als die physisch eingebauten 65536 Bytes.

Durch Abschalten von BASIC oder Betriebssystem-ROM können Assemblerprogramme zusätzliche RAM-Bereiche nutzen, müssen dann aber selbst mehr Systemfunktionen übernehmen.

Der nutzbare Speicher ist somit ein Ergebnis der aktuellen Memory Map, nicht nur der RAM-Chipzahl.

Assembler – direkter Zugriff auf die Spezialchips

6502-Assembler ist die zentrale Sprache für Spiele, Demos, Treiber und zeitkritische Routinen. Atari veröffentlichte technische Referenzunterlagen und mit De Re Atari sogar eine ausführliche Programmierdarstellung der Spezialchips.

Assemblerprogramme können Display Lists selbst erzeugen, DLI/VBI-Routinen installieren, POKEY direkt steuern und SIO auf niedriger Ebene ansprechen.

Die geringe Registerzahl des 6502 verlangt sorgfältige Zero-Page-Nutzung und Speicherorganisation, während die Spezialchips einen großen Teil der parallelen Arbeit übernehmen.

Weitere Programmiersprachen

Neben BASIC und Assembler existierten zahlreiche Sprachen und Entwicklungsumgebungen. Atari Logo, PILOT, Forth, Pascal-Varianten, C-Systeme und verschiedene Compiler erweiterten die Plattform.

Besonders bekannt wurde Action!, eine schnelle auf Atari zugeschnittene Compilersprache, die sich für systemnahe Programme eignete. MAC/65 wurde zu einem verbreiteten Assembler.

Die allgemeine Entwicklung solcher Sprachen wird auf programmierung-und-skripting.htm eingeordnet.

Atari Program Exchange – Softwarevertrieb und Entwicklerkultur

Atari Program Exchange, APX, veröffentlichte Programme und Dokumentationen von Atari-Mitarbeitern und externen Entwicklern. Damit entstand neben kommerziellen Softwarehäusern ein eigener Kanal für Werkzeuge, Spiele und Lernsoftware.

De Re Atari wurde über APX verbreitet und zählt zu den wichtigsten zeitgenössischen technischen Publikationen zur Plattform.

APX zeigt, dass Atari nicht nur Hardware verkaufte, sondern aktiv ein Entwicklerökosystem rund um die Spezialchips fördern wollte.

Spiele – Hardwarefähigkeiten wurden früh sichtbar

Star Raiders demonstrierte früh, wie stark ein Heimcomputer wirken konnte, wenn Grafik, Sound und Eingabe als Gesamtsystem programmiert werden. Später folgten zahlreiche Titel, die ANTIC-Scrolling, Player/Missile Graphics und POKEY intensiv nutzen.

M.U.L.E., Archon, Ballblazer, Rescue on Fractalus!, The Eidolon, Dropzone und weitere bekannte Programme zeigen unterschiedliche Stärken der Plattform. Manche wurden auf Atari entwickelt und anschließend auf andere Systeme portiert.

Spiele sind deshalb nicht nur Unterhaltung, sondern oft praktische Dokumente der Hardwaremöglichkeiten und Optimierungstechniken.

Vier Controllerports – frühes lokales Mehrspielerkonzept

Atari 400 und 800 besitzen vier Controllerports. Software kann damit vier Joysticks gleichzeitig abfragen, ohne Mehrfachadapter.

Spätere XL/XE-Systeme reduzierten die Zahl auf zwei Ports. Mehrspielertitel, die ausdrücklich vier physische Anschlüsse nutzen, gehören deshalb zu den Besonderheiten der Ursprungsmodelle.

Die vier Ports zeigen, wie stark Atari die Architektur aus einer Spiel- und Controllertradition heraus konzipierte.

Joystick, Paddle, Trackball und weitere Controller

Die 9-poligen Controllerports unterstützen digitale Joysticks, Trigger und analoge Potentiometereingänge. Dadurch lassen sich auch Paddle-Controller auswerten.

POKEY misst Potentiometerwerte, während digitale Richtungen und Trigger über die übrige I/O-Logik verarbeitet werden. Light-Pen- und weitere Spezialsignale sind ebenfalls Teil der Plattformmöglichkeiten.

Die Steckerform erinnert an andere Heimcomputer, die elektrische und logische Nutzung sollte jedoch immer systemspezifisch geprüft werden.

Tastaturen von Folie bis XE

Die Tastaturentwicklung spiegelt die Modellstrategie. Der 400 besitzt eine Folientastatur, der 800 eine hochwertige Volltastatur. 1200XL führt zusätzliche Funktionstasten ein; 600XL/800XL und XE verwenden wiederum andere Gehäuse- und Tastaturkonstruktionen.

POKEY übernimmt einen wesentlichen Teil der Tastaturabfrage. Das OS verarbeitet Tastencodes, Modifier und Wiederholfunktionen und stellt sie dem Editor- beziehungsweise Tastaturhandler bereit.

Bei erhaltenen Geräten sind Tastaturmembranen, Folien und Kontaktmatten häufig ein eigener Restaurierungsbereich.

START, SELECT und OPTION

Die drei Konsolentasten START, SELECT und OPTION sind fest in die Plattformkultur eingebaut. Spiele nutzen sie für Menüs, Schwierigkeitsgrade und Neustartfunktionen.

OPTION besitzt auf XL/XE-Systemen zusätzlich Bedeutung beim Booten, weil damit das eingebaute BASIC deaktiviert werden kann. Das ist wichtig für Software, die den BASIC-ROM-Bereich als RAM benötigt.

Damit ist eine scheinbar einfache Konsolentaste Teil der Speicher- und Bootarchitektur.

PBI – Parallel Bus Interface der XL-Modelle

600XL und 800XL besitzen den Parallel Bus Interface. Er führt Adress-, Daten- und Steuersignale nach außen und ermöglicht Erweiterungen mit wesentlich direkterem Systemzugriff als SIO.

Ataris 1064-RAM-Erweiterung für den 600XL nutzt diesen Erweiterungskontext. Auch komplexere Festplatten-, Speicher- und Interface-Lösungen wurden für PBI beziehungsweise kompatible Erweiterungen entwickelt.

PBI ist dadurch eher ein Systembuszugang als eine normale serielle Peripherieschnittstelle.

ECI – kompakterer Erweiterungsbus der XE-Generation

Beim 130XE ersetzt der Enhanced Cartridge Interface zusammen mit dem Cartridgeanschluss viele Funktionen des früheren PBI in kompakterer Form.

Erweiterungen können dadurch direkten Zugriff auf zusätzliche Systemsignale erhalten, ohne einen großen PBI-Stecker zu benötigen.

Die genaue Verfügbarkeit variiert bei einzelnen XE-Modellen und Marktversionen; ein konkretes Gerät sollte daher physisch geprüft werden.

Speichererweiterungen weit über 128 KiB

Nach dem 130XE entstanden zahlreiche Drittanbieter- und Szeneerweiterungen mit 256, 320, 576 KiB oder noch größeren RAM-Ausstattungen. Sie verwenden Bankumschaltungen, weil der 6502 weiterhin nur 64 KiB gleichzeitig adressiert.

Verschiedene Standards ordnen Bankbits unterschiedlich zu. Software muss daher erkennen, welche Erweiterungsart vorhanden ist.

Großer Zusatzspeicher wird für RAM-Disks, Demos, Spiele, Grafik und moderne Szeneprogramme genutzt, gehört aber nicht zum kleinsten gemeinsamen Originalstandard.

FREDDIE – Speicherverwaltung in späteren Rechnern

Mit der stärker integrierten XL/XE-Hardware übernimmt FREDDIE Aufgaben der DRAM-Adressierung und Speichersteuerung. Dadurch reduziert Atari gegenüber der ursprünglichen 400/800-Logik die Zahl diskreter Bauteile.

Beim 130XE wird das Zusammenspiel von FREDDIE, PIA-Steuerung und erweitertem RAM besonders wichtig. Die Software sieht weiterhin denselben 6502-Adressraum, während Hardware zusätzliche physische RAM-Bänke auswählt.

Solche Integrationsbausteine ändern die Systemökonomie stärker als die sichtbare Programmierschnittstelle.

PAL und NTSC – mehr als nur andere Bildfrequenz

PAL- und NTSC-Geräte unterscheiden sich bei Mastertakt, Bildfrequenz, Farbträger und damit auch bei CPU-Geschwindigkeit. NTSC-Systeme laufen ungefähr mit 1,79 MHz CPU-Takt, PAL-Systeme ungefähr mit 1,77 MHz.

PAL bietet rund 50 Bildwechsel pro Sekunde und mehr Rasterzeilen; NTSC ungefähr 60. Spieltempo, Musikroutinen und Rastereffekte können deshalb ohne Anpassung unterschiedlich schnell oder an anderer Bildposition laufen.

Viele europäische Programme nutzen zusätzliche PAL-Rasterzeit für Effekte, während NTSC-Software gelegentlich von der höheren Bildrate profitiert.

SECAM und FGTIA

Für den französischen SECAM-Markt existieren spezielle Videoausführungen. FGTIA passt die Farberzeugung an diese Fernsehnorm an und besitzt gegenüber normalem GTIA eine eingeschränktere Farb-/Helligkeitsdarstellung.

Solche regionalen Modelle zeigen, dass „Atari-Farbpalette“ keine weltweit identische analoge Ausgabe garantiert.

Bei Emulation und Restaurierung sollte die Video-Norm deshalb als Teil des konkreten Gerätezustands dokumentiert werden.

RF, Composite und Monitoranschlüsse

Je nach Modell und Region stehen RF-Ausgang, Composite Video und bei bestimmten Modellen getrennte Luma-/Chroma-Signale zur Verfügung. Nicht jede Gerätevariante besitzt dieselben Pins oder dieselbe Signalbestückung.

Gerade 400, einzelne 600XL-Varianten, 800XL und XEGS unterscheiden sich in Details. Eine pauschale Aussage „jeder Atari hat S-Video“ wäre deshalb falsch.

Für Bildqualität und Digitalisierung ist die beste tatsächlich vorhandene Originalausgabe des konkreten Geräts zu bevorzugen, ohne nicht belegte Signale vorauszusetzen.

XEP80 – 80 Zeichen als externe Erweiterung

Der XEP80 ist eine späte externe 80-Zeichen-Erweiterung. Er erzeugt eine eigene monochrome Videoausgabe und kommuniziert über einen Controllerport mit dem Atari.

Damit wird die normale 40-Spalten-orientierte Bildschirmwelt für Textanwendungen erweitert, ohne ANTIC selbst in einen völlig neuen hochauflösenden Textmodus zu verwandeln.

Der XEP80 enthält außerdem eine parallele Druckerschnittstelle und zeigt, wie Funktionen über relativ ungewöhnliche Erweiterungspfade nachgerüstet wurden.

Atari 850 Interface Module – RS-232 und Parallelwelt anbinden

Das Atari 850 Interface Module verbindet die proprietäre SIO-Welt mit standardnäheren seriellen und parallelen Schnittstellen. Dadurch können Modems, Terminals, Drucker und andere Geräte außerhalb des reinen Atari-SIO-Ökosystems genutzt werden.

Die Einheit besitzt eigene Logik und wird wie andere Atari-Peripherie über SIO angesprochen.

Historisch ist das 850 deshalb eine Brücke zwischen Heimcomputerplattform und klassischer Datenkommunikation. Verwandte Themen stehen auf schnittstellen-und-kabel.htm und interfaces.htm.

Modems, BBS und Onlinekommunikation

Atari bot verschiedene Modem- und Kommunikationslösungen an; zusätzlich existierten zahlreiche Drittanbietergeräte. Mit Terminalsoftware konnten Nutzer Mailboxen und später vernetzte Dienste erreichen.

SIO, Atari 850 und serielle Modems bilden dabei unterschiedliche technische Wege. Manche Modems sind direkt als Atari-Peripherie ausgelegt, andere benötigen eine RS-232-Brücke.

Die DFÜ-Geschichte wird auf modems-und-dataphon.htm, mailboxen-bbs.htm und bulletin-board-alltag.htm vertieft.

Drucker und Plotter

Atari bot eigene SIO-Drucker sowie den 1020-Farbplotter an. Über Interface-Module konnten außerdem parallele und serielle Fremdgeräte eingebunden werden.

Für Textverarbeitung war das wichtig, weil der Heimcomputer damit zur vollständigen kleinen Arbeitsstation aus Rechner, Diskette und Drucker wurde.

Die allgemeine Entwicklung wird auf drucker-und-nadler.htm behandelt.

Drittanbieter-Laufwerke und beschleunigte DOS-Welt

Neben Atari 810, 1050 und XF551 existierten zahlreiche Drittanbieter-Laufwerke. Einige boten echte Double Density, schnellere SIO-Protokolle, größere Puffer oder alternative Firmware.

Dadurch entstand eine vielfältige Diskettenlandschaft mit Formaten oberhalb des offiziellen kleinsten Nenners.

Für Softwarearchivierung ist deshalb wichtig, nicht nur „Atari 5,25 Zoll“ zu notieren, sondern Sektorformat, DOS und gegebenenfalls Laufwerksanforderungen.

Festplatten und PBI-/SIO-Erweiterungen

Später wurden auch Festplattenlösungen, RAM-Disks und moderne Massenspeicheradapter für die 8-Bit-Rechner entwickelt. PBI/ECI erlaubt direktere Systeme, während andere Lösungen SIO-kompatibel bleiben.

SpartaDOS und andere leistungsfähigere DOS-Systeme machen größere Laufwerke sinnvoller, weil sie Unterverzeichnisse und komplexere Dateiverwaltung unterstützen.

Solche Erweiterungen zeigen die erstaunliche Lebensdauer der Plattform weit über ihre ursprüngliche Diskettengeneration hinaus.

Moderne SD- und SIO-Emulatoren

Heute können SIO-Geräte durch Mikrocontroller- oder SD-Karten-Lösungen emuliert werden. Der Atari sieht weiterhin logische Disketten- oder Dateiservergeräte, während die Daten auf moderner Flashspeicherung liegen.

Das ist für Alltagsnutzung praktisch und schont historische Diskettenlaufwerke. Für eine Sammlung sollte dennoch zwischen Originalhardware und moderner Ersatz-/Emulationsperipherie unterschieden werden.

Ein SD-Adapter bewahrt die Funktion, ersetzt aber nicht automatisch den dokumentarischen Wert eines 810- oder 1050-Laufwerks.

Warum alte 400/800-Software auf XL/XE manchmal scheitert

XL-Systeme besitzen ein verändertes Betriebssystem-ROM. Sauber programmierte Software nutzt dokumentierte Vektoren und bleibt häufig kompatibel. Manche frühe Programme springen jedoch direkt in interne ROM-Adressen oder setzen bestimmte Speicherzustände voraus.

Dafür entstanden sogenannte Translator-Disketten beziehungsweise ROM-Umschaltlösungen, die eine ältere OS-Umgebung bereitstellen.

Der Fall ist ein klassisches Beispiel für den Unterschied zwischen dokumentierter API-Kompatibilität und zufälliger Abhängigkeit von Implementierungsdetails.

BASIC-ROM und freier Speicher als Kompatibilitätsfaktor

Programme aus der 400/800-Zeit konnten davon ausgehen, dass im Bereich des später eingebauten BASIC-ROMs RAM verfügbar ist, wenn keine BASIC-Cartridge steckt. Auf XL/XE ist dort standardmäßig BASIC eingeblendet.

Beim Booten mit gedrückter OPTION-Taste lässt sich BASIC deaktivieren, sodass dieser RAM-Bereich für entsprechende Software verfügbar wird.

Viele vermeintliche „XL-Inkompatibilitäten“ sind daher keine geänderte CPU, sondern ein anderer Startzustand der Memory Map.

Atari 5200 – nah verwandt, aber keine normale Heimcomputer-Kompatibilität

Die Atari-5200-Konsole verwendet eine eng verwandte Architektur mit 6502, ANTIC, GTIA und POKEY. Dadurch ähneln sich viele technische Grundlagen und Spielekonzepte.

Speicherkarte, Controller, Cartridgeformat und Betriebssystemumgebung unterscheiden sich jedoch. Ein Atari-8-Bit-Computerprogramm lässt sich nicht einfach als normales 5200-Modul einsetzen.

Die 5200 zeigt, wie Atari seine Heimcomputerchips auch in einer dedizierten Konsolenplattform nutzte.

Atari 2600 – gleiche Firma, andere Architektur

Das Atari 2600 verwendet einen 6507 und den TIA-Chip. Es besitzt keine ANTIC-Display-List-Architektur und keinen POKEY.

Obwohl beide Systeme 6502-verwandten Maschinencode nutzen, unterscheiden sich Speicher, Video, Betriebssystem und Programmmodell fundamental.

Die gemeinsame Marke darf daher nicht zu einer vermeintlichen Softwarekompatibilität führen.

Atari ST – Nachfolger im Markt, nicht in der 8-Bit-ISA

Ab 1985 etabliert Atari die ST-Familie mit Motorola 68000. Sie gehört zur 16/32-Bit-Generation und besitzt eine grundlegend andere CPU-, Speicher- und Betriebssystemarchitektur.

Der ST folgt den 8-Bit-Heimcomputern zeitlich und im Markt, ist aber kein „größerer XE“, auf dem 6502-Binärprogramme nativ weiterlaufen.

Die Prozessorentwicklung wird auf prozessoren-und-rechnerarchitekturen.htm systemübergreifend eingeordnet.

Atari 8-Bit und C64

Atari und C64 verwenden beide Prozessoren aus der 6502-Familie, setzen aber völlig unterschiedliche Spezialhardware ein. Beim Atari organisieren ANTIC und GTIA die Grafik gemeinsam; beim C64 übernimmt VIC-II einen stärker zusammengefassten Videochip.

Atari besitzt vier Player plus Missiles, Hardware-Display-Lists und sehr flexibles zeilenweises Modusmischen. Der C64 bietet acht Sprites, einen anderen Speicherbus und den SID mit drei sehr charakteristischen Synthesestimmen.

Welche Plattform „besser“ ist, hängt daher stark von Aufgabe und Programmierung ab. Die C64-Vertiefung liegt auf c64.htm.

Atari 8-Bit und Schneider/Amstrad CPC

Der CPC verwendet einen Z80A, einen 6845-kompatiblen CRTC, Gate Array und AY-Sound. Atari setzt dagegen auf 6502/SALLY, ANTIC, GTIA und POKEY.

Beide Systeme besitzen flexible Rastermöglichkeiten, aber mit anderer Philosophie: Beim CPC steuert der CRTC Timing und Speicheradressierung; beim Atari führt ANTIC eine Display List aus und kann Modi zeilenweise wechseln.

Die CPC-Seite steht auf cpc.htm.

Atari und Apple II – gleicher CPU-Ursprung, andere Spezialisierung

Apple II und Atari 8-Bit verwenden 6502-basierte CPUs, doch Atari verlagert viel Grafik-, Sound- und I/O-Arbeit in eigene Spezialchips.

Der Apple II ist stärker aus einer relativ direkten CPU-/Speicher-/Videoarchitektur gewachsen, während Atari von Anfang an DMA- und Spielhardware einplant.

Der Vergleich zeigt, wie wenig die gemeinsame CPU allein über den Charakter eines Heimcomputers aussagt.

Typische Atari-Programmiermuster

Viele leistungsfähige Programme teilen bestimmte Muster: Display List selbst verwalten, VBI für regelmäßige Logik verwenden, DLI für Rastereffekte einsetzen, Player/Missile-Daten in ausgerichteten RAM-Bereichen halten und POKEY-Timer oder Sound direkt programmieren.

Dazu kommt die sorgfältige Aufteilung von CPU-Zeit und ANTIC-DMA. Ein Bildschirm kann bewusst vereinfacht werden, wenn mehr Rechenzeit benötigt wird.

Diese enge Zusammenarbeit von CPU und Coprozessoren macht Atari-Assembler anders als reinen 6502-Code auf einer weniger spezialisierten Plattform.

WSYNC – CPU exakt an die nächste Rasterzeile binden

GTIA/ANTIC-Hardware stellt mit WSYNC eine Möglichkeit bereit, den Prozessor bis zu einem definierten Rasterzeitpunkt warten zu lassen. Damit lassen sich DLI-Routinen und Farbänderungen besser mit dem Bildaufbau synchronisieren.

Der Preis ist CPU-Zeit: Während des Wartens arbeitet der Prozessor nicht an normaler Programmlogik.

WSYNC ist deshalb ein Präzisionswerkzeug für Rastercode, kein allgemeiner Geschwindigkeitsgewinn.

DLI und VBI kombinieren

Ein typischer Aufbau nutzt VBI für einmal-pro-Frame-Aufgaben und DLI für Änderungen an bestimmten Bildschirmpositionen. Der Hauptcode kann währenddessen Spiel- oder Anwendungslogik ausführen.

Damit entsteht eine mehrschichtige zeitliche Architektur: Hauptprogramm, regelmäßiger Frame-Interrupt und rastergebundene Spezialinterrupts.

Fehlerhafte Registerrettung oder zu lange Interruptcodepfade können den gesamten Bildschirmaufbau stören, weshalb solche Routinen diszipliniert programmiert werden müssen.

Bildschirmspeicher ist nicht immer ein einzelner Framebuffer

Weil Display Lists neue Speicheradressen setzen und Modi wechseln können, muss ein Atari-Bildschirm nicht aus einem durchgehenden linearen Bitmapbereich bestehen.

Statuszeile, Spielfeld, Textfenster und mehrere Bildbereiche können an völlig verschiedenen RAM-Adressen liegen und dennoch in einem Frame erscheinen.

Das spart Speicher und Kopierarbeit, verlangt aber ein anderes Denken als ein moderner durchgehender Pixel-Framebuffer.

Charaktergrafik als effiziente Spieltechnik

Viele Spiele verwenden umdefinierte Zeichensätze für Hintergrundgrafik. Eine Spielfeldkarte besteht dann nur aus Zeichencodes, während jedes Zeichen ein kleines Grafikmuster beschreibt.

Animationen können durch Umschalten oder Verändern weniger Glyphen erfolgen. Das ist wesentlich billiger als das Kopieren eines großen Bitmaps.

ANTIC macht diese Technik besonders leistungsfähig, weil Zeichensatz- und Moduswechsel innerhalb eines Bildes möglich sind.

Textverarbeitung, Tabellen und Datenbanken

Die Atari-Rechner wurden nicht nur als Spielemaschinen verwendet. AtariWriter und andere Textverarbeitungen, Tabellenkalkulationen wie VisiCalc, Datenbankprogramme und Lernsoftware nutzten Disketten, Drucker und 40-Spalten-Bildschirm.

Für längere Texte ist der 800 mit seiner guten Tastatur oder ein späteres XL/XE-Gerät deutlich geeigneter als der Atari 400.

XEP80 und Druckerinterfaces erweitern die Plattform für ernsthaftere Textarbeit.

Musiksoftware und POKEY als Instrument

POKEY wurde nicht nur von Spielen verwendet. Tracker-artige Editoren, Musikprogramme und Demos nutzten die vier Kanäle, Distortionmodi und Timer als eigenständige Klangplattform.

Die Grenzen des Chips – diskrete Teiler, vier Kanäle, keine analogen Filter wie beim SID – führten zu eigenen Kompositionstechniken.

Die allgemeine Audiotechnik steht auf audio-und-midi.htm.

Grafikprogramme zwischen ANTIC-Modi und Farbartifacting

Zeichenprogramme mussten sich an die besonderen Atari-Modi anpassen. Hochauflösende Bilder besitzen andere Farbgrenzen als GTIA-Flächenmodi, und NTSC-Artifacting kann zusätzliche Farberscheinungen erzeugen.

Demos und moderne Szeneformate kombinieren Modi, Rasterwechsel und Interlacing-Techniken, um deutlich mehr Farben oder scheinbar höhere Detailstufen zu erreichen als ein einfacher BASIC-Modus.

Verwandte Grundtechniken werden auf gfx-techniken.htm vertieft.

Demoscene – ANTIC und GTIA bis an die Grenzen

Die Atari-Demoscene nutzt Display Lists, DLI, VBI, Player/Missile, GTIA-Modi, Rasteränderungen und Speichererweiterungen weit über typische Anwendungsprogramme hinaus.

PAL-Geräte sind in der europäischen Szene besonders wichtig, weil Rasterzeit und Farbdarstellung andere Möglichkeiten bieten als NTSC.

Solche Demos sind zugleich anspruchsvolle Emulator-Tests: kleine Fehler bei DMA-Timing, Rasterposition oder GTIA-Priorität werden sofort sichtbar.

Kassetten-, Disketten- und Cartridge-Software als verschiedene Welten

Ein Atari-Programm kann als Cartridge sofort starten, von Kassette sequenziell geladen oder von Diskette über DOS beziehungsweise einen eigenen Bootloader gestartet werden.

Viele Spiele verwenden eigene Diskettenloader und benötigen nach dem Boot kein DOS mehr. Andere Anwendungen bauen vollständig auf DOS-Dateizugriff auf.

Für digitale Archivierung muss deshalb das ursprüngliche Distributionsmedium berücksichtigt werden, nicht nur der Programmcode.

Kopierschutz und Spezialdisketten

Kommerzielle Programme nutzten teils ungewöhnliche Sektorformate, absichtlich fehlerhafte Sektoren, Timingmerkmale oder eigene Loader als Kopierschutz.

Ein normales ATR kann viele logische Disketten gut abbilden, aber nicht jede physische Besonderheit. Für schwer geschützte Originale können spezialisierte Flux- oder Timing-orientierte Erfassungsverfahren nötig sein.

Diese Seite behandelt den Erhalt solcher Strukturen, nicht die Umgehung aktueller Schutzmaßnahmen.

XEX – moderne Bezeichnung für Atari-Binary-Load-Dateien

Viele heute verteilte Atari-Programme liegen als XEX-Datei vor. Das Format besteht aus Ladeblöcken mit Zieladressen und optionalen Initialisierungs-/Startvektoren, entsprechend dem klassischen DOS-Binary-Load-Konzept.

XEX ist praktisch für Emulatoren und moderne SIO-Geräte, enthält aber nicht die komplette Struktur einer ursprünglichen Diskette.

Eine Programmsicherung und ein vollständiges Datenträgerimage erfüllen daher unterschiedliche Archivzwecke.

ROMs, Cartridges und Hardwarevarianten dokumentieren

Bei Cartridge-Archivierung sind ROM-Inhalt, Platinenlayout und Bankswitchinglogik getrennte Ebenen. Zwei Module mit demselben Programmnamen können unterschiedliche Platinenrevisionen besitzen.

Für Rechner-ROMs sind OS-Revision, BASIC-Version und Video-Norm wichtig. Sie beeinflussen Kompatibilität und Verhalten.

Ein reiner ROM-Dump ersetzt daher nicht die Dokumentation des physischen Geräts.

5,25-Zoll-Disketten erhalten

Magnetische 5,25-Zoll-Disketten altern mechanisch und magnetisch. Originale sollten trocken, sauber und ohne unnötige Schreibvorgänge gelagert werden.

Vor Änderungen ist ein Image sinnvoll. Für normale Disketten genügt häufig ein sektororientiertes Image; Spezialformate benötigen gegebenenfalls tiefere Erfassung.

Schreibschutzkerben und Etiketten gehören zur Dokumentation, weil sie Hinweise auf ursprüngliche Nutzung und Softwarestand geben können.

Atari-Datenkassetten digitalisieren

Bei Kassetten ist nicht nur die logische Datei, sondern auch die analoge Signalaufnahme wertvoll. Bandalterung, Dropouts und ungewöhnliche Loader können Informationen enthalten, die eine reine Dateiextraktion verliert.

Eine verlustfreie Audioaufnahme plus daraus erzeugtes CAS-Image bietet deshalb eine robuste zweistufige Archivstrategie.

Der Recorder selbst sollte vor wertvollen Originalbändern auf Riemen, Andruckrolle und Bandlauf geprüft werden.

Rechner erhalten – Netzteil, Tastatur und Steckverbinder

Bei erhaltenen Atari-Rechnern sollten Modell, Seriennummer, Video-Norm, Platinenrevision und sichtbare Umbauten dokumentiert werden, bevor Teile getauscht werden.

Externe Netzteile altern und sollten nicht ungeprüft als „funktioniert schon“ behandelt werden. Ebenso können Tastaturfolien, Steckverbinder und SIO-Buchsen mechanische Probleme entwickeln.

Pauschaler Bauteiltausch ohne Befund ist keine gute Archivstrategie. Reversible, dokumentierte Reparaturen erhalten mehr historische Information.

810, 1050 und XF551 als eigene Computer

Atari-Diskettenlaufwerke sind keine passiven Mechaniken. Sie besitzen eigene Elektronik, Firmware und zum Teil eigene Prozessorlogik. Eine Laufwerksrestaurierung ist deshalb ein separates Rechnerprojekt.

Mechanik, Schreib-/Lesekopf, Drehzahl, Spurposition und SIO-Kommunikation müssen zusammen funktionieren. Ein Laufwerk, das eine Diskette dreht, ist noch nicht automatisch datenverträglich.

Für Originalmedien sollte zuerst mit unkritischen Testdisketten geprüft werden.

Emulation – ANTIC-Timing ist die eigentliche Herausforderung

Ein einfacher 6502-Emulator reicht für Atari-Kompatibilität nicht aus. ANTIC-DMA, GTIA-Prioritäten, POKEY-Timer, SIO und Rasterinterrupts müssen zeitlich korrekt zusammenspielen.

Etablierte Emulatoren bilden deshalb nicht nur CPU-Befehle, sondern das gesamte Chipsatzverhalten nach. Demos und kopiergeschützte Disketten sind besonders anspruchsvolle Tests.

Emulation ergänzt Originalhardware: Sie erleichtert Softwarezugriff und Analyse, ersetzt aber nicht den physischen Zustand eines konkreten Rechners.

Moderne Cross-Development-Werkzeuge

Heute kann Atari-Software auf modernen Rechnern mit Cross-Assemblern, Compilern, Bildkonvertern und Emulator-Debuggern entwickelt werden.

Das beschleunigt Entwicklungszyklen erheblich, ändert aber nichts an den realen Hardwaregrenzen. Ein Programm muss weiterhin in 6502-Adressraum, ANTIC-Timing, POKEY und den verfügbaren RAM passen.

Für ein Archivprojekt ist es sinnvoll, Quellcode, Buildwerkzeuge und erzeugte Atari-Binärdatei gemeinsam zu dokumentieren.

Ataris eigene technische Dokumentation als historische Stärke

Atari veröffentlichte umfangreiche Technical Reference Notes, Betriebssystemhandbücher, Source Listings und Entwicklerliteratur. Dadurch ist die Architektur ungewöhnlich gut dokumentiert.

De Re Atari erklärt die Spezialchips aus Sicht effektiver Programmierung und zeigt, dass Display Lists, Player/Missile Graphics und Interrupttechniken bereits zeitgenössisch systematisch beschrieben wurden.

Für historische Rekonstruktion sind solche Originalunterlagen wichtiger als spätere vereinfachte Tabellen.

Häufige Missverständnisse über Atari 8-Bit

Die Atari-Rechner sind nicht einfach „6502 mit 256 Farben“. Die CPU teilt Speicherzeit mit ANTIC, und die gleichzeitige Farbzahl hängt stark vom Modus ab. GTIA besitzt eine Palette von Farbton-Helligkeits-Kombinationen, nicht einen frei adressierbaren 256-Farben-Framebuffer.

Der 130XE besitzt zwar 128 KiB RAM, aber keinen 128-KiB-linearen CPU-Adressraum. Zusatzspeicher wird bankgeschaltet. Das Atari OS im ROM ist außerdem nicht dasselbe wie Atari DOS auf Diskette.

XEGS ist trotz Konsolengehäuse ein echter Abkömmling der 8-Bit-Heimcomputerfamilie; der Atari ST dagegen ist eine andere 68000-Architektur.

• Atari 400/800, XL, XE und XEGS bilden eine gemeinsame 8-Bit-Familie.
• ANTIC ist ein Display-List- und DMA-Prozessor, nicht nur ein einfacher Grafikregistersatz.
• GTIA und ANTIC arbeiten gemeinsam an der Bildausgabe.
• POKEY ist Sound-, Tastatur-, Timer-, Potentiometer- und SIO-Baustein.
• NTSC und PAL besitzen leicht unterschiedliche CPU-Takte und deutlich andere Rasterbedingungen.
• Der 130XE sieht nicht 128 KiB gleichzeitig.
• Atari OS steckt im ROM; DOS wird von Diskette geladen.
• Atari 5200 ist technisch verwandt, aber nicht normal softwarekompatibel.
• Atari ST gehört nicht zur 8-Bit-ISA.

Checkliste für eine Atari-8-Bit-Dokumentation

Eine saubere Bestandsaufnahme sollte Modellbezeichnung, Markt-/Videoversion, RAM, ROM-Revisionen und Erweiterungen getrennt erfassen. Gerade bei XE-Systemen und späteren Umbauten reicht der Gehäusename allein nicht.

Datenträger und Peripherie sollten als eigene Komponenten dokumentiert werden, weil SIO-Geräte eigene Firmware und technische Zustände besitzen.

• Exaktes Modell und Video-Norm dokumentieren.
• Seriennummer und Platinenrevision fotografieren.
• RAM-Größe und bekannte Speichererweiterung getrennt notieren.
• OS-ROM- und BASIC-Version nur aus realem Gerät beziehungsweise Dump bestimmen.
• CTIA/GTIA beziehungsweise regionale Videoausführung nicht raten.
• SIO-Geräte mit Modell, Geräte-ID und Firmwarestand dokumentieren.
• Disketten zuerst sichern, bevor Reparatur- oder Schreibtests erfolgen.
• ATR/XFD/CAS/XEX nicht als gegenseitig identische Archivformen behandeln.
• Moderne SD-/SIO-Emulatoren klar von Originalperipherie trennen.
• Reparaturen reversibel dokumentieren.
• Netzteile vor längerer Nutzung prüfen lassen, wenn Zustand unbekannt ist.

Einordnung im SSLXY-Archiv

Die Atari-8-Bit-Familie ergänzt den SSLXY-Archivbereich um eine dritte große Heimcomputerarchitektur neben Commodore und Schneider/Amstrad. Besonders ANTIC und das SIO-Konzept zeigen Lösungswege, die sich deutlich von C64 und CPC unterscheiden.

Die Seite behauptet keinen konkreten historischen Atari-Besitz im SSLXY-Bestand, wenn dieser nicht separat dokumentiert ist. Sie dient als technische, historische und systemvergleichende Vertiefung.

Direkte Nachbarthemen sind C64, Schneider CPC, Prozessoren und Rechnerarchitekturen, Programmierung und Skripting und Dateisysteme und Datenträger.

Verwandte Themen im SSLXY-Archiv

Atari 8-Bit berührt Prozessorarchitektur, Grafik, Audio, Programmierung, Schnittstellen und magnetische Datenträger. Die folgenden Seiten bilden die wichtigsten direkten Nachbarn.