Im Gegensatz zum PC mit zwei verschiedene Videokarten mit separatem Video RAM, benutzt der ST stets den selbigen Videogenerator mit Bitmap aus dem Hauptspeicher. Nur dieser mit zwei Betriebsmodi umschaltbar. (Dies entspricht damit den PC mit MDA/HGC oder CGA drin, nur einer aufs Mal benutzbar.)

Dies mit nur dem GLUE Chip das Display Enable (DE) Signal mit anderem Timing betreiben, für 400 Zeilen mal 40 Worte pro Bild, statt 200 mal 80 Worte. (Der GLUE entspricht damit dem Mac LAG PAL, nur eben auch noch auf Verhalten für farbig schaltbar.)

Die MMU liest stets die identischen 16000 Worte in selbiger Reihenfolge, ab der in $FF8201+$FF8203 gesetzten Adresse. Diese besteht aber nur aus zwei Bytes für A23..A16 und A15..A8, hat keine A7..A0! Sie muss zudem als zwei einzelne Bytes geschrieben werden, weil MMU nur einen 8bit Datenbus hat, mangels Pins, damit nur D0..7 benutzen kann, nur an ungeraden Adressen sichtbar ist. Dazu kann allerdings der genau für solches vorgesehene MOVEP.L Befehl der 68000 nicht genutzt werden, weil dieser Serien von vier Bytes schreibt, von denen hier die mittleren beiden genutzt werden, aber die anderen beiden danebenschiessen würden. Dies besser machen hätte nur ein paar Leiterbahnen im MMU Chip anderst ziehen gebraucht, nicht mal mehr Transistoren! Weshalb ich das nicht ermöglichen als Designfehler anschaue, und als schweres Beispiel der Folgen von überhastet durchgezogen. (Der MMU entspricht den Mac 2 74LS393 und 4 74AS253.)

Der Shifter gibt selbige Worte aus, wenn auch bei Schwarzweiss direkt als 1bit analog S/W (mit 0..1V an 75Ohm), statt bei Farben als 2oder4bit durch Tabelle zu 3*3bit analog RGB (mit 0.5..1.5V an 75Ohm) (VGA ist 0..0.7V an 75Ohm). (Der Shifter entspricht im Schwarzweiss Modus dem Mac seinen zwei 74LS166 PISO Shiftregistern.)

Selbst die Mac zwei 74LS244 Buffer sind analog vorhanden, nur hier als zwei 74LS373 an U23 und U22, welche neben buffern auch noch zeitlich entkoppeln. Weil der Shifter neben Videodaten vom Speicher holen auch Konfiguration vom Prozessor braucht, sind diese antiparallel mit weiteren 2 74LS244 an U17 und U26 versehen. Alle gesteuert vom MMU Chip, die 74LS373 mit Signalen LATCH und /RDAT sowie die 74LS244 mit /WDAT.

Das ganze ist sogar autokonfigurierend. Die Schwarzweiss Monitore ziehen ein MONO Modussignal am Pin 4 vom Videostecker auf 0V = 0, während Farbmonitore oder Fernseher dies nicht tun, es per internem Widerstand auf +5V = 1 bleibt. Womit den Schwarzweiss Monitor anstecken als externen Jumper aufstecken wirkt! Die Software muss nur dessen Zustand vom 68901MFP IO Chip Pin I7 einlesen und in die GLUE Timing und Shifter Modus Konfiguration kopieren. Dies macht die Systemsoftware beim booten. Aber auch in jedem Vertikalrücklauf Interrupt nachprüfen. Dies sogar gefolgt von auto-reboot auslösen falls es sich geändert hat. Womit man nur durch Monitore umstecken schnell in die andere Konfiguration rebooten kann! Profis hatten sogar eine externe Hardware um ohne umstecken die Monitore umzuschalten. (Man vergleich dies mit PC und XT, wo dazu neben 2 Videokarten haben man einen DIP Schalter auf dem Systemboard umlegen muss. Bei AT wurde es wenigstens ein Schiebeschalter dort.)

Schwarzweiss kann 400 statt 200 Zeilen darstellen und erlaubt so 8x16 Pixel Fonts (mehr als EGA 8x14, besser als MDA 9x14, genau MCGA 8x16, nicht ganz VGA 9x16) für selbige 80x25 Zeichen. Das Resultat ist selbst besser als PC HGC 720x348 oder Lisa 720x364. Die beiden haben zwar selbige 32k an Bildspeicher, aber die 640x400 vom ST erlauben horizontale und vertikale Linien fast gleich breit zu sein, für konsistentere Graphik, inklusive bessere Fonts!

Weil dies nicht fernsehkompatibel sein kann, erlaubt es auch ein weit besseres Timing benutzen. Angefangen mit 32MHz Pixel (MDA+EGA haben nur 16.257MHz, VGA wenigstens noch 25.175MHz, Lisa hat 20.37504MHz, Mac hat 15.6672MHz, ST Farben sind 32/2=16MHz). Gefolgt von horizontal massive 35.7kHz Zeilen (MDA nur 18.432kHz, EGA 21.85kHz, VGA 31.50kHz, Lisa 22.4kHz, Mac 22.254kHz, ST Farben 15.7kHz) und vertikal stabile 71.25Hz (MDA 50Hz, EGA 60Hz, VGA 70Hz, Lisa etwa 60Hz, Mac 60.15Hz, ST Farben 60Hz). All dies bereits 2 Jahre vor der VGA! Damit können diese Monitore neben gestochen scharf auch komplett flimmerfrei sein, ohne mit langer Phosphorpersistenz verschmierende Cursor und Mauscursor Bewegungen zu produzieren (wie MDA wegen 50Hz).

Damit wird reverses Video mit Schwarz auf Weiss erst real benutzbar. Der ST ist zudem umschaltbar zwischen PC-artig 1=weiss/0=schwarz oder Mac-artig 1=schwarz/0=weiss, mit Bit0 von Farbtabelle Zeile 0. Wobei dieses erstaunlicherweise als Werte 1=inverted=PC-artig(!)/0=normal=Mac-artig verdrahtet ist. Diese Mac-artige Darstellung kann sogar 8x16 Fonts mit 2 Pixel breite Linien erlauben, und so gerundete Ecken in Zeichen ermöglichen, für detailierte Fonts. Das Resultat von alledem war das beste Schwarzweiss von damals! (In all diesem folgt der ST stark dem Mac, nur mit trotz massiv billiger auch noch einiges besser sein, mit 640x400 statt 512x342 und auf 12" statt 9" Monitor, beide etwa 72dpi. Er wurde deswegen prompt als Spitzname Jackintosh genannt!)

(Es gab sogar eine MacOS Adaption auf den ST, in Form eines ROM Modules namens The Magic Sac von Data Pacific. Dieses hatte 2 16k ROM Chips mit ST Adaption Software und 2 leere 32k ROM Sockel, in welche extrahierte oder kopierte Mac ROMs kommen. Resulat war MacOS auf ST mit 4/3 Geschwindigkeit und 3/2 Pixel und Platz, wenn auch nicht Mac GCR Floppy Format kompatibel. Nachdem der Mac Plus herauskam gab es ein weiteres Modul namens Spectre 128 von Gadgets by Small, welches Mac Plus ROMs aufnahm. Dieses wurde sogar später erweitert, als Spectre GCR, um ein externes ST Floppy Laufwerk mit Mac-artigen Floppy Controller zu benutzen.)

Der einzige Preis der 400 Zeilen ist nur 1bpp, rein Schwarzweiss, nicht mal Graustufen. Ein 2bpp mit 4 Graustufen ist nicht mal mit schaltbar halbierter Pixelzahl machbar. Vielleicht mangels freien Pins am Shifter, mit separate brauchen wiederum angenommen wegen nicht auf dem damaligem Shifter Chip mit 32MHz Pixelfrequenz durch die Farbtabelle können. Oder weil 2bpp mit obigem umschaltbar PC-artig/Mac-artig kollidiert, wieder wegen nicht durch Farbtabelle gehen. Aber Graustufen sind ohnehin oft unnötig, man kann rastern, wenn auch Text dabei schlecht lesbar wird. (Was der Mac auch machen muss und darunter leidet. Nur dass es dessen 6x12 Font mit 1 Pixel breite Linien weit schlimmer trifft als dem ST seinen 8x16 mit 2 breite Linien. PC HGC muss dies auch so.)

Damit war der ST praktisch ideal für jegliche normalen Büroanwendungen wie Textverarbeitung oder DTP. Dies erst recht wenn zusammen mit dem SLM Laserdrucker. Ebenso für andere erweiterte Büroanwendungen wie Tabellenkalkulation oder Datenbanken. Aber auch für technisches wie Programmieren oder CAD. Selbst Spieleprogrammierer hatten teilweise beides Schwarzweiss- und Farbmonitor umsteckbar (oder umschaltbar) und benutzten ersteren zum programmieren und zweiteren nur zum testen. Generell gilt: Solange das Ziel etwas ausdruckbares ist, was in 1985 ohnehin zumeist nur schwarzweiss sein konnte, ist 1bpp kein Problem. Der ST ist damit eigentlich ein nettes kleines Rechnerchen, der aber wegen billig und keine Amiga Supergraphik haben gnadenlos unterschätzt wurde.

Die STF und MegaST ändern gar nichts, mit selbigem Chipsatz. Ebenso die STE und MegaSTE nichts, mit nur Farbmodus verbessern. Für Schwarzweiss blieb es unverändert, weder mehr Pixel noch mehr bpp.

Der TT030 dagegen überbietet alles bisherige, hat ein vierfach breites 64bit ST RAM aus 16 256kx4bit Chips. Dies erlaubt auszudehnen von 640x400 aus 32kByte auf 1280x960 aus 152kByte! (Das ist sogar mehr als nur vierfache, das wäre 1280x800 aus 128k.) Dies reicht mit dem 8x16 Font für 160x60 Zeichen. Was ausreicht um DTP mit Doppelseiten 2*A4 oder CAD mit A3 anzeigen. Es ist genau 4* VGA 640x480, wenn auch mit nur 1bpp statt 4bpp, aber damit gleiche Datenmenge wie diese. Das aber schon 3 Jahre nach der VGA! Es ist somit immerhin mehr als 2 * SVGA 800x600 Pixel, ebenso noch über 1024x768 und 1152x864, erst unter 1280x1024. Es ist sogar mehr als teure über-$10'0000 Sun Workstations mit 1152x900 hatten! Kein Wunder, wurde der TT030 doch anfangs als günstige Unix Workstation designt. (Unix wurde aber fallen gelassen, nachdem MultiTOS kam, abgeleitet vom MiNT, einem Multitasking fähigen TOS Ersatz.) (MiNT stand einst für MiNT is Not TOS, wurde nach offiziell werden umbenamst in MiNT is Now TOS.)

Dabei wird die ST Schwarzweiss 32MHz Pixelrate aber *4 zu TT030 massiven 128MHz, und das in 1990! Horizontal sind es nun 74kHz (mehr als 35.7kHz *2), vertikal 71Hz (unter 71.25Hz, aber nur weil x960 statt x800). Dazu musste Atari den Shifter in 2 Chips spalten, einen TT Schifter in normaler MOS Technologie für farbig, der nur 16MHz *2 = 32MHz macht, sowie einem NEC DP8516 Shifter plus DP8530 PLL Oszillator für Schwarzweiss. Letztere sind in ECL Bipolar Technologie implementiert, weil selbst TTL Bipolar für 128MHz zu langsam ist! Dazu gibt es den passenden TTM194 19" Monitor. Mit VGA HD15/DE15f Stecker, aber erweitert um Schwarzweiss mit differenziellen Signalen an Pin 4 (+) und 15 (-) um den TTM194 ausreichend schnell zu versorgen (das waren bei VGA ID2+3 Pins, dessen ID0+1 werden zu unbenutzt), sowie mit Pin 9 als MONO Modussignal um den TTM194 von einem VGA Monitor für Farbmodi zu unterscheiden (war VGA unbenutzt/Key).

(Als Vergleich für all die denen 128MHz nichts sagt: Mein 1995 17" Monitor mit 1152x864 70Hz bekam vom PC nur 72MHz, ganze 56% von obigen 128MHz, und das 5 Jahre später! Mit 6x13 Font passten 192x66 Zeichen. Wenn auch mit ATI Mach32 Videokarte auf 16bpp. Erst mein 1998 21" Monitor mit 1600x1200 65Hz bekam vom PC 165MHz, 129% davon. Mit 8x16 Font 200x75 Zeichen. (Nur 65Hz statt 70Hz weil die eigentlich exzellente Matrox Millennium Videokarte auf 32bpp bei mehr MHz anfing Pixel falsch auszulesen, so knapp war das an der Leistungsgrenze von ihrem Video RAM.) Der moderne 24" Monitor mit FullHD+ 1920x1200 60Hz auf dem ich in 2024 dies schreibe bekommt vom PC 154MHz, nur 120% davon. Mit 8x16 Font 240x75 Zeichen. (Nur noch 60Hz weil LCD Monitore nicht mehr brauchen, logisch auch auf 32bpp, weil selbst bei Jahr 2008 Laptop mit Intel Core2Duo mit GM45 Chipsatz Graphik ist sowas inzwischen komplett harmlos.))

(Der Amiga konnte vergleichbares zum ST Schwarzweiss erst mit dem ECS im Productivity Modus. Dieser kann doppelte Datenrate "35ns" (=28.63636MHz) statt "70ns" (=14.31818MHz). (Als Vergleich ST hat 32MHz Schwarzweiss und 16MHz Farben.) Dabei hat er wie ST nur noch 1bpp, ausser Prozessor wird zu mehr als 50% geopfert für 2bpp. Dies resultiert strikte in relativ nutzlosem 1280x200, was den Verlust an bpp oder Prozessor nicht wert wäre. Aber ECS hat vor allem programmieres Timing. Dieses kann man für doppelviele halblange Zeilen benutzen. Damit liefert der ECS einen 640x480 60Hz VGA Graphikmodus. Auch mit VGA HD15/DE15f Stecker. Strikte könnte die Hardware auch 640x400 70Hz VGA Textmodus, es fehlt nur an der Software. Mit diesem wäre in Pixel das ST Schwarzweiss genau gleichgezogen. Aber ECS kam erst in den Amiga 3000 sowie 500 Plus und 600 in 1990, 5 Jahre nach dem ST (wenn auch der ECS Chipsatz in den 500 und 2000B/B2000 von 1987 nachrüstbar ist). Also sehr spät, als bereits der TT030 da war.)

(Erst Amiga mit AGA schaffte vergleichbares zum TT030 seiner massiven vierfachen Pixelmenge aufholen. Aber AGA kam erst in den Amiga 4000 und 1200 in 1992/1993, 2 oder gar 3 Jahre nach TT030, 5 oder gar 6 nach VGA.)

Amiga

Amiga: Farben

Dies erlaubt den AGNUS auf diverse Videomodi hin zu optimieren wegen Speicherverbrauch und -bandbreite (und auch Prozessorleistung um sie zu beschreiben!) je nach genutzter Farbenvielfalt. Dies ist analog zum Atari 800 seinen ANTIC und Videomodi. Selbst Modi zeilenweise wechseln wie beim 800 ANTIC seiner Displayliste geht mit AGNUS seiner Copperliste. Wobei dem 800 sein hochgetackteter Prozessor alle Zeitslots ausnutzen konnte, auch nur minimal 1 Zeitslot Video ihn etwas bremste, weshalb er auch Modi hatte um Zeilen aus internem RAM vom CTIA/GTIA zu wiederholen. Beim Amiga sind dagegen die ersten 4 von 8 Zeitslots kostenlos, was zu obigen Standardmodi führt. Alle 8 Zeitslots nutzen ist als saturated (= getränkt) bekannt, was nur mit 640 4bpp geht, oder mit ECS Productivity 2bpp.

Der Amiga benutzt stets den selbigen Videogenerator mit Daten aus dem Hauptspeicher (wie ST). Mit diesmal nur den AGNUS das auslesen weit flexibler timen, für Hires 1..4 mal 16kByte (2..8 Zeitslots, als 1..4 Paare) oder Lowres 1..6 mal 8kByte (1..6 Zeitslots, als 1..6 Einzelne). Er liest damit eine variable Menge Worte, einstellbar in Register BPLCON0 (Bit12..14 Anzahl bpp 0..6 und Bit15 1Hires/0=Lowres). Der DENISE (Display ENabler) gibt diese Worte aus, in sehr verschiedenen Varianten, je nach wieviele bpp in ein Pixel zu kombinieren sind.

Wie beim ST sind 2 74LS373 an U3J und U3H als Buffer und Entkoppler vorhanden, wieder mit antiparallel 2 weitere 74LS244 an U3I und U2I, weil hier der ganze Chipsatz von AGNUS und DENISE und PAULA hinter diesen beim Speicher liegen (ST nur Shifter, nicht MMU und GLUE und DMA). Auch die Registeradressen an alle die drei gehen durch einen weiteren 74LS244 an U4J, weil AGNUS bei Copper Betrieb die Adressierung der anderen beiden übernehmen muss.

Die bpp reduzieren ist um Speicher zu sparen. Dabei wird aber zumeist irrelevant wenig gespart. Bei 640x200 sind von 2bpp zu 1bpp nur 32kByte zu 16k halbiert, bei 320x200 sind 4bpp zu 1/2/3bpp dann 32kByte zu 8/16/24k. Oder dies ist allenfalls weit sinnvoller um Prozessor zu sparen, wenn weniger Farben notwendig sind. Letzteres wird vor allem relevant wenn zusammen mit Sprites benutzt, welche die Anzahl Farben erhöhen ohne mehr bpp zu brauchen.

Die bpp vergrössern ist für mehr bpp und Farben. Das kann dagegen sehr entscheidend sein. Bei 640x200 von 2bpp auf 3bpp oder 4bpp ist vermutlich nicht so viel wert, und kostet massiv Prozessor. Hier nun statt 4 ganze 6 oder 8 Zeitslots brauchen kostet dem Prozessor 2 oder 4 davon, neben auch mehr Prozessor verbrauchen um das grössere Bild zu bearbeiten. Es ist NTSC mindestens 3bpp 24% oder gar volle 4bpp 48% an Verlust. PAL wäre bei x200 20% bzw 40%, ist aber bei x256 25.6% bzw 51.2%. Bei 320x200 von 4bpp auf 5bpp oder 6bpp ist es dagegen sehr entscheidend. Dies kostet nur halb soviel Prozessor, 1 oder 2 Zeitslots, bei 5bpp 12/10/12.8% und bei 6bpp 24/20/25.6%, und bringt enorm viel.

Bei 5bpp kann man erst die volle 32von4096 Farbtabelle von RGB Werten ausnutzen. Bei 6bpp macht die 32er Farbtabelle zwar schlapp, aber es gibt zwei erweiterte Modi. Bei Extra Half Bright (EHB) entstehen automatisch weitere 32 abgeleitete halbhelle Farben, was die ersten 32 besser nutzen erlaubt. Bei Hold And Modify (HAM) Modus sind sogar alle 4096 Farben gleichzeitig nutzbar! Dazu werden die Pixelwerte 00TTTT als erste 16 in Farbtabelle benutzt, aber 01BBBB und 10RRRR und 11GGGG nehmen die gespeicherte (= Hold) Farbe des letzten Pixels und (= And) modifizieren (= Modify) diese, durch eine der 3 Farbkomponenten ersetzen. Dabei kann man zwar eine vollständige Farbe nur in 3 Pixelschritten ersetzen, was reale 320/3=107Pixel ergibt, aber die Helligkeit hat volle 320 Pixel, weil in jedem Schritt ändernd. Zudem kann man 16 scharfe Kantenfarben oder schlicht nächste Anfangswerte mit der Farbtabelle vorbesetzen.

Damit wurde der Amiga zu praktisch ideal für Paintprogramme. Die ganzen photorealistischen Bilder welche damals so sehr beeindruckten nutzten teilweise HAM, aber manche auch erstaunlicherweise nur 32 oder allenfalls noch EHB. Dies egal ob digitale Kunst oder Illustrationen. Ebenso wissenschaftliches wie Visualisierung.

(Aber es fehlte damals an der rechnerexternen Auslieferung der erzeugten Bilder, weil keine brauchbaren Farbdrucker existierten! Bestenfalls hatte es CYM(K) Nadeldrucker, welche 3oder4bit digital 8oder16farbig ausgeben konnten, was der ST aber auch darstellen konnte. Also musste man mit Amiga auf Bildschirmphotos zielen, oder allenfalls noch Videobandaufzeichnung. Nur so bleiben die vielen detaillierten Farben erhalten, sonst ist alles 5bpp oder gar 6bpp sinnlos.)

(Gute Bildschirmphotos machte man damals, indem man eine gegen Streulicht abgeschirmte Kamera nahm, zuerst Bild abdunkelte, mit Fernauflöser aufmachte, Taste drücken, Bild wird einmal ausgegeben und wieder abgedunkelt, Meldebeep, Auflöser zu. Am besten zuerst eine Serie Bilder erzeugen, diese nun so als Diashow durchschiessen, um danach den ganzen Film entwickeln zu lassen. Wenn auf Diafilm zusammen mit Diaprojektor als Anzeige hatte man das nächste zu heute einen Beamer benutzen. Es gab sogar spezielle Profigeräte, an die man das Videosignal schickte und vorne eine Kamera ohne Objektiv anschraubte, mit dessen mechanischen Fernauslöser vom Rechner gesteuert, um ganze Serien automatisch auszugeben. Diese hatten hochscharfe kleinformatige Spezialbildröhren, oder gar 3 separatfarbige zusammengefügt mit halbdurchlässigen Spiegeln. Auch dies Techniken sind in besseren heutigen Beamern drin.)

Die ECS Amiga 3000 sowie 500 Plus und 600 änderten hier nur wenig, blieben bei max 6bpp, und selbige Datenrate. Sie erlaubten nur doppelten Pixeltakt mit halbierter bpp, was den Productivity Modus ermöglichte. Für Farben war dies alles irrelevant.

Erst die AGA Amiga 4000 und 1200 brachten weit mehr. Sie nutzten 32bit Videospeicher plus Pagemode Doppelzugriffe auf die RAMs. Dabei wird die erste Adresshälfte einmal mit /RAS angeliefert gefolgt von zwischen Adresshälften schalten, dann zweimal hinter einander die zweite Adresshälfte anliefern mit /CAS gefolgt von Daten auslesen. Damit kann man dopplte Datenmenge in nur 1.5 mal Zeit holen (oder gar in gleicher Zeit mit nur Faktor 1.5 statt 2 schnelleren RAMs). Bedingung ist nur, dass die erste Adresshälfte konstant bleibt, was aber bei 2 Worte einer Videozeile direkt hinter einander im Speicher liegen trivial gegeben ist, mit nur unterstes Adressbit als Teil von der zweiten Adresshälfte 0 zu 1 gehen. Des weiteren kommen die zweimal Daten in unregelmässigen Zeitschritten, was die Pixelausgabe nicht verkraftet, also muss ein Zwischenbuffer hinein, der erstes Wort aufnimmt, dann abgibt bei zweites Wort aufnehmen, mit dieses nach halber Zeit abgeben. Was aber mit dem LISA (DENISE Nachfolger) Customchip kein Problem ist (ALICE ist der AGNUS Nachfolger, PAULA bleibt unverändert).

Das erlaubt wieder verdoppelte Busbreite (16 zu 32bit) plus verdoppelte Taktfrequenz (1 zu 2 Zugriffe pro Zeitslot) und somit nochmals vierfache Bandbreite, was 64bit anstelle 16bit pro Zeitslot ergibt (wie TT030). Damit können AGA selbst 8bpp bis 640x200 72Hz ohne Prozessorbremse, oder gar 8bpp auf 1280x200 72Hz bzw 640x480 60Hz mit Bremse, oder nur 4bpp bei letzteren beiden ohne Bremse (wie VGA mit 152k). Bei 8bpp nutzen sie eine Farbtabelle mit 8*32=256 Tabellenzeilen von 3*(2*4)=24bit mit je 256 Farbstufen für 256von16M Farben. Dazu kommt noch HAM8 mit TTTTTT00 als erste 64 in Farbtabelle, und BBBBBB01 und RRRRRR10 und GGGGGG11 modifizieren nur die oberen 6 von 8 Bits ihrer Farbkomponente. All das an VGA HD15/DE15f Videostecker.

(Der ST mit nur 4bpp und 16 Farben dagegen konnte Kunst oder Illustrationen nur falls absichtlich minimalistische limitierte Graphik ausreichte. Man vergleiche die beiden Rechner als ST analog zu einem Zeichner mit einer kleinen Menge fester Farbstifte und Amiga analog zu einem Maler mit vielen mischbaren Farbtönen.)

(Der STE addiert nur 16von4096 Farben (Format %xxxx'rRRR'gGGG'bBBB, mit RRRGGGBBB Bit1..3 und rgb Bit 0). Er zog damit lediglich halbwegs mit Amiga gleich, bei der Farbdefinition aber nicht den nutzbaren Farben.)

(Der TT030 lieferte neben Schwarzweiss *4 auch Farben *4. Keine Pagemode Doppelzugriffe weil statt dessen 64bit RAM und Funnel Chips. Diese als VGA 640x480 4bpp und über-MCGA 320x480 8bpp mit 256von4096 Farben (Format nun als %xxxx'RRRR'GGGG'BBBB, mit linear Bit0..3). All das auch an VGA HD15/DE15f Videostecker, auf den normalen Analogpins. Dessen ST 640x400 Schwarzweissmodus kommt nun als "Duochrome" Farbmodus auf VGA daher. Ebenso dessen ST x200 Modi erweitert mit STE 16von4096 Farben nun als 200 Zeilen 2 mal wiederholt per Doublescan (wie MCGA und VGA ihre CGA x200 Modi). Aber das war erst in 1990 und weit teurer als STE.)

Amiga: Videoeffekte

Diesen Scanbereich kann man beliebig einstellen. Den Anfang in Register DIWSTRT (Display Window Start), das Ende mit DIWSTOP (D W Stop). Beide mit selbigem Format, mit Vertikal Bit15..8 in Zeilen und Horizontal Bit7..0 in Lowres Pixel. Anfang mit 8bit (Defaultwert NTSC und PAL $2C und $81), aber Ende vertikal 9bit Zahlenwerte, kompaktiert zu 8bit mit Bit8=-Bit7 (Defaultwert NTSC $0F4 als $F4 und PAL $12C als $2C), sowie horizontal mit Bit8=1 (NTSC und PAL $1C1 als $C1). Innerhalb von diesem Bereich muss man noch den Datentransfer vom Speicher starten und stoppen, in 4 Pixel Schritten aber auf 16 Pixel Worte ausgerichtet. Den Anfang in DDFSTRT (Display Data Fetch Start) als einzelne Zahl (Defaultwert Lowres $0038 und Hires $003C), das Ende in DDFSTOP (Defaultwert Lowres $00D0 und Hires $00D4).

(Der ST hat kein Overscan, nicht mal die erweiterten STE oder TT. Strikte tut er die ganze Overscanzeit Farbe 0 anzeigen, welche in der Farbtabelle definiert ist. Diese kann zeilenweise modifiziert werden, wozu ein vom Vertikalinterrupt angestossener Zeilenzeit Timer mit eigenem Interrupt nutzbar ist. Erst Falcon030 hat hier etwas addiert, in 1992. Daher hat der Amiga praktisch die Graphikstudios dominiert, niemand sonst war so gut.)

(Der Atari 800 kann bereits Overscan, wenn auch weit beschränkter. Dies mit fest horizontal 352von384 statt 320 Pixel (und auch Unterscan mit 256 statt 320 Pixel um Speicherplatz und Bandbreite zu sparen). Sowie vertikal die Zeilenfolge durch die Displayliste gesetzt und damit auch Zeilenmenge, standard 192, maximal 240.)

(Der C64 hat kein Overscan. Situation identisch wie beim ST. Vermutlich haben die ST Designer wegen ex Commodore, mit PET und C64 hinter sich, schlicht den Bedarf für Overscan gar nicht gekannt. Weil der Aufwand für eine Minimalversion wäre wenig gewesen, nur ein Timing Konfigurationsbit im GLUE für 384 statt 320 bzw 720 statt 640 Pixel sowie 224 statt 200 bzw 448 statt 400 Zeilen, mit dazu noch im MMU 40320 von 64k statt 32000 von 32k Bildspeicher durchzählbar.)

Ebenso kann der Amiga Interlace, für volle Bildfläche abdecken ohne streifiges Bild. Fernsehen erzeugt eigentlich ein Bild, das aus doppelt so viele Zeilen besteht, aber mit halber Frequenz. Nur das würde flackern. Also werden die Zeilen in 2 Halbbilder aufgeteilt, mit abwechselnd gerade und ungrade Zeilen senden. Was die Bildfrequenz verdoppeln erlaubt, ohne halbe Zeilenzahl. Das nennt man Interlaced (i). Aber davon tut das Bild flimmern. Gerade auch wo es scharfe Helligkeitsunterschiede an horizontalen Kanten hat, was Rechner voll trifft. Weshalb sie zumeist ihr Timing derart einstellen, das die Zeilenverschiebung entfällt, halbe Zeilenzahl aber volle Frequenz. Das nennt man Progressive (p). Strikte hat NTSC 240p oder 480i und PAL 288p oder 576i.

Auf Interlace schalten ist wieder optimal für Kunst oder Illustrationen, da diese zumeist keine scharfen Kanten haben. Es wird noch besser, wenn man photographiert, mit einfach 2 Halbframes ausgeben, doppelte Zeilenzahl auf dem Photo, das selber niemals flimmern kann. Der Amiga 3000 addierte einen Display Enhancer, der Interlace in Progressive umwandelte, mit VGA HD15/DE15f Videostecker.

Ebenso kann der Amiga Gensync/Genlock, für Videobearbeitung angefangen mit Untertitel. Fernseher müssen bei jedem Senderwechsel neu synchronisieren, was früher kurzzeitig durchlaufendes oder steifiges Bild erzeugte und heute abgedunkelt wird. Dies wäre bei im Fernsehstudio zwischen Kamerawinkel umschalten nicht akzeptabel. Folglich müssen alle Kameras zu einander synchron laufen, was Gensync heisst. Dazu gibt ein zentraler Taktgenerator vor, und alle anderen synchronisieren damit, was Genlock heisst. Der Amiga kann auch zu so einem synchron laufen.

Synchron gilt erst recht bei Videoeffekte wie Bild überlagern oder Untertitel addieren, weil diese sonst herumschwimmen. Dazu wird ein Bild genommen, das mit einem hell/dunkel Muster vorgibt, wo zwischen zwei Kameras ihre Bilder als Ausschnitte geschaltet werden. Das nennt man Keying. Als Spezialversion davon kann man Elemente in ein anderes Bild einsetzen, mit diese vor einem scharfen blauen oder grünen Hintergrund filmen und alle Pixel dieser Farbe mit dem separaten Hintergrundbild ersetzen. Das nennt man Chromakey. Der Amiga kann nicht nur Gensync/Genlock sondern auch Chromakey, mit einer Farbtabelle Nummer als durchsichtig interpretieren, oder ab ECS gar ein separates 1bpp Bild dazu benutzen. Weiter gab es sehr bald als Erweiterung zum Amiga Photodigitalisierung oder gar Videodigitalisierung.

(Der ST hat auch kein Interlace, nicht mal die erweiterten STE oder TT. Es hat schlicht gar keine Möglichkeit hier Er hat erstaunlicherweise Genlock/Gensync, trotz wenige Farben und kein Overscan oder Interlace. Dazu war es erst noch defekt implementiert, weil interne Taktfrequenz von externem Sync gesteuert wurde, mit deswegen Pixelzeit Rundungsfehler und davon horizontal "zitternde" Zeilen. Womit dies real praktisch unbenutzbar war, einfach ignoriert wurde. Dies wurde beim STE sogar leicht ausgebaut, diesmal Pixelsynchron, blieb aber trotzdem unbedeutend. Bei TT030 verschwand es sinnvollerweise. Daher hat der Amiga praktisch Videostudios dominiert, niemand sonst war so gut.)

Amiga: Spiele

Hier zählen stattdessen weitere spielespezifische Erweiterungen. Genau darin ist der Amiga Chipsatz massiv im Vorteil, weil vom Atari 800 gross erweitert, der wiederum vom VCS/2600 erweitert wurde, also von Grund auf für spielen ausgelegt worden ist!

Rechner ohne dies, wie ST, können nur mit mehr Prozessor und Speicher ausnutzen teilweise kontern. Man kann diese Situation vergleichen mit PCs etwa um 2000. Damals hatten GamerPCs bereits GPUs, aber BüroPCs mit Chipsatzgraphik keine. Letztere konnten zwar spielen, aber nur so lange einfachere Spiele gewollt waren, siehe Windows Solitaire. Genauso kann der ST spielen, aber es reicht nur für einfachere Spiele. Man kann es aber auch kontrastieren mit dem Trio von 1977, alle hatten keine GPUs. Aber damals war der Apple II der GamerPC, nur wegen Bitmapgraphik und Farben und Audio und Joysticks haben! Während PET und TRS80 lediglich Text+Blockgraphik in Schwarzweiss ohne Grau sowie nur Tastatur hatten, kein Audio oder Joysticks. Wobei dann in 1979 deren Revisionen so blieben, aber der Atari 800 dazukam. Womit dieser jetzt der GamerPC wurde, und Apple II Plus keiner mehr war, weil abgehängt. Genauso kann der ST als vierfacher Apple II Plus spielen, aber nicht wie Amiga als vierfacher Atari 800. Frage ist also immer, ob/wo der ST ausreicht und wann/wieviel der Amiga mit was davonziehen kann.

Bei einfachem wie Brettspiele oder Kartenspiele reicht strikte sogar Schwarzweiss. Daher gibt es solche sogar auf dem Mac, trotz dass Apple sich gezielt von Spielen distanziert hat. Der ST kann bei solchen seine 640x400 und 12" ausnutzen, 50% über Mac 512x342 und 9". Dazu noch 8MHz Prozessor über 6von7.883MHz, und 512oder1024k RAM über 128oder512k. Womit er, wie schon bei Text/Tabellen/Datenbanken, den Mac einfach an die Wand spielt. Diesmal wörtlich so.

Selbiges gilt bei Adventure und RPGs, solange keine Farben gewollt oder gar notwendig sind. Der Amiga kann dabei aber versuchen mit 5oder6bpp und mehr Farben bei Illustrationen zu punkten. Bereits bei 4bpp ausreichend kann der ST ja mithalten, bei 2bpp sogar PC/XT/AT CGA, bei 1bpp selbst der Mac. Das wird somit nur relevant, wenn viele Farben gewollt sind, oder auch nur nützlich sind. Dies geht wegen 5bpp oder gar 6bpp mit Bremse nur gut bei illustrierten Rollenspielen, welche ohne schnelle Action keine hohe Prozessorleistung brauchen. Diese passen erst recht wenn zusammen mit dem Amiga seiner grösseren Floppy, für mehr Spielwelt. Siehe die ganzen "Cinematic" Stil Spiele beim Amiga.

Ansonsten ist bis 4bpp der ST rein billiger, und dieses ist oft brauchbar. Siehe hierzu das Adventure "Another World". Spielemässig ist es mehr Illustrationen denn Action, weil ein Adventure. Es wurde für beide Amiga und ST parallel entwickelt. Mit unter anderem gezielt nur 16 Farben benutzt wegen ST. Was der Autor aber als eine gute Limite anschaut, weil diese genau auswählen eine spezielle flache Ästhetik definierten, welche mehr an Comic/Cartoon gezeichnet errinnert als an Film/Fernsehen photographisch, und damit zeitlos wirkt. (Selbigen Effekt sieht man auch bei Nintendo, deren limitiertere billigere Hardware zu Comic/Cartoon Graphik führte, welche zeitlos wirkt, im Gegensatz zu Sony und Microsoft deren 3D Renderei bald von besserer Graphik überholt wird und dann veraltet aussieht.)

(Aber egal welcher besser passt, dieses Gebiet können viele andere Rechner genauso gut, oder besser, oder zumindest billiger. Schon seit 1977 hatten Apple II und II Plus ihr Hires 8k und Split Screen Modus für Illustration plus Text. Sie dominierten bald Adventure und RPGs. Das wurde verbessert in 1983 mit Apple IIe sein Double Hires 16k. Selbst Atari 800 und C64 konnten solche schon, in 1979 und 1982, und addierten mit ihren Sprites weit bessere Action. Zwar kamen in 1985 ST und Amiga mit 32k, aber schon 1986 zieht Apple IIGS mit 32k gleich. Er liefert zwar keine 5oder6bpp, aber immerhin 16von4096 Farben (wie STE), erst noch pro Zeile auto-schaltbare 16 Sätze von je 16 (schaltbar kam erst mit TT030 und nicht auto), und das zu 8bit Preis. Dann zog 1987 der PC nach, von der schrottigen CGA 2bpp mit 16k und versagten PCjr 4bpp mit 32k und teuren EGA 4bpp mit 4*28=112k zu den gutem 8bpp MCGA mit 64k und inzwischen bezahlbaren 4bpp VGA mit 4*38=152k. Dies erst noch zusammen mit 1440k Floppy (oder gar mit Harddisk Install mehrerer Floppys). All dies ist noch vor auch nur A500 und A2000 erscheinen, geschweige denn STE oder ECS, oder gar TT030 und AGA. Nur der geringere Preis und trotzdem 16bit haben die ST und Amiga hier voraus, fallen so aber oft zwischen 8bit billig und PC leistungsfähig durch.)

Amiga: Sprites

Um zu verstehen wie sie das soviel besser können, siehe wie aufwendig ein Spiel programmieren auf einem Rechner ohne Sprites aussieht, wie eben ST (oder PC/XT/AT oder Mac): Als erstes muss jedes bewegliche Objekt in den bereits gezeichneten Hintergrundbild eingefügt werden. Dazu muss jedes Wort vom Objekt seinem Datenmuster ins Bild kopiert werden. Dieses Muster ist aber wegen 16 Pixel pro Wort und das in allen Zeilen vom Muster als rechteckiger Block definiert. Dessen Ecken könnten bei nicht-rechteckigem Objekt ohne weiteres mit dem sichtbar bleiben sollenden Hintergrund überlappen, oder bei beliebigen Formen mit anderen bereits eingefügten Objekten, was Teile davon löschen würde, was Bildfehler ergibt. Also muss dieses einfügen auch noch mit OR Funktion statt nur MOVE gemacht werden, was etwas länger braucht, weil 3 statt 2 Speicherzugriffe pro Wort an Pixeldaten.

Des weiterem könnte an der Stelle bereits ein anderes Objekt oder Hintergrund schon stehen, dessen Daten aber bei OR statt MOVE mit den neuen Objektdaten vermischt werden, was zu falschen Bitmustern führt, auch Bildfehler. Diese müssen daher zuerst entfernt werden, aber nur dort wo das neue Objekt hinkommt ausgestanzt, weil sonst ein Loch entsteht, wieder Bildfehler. Was nach AND Funktion verlangt, mit als Daten dazu eine Objektform ihr Datenmuster benutzt. Weitere 3 Speicherzugriffe pro Wort.

Aber nach einfügen muss ein bewegliches Objekt wieder entfernt und an anderem Ort eingefügt werden. Wozu vor einfügen zuerst der betroffene Hintergrund zuerst weggespeichert werden muss, um ihn zwecks Objekt entfernen wiederherzustellen. Letzeres ebenfalls als ganzes Rechteck in dem das Objekt stets passt, egal um wieviele Pixel es verschoben ist. Wegen Objekt pixelweise bewegt einfügbar muss das auf Worte ausgerichtete Abspeicherrechteck zudem ein Wort breiter breiter sein. (Strikte wird bei n*16 Pixel Objekt in (n+1)*16 Pixel Feld in einer Stellung die extra 16 Pixel unbenuzt sein. Weshalb man darin bis zu n*16+1 Pixel an Objekt haben kann, ideal für rechts-links symmetrische Objekte mit vertikaler Mittellinie von 1 Pixel breite.)

Am Schluss ist jede Bewegung eine ganze Litanei: Alter Ort wiederherstellen MOVE und neuer Ort Abspeichern MOVE, beide diese auf ausreichend breitem Block, dann Ort bestehendes ausstanzen AND und Objekt einfügen OR, beide diese auf Pixel verschoben. Zusammen sind das 2+2+3+3=10 Speicherzugriffe pro Wort an Pixeldaten. All das mal Worte pro Zeile, mal Zeilen im Objekt! Ein 16x16 Pixel Objekt sind 16Zeilen*4Worte*10=640 Speicherzugriffe an Daten. Ein 32x32 vier mal mehr. Ergibt viel Zeitverbrauch.

Dies alles wird weiter noch unnötig ausgebremst, weil ST (und auch Amiga sowie EGA) Bitplanes benutzen statt Chunks (wie Atari 800 und VC20 und C64 und CGA und CPC). Dabei werden die 2 oder 4 Bits eines einzelnen Pixels über gleichviele Worte verteilt, stets selbiges Bit von allen 16 Pixeln in einem Wort, alle Bits in 2 oder 4 Worte, zuerst das Wort mit allem Bit0, dann Bit1, und bei 4bpp weitere Worte Bit2 und Bit3. Dies statt bei Chunks 2 oder 4 Bits als Bitgruppen in einem Wort untergebracht, was 8Pixel*2bpp oder 4Pixel*4bpp in einem einzelnen 16bit Wort packt.

Dies wurde bei Programmierern sehr schnell äusserst unbeliebt, weil umständlich und langsam. Gerade bei den für Spielen idealen 4bpp Pixel verhindert dies Objekte einfach als Serien von passenden 4bit Hexziffern zu definieren. Wobei man dies noch verstecken kann, mit in Hexziffern designen und dann automatisch umrechnen/umsortieren lassen.

Viel schlimmer müssen Objekte in 16Pixel statt 4Pixel breiten Streifen eingefügt (plus weggespeichert und wiederhergestellt) werden, was insbesondere bei horizontal schmalen Objekten bis zu viermal mehr Daten schaufeln verlangt (und ebenfalls so bei schmalen Hintergrund Bauelementen). Dies wegen in 4* 16Pixel Worte = 64bit arbeitend statt nur in 1* 4Pixel 1 Wort = 16bit. Dazu kann man nicht Paare von 16bit Worte schnell mit der 68000 ihrer 32bit Long Arithmetik pixelweise verschieben, weil bereits ohne Paare schon 1oder2* 32bit breit. Auch nur Text ausgeben braucht 2 oder 4 Halbworte statt einfach in 1 oder 2 Worte zu passen. Was alles Ineffizient ist. Mehr Zeitverbrauch.

Neben Daten umkopieren muss der Prozessor auch noch Programm holen, um zu wissen was zu tun. Für die mehreren Worte eines Objektes braucht es zudem noch Kopierschleifen, welche neben dem eigentlichen Datentransfer auch Worte zählen und pro Wort von Anfang wiederholen, was noch mehr Zeit kostet. Diese kann man meiden durch Schleifen ausrollen, ihren Programminhalt mehrfach hinstellen, um Zählen und Sprung zu Anfang einzusparen, für halbwegs schnell sein, wenn auch zum Preis leicht grösserer Programme. Zumindest solange eine feste Menge Worte angezielt werden, oder mehrere Routinen für wenige oft benutzte Wortanzahlen vorhanden sind. Zumindest horizontal geht dies, wo ohnehin die Bitplanes abgeklappert werden müssen, auch gleich die Wortserien danach. Aber auch vertikal, wenn man ein paar Standard Objektgrössen definiert. Selbst so ist mindestens mit pro 2 Worte MOVE/AND/OR LONG mit 1 Wort Programm zu rechnen, also +1/4 bei MOVE und +1/6 bei AND/OR. Obige 640 Speicherzugriffe werden zu 768, bestenfalls.

Wenigstens hilft die 68000 bei all diesem, weil man 4 Adresszeiger auf Objektform plus Objektmuster sowie Bildspeicherort und Wegspeicherort setzen und in beliebiger Reihenfolge benutzen kann! Damit kann man zumindest die 3 Operationen wegkopieren und Form ausblenden und Muster einblenden in einem Rutsch machen! Aber all das für Pixel/16 Worte, mal die zumeist 4 Bitplanes, dann mal horizontale 16Pixelgruppen, und dieses mal vertikale Zeilen.

Als schlimmstes kommt noch, all das mal die Anzahl bewegender Objekte im Bild, wie eine ganze Flotte angreifender Aliens in Space Invaders. Dies alles multipliziert sich zu sehr aufwendig, einem gnadenlosen Angriff auf den Prozessor, Space Invaders werden dann praktisch zu Prozessor Invaders. All das muss zudem in für Animation genug geringer Zeit geschehen. Die obigen 16x16 Pixel 768 Speicherzugriffe brauchen 384µs, 0.384ms. Wenn 10fps Bewegungen die sehr tiefe unterste Limite sind, hat man 100ms, passen theoretisch maximal 260 mal 16x16 Pixel Objekte hinein. Falls flüssigere 30fps und 32x32 gewollt sind, sind das noch 260/3/(2*2)=23 Objekte. Praktisch sind es weniger als das, weil der Rechner ja noch Spiellogik abarbeiten muss. Viel Spass wenn es deswegen ruckelt!

Wo die 68000 schwach wird und versagt ist Objekte auf einzelne Pixel in Worte zu verschieben, sobald eine horizontale Bewegung genauer als 16 Pixel benötigt wird (und das sind bei 320x200 Modus immerhin zwei der 40 Schriftzeichen an Breite!). Darin ist sie gnadenlos langsam. Also braucht es vorgeshiftete Objektformen und Objektmuster im Speicher, wozu der ST aber wenigstens noch viel Speicher an Platz hat. Wenn auch wieder wegen den Bitplanes dazu 16 statt nur 4 Kopien im Speicher notwendig werden! Noch schlimmer weil ohne Bitplanes solches verschieben nur bei Bewegung genauer als 4 Pixel (statt 16 Pixel) überhaupt notwendig wäre (was ein halbes Schritzeichen Breite ist), und dieses verschieben falls vorzu gerechnet erst noch nur 1/4 Zeit brauchen würde. Bitplanes sind bei Programmierern genau deshalb so äusserst unbeliebt!

Man kann wenigstens diesen Prozessorbedarf über die ganze Bilddarstellzeit verteilen, weil jede Bildzeile nur kurz (etwa 40µs) angezeigt wird, und dann andere dran sind. Solange man jede Zeile vor ihrer Ausgabe fertig hat, und erst nach ihrer Ausgabe wieder an ihr ändert merkt niemand etwas. Aber ob man dies auch ausnutzen kann ist zudem abhängig davon, ob die auf ganze Worte ausgelegten Wegspeicher Rechtecksausschnitte einander überlappen! Ohne dies ist sie wiederherstellen kein Problem, einfach in selbiger Reihenfolge alle raus wie es reinkam, von oben nach unten.

Aber mit überlappen muss zuerst der später wegkopierte, der eventuell Teile des zuerst eingefügten Objektes in sich hat, wiederhergestellt werden. Erst danach kann an den ersten wiederherstellen, sonst verbleiben wieder Bildfehler. Siehe ein rundes Alien in seinem Wegspeicherrechteck ist schon dort und ein dreieckiger Spieler in seinem Rechteck fliegt knapp daran vorbei. Dessen Leeranteil vom Rechteck geht durch das Alien, keine Kollision, keine Explosion, kein Game Over, aber das Wegspeicherrechteck vom Spieler hat einen Teil vom Alien drin. Dieses erst nach dem Alien verschieben wiederherstellen würde einen Teil von diesem dort "liegen lassen".

Nur heisst das schlimmstenfalls bei allen Objekten umgekehrt vorgehen, und damit nicht von oben nach unten hinein und hinaus, parallel zu Zeilen ausgeben. Aber einfach alle von oben nach unten rein und dann unten nach oben raus reduziert die nutzbare Prozessorzeit massiv, auf nur wenn kein Bild ausgegeben wird, während der Monitor nach von oben nach unten zeichnen wieder von unten nach oben positionieren muss, was als vertikalen Rücklauf bekannt ist. Was aber nur etwa 1/4 der Zeit ist, somit 3/4 Prozessor zu Leerlauf machen würde! Also muss man selektiv reversieren, einzelne nicht überlappende Objekte geradeaus von oben nach unten, aber Gruppen von überlappenden reversiert, was Komplexität der Software verlangt und Prozessorverbrauch weiter nach oben treibt. Dies macht zudem noch die Laufzeit unvorhersehbar, und deren Maximum limitiert die Anzahl nutzbarer Objekte, weil sonst ruckelts. Viel Spass dabei!

Weshalb man irgendwann auf Doublebuffering und Compositing umstellen muss. Wonach gar nicht mehr wegspeichern und wiederherstellen geschieht! Vielmehr wird dazu ein zweiter Bildspeicher angelegt, eben der doppelte Buffer. Dann wird er gelöscht und mit neuem Bild von Null aufbauen gefült, dem Compositing. Nach fertigzeichnen wird auf diesen anzeigen umgestellt, und während er sichtbar ist der alte gelöscht und mit drittem Bild von Null gefült, daher eben kein wegspeichern notwendig. Danach wieder umschalten, löschen und viertes, und so weiter. Was zwar kein bestehenden Bild wiederherstellen braucht, aber auch nichts davon behalten erlaubt, ganzes neu zeichnen braucht, was erst recht lange dauert!

Allerdings kann man auch ein Bild mehrere Frames lang anzeigen lassen, und somit Prozessorzeit aufsammeln. Je nach wie ruckelig akzeptabel ist, kann man bei 2/3/4/5/6 Frames anzeigen mit 30/20/15/12/10fps (Frames per Second) durchkommen. Und man kann bei aus Bildelementen durch Compositing zusammenstellen oft auf vorgeshiftete Elemente verzichten, zumindest solange der Hintergrund aus n*16 Pixel breiten Teilen/Streifen zusammengesetzt wird, ebenso kann man dabei nur MOVE statt AND plus OR benutzen, nur die beweglichen Objekte brauchen vorshiften und AND plus OR. Und die Bitplanes stören auch nicht mehr.

Immer wieder ganz von Null aufbauen kann man auch etwas kürzen mit in drittem Bildspeicher alles Stillstehende einmal zeichnen und halten. Gefolgt von nur dieses einkopieren statt löschen und aufbauen. Wobei 32000 Bytes einkopieren mit aggressiv ausrollen 5 Speicherzugriffe pro 2 Worte braucht, bei 32000Byte/16000Wort einkopieren (16000/2)*5=40'000, was 20'000us=20ms ist. Bei 1 Frame=16ms verbleiben mit je 2 mal anzeigen nur noch (32-20=12)/32 = 3/8 Prozessor für bewegte Objekte addieren, mit 3 mal anzeigen (48-20=28)/48 = 7/12, mit 4 mal (64-20=44)/64 = 11/16. Als Vergleich: Ein Frame löschen ohne etwas einkopieren ist 3/5 davon 12ms. Einkopieren ganzes Bild ist 20ms, unter dies kommt man, wenn weniger als 20-12=8ms einkopieren, also wenn mehr als 3/5 vom Bild leerer Hintergrund ist, wie der ganze Platz wo die Objekte sich bewegen.

Das nächste Stillstehende muss aber auch noch aufgebaut werden, was auch einen Teil der Zeit braucht. Weil das bestehende in der Zeit noch benutzt wird, verlangt dies nach ebenfalls zwei Stillstehbuffer, einkopierer und aufbauer, ebenfalls abwechselnd, also insgesammt vier Bildspeicher. Und Softwareaufwand. Und Prozessorverbrauch. Ich hoffe, die massiven Probleme mit diesem Ansatz sind nun klar!

Auf ST (oder PC/XT/AT oder Mac) hat man keine andere Wahl als das. Wenn auch ein MCGA 320x200 8bbp (und VGA in diesem Modus) wenigstens Chunks statt Bitplanes hat, somit 1 16bit Wort nur noch 2 Pixel sind, maximal schnell kopierbar und keine vorgeshiftete Kopien mehr notwendig.

Die bessere Alternative dazu sind Sprites, was der Amiga kann. Deren Datenmuster werden aus einem separaten Speicherausschnitt geholt. Sie brauchen so gar kein einfügen ins Bild, folglich auch kein ausstanzen vom Hintergrund, also auch kein dieses wegspeichern und wiederherstellen. Ebenso keine Kopierschleifen oder ausrollen. Auch keine vorgeshiftete Objektformen und Objektmuster. Ebenso keine Kollison von Wegspeicher Rechtecken, sowie keine komplexe Progammlogik dagegen. Das ist weit schneller! Die ganze Prozessorleistung bleibt frei für Spiellogik und Hintergrund modifizieren, oder auch nur Hintergrund mit Doublebuffering aufbauen, ohne jegliche Stillstehbuffer.

Der Trick besteht darin, dass der Spritegenerator im Videogenerator die verschiebbaren Objekte separat von ausserhalb vom Bildspeicher abholen kann. Dazu nutzt er die Zeit in der kein Bild ausgegeben wird, weil der Monitor nach einer Zeile von links nach rechts zeichnen wieder sich von rechts nach links positionieren muss, was als horizontalen Rücklauf bekannt ist. Eine Zeile ist 63.5µs bei NTSC und 64µs bei PAL, bei Amiga 28 8er Pakete an Zeitslots (bei ST 32). Davon werden bei Amiga Standardmodi (und ST stets) 20 fürs Bild ausgeben benutzt. Was je nach genutzter Bildausschnittbreite etwa 1/5..1/3 der Zeilenzeit frei lässt. In dieser werden die Video Zeitslots vom Speicher nicht benutzt. Also kann ein Spritegenerator die separaten Objektformen und Objektmuster auf Vorrat von ausserhalb des Bildspeichers holen.

Logisch sind diese Daten nicht sofort ausgebbar, werden also im Spritegenerator zwischengespeichert. Während danach die Zeile ausgeben kann dieser sie zu einem einstellbaren Zeitpunkt mit den Bilddaten zusammen gemischt ausgeben, durch sie im Vorbeigehen ins Bildsignal einblenden, trotz sie nicht im eigentlichen Bildspeicher eingefügt sein. Womit eben der riesige Aufwand vermieden werden kann. Dabei wird Spritepixel gleich 0 als Objektform durchsichtig gewertet und dort das Bild vom Bildspeicher als Hintergrund angezeigt, aber Pixel ungleich 0 als Objektmuster angezeigt. Ein Objekt horizontal verschieben braucht nur den Zeitpunkt zu verstellen, eine simple Addition zu einer Zeitpunkt Zahl, keine massive Kopiererei. Das ist schnell!

Um dies sinnvoll zu nutzen werden mehrere Sprites geholt und jede an ihren eigenen Ort eingefügt, was mehrere bewegte Objekte erlaubt. Dies geschieht im Amiga mit AGNUS die Daten holen und DENISE sie intern speichern und dann einblenden. Es sind 8 Sprites zu je 2 Worte pro Zeile. Als Vergleich: Die Zeile selber ist bei 320 Pixel 4bpp 80 Worte, also addiert dies (8*2=)16/80 = 1/5 an Daten. Diese je 2 Worte beinhalten 16 Pixel breite Objekte mit 2bpp, dabei gilt 0=durchsichtig/Hintergrund als Objektform und 1..3=3Farben als Objektmuster. Auch diese 2 Worte sind als Bitplanes, zuerst Bit0 dann Bit1. Im Kontrast zu den Sprites wird der Hintergrund als Playfield bezeichnet. Sprites geben horizontal nur im 320 Pixel Raster aus, um bei ihrer limitierten Bitmenge doppelt so breit zu sein. Ebenfalls sind sie nur in diesem Raster positionierbar, selbst wenn das Playfield im 640er Raster läuft! Die Position 0 ist übrigens ausserhalb vom Bild, ebenso die max 447, Bild ist eben 448/16=28 Worte pro Zeile, mit sichtbare Pixel von 64 bis 383 laufend, als 320/16=20.

(Bei Atari 800 geschieht dies mit ANTIC die Daten holen und CTIA/GTIA sie intern speichern und dann einblenden. Es sind 5 Bytes (statt 16 Worte), als 4 volle "Player" Sprites zu je 1 Byte pro Zeile, plus 4 kleine "Missile" Sprites zu 2 Bits pro Zeile, welche aber zu einem fünften 1 Byte "Player" zusammensetzbar sind. Diese Bytes beinhalten 8 Pixel breite Objekte mit 1bpp, dabei gilt ebenfalls 0=durchsichtig/Hintergrund als Objektform und 1=1Farbe als Objektmuster. Sprites geben horizontal maximal im 160 Pixel Raster aus, um bei ihrer limitierten Bitmenge doppelt so breit zu sein. Man kann sie auch pro Sprite schaltbar auf 80 oder 40 Raster reduzieren. Ebenfalls sind sie nur in 160er Raster positionierbar, selbst wenn das Playfield im 320er Raster läuft, womit Position in 8bit Register passt. Position 0 ist ebenfalls ausserhalb vom Bild, ebenso die max 255, Bild geht von 47 bis 208.)

(Bei C64 geschieht dies alles mit VIC-II, holen und intern speichern und dann einblenden. Es sind 24 Bytes, als 8 Sprites zu je 3 Bytes pro Zeile. Diese Bytes beinhalten schaltbar 24 Pixel mit 1bpp oder 12 Pixel mit 2bpp, dabei gilt ebenfalls 0=durchsichtig/Hintergrund als Objektform und pro Sprite schaltbar 1=1Farbe bzw 1..3=3Farben als Objektmuster. Letztere wie Hintergrundpixel als Chunks. Sprites geben horizontal 1bpp im vollen 320 Pixel Raster aus, und 2bpp im 160 Pixel Raster, weil so viele Pixel. Man kann sie auch pro Sprite schaltbar mit Doppelbreit Modus auf 1bpp 160 Pixel oder gar 2bpp 80 Pixel strecken. Sie sind stets im 320er Raster positionierbar, was 1+8=9bit an Position Register braucht.)

(Bei TMS9918 geschieht dies alles mit VDG. Es sind 8 Bytes, als 4 Sprites zu je 2 Bytes pro Zeile. Diese sind 16 Pixel mit 1bpp. Ausser alle Sprites zusammen sind auf 8 Pixel 1bpp reduziert. Im vollen 256 Pixel Raster, oder alle Sprites zusammen auf 128 Pixel Raster schaltbar. Aber stets in 256er positionierbar.)

Dazu braucht es noch weil mehrere Sprites überlappen können eine Prioritätslogik, welche feststellt, welche Sprites ihre Objektmuster vor/hinter welchen anderen erscheinen. Dies ist beim Amiga fest Sprite 0 vorne und Sprite 7 hinten. Weiter kann es sogar Sprites hinter Teile vom Playfield verkriechen lassen, dort wo dessen Pixel nicht Farbe 0 ist. Wobei Sprites in Gruppen 0+1 2+3 4+5 6+7 sind, und davon 0/1/2/3/4 Paare vor dem Playfield erscheinen, gesteuert von Register BPLCON2. Überlappen sich nicht-0 Pixel von mehreren Sprites oder von Sprite und Playfield wird dies zudem nebenbei als Objektkollision vermerkt in Register CLXDAT, damit Treffer auch zu Explosionen führen, ohne komplexe Trefferzonen Rechnung. Nett!

Als Seiteneffekt von die passenden Farben vom sichtbaren Pixel erkennen und übersteuern, können Sprites eigene Farbtabellen Einträge nutzen! Dem Amiga seine 32von4096 Farben sind eigentlich gedacht als 16 für 4bpp Hintergrund plus 16 für Sprites. Die Sprites 0+1 haben 3 Farben in 17..19, 2+3 in 21..23, 4+5 in 25..27, 6+7 in 29..31. So kommt man mit ihnen auf 16+4*3=28 Farben ohne Prozessor bremsende 5bpp. Geil! Man kann auch die jeweiligen Spritepaare zusammenlegen zu 4bpp, womit sie die 15 Farben 17..31 nutzen, mit Bit0 und Bit1 im ersten Sprite sowie Bit2 und Bit3 im zweiten. Das halbiert aber deren Anzahl. Ebenso kann man Sprites breiter machen, durch mehrere davon synchron bewegen. Das reduziert die Anzahl ebenfalls, beides zusammen nochmals mehr.

(Bei Atari 800 sind es 5 Hintergrund plus 4 Sprite Farben aus 128. Die vier "Missile" haben die Farbe ihres passenden "Player". Sie können aber auch zusammengelegt die fünfte Hintergrund Farbe nutzen.)

(Bei C64 sind es nur 16 feste Farben, mit davon Hintergrund je nach Modus 1oder2oder3 pro 8x8 Pixelzelle und restliche ganzes Bild, plus 8 Sprites mit 1 pro Sprite wenn 1bpp plus 2 gemeinsame für alle mit 2bpp.)

(Bei TMS9918 sind es auch feste Farben, mit davon Hintergrund 2 pro 32er Satz an Zeichencodes(!) oder pro 8x1 Pixelzeile, plus 4 Sprites mit 1 pro Sprite.)

Neben horizontal den Zeitpunkt abwarten können Sprites aber auch vertikal erst ab einer spezifizierten Zeile aktiv sein, für eine ebenfalls spezifizierte Menge an Zeilen. Im Amiga ist dies maximal ganzes Bild hoch, aber um Speicher zu sparen auch kürzer. Auch hier ist vertikal verscheiben nur die Anfangszeile verstellen, wieder eine simple Addition zu einer Zeitpunkt Zahl. Auch hier sind sie nur auf 200 oder 256 positionierbar, selbst wenn Playfield im 400 oder 512 interlaced Raster läuft. Die Position 0 ist ebenfalls ausserhalb vom Bild, ebenso die max 262, mit sichtbare Zeilen von 44 bis 243 (NTSC) oder 299 (PAL) laufend.

(Bei Atari 800 sind die Sprites stets ganzes Bild hoch, im Speicher als 256Byte Streifen. Vertikal verschieben ist mit im jeweiligen Streifen umkopieren. Dies kann man aber ohne wegspeichern und AND und OR machen, weil der ganze nicht-Sprite Anteil vom Block stets 0 sein muss. Also muss man Sprite nur umkopieren und freiwerdende Zeilen mit Nullen löschen. Man kann alle Sprites auch mit Zeilenwiederholung aus 128Byte Streifen nehmen um Speicher zu sparen.)

(Bei C64 sind es stets 21 Zeilen, im Speicher als Block von 21*3=63 Bytes. Auch hier kann man pro Sprite schaltbar mit Doppelhoch jede Zeile zweimal ausgeben lassen. Vertikal verschieben ist in Register einzustellen wie horizontal, hier mit nur 8bit Register.)

(Bei TMS9918 sind es 16 Zeilen, im Speicher die 16x16 als 4 Teile von je 8x8, ausser alle Sprites zusammen auf nur 1 8x8 reduziert. Auch hier alle Sprites zusammen auf Doppelzeilen schaltbar, gleichzeitig mit dann 128er Raster. Vertikal mit Register wie horizontal.)

Danach kann man den selbigen Spritegenerator für weitere Objekte recyclen, um so zu mehr Sprites zu kommen. Dabei werden die Position und Höhe pro Gebrauch des Spritegenerators neu geladen. Genauer besteht eine Spritedefinition beim Amiga aus 2 Worten Spritekonfiguration SPRxPOS und SPRxCTL (mit x=0..7 je nach Sprite), dann Zeilen * 2 Worte Spritedaten, dann 2 Worte Fortsetzungsinfo. Die SPRxPOS beinhalten Vertikal Anfang Bit15..8 und Horizontal Bit7..0, sowie SPRxCTL noch Vertikal Ende Bit15..8 und diverse Steuerbits (Bit7 zusammenlegen zu 4bpp im zweiten Sprite, Bit2 V Anfang Bit8, Bit1 V Ende Bit8, Bit0 H Bit8). Ein Sprite horizontal verschieben braucht nur SPRxPOS untere 8bit anpassen. Dazu reicht ein ADDQ.B Befehl mit nur 3 Speicherzugriffe, statt obigen 768, 256 mal schneller. Vertikal verschieben muss beide obere 8bit anpassen, zweimal ADDQ.B, immer noch 128 mal schneller. Das ist Power!

Die Spritekonfiguration landet in Chipsatz Registern, alle Adressbits in AGNUS, plus alle Zusammenlegmodus in DENISE. Dies geschieht auf der ersten Zeile nach Bildanfang resetten im vertikalen Rücklauf. Es wird gefolgt von bis Zeile in Vertikal Anfang abwarten und dort ausgeben einschalten, mit ab und inklusive dieser immer 2 Worte Spritedaten, bis zu aber nicht mehr inklusive die Zeile mit Vertikal Ende. Mit dort zwar auch holen, aber statt ausgeben als Fortsetzung erneut in SPRxPOS und SPRxCTL laden und wieder warten. Mit 0+0 bei letztem Gebrauch vom Spritegenerator, was als bereits "vorbeigegangene" Zeile nicht mehr aktiv werden wird. Womit die Spritedefinition zu einer Definitionsliste mit Nullterminierung wird.

Nach einer solchen Spriteserie definieren wird diese angemeldet durch SPRxPTH+L (auch x=0..7) auf die Anfangsadresse deren Definition stellen. Diese muss aber wegen SPRxPTH+L beim holen der Spritedaten pro Wort um +2 rechnen bei jedem Bild im Vertikalrücklauf neu gesetzt werden. Das alles treibt zwar die Softwarekomplexität leicht nach oben, aber weit weniger als alles umkopieren organisieren, gerade auch wenn Überlappung geschieht. Das Resultat ist es also locker wert!

(Bei Atari 800 sind die 4 "Missiles" fest im vierten und die 4 "Player" fest in den fünften bis achten von acht 256 Streifen in einem einzelnen 2kByte Speicherblock.)

(Bei C64 sind die 8 Sprites stets 63von64 Byte Blöcke, mit einem 8bit Blockindex, der aus einem 16kByte Speicherblock auswählt. Diese Blockindizes werden in den letzten 8 Bytes vom Textvideospeicher abgelegt, der ja nur 40*25=1000von1024 Bytes benutzt.)

(Bei TMS9918 sind die 4 Sprites im Fontspeicher, je 8x8 Pixel einfach eine normale Zeichenzelle von 8 Bytes, ein Sprite ein Satz von 4 Zeichen aus den 256, ausser auf 8x8 geschaltet nur 1 Zeichen von 256.)

Man kann sogar die Spritegeneratoren rekonfigurieren abseits obiger Automatik, egal ob wartend auf 0 oder beliebigen anderen Wert, die beiden bereits gelesenen Worte im Chip modifizieren! Nur ein Test auf aktuelle Zeile = momentan in SPRxPOS Vertikal startet Sprite ausgeben, nur Test auf aktuelle Zeile = momentan in SPRxCTL Vertikal endet dies und lädt beide neu und wartet. Dabei wird einfach momentanes SPRxPTH+L benutzt um Daten zu holen. Aber alles kann beliebig direkt im Chip verändert werden. Farbtabellen Einträge modifizieren für weitere Sprites muss man ohnehin so im Chip umstellen. Damit kann man aber auch im Speicher verstreute Sprites dynamisch auf die Generatoren verteilen, einfach jedes mit Fortsetzung = 0 beenden, und danach neues SPRxPTH+L setzen und mit manuell SPRxPOS und SPRxCTL laden wieder die Spriteausgabe anwerfen. Das sind dann fortgeschrittene Techniken.

(Atari 800 und C64 müssen dies die Software machen, mit Ende vom Erstgebrauch abwarten und dann Register neu setzen. Weil der Speicherblock nur Pixel drin hat.

(TMS9918 ist die ganze Spritekonfiguration in 32 Registersätzen eintragbar, von denen die erstpriorisierten 4 auf dieser Zeile aktiven automatisch eingelesen und ausgegeben werden. Konsolen übernehmen diesen Ansatz, mit NES und Master System 8 von 64, MegaDrive/Genesis 20 von 80, SNES 32 von 128. Auch Spielhallenautomaten verwenden dies, mit NeoGeo MVS 96 von 380(!).)

Nicht überraschend sind die Sprites das Superfeature schlechthin vom Amiga. (Ebenso von Atari 800 und C64 und TS9918 Rechner. Ebenso vieler 1980er und noch mancher 1990er Spielkonsolen und Spielhallenautomaten.)

Der Amiga kann dabei aber schnell an seine Grenzen stossen, weil er nur wenige Sprites pro Zeile hat. Gerade grosse Objekte passen nicht in das Sprite Volumen, verheizen schnell die nur 8* 16 Pixel. Dies vor allem weil der Amiga nur vierfacher Atari 800 ist und nicht vierfacher C64. Dies ist eine weitere Marotte vom Designer. Bereits im VCS/2600 von 1977 hatte er im TIA Chip nur 2*8bit "Player" + 3*2bit "Missile" = 22bit/Zeile an Sprites verbaut. Im 800 von 1979 sind im CTIA/GTIA 4*8 "Player" plus 4*2 "Missile" =40bit/Zeile. Der Amiga von 1985 hat im DENISE nun 8*32=256bit/Zeile, entstanden aus erweitern des 800 von 4*8+4*2=40 auf 8*8=64 und dann vervierfachen.

(Als Vergleich haben TMS9918 Rechner trotz Chip auch von 1979 bereits 4*16=64bit/Zeile. Der C64 von 1982 hat in VIC-II saftige 8*24=192bit/Zeile. Selbst die Famicom/NES von 1983/1985 hat trotz Billigkonsole immerhin 8*16=128bit/Zeile. Aber damit hat Amiga im Vergleich nur zweimal NES und vierdrittel C64, kein vierfacher C64. Ein hypothetischer 16bit C64 Nachfolger in 1982+6=1988 hätte wohl eher etwa 8*128=1024bit/Zeile, wenn erweitern von 8*24=192 auf 8*32=256 angenommen und dann vierfach, analog wie von Atari 800 auf Amiga. Im Vergleich hat die reale MegaDrive/Genesis von 1988/1989 bereits 20*128=2560kbit/Zeile! Die SNES von 1990/1991 hat trotz wie die NES eine Billigkonsole immerhin 34*32=1088bit/Zeile. Im Vergleich mit Spielhallenautomaten hat die NeoGeo MVS von 1990 sogar saftige 96*64=6144bit/Zeile!)

Die ECS Amiga 3000 sowie 500 Plus und 600 änderten hier nur wenig, blieben bei 8* 16Pixel 2bpp, und selbige Datenrate, trotz 1990. ECS erlaubte nur präziser positionieren mit SPRxPOS Horizontal von bisher 8bit erweitern um Bit4 in SPRxCTL auf 9bit. Dies passend zur doppelten Bitrate und halber Zeilenzeit im Productivity Modus. Wohl wegen dem Mauszeiger. Der dreifarbige klotzige vom Amiga ist logischerweise ein Sprite.

Erst die AGA Amiga 4000 und 1200 nutzen auch bei Sprites ihren 32bit Videospeicher plus Pagemode Doppelzugriffe auf die RAMs. Damit können sie neben bestehenden 2 Worte auch 2 Langworte oder gar 2 Doppellangworte an Spritedaten holen. Sprites sind damit 4bpp ohne Spritepaare oder doppelt breit oder gar beides. Farben können separat für alle geraden und ungeraden Sprites auf einen 16er Auschnitt der 256 Farbregister gestellt werden. AGA kommt so auf die 8*128=1024bit/Zeile vom hypothetischen 16bit C64 Nachfolger, aber erst in 1992, nachdem SNES schon etwas mehr und MegaDrive/Genesis seit 4 Jahren das doppelte hatten. Wegen zu spät koplett abgehängt.

(Der ST hat dagegen gar keine Sprites. Genau darin ist er kein vierfacher C64, nur ein vierfacher Apple II Plus, bzw zweifacher Apple IIe und CPC. Diese wurden auch nicht bei irgendeinem der Nachfolger addiert, nicht mal im STE oder TT030. Somit reicht er bei wenige/kleine Objekte verschieben, hinauf bis der zumindest stärkere Prozessor ansteht. Was Spiele dort limitiert.)

(Dies reicht aber bei Puzzlespielen. Bei diesen sind oft diverse Farben gewollt oder gar notwendig, mehr und flexibler als PC/XT/AT CGA kann, und der Mac scheidet ganz aus. Diese brauchen aber selten mehr als 4bpp. Und sie bewegen zumeist eher wenige Objekte aufs Mal. Zudem ist oft ein blanker Hintergrund der nicht weggespeichert werden muss, statt wiederherzustellen reicht nur mit Nullen löschen. Weiter sind zumeist rechteckige Felder für Spielobjekte, was auch kein ausstanzen AND oder einfügen OR braucht, nur einkopieren MOVE. Dazu bewegen sich Objekte zumeist in festen Felddistanzen, also kein pixelweise bewegt und keine vorgeshiftete Objektmuster (und ohne ausstanzen gar keine Objektformen). Auch stören die Bitplanes bei feldgrossen Objekten nicht (bei n*16 Pixel breiten Feldern) oder wenig (bei kleinen 8 Pixel). Und überlappen ist dabei auch noch zumeist irrelevant, also keine Probleme mit Reihenfolge. Also kann der ST voll durchziehen. Dies gilt selbst bei Action Puzzles, egal ob Pacman oder Tetris oder Bomberman. Dann hat der Amiga nur noch seine mehr Farben und Sprites separate Farben Vorteile.)

(Aber auch hier gilt, dass bereits 8bit sowas können. Wenn auch mit weniger Farben, oft nur 2bpp, und langsamer. Wobei Atari 800 und C64 dazu Sprites addieren, und mit ihnen auch separate Farben. Sowie VC20 und C64 zudem separate Farben pro 8x8 Pixel Feld können, aber Atari 800 kann dies nicht.)

(PC Videokarten hatten ab 1990 "Videobeschleuniger". Oft mitsammt darin einem einzelnen "Mausbeschleuniger" oder "Hardware Mauscursor", was ein einzelnes Sprite ist, damit man diesen nicht dauernd bei Bild updaten zuerst entfernen und danach wieder einfügen musste. Wozu der Amige bereits genau eines seiner Sprites nutzt, daher auch dessen dreifarbiger Mauscursor! Nur dieser eine beim PC mit direkt im Video Chip abgelegten Objektform und Objektmuster, zumeist nur 16x16 Pixel 2bpp, oft bestehen aus je 1bpp Transparenz/Objektform plus Inversion/Objektmuster. Mac II Videokarten hatten nicht mal das. Der Mac bekam es erst in Form der neueren PCI basierten PPC Macs, welche schlicht PC Videokarten aufnahmen, in zweiter Hälfte 1990er.)

Amiga: Blitter

Ein Blitter kann beliebige lineare oder blockweise Speicherausschnitte füllen oder umzukopieren mit dabei auch mehrere kombinieren. Dies inklusive vor allem beliebige rechteckige Ausschnitte im Bild einkopieren (wie Spielobjekte) oder umkopieren (wie Fensterinhalte scrollen). Dazu muss man vom Zielblock die Anfangsadresse und Breite (in Worten) angeben, plus wievielen Adressen an Restzeile überspringen sowie Höhe (in Zeilen). Weiter kann man die Anfangsadressen von mehreren Datenquellen angeben, von der eine das Kopierziel sein kann aber nicht sein muss. Oder auch nur Blöcke mit fester Farbe füllen, ohne Datenquellen.

Danach kopiert ein Blitter mit maximaler Busgeschwindigkeit, nur Datentransfers ohne Programmcode lesen, also 5/4 vom Software maximal wenn mit Prozessor bestmöglich kopiert durch MOVE LONG. All das erst noch ohne Kopierschleifen kosten, trotz kein auf feste Grössen ausrollen, weil die Wiederholung im Blitterablauf impliziert ist und in separater Logik automatisch abgezählt wird! Er arbeitet wie die Videoausgabe stets in vollen Worten, auch maximal schnell.

Dabei kann ein Blitter auch gleich Pixel in Worte shiften von den ersten zwei Datenquellen (Objektform und Objektmuster), ohne dass man vorgeshiftete Kopien braucht. Spart Speicher und Prozessor vom vorshiften und Logik um die richtige Kopie zu nehmen. Dritte Datenquelle ist zumeist das vorhandene Bild, neben dieses auch Kopierziel sein, braucht somit kein shiften.

Weiter kann ein Blitter die Sorte Kombinieroperation setzen wie die Datenquellen zu kombinieren sind. Das erlaubt Objektmuster von der Objektform gesteuert mit dem Bild kombinieren, die AND und OR Funktionen gleichzeitig zu machen, ohne dazu mehrere Operationen und Speicherzugriffe zu verbrauchen. Vor allem wird vermieden nach dem AND abzuspeichern und wieder für das OR einlesen, was 3/2 Geschwindigkeit ergibt, womit er erst auf mehr als obige 5/4 kommen kann, zusammen 15/8!

Ebenso kann ein Blitter dies sogar mit automatisch Blockränder eines zu kopierenden Ausschnittes links und rechts abschneiden machen. Dies mit erstes plus n*mittlere plus letztes Wort in einer Zeile wissen. Was gerade auch jegliche horizontal pixelweise positionierte Fenster ihre Inhalte löschen oder scrollen schneller macht. Und zusammen mit obigem Pixel in Worte shiften auch Fenster horizontal pixelweise verschieben.

Beim Amiga hat es Adressen für bis zu drei Datenquellen A B und C, sowie einen weiteren Zielblock D, von allen dreien unabhängig. Jedes hat wie die Sprite Adressregister BLTxPTH+L (mit x=A..D je nach Block). Wie die Bitplanes ihre Modusbits hat es auch hier BLTCON0 um die Bläcke zu aktivieren. Die drei Datenquellen haben je ein Datenregister BLTxDAT, in welches sie mit BLTxPTH+L vom Speicher holen. Aber bei BLTCON0=aus wird nichts geholt und man kann stattdessen direkt ein festes Wort in BLTxDAT setzen, zwecks mit fester Farbe oder Form oder Muster füllen.

Mit BLTSIZE wird die identische Grösse aller 4 Blöcke angegeben. Mit asymetrisch Bit5..0 6bitBreite in Worte (1..64 weil 0=64), und Bit15..6 10bit Höhe in Zeilen (1..1024 weil 0=1024), was bis zu 1024x1024 Pixel erlaubt, mehr als ein ganzes Bild. Das BLTSIZE beschreiben löst zudem gleich die Kopieraktion aus. Danach wird der Prozessor komplett angehalten, um maximal schnell zu blitten, ausser ihm werden mit Bit DMAF_BLITHOG=0 im Register DMACON ein gewisser Prozentsatz Speicherzugriffe abgegeben, nach 3 Zyklen warten bekommt er einen. Das bremst den Blitter aber erlaubt dem Prozessor Interrupts zu bearbeiten. Prozessor weiterlaufen bedeutet ohne dies Blitter Operation fertig. Falls aber Speicherzugriffe abgegeben muss der Prozessor auf allfällig nicht fertig warten, mit Bit DMAF_BLTDONE im Register DMACONR auf 0 werden testen.

Da zumeist aber kein ganzes Bild verschoben wird, können nach in jeder Zeile die gewollten Worte kopieren die restlichen davon übersprungen werden. Dazu kann zu allen BLTxPTH+L ein passender Spung addiert werden, der als Modulo bekannt ist, in Register BLTxMOD. Normal wird im Ascending Modus BLTxPTH+L auf den Anfang von einem Block gestellt und mit +1 sowie +Modulo gerechnet, was gut passt bei nach links oder oben kopieren. Mit BLTCON1 kann man aber umschalten auf Descending Modus mit -1 sowie -Modulo, nach BLTxPTH+L auf Ende von Block setzen, für nach rechts oder unten kopieren.

Das kombinieren der Datenquellen macht der Amiga mit für den Zielausschnitt jedes Pixel per beliebiger 8bit Logiktabelle aus den korrespondierenden Pixelbits der Ausschnitte "A" und "B" und "C" verknüpfen. Nur A kopieren ist mit $F0 (reversiert $0F), B ist $CC (rev $33), C ist $AA (rev $55). Eine Funktion wie "falls A dann B sonst C" wird somit zu (A AND B) OR (NOT A AND C) = $C0 OR $0A = $CA. Dieses ist ebenfalls in BLTCON0, Bit 7..0. Damit kann er Fontmuster (A aus Speicher) einfärben (B fest) und ins vorhandene Bild (C Speicher) hineinrendern (D). Oder mit Objektform als Schablone (A Speicher) bereits farblich fertiges Objektmuster (B Speicher) ins Bild (C Speicher) rendern (D). Man kann aber auch ohne D Arbeiten, nur Bits kombinieren und auf Worte = 0 testen um Objektkollisionen zu bestimmen.

Das kombinieren geschieht erst nachdem A und B mit einem 16bit Barrelshifter um 0..15 Pixel nach rechts geshiftet wurden, mit BLTCON0 bzw BLTCON1 jeweils Bit15..12 gesetzt. (C kann nicht geschoben werden, es wird genau daher zumeist für den Hintergrund benutzt, mit A und B daher als Objektform und Objektmuster.) Rechts hinausfallende "unverbrauchte" Bits werden aufbewahrt und mit den geshifteten Pixeln des nächten Wortes kombiniert, mit wiederum seine unverbrauchten Pixel an das nächte Wort weitergeben (erstes Wort einer Zeile bekommt Nullen). Wenn Descending wird auch nach links geshiftet, weil links herausgehende Pixel eben in das nächten Wortes links passen. All dies beseitigt die ganzen Probleme mit vorgeshiftete Kopien brauchen, durch vorzu nebenbei shiften! (Genau hier versagt der EGA/VGA Pixelprozessor gnadenlos.)

Nur bei A kann man bei Datenquellen welche nicht genau in 16bit passen diese abschneiden. Dazu kann der Blitter im ersten und letzten Wort jeder Zeile (bzw beide Enden eines Einzelwortes) automatisch Teilworte bitpositionweise ausmaskieren, mit BLTAFWM (BLiTter A First Word Mask) und BLTALWM (Last Word Mask), mit $FFFF alles durchlassend, aber Nullbits diese A Bits ausläschen. Daher wird B für Objektmuster aus dem Bild benutzt, und A für Objektform, welche hiermit "abgeschnitten" wird. Dies wirkt selbst bei Fenster scrollen, mit A fest $FFFF, BLTAFWM und BLTALWM Fensterränder abschneiden und B von Speicher mit Barrelshifter Fenster verschieben.

Und sollte man beim Hintergrund erstellen doch zu Doublebuffering und Compositing greifen wollen, hilft der Blitter auch da, bei löschen und aufbauen durch einkopieren. Löschen ist er 3/2 so schnell wie ein CLR LONG, einkopieren wieder die 15/8. Dies erst noch mit Hintergrund nicht auf 16 Pixel breiten Elementen/Streifen limitiert, weil er shiften kann. Damit ist er sogar sehr gut für spritelose grossflächige Animationseffekte erzeugen nutzbar, um alle Objekte bitgenau geshiftet und ausmaskiert ins neue Bild hineinzurendern, für schnelles Compositing.

Das einzige was den Blitter so richtig killen kann sind wieder mal die Bitplanes. Dies gerade auch weil der Amiga echte Bitplanes hat. Der ST hat nämlich nur Pseudobitplanes. In letzteren folgen bei 2bpp und 4bpp die 2 oder 4 Worte eines 16 Pixel Satzes direkt aufeinander, in den 80 Worten einer Zeile, als 40 2er Pakete oder 20 4er Pakete, womit sie nur mühsam und ineffizient sind. ST Programmierer nennen das "woven layout" (= gewobene Anordnung) und damit umgehen als "woven hell" (= gewobene Hölle), so sehr "lieben" sie dies. Es wird von einigen als das schlechteste Feature vom ganzen ST angeschaut!

Beim Amiga ist es aber sogar schlimmer als beim ST. Da sind die Worte der einzelnen Bitplanes zudem auf 2 oder 4 separate 16 oder 8kByte Speicherausschnitte verteilt! Das verlangt nach Objekte in 2 oder gar 4 separaten Schritten kopieren. Was nochmals mühsamer und ineffizienter ist, weil alle Blitterkopie Operationen für jede Bitplane separat geschehen müssen! Damit steigt auch der Aufwand an Program. Noch schlimmer ist der Blitter technisch ein Vektorprozessor. Jeder solcher verarbeitet ganze Datenblöcke, die Vektoren, mit selbige Operation auf alle Elemente davon durchrattern. Genau deshalb kann ein solcher erst so schnell sein. Aber dies geschieht nur nach langwierigem Aufsetzen. Also muss er mit der ersparten Laufzeit zuerst die Aufsetzzeit kompensieren bevor er sich auszahlen kann, was alle Vektorprozessoren ihre Limiten setzt, und seit 1967 als Amdahls Gesetz bekannt ist. Dies wegen Bitplanes mehrfach machen müssen killt genau die erzielbare Geschwindigkeit.

Vor allem aber erzeugt dies während der Kopierzeit (teils Planes ihre Pixel alle verschoben andere noch nicht) eine Anordnung, bei der nicht mehr zusammenpassende Bitmuster der 2 oder 4 Bit Zahlen erzeugt werden, welche als Falschfarben ausgegeben werden, in der Form der verschoben werdenden Objekte, an beiden Positionen! Dieser Effekt ist als Ghosting bekannt. Man kann dieses nicht beseitigen, nur verringern, durch zeilenweise (und in diesen planeweise) kopieren, oder gar vermeiden durch synchron zur Bildausgabe Zeilen kopieren. Was aber noch mühsamer und ineffizienter ist, und viele Programmierer nicht konnten oder wollten.

(Man bemerke, Bitplanes waren eine vorübergehende Modewelle in 1984..85. Sie traffen die EGA und den QL in 1984 und die ST bzw Amiga in 1985. Bei EGA waren sie noch akzeptabel, wegen 256kByte aus 4*8=32bit Videospeicher an 8bit Bus von 8088 Rechner mit nur 64k Adressen Platz, sowie mit separaten Videospeicher hinter einem Businterface versteckt, welcher auch gleich 32bit Graphikoperationen lokal verarbeiten konnte, damit kein Ghosting. Es war trotzdem derart langsam, dass VGA 16bit mit Chunks ohne Pixelprozessor schneller war, trotz doppelter Menge an Daten bei 8bpp statt 4bpp! Bei allen anderen mit Video aus Hauptspeicher, mit genug Adressen, war es nur eine Verschlechterung relativ zu davor Chunks, wie sie in allen 8bit Rechnern bereits benutzt wurden, egal ob Atari 800 oder VC20 und C64 oder PC/XT/AT CGA, oder gar selbst in 1984 im PCjr und CPC. Programmierer beschwerten sich massiv, weshalb ab MCGA und VGA in 1987 alle neuen Systeme wieder mit Chunks daherkommen. (TT030 1990 sein neues 8bpp bleib aber bei Planes, erst Falcon030 1992 sein neues 16bpp hatte Chunks. Ebenso bleib ECS 1990 bei Planes, und auch AGA 1992 sein neues 8bpp. Erst der CD32 addierte als Teil von dessen AKIKO Chip automatische Chunks zu Bitplanes Konvertierung.))

Aber es gibt beim Amiga einen Trick! Man kann bei den Bitplanes vorgeben, dass sie am Ende jeder Zeile eine Menge an Worte überspringen. Auch hier durch ein Modulo addieren. Dies ist eigentlich gedacht, um für Interlace benutzt zu werden, um die gerade und ungrade nummerierten Zeilen des jeweils anderen Frames zu überspringen, in erstes Halbbild 0,2,4,...398 und zweites 1,3,5,..399 von 400 anzeigend. Man kann damit aber auch genau die Datenmenge der anderen Bitplanes der selbigen Zeile überspringen, mit bei 320x200 4bpp nach 320/16=20 Worte die (4-1=3)*20=60 addieren!

Den Sprung kann man im AGNUS in den Registern BPL1MOD und BPL2MOD angeben, ersteres die Planes ungerade 1+3+5 treffend und zweiteres die gerade 2+4+6. Dann kann man alle solche "löchtigen" Bitplanes in einander verzahnen, durch ihre Anfangadressen in Zeilendistanz von 20 vorgeben, in AGNUS Registern BPLxPTH+L (mit x=1..6 je nach Plane). Womit alle Bitplanes einer Zeile als Zeilenpaket von 4*20 kommen, dann erst der nächsten Zeile, und so fort. Was als Planeinterleave bekannt ist. Resultat ist auf nur einzelne Zeilen reduziertes Ghosting, statt bis zu ganzes Bild.

Da der Blitter ohnehin auch ein Modulo haben muss, wegen Breite von Objekten zumeist kleiner sein als die Länge von ganzen Zeilen, um die Adressen der Restzeile zu überspringen, kann man damit auch die Länge vom Zeilenpaket statt Zeile angeben. Schon muss man nur noch einmal Blitter aufsetzen, mit vertikal nun Bitplanezahl*Zeilenzahl durchlaufen lassen, ohne den Blitter zeilenweise und planeweise aufsetzen zu müsen. Auch bei den Datenquellen wirkt dies, mit Objektform und Objektmuster nur deren Breite * Planes, sowie Bildspeicher selbiges Breite * Planes wie den Zielblock. Ein Fall von der "gerade noch gerettet" Sorte.

Problem mit diesem Trick ist, dass er nicht im Programmierhandbuch erwähnt wird (das beschreibt nur Interlace überspringen). Noch schlimmer, auch die Systemsoftware kennt ihn nicht und versagt beim Videospeicher anlegen dazu passend vorzugehen! Dies zumindest wenn man mit dem Intuition GUI Library Aufruf OpenScreen() eine Bildschirmstruktur anlegen will, wo man als Paramerter nur Modus und Bildgrösse und Planeanzahl angeben kann! Das ist der wohl besste Grund um Spiele am System vorbei zu schreiben. Oder gleich ohne Desktop direkt von Bootfloppy zu laden.

Daher war dieser Ansatz vielen Programmierern gar nicht bekannt, weshalb viele Programme es nicht nutzen, vor allem auch frühe. Was dem Amiga bald seinen Ruf wegen "Ghosting" einbrachte, er dafür berüchtigt wurde. (Mit AGA erschien erstmals ein Systemaufruf AllocBitMap(), welcher auch interleaved erzeugen kann. Nur war das erst in 1992, als der Amiga bereits am absteigen war.) (Der Chefdesigner Jay Miner hat dazu ausgesagt, er bedauere seinen Designentscheid zu Bitplanes statt Chunks als einen der schwersten im ganzen System!)

Der Blitter kann nicht mit Multitasking benutzt werden, weil er nicht bei Taskwechsel "entleert" und wieder "angelaufen" werden kann. Daher muss er für einem einzelnen Task reserviert werden mit System Aufruf OwnBlitter() und abgegeben werden mit DisownBlitter(). Mit WaitBLit() kann man bestimmen ob er in Gebrauch ist.

Das einzige was selbst mit all obigen Tricks nicht mehr gerettet werden kann sind viele kleine Objekte. Dies passen erst recht nicht in die Spriteanzahl Limite, müssen also auch in den Speicher. Nur ist der Blitter von seinem Ablauf her ein Vektorprozessor, der wenn ablaufend schnell ist, aber erst nach alle Register aufsetzen. Neben Bitplanes separat aufsetzen, kill ihn etwas noch mehr, viele kleine Objekte, mit jedes davon einzeln aufsetzen und zuwenig Laufzeit danach um ihn auszunutzen! Also ist der Blitter nur für grosse Objekte effizient nutzbar. Für viele kleine Objekte fällt der Amiga unweigerlich auf mit Prozessor kopieren zurück. Dabei wird die volle gleiche Logik notwendig wie beim ST für alles, sich genauso aufsummierend!

Daher muss man als Programmierer die Objekte nach Kategorien aufteilen, in oft bewegte und extrafarbige als Sprites, mit andere in Hintergrund einbauen, grosse davon mit Blitter und kleine mit Prozessor. Das bedeutet wieder mal mehr Komplexität.

Noch schlimmer trifft dies wenn es nur kleine Objekte hat, weder Sprites noch Blitter helfen können, was den Amiga ganz auf nur seinen Prozessor zurückwirft. Dazu kommt wegen oft diese so vielen auch noch überlappend sein sogar mit Doublebuffering und Compositing als einzigen Ansatz. Siehe dazu Lemmings. Dann gilt nur noch, dass dem Amiga sein Prozessor 10% langsamer ist als dem ST seinen. Davon haben wir die seltene Sorte Spiele wo der ST besser sein kann. Ausser der Amiga kann irgendwie seine 32 Farben ausspielen, was aber weiter Prozessor kostet, nochmals 12.5% von den 90% ST wegnimmt, nur noch 79% ST lässt!

Wie sieht der Vergleich real aus? Siehe dazu wieder "Another World", dessen Innereien detailiert analysiert worden sind. Wegen für beide Amiga und ST portabel designt, ist es implementiert als eine kleine einfache vom Rechner abhängige Game Engine, plus alles andere als portable Daten in Bytecode, dies vor allem mit als RLL gepackte Bilder expandieren, plus die ganze Spiellogik. Alles wird wegen grossflächig und 3D alles ohne Sprites und andere spezielle Ausgabe gemacht, nur reine Bitmaps auf Basis von Doublebuffering plus 2 Stillstehende. (Daher kenne ich diese Technik!) Es konnte deswegen auch später problemlos auf PC und MegaDrive und sogar SNES portiert werden. Auf ST benutzt es rein den Prozessor, auf Amiga kommt nur der Blitter dazu, weshalb es für dessen ausmessen ein gutes Mass it. Dies demonstrierte trotz diesem nutzen nur eine erstaunlich geringe Differenz. Die Amiga Version kam auf 28fps. Der Autor gab das minimal benutzbare Spiel als 20fps an, als Vorgabe beim Port auf MegaDrive und SNES. Diese mussten deswegen mit verkleinertem Bildausschnitt arbeiten. Seine eigene ST Version ist Vollbild und schlug diese fps Vorgabe deutlich. Ebenso die PC Version, Vollbild auf CGA oder EGA oder TGA Karten, aber weniger fps als ST. Grund ist vermutlich die Folge von Blitter als Vektorprozessor, mit seiner Aufsetzzeit und hier viele teils recht kleine Bildelemente.

(Der MegaST addiert einen beim ST geplanten aber weggelassenen Blitter. Der ist auch in STE und MegaSTE drin. Er erscheint an $FF8A00..$FF8BFF. Aber dies ist ein weit schwächerer als beim Amiga, weil nur auf beschleunigen der GEM GDI Graphiklibrary entwickelt, bzw genauer auf die von dieser benutzten Line-A Routinen A007 BITBLT und A008 TEXTBLT. (Es ist hierzu bekannt, dass mehrere der 800 gewohnten Atari Leute dem GEM seine Graphiklibrary gering achteten. Das weil diese auf GSX basiert, welches von 1960er CAD Vektorgraphik her kommt, nur gerasterte Striche und Rechtecke auf Bildschirm als Papierersatz zeichnen kennt, keine gemusterten rechteckigen Bitmap Objekte oder Elemente offeriert, wie sie für Spielegraphik benutzt werden. Zudem war Line-A langsam, weshalb alle Spieleprogrammierer dieses mieden, womit der Blitter ungenutzt blieb.))

(Der MegaST Blitter hat nur zwei Datenquellen, von denen einer zugleich fest der Zielblock ist, und dazu nur zwei Adressen mit deren Schrittweiten beliebig setzbar in X und Y Richtung. Damit kann er mangels drei Adressen keine Objektmuster von einer Objektform gesteuert mit Bild kombinieren. Wegen nur 2 Eingangsworte hat es auch nur 4bit Logiktabelle, ebenfalls nichts mit AND und OR Funktion in einem machen, was 8bit braucht. (Nur Quellbit kopieren ist Funktion 3, nur Zielbit 5, Q AND Z 1, Q OR Z 7, löschen 0, füllen 15.) Also muss man den Hintergrund mit AND ausstanzen und dann separat das Objektmuster mit OR einsetzen, was zwei Durchläfe braucht, doppelte Laufzeit. Was neben mehr Programmaufwand brauchen auch die mehr als 5/4 Geschwindigkeit verhindert! Damit kann er nur auf Leerfläche zeichnen real beschleunigen, womit er praktisch nur für Compositing zu benutzen ist. Genau dabei ist er aber nur unwesentlich schneller als der Prozessor mit aggressiv ausrollen! Wenigstens ist er nicht umständlich wie der EGA Pixelprozessor, der sogar hinderlich sein kann wegen für 4*8=32bit durch diesen hindurch müssen.)

(Er kann auch Objekte shiften vor sie kombinieren, spart Speicher und Vorbereitungszeit von vorshiften, aber nur den einen Quellausschnitt. Dazu kann er auch ein Wort vorausladen, bevor die Kopierrunden losgehen, oder gar letztes Wort laden weglassen, wenn nur noch geshiftete Bits kommen. Er kann dabei auch automatisch das erstes/rest/letztes Wort einer Zeile bitpositionweise ausmaskieren. Reicht bei 1bpp Schwarzweiss. Nur kollidiert dies bei 2oder4bpp Farben mit den Pseudobitplanes, weil entgegen Amiga mit Planeinterleave dieses erstes/rest/letztes nicht per Zeile=Plane wiederholt werden kann, nur per Zeile=Planesatz einmal. Also muss man den Blitter auch noch pro Plane anwerfen, mit Schrittweite horizontal 2oder4, nochmals langsamer. Schlimmstenfalls langsamer als per Prozessor wenn effektiv ausrollen benutzt wird! Chunks statt Bitplanes hätte mehr Zeit gespart als der Blitter, mit weniger Aufwand.)

(Dazu muss die Grösse der Blöcke auch noch in zwei 16bit Register spezifiziert werden, statt 2*8=16bit in einem, total überdimensioniert bei max 160Byte/80Worte pro Zeile und 400 Zeilen/Bild, nur mehr Aufwand. Und schliesslich muss die Kopieraktion auch noch separat gestartet werden, statt bei Grösse setzen automatisch loslaufen. Was alles den Startaufwand nach oben treibt, nur bei grossen Flächen sich lohnt. Wie Amiga kann er den Prozessor ganz anhalten, oder Speicherzugriffe halbe-halbe machen. Erstaunlich kann er statt nur mit festem 1x16bit Pixelwort füllen ein im Chip liegendes 16x16 1bpp Füllmuster benutzen, und sogar dieses mit einem Objektmuster oder einer Objektform AND-ierend kombinieren. Damit kann man Hintergrund (bei löschen) oder Objekte (bei zeichnen) automatisch rastern für Graustufen auf dem Schwarzweiss Monitor.)

(Der Blitter wurde im TT030 weggelassen, weil GEM GDI bzw Line-A auf dem Prozessor ablaufen inzwischen schneller ist, dank Program aus Cache ausführen und Daten per 32bit ALU shiften/modifizieren. Er ist erstaunlicherweise im Falcon030 wieder vorhanden, vermutlich wegen Software welche ihn direkt benutzt hat und auf dem TT030 scheiterte, trotz dass solche Software wegen kein Blitter vor MegaST vorhanden selten gebleiben sein dürfte.)

(Atari 800 und C64 haben gar nichts derartiges, machen stets alles mit dem Prozessor, nur die Sprites entlasten diesen. Ebenso Konsolen wie NES und Master System, sowie MegaDrive/Genesis und SNES, abgesehen von simplen Blöcke von Bytes im separaten Videospeicher Umkopierer. Das gilt sogar für Spielhallenautomaten wie NeoGeo MVS. Hier ist Amiga absolut einsamer Vorausläufer! Erst Playstation reversiert obiges, keine Sprites mehr, nur noch Blitter im separaten Videospeicher, aber auch dieser ein reiner 16bit Worte Umkopierer.)

(PCs hatten anfangs nicht mehr als ST, nur Chunks statt Bitplanes. Aber selbst normale BüroPC Videokarten ihre 2D Videobeschleuniger ab 1990 sind ebenfalls Blitter. Diese je nach Videokarte varierend, Details mir unbekannt, aber ich verdächtige eher bei MegaST liegend als bei Amiga, weil nur auf Windows Graphiktreiber beschleunigen ausgelegt. Selbst moderne GamerPC Videokarten und Spielkonsolen mit GPUs ab etwa 1995 arbeiten vergleichbar, wenn auch mit aufwendigem 3D Generator für die Objektmuster erzeugen. Aber selbst diese basieren rein auf Doublebuffering und Compositing, nur mit viel mehr Leistung von heutigen meherere GHz Cores 64bit Prozessoren plus mehrere TFlops Computeunit GPUs. So wird das Problem einfach mit Masse erschlagen, mit am oberen Ende sauteure $4stellige Videokarten als Masse. Dazu kommen noch die GBytes an detaillierten Hintergrund und Objektdaten. Charakterisierend ist nur genau wieviele fps an Compositing die GPU bei gegebener Auflösung hinbekommt, bei welchem Anteil der maximalen Spielegraphik Details eingestellt.)

Amiga: Scrollen

Der ST kann nichts anderes als umkopieren. Prozessorverbrauch genau identisch mit drittem Bildspeicher mit allem Stillstehenden einkopieren, also 20ms, mehr als ein Frame von 16ms. Auch Blitter macht dies nur 5/4 schneller zu 16ms. Bei Büroanwendungen scrollen ist das völlig ausreichend, weil weit unter den wahrnehmbaren 100ms. Bei Spielen wird es problematisch weil es andere animierte Objekte verschieben beeinflusst, wenn der Prozessor ab und zu für diese Zeit blockiert wird, womit das Spiel ruckelt. Was als Stuttering bekannt ist.

Das kann man vermeiden/reduzieren mit Bild nur teilweise pro Frame verschieben. Aber das führt zu teils verschobe und teils nicht verschobe anzeigen, mit allen bei der gerade aktuellen Kopierposition duplizierten Zeilen zweimal, mitsammt alle Objekte darin gestreckt. Daher muss man wieder umstellen auf Doublebuffering, mit pro Frame den konstanten Prozentsatz umkopieren wie man Frames pro Scrollschritt geplant hat, dann Objekte nachkorrigiren, dann umschalten. Oder man geht gleich zu Compositing und spart Objekte wegspeichern und wiederherstellen, welche vor kopieren aus dem Weg sein müssen und danach wieder eingesetzt, sowie nach Bildwechsel dort alle gleich richtig eingesetzt. Dabei wird man aber wieder von den Bitplanes unnötig ausgebremst. (Ist bei PC/XT/AT und Mac genauso, nur ohne Bitplanes im Weg.)

Der Amiga kann hier wieder den Blitter nutzen. Aber dieser ist auch nur noch 5/4 schneller, wegen kein 20% Programmbytes Codezahl holen. All sein Objektformen kombinieren ist hierzu irrelevant. Also auch nur von 20ms auf 16ms runter, immer noch ein Frame. Zudem entsteht wegen ganzes Bild bewegen als ultimative Form von grossem Objekt wegen den Bitplanes auch das ultimative Ghosting. Ausser der Videospeicher wird mit Planeinterleave angeordnet. (Ist bei PC/XT/AT mit SVGA 2D Videobeschleuniger genauso.)

Weit besser ist gar nicht umkopieren, analog zu bei Objekte dank Sprites gar nicht in den Bildspeicher einfügen! Das kann man machen mit den Bildspeicher nichtlinear ausgeben. Der Trick ist, wenn man erstes Bild von Null aufbaut sind die Zeilen in Reihenfolge 0..199 im Speicher, wie gehabt. Jetzt will man nach oben scrollen. Einfach Bildausgabe um eine Zeile von 4*20=80Worten weiter hinten im Speicher anfangen, und schon ist die ehemalige zweite Zeile vom Bild jetzt die erste! Dann folgen dritte bis letzte im Speicher als zweite bis zweitletzte vom Bild, womit das ganze Bild verschoben ist, ohne etwas umzukopieren zu müssen. Aber dann muss noch als letzte die nun fehlende Zeile 199 vom Bild kommen. Dies macht man mit dem Speicherplatz der ehemaligen ersten anzeigen, welche man mit neu eingescrollt werdendem Inhalt füllt. Beim nächsten Scroll sind es dritte bis letzte und dann erste bis zweite. Dann vierte bis letzte und erste bis dritte. Und so weiter bis nach 200 mal scrollen wieder alle linear sind. Sowas ist als rollende Anordnung bekannt.

Der Amiga kann dazu einerseits die Adresse vom Bildspeicheranfang beliebig positionieren mit BPLxPTH+L, wie es bereits für Planeinterleave genutzt wurde. Aber viel wichtiger kann er während der Ausgabe den aktuell erreichten Ort umstellen. Dazu muss er lediglich die letzte Zeile im Speicher (nicht letzte im Bild) abwarten und dann die Adressen in BPLxPTH+L auf die erste Zeile im Speicherblock umstellen, um die oben hinausgescrollten Zeilen als restliche Zeilen vom Bild zu holen. Dieses kann der Prozessor machen, wozu er die Register VPOSR und VHPOSR lesen kann. Was aber warten auf Zeile braucht, den Prozessor blockiert. Oder man kann ihm per Rasterzeileninterrupt anstossen lassen.

Besser kann man dies alles an den Copper Koprozessor abtreten, um den Prozessor ganz zu sparen! Der Copper kann auf eine beliebige Anzeigeposition warten (WAIT), und dann beliebige Chipsatz Register neu mit Konstanten laden (MOVE), egal ob Bildadressen oder Bildmodi oder Farbsatz oder Spritegenerator. Das erlaubt auch die BPLxPTH+L Register mit vom Programm abgelegten neuen Adressen nachfüllen.

Warten ist analog zu den Sprites 1 Wort Vertikal Position Bit7..0 und Horizontal Bit7..1, mit Bit0=1 = WAIT, gefolgt von 1 Wort Bit15=1 (zumeist) und Vertikal Test erlaubt Bit6..0 und Horizontal Test erlaubt Bit7..1 und Bit0=0. Mit zweites Wort = $FF00 wird nur vertikal getestet. Horizontal ist in 4 320er oder 8 640er Pixel Schritten, mehr als $E2 geschieht nie. Mit beide Worte $FFFF+$FFFE wird unendlich gewartet = Liste zu Ende.

Laden ist 1 Wort Registernummer ($0000..$01FE), mit Bit0=0 = MOVE, nur gerade Zahlen, weil Register alle 16bit sind, gefolgt von 1 Wort Datenwert ($0000..$FFFF). Womit die meiste Prozessorzeit weiterhin für Spiellogik und Bild erstellen verbleibt, ausser die wo er wegen Copper ablaufen kurz angehalten wird.

Für einfacheres kann man die Copperliste statisch programmieren wie die Spritedaten. Für aufwendigeres muss man aber die Copperliste zur Laufzeit generieren, oder zumindest modifizieren. Was die Komplexität etwas weiter hinauftreibt. Analog zu den Bitplanes in BPLxPTH+L (x=1..6) und Sprites in SPRxPTH+L (x=0..7) braucht es auch hier Adressen in COPxLCH+L (x=1..2). Bei jedem Bildwechsel wird nur der Copper auf COP1LCH+L gesetzt. Er muss dann wiederum aus seiner Liste die Anfangsadressen der Bitplanes und Sprites setzen, weil kein hart verdrahteter Mechanismus dafür existiert! Der Prozessor kann jederzeit diese beiden Adressen modifizieren und laden erzwingen mit Zugriff auf COPJMPx (x=1..2).

Wiederum kann jede Copperliste den Prozessor per Interrupt anschubsen, um einen Wechsel zu bekommen. Oder um beliebige andere Operationen zu machen, welche dem Copper seinen WAIT+MOVE übersteigen. Was auch gleich für Rasterzeileninterrupts benutzt wird. Dazu kann er Register INTREQ (anstehende Interrupts) mit $8010 (aktiv Copper) beschreiben. Was aber alles noch mehr Komplexität ergibt, und weniger vorhersehbares Timing, weshalb man generell Interrupts meidet in Spielen.

Der Amiga kann damit sogar horizontale Zeilenbänder vom Bild separat behandeln, wie statische Menuzeilen/-bereiche oder gar Radaranzeige oben sowie Statuszeilen/-bereiche oder gar Instrumentenpannel unten. Egal ob dafür verschiedene Videomodi mit diese 640 statt restliche 320 Pixel benutzt werden, oder auch nur andere Anzahl Bitplanes. Oder dies sogar mit einem scrollendem Spielfeld oder gar Cockpitaussicht dazwischen.

Was auch hier zuschlägt sind wieder mal die Bitplanes. Der Copper muss alle Bitplanes ihre Adressregister einzeln schalten, zumeist 4*2=8 davon mit Konstante Laden, dazu 8*2=16 Worte Copperliste abarbeiten, was 8µs dauert. Das alles in der Rücklaufzeit einer Zeile, etwa 12..15µs, weil sonst haben wir wieder Ghosting!

Das grosse Problem dabei ist, diese Umpositionierung kann wegen rollende Anordnung jede beliebige Zeile treffen, je nach aktuellem Rollzustand, wievielmal gerollt wurde seit letztesmal der Bildspeicher linear war! Daher kann der Copperliste ihrer Umpositionierteil wandern, relativ zu anderen Aktionen wie Sprites wiederbenutzen, somit vor oder zwischen oder nach ihnen geschehen. Also muss die Copperliste erst recht zur Laufzeit generiert werden, weil nach jedem Scroll potentiell anderst formatiert!

Dabei kann aber der aufwendige Umpositionierteil jede Zeile treffen, also wird anderes in dieser als unmöglich ausgeblockt werden müssen. Ein Trick um dies zu umgehen wurde bereits im VCS/2600 benutzt. Dort musste der Prozessor noch die Videodaten in den TIA Videochip schicken, was mit Sprites plus Playfield sehr komplex war. Also wurde ausgenutzt, dass bei 160 Pixel pro Zeile eigentlich 100 Zeilen vertikal ausreichen, sowie der TIA Zeilen ohne neuen Daten wiederholt, mit Playfield in jeder geraden Zeile und Sprites in jeder ungeraden verändern. Sowas ist unter VCS/2600 als "Zweizeilenkernel" bekannt.

Analog geht hier, mit umpositionieren in geraden Zeilen und anderes in ungeraden machen. Dazu muss der Bildspeicher eine Zeile länger sein, mit nach 0..199 zuerst auf 1..200 verschieben, mit erst danach rollen auf 2..199+0..1, danach wieder verschieben auf 3..200+0..1, dann rollen auf 4..199+0..3. Damit kann man garantieren, dass in allen Zwischenzeilen der Copper frei ist und sonstige Aktionen nur in diesen umkonfigurieren. Dies ergibt eine Art Multithreading des Copper, mit festen Zweizeilen-Timeslices.

Ein dabei verbleibendes Problem ist, dass die Zeilen nun nichtlinear im Speicher liegen. Das bricht Programmiertechniken, welche mit linearem Bildspeicher rechnen, als Bildpeicherort der nächsten Zeile stets die aktuelle +80Worte annehmen. Statt dessen muss jeder Zeilenwechsel geschehen mit Zeile +1 statt Adresse +160Bytes und dann mit der Zeilennummer deren Anfangsadresse aus einer Tabelle von 200*4Bytes an Adressen auslesen, in der die aktuelle Rollanordnung aufgezeichnet ist. Oder doch +160Bytes benutzen aber falls Adresse nach dem Bildspeicherende entsteht dessen gesammte Länge subtrahieren. Trifft dies den Prozessor, so kann er es in Software einfach behandeln. Dem Blitter sein Zeilensprung mit Modulo kann das aber nicht, also muss die Software Blitteroperationen auf aktuelles Bildspeicherende überschreiten testen und betroffene Operationen in zwei Bänder aufspalten.

(Der ST hat nichts von alledem, er kann nur den Bildpeicheranfang in 256Byte Schritten setzen (Register $FF8201+3) und aktuellen Ausgabeort auslesen (Register $FF8205+7+9) für Programme mit Bildausgabe synchronisieren.)

(Erst der STE addiert nichtlinearen Videospeicher, in Software, mit Bildpeicheranfang in Wortschritten setzen (Register $FF8201+3 erweitert um $FF820D) und aktuellen Ausgabeort ($FF8205+7+9) neben auslesbar auch überschreibbar. Logisch alles nur mit Prozessor, weil kein Copper. Aber wegen Pseudobitplanes muss er auch nur ein Adressregister schalten. (Allerdings ist wieder der MOVEP.L Befehl der 68000 nicht benutzbar.) Wegen Bildspeicher Ende in jeder Zeile möglich wird aus Copperliste zur Laufzeit generieren nun mit dem Programm eine Displayschleife generieren. Oder analog zu Copper Rasterzeileninterrupts mit 68901MFP Zeilenzähler einen Timer Interrupt absetzen. Dabei wäre der Aufwand für einen Automatismus trivial, nur Videospeicher Anfangsadresse aufteilen in fest 32k Block ansteuern und variabel Anfang darin, gefolgt von feste Endadresse erreichen erkennen und auf festen Anfang vom Block resetten.)

(Bei Atari 800 kann dies alles mit der ANTIC seiner Displayliste analog gemacht werden. Nur dass dort wegen Chunks statt Bitplanes ohnehin nur eine Adresse neu gesetzt werden muss. Genauer tut die Displayliste das Bild in horizontale Streifen aufteilen (zu je 1..16 Videozeilen), und für jedes davon mit 4bit (Bits 3..0) den Videomodus setzen (6 Zeichenzelle und 8 Bitmap Modi). Bei jedem Streifenanfang können mit weiteren 4bit (7..4) Optionen aktiviert werden, darunter auch mit Bit6 die Bildpeicherposition ersetzt werden und mit Bit7 einen Displaylistinterrupt auslösen.)

(Beim C64 gibt es gar nichts solches, er muss wie beim ST stets umkopieren. Allerdings hat er einen Rasterzeileninterrupt, wenn auch ohne Copperliste oder Displaylistie, lediglich mit eine Zeilennummer anmelden wo der Interrupt ausgelöst wird, damit etwas freundlicher als beim ST Timer Interrupt verwenden.)

Horizontal scrollen ist schlimmer, sobald pixelweise bewegen gewollt ist und nicht nur wortweise. Kopieren wäre bei wortweise statt zeilenweise noch harmlos, wenn auch wieder Prozessorverbrauch mit allen Folgen und Methoden. Bis auf dass das Bild nur teilweise pro Frame verschieben bei Zeilen horizontal verschoben statt vertikal versetzt weit schlimmer ist, weil nun Objekte nicht mehr zeilendupliziert gestreckt werden sondern streifenweise verformt! Was als Shearing bekannt ist.

Beim Amiga mit Copper rollen ist wortweise horizontal noch harmlos, man muss den Bildpeicheranfang einfach in 1 Wort statt 1 Zeile Schritten verschieben. Weil man dem Program keine nichtlinearen Zeilen zumuten will, was durchgehende Zeilen verlangt, wonach rollen nur noch zeilenweise machbar ist, muss man aber den Bildpeicher eine Ziele länger machen. Das reicht um bis zu eine ganze Zeile horizontal zu verschieben. Genau beim letzten Wort wird aus allen bisherigen Worten zusammen eine Zeile weit, die man dann wie gehabt mit rollen statt verschieben behandeln tut. Sollte man wegen Copper Timeslices schon eine extra Zeile haben sind nur zwei davon fällig, weil man so lange verschiebt. Shearing entfällt bei verschieben und rollen komplett.

(Bei obigem trivialem Automatismus müsste dazu resetten bis nach Zeilenende verzögert werden (weil sonst Zeilen zerteilt), und dann die untersten 8 Adressbits (ausreichend für eine Zeile holen) in Ruhe lassen, nur die oberen resetten (auch ausreichend um Blockanfang zu erreichen).)

Oder man kann Modulo verwenden für längere Zeilen bevor man das ganze Bild rollen muss. Damit kann man auch Horizontalscroller Platz geben um den kommenden Hintergrund wortweise oder gar streifenweise statt nur pixelweise aufzubauen. Das gerade auch wenn man den Hintergrund ohnehin aus 16x16 (oder allenfalls sogar 32x32) Bildelementen aufbaut. Dann pro Zeile 320 +16 oder +32 Pixel Bildspeicher anlegen, und nur 320 davon anzeigen, mit dann bis zu 16 oder 32 Pixel scrollen können bevor verschieben oder rollen. Oft wird man in solcher Situation auch gleich +16 oder +32 Zeilen Bild anlegen, und auch vertikal 16 oder 32 Zeilen aufbauen. Dann wird man auch so weit verscheiben können bevor rollen. Was dann die festen Copper (Sechzehnzeilen-)Timeslices vereinfacht. Oder man kann gar doppellange Zeilen anlegen, in denen man nur noch in der Zeile drin rollt, nicht mehr im ganzen Bild. Wenn auch dieses doppelte Menge an Speicher verbraucht.

(Bei Konsolen mit ihrem separatem Videospeicher wird dieser ohnehin mit eigenen Adressregistern angesprochen, erscheint dem Prozessor nur als einzelnes Byte! Rollen geht einfach mit Anfangsadresse verschieben. Die interne Adresse geht automatisch nach letzter Zeile an erste weiter, weil schlicht keine weiteren Adressbits den Übertrag aufnehmen können. Ebenso nach letztem Pixel an ersten weiter, weil kein Übertrag von Adresse-in-Zeile Adressteil zu Zeile-in-Bild Teil! Dies gilt sowohl für Ausgabe auf den Bildschirm wie auch für bearbeiten durch den Prozessor. Eine NES tut ihre 2048Bytes an 8x8Pixel Zellennummern als "horizontal" Modus 16Zeilen*64Zellen oder "vertikal" 32Zeilen*32Zellen anschauen, mit Ausgabe einen 14Zeilen*32Zellen Ausschnitt, der im ganzen Speicher per Anfangsadresse verschiebbar ist. Alle anderen Konsolen sind vergleichbar. Selbst Playstation ist selbiges, nur weit grösser, mit 1MByte an Pixeln als 512Zeilen*1024Pixel*16bpp, mit Ausgabe einen 256/320/384/512/640x224 Pixel Ausschnitt.)

Aber dann haben wir immer noch das Problem von pixelweise, falls um feiner als Wortgrenzen gescrollt wird. Die Pixel sind mehrere in einer Wortgruppe, 1 Wort pro Bitplane, nicht feiner als 16 Pixel sind mit rollen scrollbar. Wieder viermal schlimmer dank den Bitplanes 16 statt 4 Pixel pro Wort. Pixelweise scrollen verlangt damit nach Rotieroperationen. Nur genau da ist die 68000 ja schwach, weitaus zu langsam. Noch schlimmer, schlagen die Bitplanes gleich nochmals zu, verlangen die Rotieroperationen pro Plane zu machen. Was gleich ein Ghosting ganzes Bild Volltreffer wird! Dies geschieht sogar auf dem ST, der ansonsten nicht ghostet, bzw strikte nur in einem 16Pixel Block drin! Ausser man tut die Rotierschleife wegen schnell ohnehin ausrollen, und tut dabei zeilenweise durch alle Planes gehen. Dann ist nur noch zeilenweise Ghosting, auch auf dem ST. Nicht überraschend geht man auf dem ST zumeist andere Wege, und benutzt hier erst recht Compositing, nur dass dabei nun auch die Hintergrund Bildelemente vorgeshiftet sein müssen. Auch der Blitter ist zu langsam für solches, und wird massive ghosten, zumindest zeilenweise.

Aber der Amiga kann auch Zeilen verzögert ausgeben, um 0..15 Pixel verschoben, mit dann bei +1 statt zu 16 wieder auf 0 schalten plus dann wie gewohnt wortweise verschieben, und danach zeilenweise rollen. Dazu muss man Zeilen mit um ein Wort links länger anlegen, welches normal geholt wird aber weil zuweit links nicht angezeigt wird. Um diese zu holen muss DDFSTRT kleiner sein, was einem auch noch Sprite Nummer 7 killt. Um etwas davon zu sehen muss das Bild verzögert werden, mit Register BPLCON1, Bit0..3 und 4..7 separate 0..15 Pixel für Bitplanes ungerade 1+3+5 bzw gerade 2+4+6.

(Der ST hat wieder nichts von alledem, er kann nur Rotieroperationen in Software nutzen, oder eher Compositing. Dabei hätte die Hardware dazu weniger gekostet als die ohne Bitplanes wegsparbare.)

(Erst der STE addiert auch Zeilen verzögert ausgeben (Register $FF8265). Genauer tut er 0..15 Anfangspixel auslassen (wie EGA), womit das Bild nach links wandert. Es braucht aber trotzdem volle Pixelzahl pro Zeile, muss also ein weiteres Wort holen. Selbst ein Modulo ist dazu nun vorhanden ($FF820F), was bis zu 256 Worte lange Zeilen erlaubt, inklusive doppellange (im Falcon030 bis 65536 Worte).)

(Dieses fehlen im ST ist weit schlimmer als manch anderes, weil solches Zeilen verzögern nicht nur bereits im Atari 800 drin war, sondern sogar schon im VC20(!) und erst recht im C64. Bei diesen gibt es sogar horizontal und vertikal innerhalb einer 8x8 Pixel Zeichenzelle scrollen, weil der Hintergrund oft aus solchen Zellen zusammengesetzt wird. Bei Atari 800 kann sogar die Displayliste in jedem Streifen mit Optionen dies ein oder aus schalten (Bit4 horizontal und Bit5 vertikal), für stehende Menues und Status sowie scrollendes Hauptbild (maximale Distanz 16 Pixel oder Zeilen). Bei VC20 und C64 ist es stets ganzes Bild (und maximale Distanz 8 Pixel oder Zeilen). Aber der ST Shifter Chip Designer war zwar am C64 beteiligt, aber nicht am VIC-II Chip, und hat dieses Features nicht gekannt oder dessen Bedeutung nicht verstanden und übernommen. Oder es ist ein weiterer Fall von wegen überhastet schlicht nicht daran gedacht. Weshalb der ST praktisch nur für Spiele mit statischem Spielfeld taugt, oder zumindest wo in 16 von 320 Pixel Schritten sprungweise horizontal scrollen akzeptabel ist.)

Eine besondere Funktion ist Parallaxscroll. Dieses erzeugt einen pseudo-3D Effekt durch Vordergrundelemente vom Bild schneller horizontal scrollen als den weitesten Hintergrund, was den Eindruck erweckt von näher befindliche Objekte schneller vorbeiziehen. Beim Amiga kann man dazu Dual-Playfield Modus nutzen. Dabei werden die 1..6 Bitplanes in 2 Sätze zu je 1..3 aufgeteilt, ungerade 1+3+5 als Playfield 1 und gerade 2+4+6 als Playfield 2. Dabei nutzt Playfield 1 die Farben 0..7 und Playfield 2 die Farben 9..15. (Beim ST ist ausser mit Compositing gar nichts solches zu machen.)

Die "Farben" 0 und 8 sind wie bei Sprites 0=durchsichtig. Alles ebenfalls gesteuert von Register BPLCON2, Bit0..2 Position von Sprites relativ zu Playfield 1, Bit3..5 Sprites zu Playfield 2, Bit6 Playfield 2 zu 1, wobei non-DUAL nur Bit3..5 wirken. Diese beiden Sätze haben ja separate Modulo Register BPL1MOD und BPL2MOD, was je nach ihrer bpp Menge auch passendes Planeinterleave erlaubt, und alle Bitplanes sind ohnehin separat scrollbar sowie rollbar, aber nur die Gruppen verzögerbar. Genau deshalb sind die Modulo und Verzögerung zweifach vorhanden für ungerade 1+3+5 und gerade 2+4+6. Damit kann man sie für Parallaxscroll Effekte nutzen. Dies ist eines der wenigen Vorteile, welche die Bitplanes brachten, und ist auch nur beim Amiga mit seinen echten Bitplanes möglich, nicht bei ST mit Pseudobitplanes. Man kann immer noch Planeinterleave verwenden, aber nur die Planes eines Satzes zusammen angeordnet.

Selbst Mehrfachparallax liegt drin, mit mehreren gestaffelten Tiefen, solange man pro horizontalem Zeilenband nur 2 Tiefen hat, dazwischen das ehemalig hintere Playfield subtrahiert, dann das ehemalige vordere zum hinteren macht, dann erst daas neue vordere addiert. Die Copperliste kann alles was man dazu braucht, und mit dies erst noch auf festen Zeilen liegen sogar eine statische. Wobei innerhalb der Zeilenbänder wegen scrollen ohnehin gerollt wird, also doch zur Laufzeit generieren. Einziges Problem ist, dass mehr als Dual 2bpp die extra Bitplanes braucht und damit Prozessor killt, trotz nur 8+7 Farben. Der Prozessorverlust muss gegen dem durch Kopieren eingesparten Prozessorverbrauch abgewogen werden.

(Als Vergleich hat MegaDrive/Genesis hat Parallax mit 2 Playfields zu je 4bpp. Die SNES hat selbiges, kann aber diese beiden separat in 2 mal 2bpp aufteilen für bis zu 4 Playfields, oder aber beide zuammenlegen zu 8bpp wenn auch dann nur 1 Playfield. Alles ohne Prozessorbremse, weil Bild sowieso in separatem SPeicher liegt.)

Strikte ergibt das vordere Playfield wegen 0=durchsichtig ein vollbildgrosses Monstersprite! Es kann als ein grosses Sprite benutzt werden, für ein einzelnes riesiges Objekt wie einen Endboss. Damit erspart man sich auch bei einem grossen oft bewegten Objekt den Blitter einsetzen. Nur bleiben Endbosse ohnehin zumeist stehed, passen also problemlos mit Blitter in den Bildhintergrund.

Oder man nutzt das vordere Playfield stehend als Overlay. Sei das um mehrere verschieden bewegende Teile vom Endboss vom Hintergrund zu entkoppeln. Oder auch nur viele kleine Sprites für ein ganzes Feld vom vielen kleinen Objekten wie Angreifern oder Geschossen. Erstere rufen nach Blitter, letztere rufen ohnehin nach mit Prozessor einfügen. Egal welches erspart man sich zumindest wegspeichern und wiederherstellen vom Hintergrund, weil beim vorderen Playfield wegen 0=durchsichtig man dieses zuerst auf 0 leert, solche Objekte einfach mit wieder auf 0 stellen entfernen kann (wie Atari 800 Sprites vertikal im 256Byte Streifen verschieben).

Allenfalls erspart man sich mit AND Funktion ausstanzen, weil nichts dort ist, damit reicht sogar MOVE. Zumindest solange Objekte ihre umgebenden Rechtecke nicht überlappen, dann braucht es AND und OR. Aber selbst überlappen kann man reduzieren, mit unplanbar bewegende Spielerobjekte als Sprites und planbare Gegnerobjekte als Dual-Playfield. Sollte das trotzdem versagen kann man halbe-halbe den vorderen Playfield mit Doublebuffering und nur Objekte Compositing aufbauen, ohne den weitaus aufwendigeren Hintergrund so machen zu müssen. Bonuspunkte, dass man damit nur 2 oder 3 Bitplanes an Datenmenge erzeugen muss, statt volle 4 oder gar 5 modifizieren. Einziges Problem ist, dass alle diese Objekte in Playfield zusammen nur 7 Farben haben, also dies gegen echte Sprites 3 oder 15 abwägen. Wiederum sind solche vielen kleinen Objekte oft in identischer Farbe. Wieder mal ist man hier bei entscheiden und mehr Komplexität.

(Als Vergleich hat der NeoGeo MVS Spielhallenautomat gar keine Playfields! Er nutzt die ganze Speicherbandbreite nur für Sprites, was erst die massiven 96 pro Zeile von 380 angemeldeten erlaubt. Wer ein Playfield haben will tut einfach 320/16=20 Sprites auf Höhe 224/16=14 Zellen setzen. Diese sind als Spritegruppe bewegbar, womit auch kein Zeilen verzögern mehr notwendig ist. In 96 passen bis zu 4 mal 20, also bis zu 4 Playfields ohne auf 2bpp zu gehen. Diese müssen zudem nicht die ganze Bildhöhe abdecken, was bis zu 4 Playfield Ebenen auf jeder einzelnen Zeile erlaubt. In 380 passen sogar bis zu 18 Ebenen im ganzen Bild. Oder man lässt den ganzen Parallax Ansatz fallen und verschiebt jedes Objekt im Bild abhängig von wie weit vorne es ist. Das reicht bei 380 angemeleten Sprites auch für massive Mengen an kleinen 16x16 Pixel Objekten. Die 96 Sprites * 16 Pixel * 4bpp = 768 Bytes/Zeile sind nur dank 32bit breitem Objektmuster ROM machbar, was 192 Lesezugriffe pro Zeile braucht, in 64µs pro Zeile mit 24MHz Pixeltakt und 12MHz Prozessor wohl 3MHz Speichertakt.)

Beide: Kein 3D rendern

Strikte kann der Amiga Blitter einen Linienzeichnen Modus, der neben reinen horizontalen und vertikalen auch schräge Linien kann. Man muss dazu einen der 8 Quadranten in einem X/Y Diagramm vorgeben, woraus er weiss ob X und Y Schritte +1 oder -1 sind, sowie welcher immer schreitet und welcher nur ab und zu. Zusammen mit einem Feature um Pixelstreifen zwischen zwei Pixeln mit fester Farbe zu füllen kann er auch zwischen 2 solchen Linien arbeiten. Man kann damit Dreiecke nach der Höhe der vertikal mittleren Ecke in 2 teilen, mit jeder Teil durch 2 Linien plus Horizontale begrenzt. Dies kann an in separaten Speicher zeichnen und füllen. Die Form kann dann benutzt werden um Dreiecke ins Bild zu setzen. Strikte kann man damit Texel zeichnen, wenn man die Dreiecke als Objektformen nutzt um Texturen als Objektmuster zurechtzuschneiden. Man muss dann "nur" all das 1000e mal wiederholen, in für Animation genug geringer Zeit!

Die Performance dürfte dabei jenseits von gut und böse liegen. Erst mit alle obigen Schritte automatisch hintereinander, so wie der Blitter alles von blockkopieren und shiften und kombinieren und Schleifen abarbeiten automatisch hintereinander macht, wird es ausreichend schnell. Solche Hardware ist als 3D Pipeline bekannt. Mit dieser kommt man zu einer brauchbaren 3D GPU. Ohne das haben 2D Rechner nur eine Chance in 3D, wenn sie vorgerenderte Objekte plazieren, mit alle Sichtwinkel im Speicher und nur noch als 2D Ansichten einkopieren. Wozu der Amiga zumindest Sprites und Blitter nutzen kann. Was aber den Diskbedarf massiv in die Höhe treibt, ausser man tut sie erst zur Aufstartzeit vorrendern, analog zu bei ST die Objekte und Elemente vorshiften. Hierbei profitiert der ST wieder einmal von mehr Prozessor und Speicher.

(Solche 3D Pipeline, zusammen mit FPU für Geometrie umrechnen von 3D Objekt zu 2D Texel, ist etwa der Stand der Playstation 1 in 1994/1995. Sie hat keinerlei Sprites und keinen Copper, ist eine reine Bitmapgraphik mit Blitter und scrollen. Mit Anzeige aus einem verschiebbaren und skalierbaren 256/320/384/512/640 Pixel breitem Ausschnitt von einem separaten 1MByte Video RAM, fest aufgeteilt als 512 Zeilen * 1042 Pixel * 16bpp Chunks. Dieses ist nur mit dessen Blitter bearbeitbar, kein Zugriff durch den Prozessor. Mit im Blitter eine solche 3D Pipeline erweitert, welche nur als Eckkoordinaten gegebene Dreiecke in Linien zerlegt und automatisch diese im Chip drinnen füllt und das als Objektform benutzt um Texturen ins Bild zu kopieren. Der Prozessor muss nur 3D Geometrie in 2D projizeren, wozu er eine spezielle Fliesskommaeinheit (FPU) hat. Und selbst die PS1 ist immer noch grenzwertiges 3D, erst PS2 lieferte wirklich gut, in 2000.)

(PCs hatten anfangs nicht mehr als ST. Nur haben sie das mit immer mehr Prozessor wettgemacht, plus ab 1990 mit "Videobeschleuniger" Blitter rein einkopieren. Trotzdem war 3D für sie hoch belastend. Meine Erfahrung auf einem Cyrix 486DX4/100 mit Quake 1 bei 320x200 8bpp auf einer ATI Mach32 war etwa 4fps! Das war so schlecht, dass ich nach dem resultierenden Schlachtfest meinen PC ausbaute mit einem AMD K6-2/350 und Matrox Millennium, der prompt etwa 20fps hinbekam. Kein Wunder stiegen ernsthafte Gamer ab 1995 sehr bald auf 3D GPUs um. Als dazumals nur Gelegenheitsgamer hab ich einen mit grossem Prozessor schnell compilierenden Rechner vorgezogen, der zumindest brauchbar spielte, also eher ST denn Amiga Philosophie.)

Beide: Fazit

Der ST ist im Vorteil wenn Schwarzweiss ausreicht. Er kann einen 400 Zeilen Spezialmonitor benutzen, der PC MDA/HGC und Lisa schlägt wegen quadratischen Pixeln. Er deklassiert erst recht den Mac komplett wegen etwa 50% mehr Pixeln. Damit ist ST ideal für jegliche Büroanwendungen mit Schwarzeiss und Druckerausgabe. Der TT030 vervierfachte dies auf Monster 19" Monitor. Der Amiga brachte erst nach 5 Jahre den ECS Productivity Modus, auf originalem ST Niveau, als TT030 herauskam.

Der Amiga ist im Vorteil wenn viele Farben gewollt sind. Seine mehr bpp machten den Unterschied bei Kunst und Illustrationen, egal ob Ausgabe auf Photos oder Videobandaufzeichnung. Dies war sehr sichtbar, nicht zuletzt mit an der Markteinführung Andy Warhol auftreten und ihn vorführen. Dies begründete dessen Ruf als Graphikwunder, komplett gerechtfertigt.

Aber dahinter lauerten weit unsichtbarer die ganzen gegenüber dem Atari 800 massiv erweiterten Spiele Fähigkeiten. Angefangen mit ausgebauten Sprites, über Blitter, bis zum ANTIC Dislayliste zu Copperlisten erweitert, sowie nichtlinearen Videospeicher und Zeilen verzögert ausgeben und Dual-Playfield. Diese verfestigten den Ruf. Des kostete zwar oft komplexe Deseignentscheidungen und Software, aber es offerierte auch Tiefgang den man ausnutzen konnte, sofern man einen Ansatz fad um die Koprozessoren auszunutzen. Sobald die Democoder das alles entdeckten und ausnutzten war kein Halten mehr.. Weshalb sie den Amiga bis heute weiter programmieren, trotz inzwischen 40 Jahre alte Hardware!

Der ST kann hier nur mit mehr Prozessor und Speicher ausnutzen kontern versuchen. Was bei einfacheren Spielen ausreicht, aber dann an seine Limiten stösst, wenn zuviele Objekte bewegt werden. Es hat keine Komplexität aber auch kein Tiefgang, nur mit Software effektiv programmieren. Dies tut keine Democoder herausfordern.

Erst der STE addiert einen Subset vom Amiga. Aber kein mehr als 4bpp. Keine Sprites. Er hat wenigstens 4096 Farben. Dazu kam nichtlinearen Videospeicher, wenn auch nur per Software ohne Copper. Sowie Zeilen verzögert ausgeben, sogar die volle Funktion in Hardware. Aber all dies kam erst in 1989, zu spät und zu wenig um nicht abzusteigen, sobald der Amiga seine verspätete Ankunft und mit dem 500 den anfangs höheren Preis vom 1000 überwunden hatte. Dies gerade auch weil in 4 Jahren bereits viele nicht-STE verbreitet worden waren, die Mehrheit aller produzierten Systeme! Weshalb die meisten Spieleprogrammierer die nur geringen extra Fähigkeiten nicht mehr benutzen wollten, zumal das auf Kosten kommt von auf vielen bestehenden Systemen nicht laufen. Was wiederum mangels mehr Nutzen die Anzahl weiter verkaufter Systeme limitierte, so den STE am übernehmen hinderte. Atari versuchte trotzdem den STE als "Amiga Killer" auszugeben, aber man sieht, dass sie nicht mal den Amiga voll aufgeholt hatten!

Logisch addieren all diese Fähigkeiten massiv zum Hardwareaufwand und zum Preis vom Amiga ($1300 statt $600), aber sie lieferten auch viel mehr Farben und Leistung (und auch Audio und Joysticks) als den ST. Aber das war nur wertvoll und Preis rechtfertigend, wenn man dies auch ausnutzen konnte und hinbekam. Das sprach eher grosse Spielestudios an, die mit mehreren Personen den Aufwand in den Griff bekommen konnten, und auch mit mehr zahlende Kunden rechneten. Der ST hat seine Limiten. Aber ist einfacher und billiger. Das sprach einerseits reine Büroanwendungen an, aber auch eher kleine Indy Studios oder gar Hobbyisten, mit Einzelpersonen alles machend, und dann billig vertreiben (oder gar Hobbyisten es kostenlos abgeben). Damit wurde der Amiga eher bekannt für intensive Action sowie epische Adventures und RPGs, der ST eher für Puzzles sowie simple Adventures und RPGs. Als der Amiga 500 den Preis senkte holte er auf und überholte. Gerade auch bei Spielen, wo der ST Schwarzweiss irrelevant ist.

Später wurden die Amiga mit separaten Videokarten erweitert, welche in den Zorro Bus passen. Diese verlieren aber die ganzen Amiga Chipsatz Vorteile, erlauben jedoch weit mehr Auflösung. Im Extremfall kann selbst ein Amiga 2000/2000A eine solche Karte beinhalten. Kombiniert mit noch einer A2620 68020 oder gar A2630 68030 Prozessor+Speicher Karte verbleiben vom origialen Amiga nur noch ROM+Bus+IO+Netzteil+Gehäuse. Die erweiterte Systemsoftware erlaubt aber selektiv zurückfallen auf die originalen Teile, um kompatibel zu bleiben.

Audio

• Die PC/XT/AT zeigen die simpelste, mit per Timer oder Portbit Pulse erzeugen. Einfache Hardware, aber sehr limitiert.
• Der Mac zeigt die universellste, Samples von Pulse Code Modulation (PCM) per Digital Analog Converter (DAC) ausgeben. Kann alles, aber die Samples generieren belastet dessen Prozessor massiv, je Kanal 10% Prozessorleistung um zu rendern.
• Der ST hat dagegen einen Programmable Sound Generator (PSG). Dieser kann komplexere Signale erzeugen ohne den Prozessor zu belasten. Aber er ist immer noch durch feste Signalformen limitiert, wenn auch weit flexibler als PC/XT/AT sein Timer.
• Der Amiga hat einen Wavetable Generator. Dieser kann beliebige Signalformen ausgeben, dies trotz ohne den Prozessor zu belasten. Aber er ist in der Komplexität etwas limitert.
• Die fünfe und letzte ist die Frequenzmodulation (FM) Synthese. Diese wird in diversen PC/XT/AT Soundkarten benutzt. Sie kann mehr als PSG aber weniger als Wavetable. Neuere Soundkarten addierten Wavetable. Noch neuere Samples. Letzteres ist was wir heute universell benutzen, seit dem AC97 Chipsatz Audio von 1997.

ST

(Hauptkonkurrent war der SN76489/SN76496 von Texas Instruments, ein leicht modifizierter TMS9919. Der TMS9919 wurde nur benutzt in TI 99/4 und 99/4A, neben dem TMS9918 Video Display Controller (VDG). Der SN76489/SN76496 ist neben PCjr auch in Tandy 1000, dazu noch BBC Micro, ColecoVision und Sega Master System und Game Gear. Ansonsten gab es damals noch diverse nur in einem spezifischen Rechner verbaute PSGs. Am besten bekannt sind wohl der POKEY im Atari 800 und der SID im C64. Bei Konsolen hat die Famicom/NES auch PSG, GameBoy hat PSG plus minimales Wavetable. (SNES und GBA benutzen Samples.))

Kern eines jeglichen PSG ist ein programmierbarer Frequenzteiler. Der AY-3-8910/YM2149F erzeugt damit Rechteckwellen, beim ST aus 2MHz, geteilt durch feste /16 und danach variable /1..4096, was theoretisch den Bereich von 30Hz bis 125kHz erlaubt. Aber da nur von /1 auf /2 schalten bereits die Frequenz halbiert, was einer ganze Oktave entspricht, ist er weit weniger weit hinauf nutzbar. Selbst bei 125/8=15.625kHz hat es erst 8 Töne pro Oktave statt 12. Für volle 12er erlauben muss auf unter 125/12=10.4kHz geteilt werden, nur noch 12* die 440Hz von Grundton A, nur etwa 3.5 Oktaven! Oberhalb davon werden die Töne nicht mehr genau getroffen. Es hat 3 separate Generatoren, mit je eigener einstellbarer Frequenz. Diese kann man für separate Töne mit anderen Frequenzen benutzen, aber auch mit änlicher Frequenz einen Wah-Wah Effekt erzeugnen, mit deren Frequenzdifferenz diesen antreiben.

(Im Vergleich hat der SN76489/SN76496 ebenfalls 3 separate Generatoren, auch Rechteckwellen aus 4MHz, geteilt durch feste /32 und danach variable /0..1023, was 122Hz bis selbige 125kHz erlaubt. Strikte sind es in der Hardware /16 geteilt und dann die /0..1023 pro Halbwelle nach 0 herunterzählen, was dann weiter /2 die Wellen ergibt.)

(Der POKEY hat dagegen zwar 4 separate Generatoren, wieder Rechteckwellen, aber diese limitierter. Nur global schaltbar eine Basisfrequenz von nominell "64kHz" oder "15kHz" (real 1.79bzw1.77MHz durch schaltber /28 oder /114 zu 63.5kHz oder 16.6kHz, 2 Oktaven auseinander) und danach geteilt separat variabel /1..256 (Datenwert 0..255 +1) und dann noch fest /2 (wegen zwei Halbwellen pro Welle), was 30.5Hz bis 31.75kHz erlaubt, somit genaue 12 Töne erst unter 331Hz! Oder nur noch bei Generatoren 1+3 separat direkt aus 1.79bzw1.77MHz durch variabel /1..256 und fest /2, was sehr feine Tonsprünge erlaubt, aber nicht unter 3.5kHz kommen kann, plus allenfalls Generatoren 2+4 separat aus stillgeschalteten obigen 1+3 mit variabel /1..256 (zusammen /1..65536), was ab 13.5Hz erlaubt und trotzdem feine Tonsprünge, aber dann nur noch 2 Generatorpaare hat.)

(Der SID macht es total anderst, hat 3 separate Generatoren, mit diversen Wellenformen, Dreieck (etwa Holzflöte), Sägezahn (etwa Trompete), Rechteck (etwa Klarinette als Klang). Ohne jegliche Teiler, mit stattdessen je Generator einem 24bit Zähler, zu dem mit jedem Takt von 1.0227bzw0.9852MHz eine variable 1..65535 addiert wird. Von diesen 24bit fahren die obersten 8/9/12bit die Tonwelle ab. Was minimal 16777216 / 65535 = 256 Takte pro Welle braucht, also bei etwa 1MHz nur bis zu 3.9kHz erlaubt! Dies aber mit sehr feinen Tonsprüngen. Sägezahn ist 256 Schritte 0..255 (schlicht die obersten 8bit der 24), Dreieck ist 512 0..255 und dann 255..0 (untere 8 der obersten 9, mit oberstem sie invertieren), Rechteck kann mit einer weiteren Zahl 0..4095 die Pulsbreite (mit 0 vor und 255 ab wann, die obersten 12bit mit dieser Zahl identisch sind) eingestellt werden (je schmaler umso kratziger), mit 2048 als symmetrisch (die einzige Tonform welche die obigen drei Chips haben!). Zudem kann er alle drei Tonformen kombinieren, aber dies ist nicht eine Addition, sondern deren 8 Bits ANDieren, was sehr wilde Wellenformen ergibt. Weiter kann jeder Generator mit einem anderen synchronisiert werden, was harte Resets der teilweise angelaufenen Schrittzahl der Tone erlaubt, für komplexere Tonformen (wie Schwebungen, was in Richtung FM Synthese geht). Ebenso mit einem anderen Ringmoduliert werden, was nicht-harmonische Tonformen erzeugt (wie Glocke oder Gong). Zudem kann er den stillschaltbaren Generator 3 auslesen und damit vorzu andere Parameter verstellen, wie Frequenz für Vibrato Effekte. Was alles weit flexibler ist, erst dem SID seinen viel besseren Klang erlaubt. Womit er eben ein Musikinstrument/Synthesiser ist, und nicht bloss ein Geräuscherzeuger. Aber man kann ja alles was steuerbare Geräusche erzeugen kann als Musikinstrument benutzen, nur einfach als primitiveres.)

Daneben kann ein PSG Rauschen erzeugen für Effekte. Der AY-3-8910/YM2149F kann solches pro Generator einmischen, mit entweder nichts/Ton/Rauschen/beides. Aus selbigen 2MHz, ebenfalls geteilt durch die festen /16 aber dann variable /1..32 als Takt benutzt, was theoretisch 3.9kHz bis 125kHz erzeugt. Dieses für alle Generatoren identisch. Damit wird aber kein Rechteck erzeugt, sondern pseudozufällig 0 oder 1 geschaltet. Es wird im Chip Datenblatt nur spezifiziert, dass die Frequenz davon variert, aber keine Angabe wie es genau abläuft.

(Der SN76489/SN76496 kann ebenfalls Rauschen. Dieses ist aber nicht pro Generator zuschaltbar, sondern ein separater vierter Generator. Benutzt die 4MHz /512oder1024oder2048 oder das Rechteck von Generator 3, und treibt damit ein Schieberegister mit XOR Feedback. Datenblatt macht keine Aussage zu Länge vom Schieberegister oder welche Bits in das XOR einfliessen, nur dass es zwei verschiedene Bitsequenzen hat, pulsend oder statistisch.)

(Der POKEY kann ebenfalls Rauschen. Ein dauerend laufender Generator mit Polynomzählern erzeugt Serien von Pseudozufallszahlen (1bit). Es hat mehrere davon, einer global schaltbar 17oder9bit, sowie zwei feste 5bit und 4bit. Alle sind direkt angetrieben von 1.79bzw1.77MHz, womit deren Serien in /2^N wiederholen, also /131072oder/512 sowie /32 und /16, was auf 13.58oder3476Hz sowie 55.625kHz und 111.250kHz kommt. Diese sind aber keine direkten Töne, sondern wirken als Pulskiller, wenn der Generator ansonsten mit seiner Pulsfrequenz sein Signal kippen würde. Diese sind pro Generator zuschaltbar in allen 4 separat, einstellbar zuerst ob 5bit ja/nein, gefolgt von entweder 4bit oder 17oder9bit ja/nein, was mehrere Mustern an Rauschen erlaubt.)

(Der SID kann ebenfalls Rauschen. Wieder pro Generator zuschaltbar in allen drei. Von deren Frequenz gesteuert. Dieser kann diverses von rumpeln bis zischen, für Schlagzeug oder Motoren oder Explosionen bis zu Wind/Wellen. Mit stillschaltbaren Generator 3 auf Rauschen gestellt und dessen Wellenzustand ausgelesen bekommt man einen Zufallszahlengenerator.)

Weiter kann ein PSG die Lautstärke einstellen. Der AY-3-8910/YM2149F kann dies pro Generator mit einem 4bit = (0..15)/15 Lautstärkeregler (wie Mac 3bit = (1..8)/8). Wobei dieser hier aber nicht linear ist, sondern von 0..15 exponentiell ansteigend, das Datenblatt gibt aber nur eine Kurve, keine Formel. (Der SN76489/SN76496 hat nur 4 Schalter, welche 2oder4oder8oder16db abziehen können (-10db = halbiert), beliebig kombinierbar, ausser alle 4 sind aktiv = aus (damit max 28db).) (POKEY hat 4bit, nicht weiter spezifiziert, zusammen maximal 32 sonst wird die Analogschaltung übersteuert.) (SID auch 4bit pro Generator, als linear spezifiziert, plus dazu noch am Schluss einen weiteren 4bit an Gesammtlautstärke.)

Obiger Lautstärkeregler pro Generator kann per Software fest gesetzt werden oder auto-modifiziert in Hardware sein. Letzteres geschieht mit einem Hüllkurvengenerator. Beim AY-3-8910/YM2149F wird mit einem Schaltbit auf Hüllkurvenbetrieb umgestellt. Diese läuft langsam, aus selbigen 2MHz, aber geteilt durch feste /256 und danach variable /1..65536, was im Bereich von 128µs bis 8s erlaubt. Er kann 8 Modi benutzen, spezifiziert mit einer Zahl 0..15, als Summe von: wiederholt=8/einmal=0 + aufsteigend=4/abnehmend/0 + alternierend=2/nicht=0 + halten=1/nicht=0. Alternierend ergibt Sägezahn, nicht ergibt Dreieck. Er rechnet die Flanken 16 Schritten (0..15)/15 im originalen AY-3-8910, aber in 32 (0..31)/31 im YM2149F.

(SN76489/SN76496 und POKEY haben nichts derartiges. Man kann allerdings selbige Wirkung mit etwas mehr Software kompensieren, welche die "feste" Hardwarefolgen vom Lautstärkeregler "manuell" nachstellt, mit pro Bild im Vertikalinterrupt nachstellen.)

(SID hat dies, und sogar sehr elaborat. Lautstärke stellen tut nicht direkt den Ton ausgeben, nur seinen Wert spzifizieren. Ton ein/aus macht erst ein Gate Bit. Dazu kann man mit 4*4bit einen Satz ADSR Parameter spezifizieren: Attack (A) wie lange ab Gate aufmachen von Null bis Maximum braucht (2ms bis 8s), gefolgt von Decay (D) wie lange von max bis "S" (6ms bis 24s), dann Sustain (S) wie viel von Maximum das "S" ist (eben die (0..15)/15 der Lautstärke), sowie Release (R) wie lange ab Gate zumachen bis Null (selbige 6ms bis 24s wie S). Damit wird eine Art von Klavieranschlag simuliert, falls man "S" auf 3 setzt und genau bei "S" erreicht Zeitpunkt Gate zumacht. Mit schnell Gate auf/zu schalten kann man direkt von A zu R wechseln, in Software beliebige Kurven erzeugen.)

Jeder Ton ausser einem Sinus hat Oberwellen, bei genauen Mehrfachen der Grundfrequenz, und deren Mehrfachen mehrfach wiederholt. Deren Abstand und Stärke unterscheidet den Klang bei ansonsten gleichfrequenten Tönen. Ein PSG kann von Filtern gefolgt werden um Oberwellen zu beeinflussen. Der AY-3-8910/YM2149F hat aber keinen solchen.

(Ebenso SN76489/SN76496 keinen.) (Der POKEY hat nur einen Hochpassfilter. Dieser tut per Flopflop und XOR Gatter feststellen wenn die Frequenz vom einen Generator unter eine Vergleichsfrequenz von einem anderen fällt, und dann den ersten abschalten. Nur Generator 1 und 2 können dies, mit Generator 3 und 4 als Lieferanten der Vergleichsfrequenz.) (SID kann hier weit mehr. Man kann mit separaten 8+3=11bit eine Vergleichsfrequenz einstellen, plus mit 4bit Resonanzverhalten. Dann kann man alle 3 Generator plus ein externes Audiosignal zwischen 1=gefiltert/0=direkt schalten. Dann kann man per 3bit Tiefpass/Bandpass/Hochpass aktivieren, in beliebiger Kombination.)

Ein PSG erlaubt somit vorzu ein komplexes Signal zu generieren mit nur wenig Prozessoraufwand, weil nur ändern der Tonspezifikation nach mit Prozessor die Register neu konfigurieren verlangt. Wozu bereits pro Bild im Vertikalinterupt nachstellen ausreicht, weil dessen 60oder50Hz bereits unter der Wahrnehmungsschwelle von etwa 100ms liegen. (Dies ist analog zum PC Beep, wo der Timer 2 eine Rechteckwelle generiert und der Prozessor nur start und stop macht, wenn auch weit leistungsfähiger konfigurierbar.)

Mit den Lautstärkeregler per Software schnell setzen kann man aber auch primitive Samples in Software ausgeben. Im Gegensatz zum PC/XT/AT nur 1bit sogar mit mehreren Bits. Der AY-3-8910/YM2149F kann dies nicht.

(Ebenso SN76489/SN76496 nicht.) (Der POKEY kann dies mit einem Steuerbit um hart eine 1 durch den Lautstärkeregler zu senden.) (Der SID kann dies mit alle Generatoren aus und den resultierenden ungeplanten Spannungspegel durch die Gesammtlautstäre teilen. Was aber in den neueren 9V SIDs mangelns Spannungspegel versagt, ausser man verpasst dem externen Audio Einfang eine Spannung per Widerstand einlöten. Es gibt aber inzwischen diverse Methoden, welche die Generatoren missbrauchen, sei dies Sägezahn Endwert oder Pulsbreite ausnutzend.) (Egal welcher Chip und welche Methode verbraucht dies aber die ganze Prozessorleistung, wie auch bei PC in Software 1-Bit Sound ausgeben. Weshalb man dies nur parallel zu zuerst Illustrationen anzeigen und dann auf Tasten warten benutzen kann.)

Damit kann man ganz ordentliche Geräuscheffekte erzeugen. Aber der AY-3-8910/YM2149F ist schwach für Hintergrundmusik, mangels andere Wellenformen als Rechteck (selbiges auch SN76489/SN76496 und POKEY), sowie mangels 12 Töne pro Oktave bei höheren Frequenzen. Womit der ST problemlos den Atari 800 und POKEY beerben kann, wenn auch nicht verbessern. Gegen den C64 und SID hat er schlicht gar keine Chance.

Aber der AY-3-8910/YM2149F war billig und vorhanden. Sein Gebrauch im ST ist somit ein klassischer Fall von wir brauchen schnell mal was ab der Stange. Dabei sind diese etwas vom besseren. Sie erscheint an Adressen $FF8800..$FF89FF, mit GLUE Signal /SNDCS (ab STE ist dieses reduziert auf $FF8800..$FF88FF). Dessen Registeradresse BC1 kommt von Prozessoradresse A1, also in 1 Wort Schritt. Die Datenleitungen sind an Prozessordaten D8..D15, also erscheint sie an Bytes mit geraden Adressen. Nur erwartet der AY-3-8910/YM2149F seine Adressen auf den selbigen Pins wie die Daten, weil von General Instrument eigentlich für deren 16bit Prozessor CP1600 designt, der Pins so doppelt nutzt (wie 8086). Also ist Prozessor A1 eigentlich an dessen Daten=1/Adressen=0 Schaltbit. Mit $FF8800 wird daher eines der internen 16 Register angewählt. Mit $FF8802 werden dann die Daten geschrieben. Aber erstaunlich werden Daten von $FF8800 gelesen, weil A1 als dem CP1600 sein Bus Daten schreiben Signal benutzt wird, und R/W als Daten lesen Signal.

Die im ST verwendete 40pin Grossversion kommt mit 2*8bit PIO Ports. Neben diesem AY-3-8910 gibt es eine 28pin Mittelversion AY-3-8912 ohne PIO Port B und eine 24pin Kleinversion AY-3-8913 ohne beide PIO Ports. Die YM2149F gibt es nur in 40pin. (Die SN76489/SN76496 sind stets 16pin, ohne jegliche Ports.) (POKEY ist 40pin mit diversen Ports.) (SID ist 28pin mit Paddleport.)

Wie bei der 8255 im PC können diese PIO nur in 8er Blöcken als Eingang oder Ausgang geschaltet werden. Im ST ist Port A stets Ausgang, treibt diverse Sachen: IO A0 ist Floppy Kopfauswahlsignal, IO A1..A2 sind Laufwerkswahl FD0+FD1, IO A3..A4 sind RS232 RTS+DTR, IO A5 ist Drucker Strobe, IO A6 ist GPO Signal an Monitorstecker Pin 3, IO A7 ist unbenutzt. Weiter ist Port B zumeist Ausgang, IO B0..B7 sind Drucker D0..D7. Er kann aber auch reversiert werden, wenn keine Daten an Drucker am senden sind.

Der ST hat zudem eingebautes MIDI. Dieses wird benutzt um in der professionellen Musik Klaviaturen oder Sequencer mit Synthesizern zu verbinden. Aber es kann mangelns solcher Ausrüstung bei den meisten normalen Benutzern nicht für Spiele Hintergrundmusik benutzt werden.

MIDI ist technisch ein reduziertes RS232, ohne die +/-12V Wandlung, reine TTL 5/0V. Es läuft mit fester 1/32MHz=31.250kHz Bitrate und 8N1 Bitanordnung. Es läuft über bestehende DIN5 Stereo Audiokabel, selbige wie in HiFi Komponentensystemen zwischen Tapedecks und Vorverstärker benutzt werden. An der MIDI Out Buchse sind Pin 1+3 MIDI Through (von MIDI In), 2 GND, 4+5 MIDI Out (vom ST). An der MIDI In Buchse sind Pin 4+5 MIDI In, Rest unbenutzt. Womit standard Audiokabel MIDI Out zu MIDI In verdrahten.

Der ST benutzt für MIDI einen 6850UART, ein simpler Mitte 1970er Chip. Sie erscheint an Adressen $FFFC00..$FFFDFF, mit GLUE Signal /6850CS, und decodiert selber noch A2=1 (ab MegaST auch A5=0). Dessen Registeradresse RS kommt von Prozessoradresse A1, also in 1 Wort Schritt. Die Datenleitungen sind an Prozessordaten D8..D15, also erscheint sie an Bytes mit geraden Adressen. (Es kann auch für ein langsames aber billiges 31.25kbps Filetransfer Netzwerk zwischen zwei ST missbraucht werden. Es ist ebenso ausreichend für Multirechner Multiuser Spiele.)

Wobei bei MIDI eigentlich 5mA Strom oder nicht gemessen wird. Es benutzt dazu galvanische Trennung durch Optokoppler beim Empfangenden gegen Brummschleifenstörungen, daher eben nur Strommessung machbar, weil mit Strom die LED im Optokoppler leuchtet. Um Strom zu generieren hat es in Folge: Widerstand 220Ohm von 5V an R77 und R78, durch Kabel Out zu In, dort weiteren Widerstand 220Ohm an R76 und Optokoppler PC-900 an U39, wieder durch Kabel In zu Out, nochmals Widerstand 220Ohm an R79 und R80, dann durch 74LS05 Chip an U36 zu 0V. Damit fliesst strikte 5-0.7=4.3V durch 3*220=660Ohm, was 6.5mA ergibt. Da der 74LS05 das Signal invertiert sind davor die 74LS04 an U35 als Kompensation. Das TxDATA=1/0 6850UART vom schaltet somit Strom aus/ein. Dessen RxDATA bekommt eine 1 vom Widerstand 4.7k an R81, ausser Strom triggert den Optokoppler der nach 0 zieht.

MIDI zusammen mit 400 Zeilen 71.25Hz Schwarzweiss Monitor machten den ST ideal für Sequencer Software in Musikstudios. Aber auch an Konzerten ist er nutzbar, weil kompakt. Selbst der YM2149F schafft es in die Musik, weil gerade sein charakteristischer Primitivsynth Klang als Robottersound oder Chiptune Instrument gut taugt, zusammen mit Tracker Software. Aber auch abseits von elektronischer Musik erzeugen ist der ST gut für editierien von Notenblättern durch Komponisten. Daher hat er praktisch die Musik dominiert, niemand sonst war so gut, erst recht zu dem Preis.

Gerade weil der ST für Musik wichtig war gab es auch von Drittherstellern Erweiterungen. Das fing an mit 8bit DAC an den Druckerport hängen und mit Software Samples schreiben. Was etwa Mac-artigen Klang ermöglichte, wenn auch mit entsprechendem Verbrauch an Prozessor. Im Extrem wurde der Modulslot missbraucht, der zwar strikte nur ROMs lesen kann, aber mit 2 separaten /CS Signalen kann man mit einem ein ROM lesen (was auf 64k statt 128k ROM limitiert), und mit dem anderen IO Hardware anschubsen mit Adressbits als Datenbits missbraucht! Wobei die 68000 einem erst noch hilft, mit Index Adressmodus nutzen, mit Basisadresse auf $FB0000 (zweites /CS) setzen und dann mit Daten 16bit dazu addieren Adressen im ganzen $FBxxxx Bereich generieren. Was auch besseres als 8bit DAC ansteuern erlaubt. Oder man lässt ROMs ganz weg und nutzt auch noch $FAxxxx um Samples einzulesen, diese per Datenbus.

(Nach in 1993 von Atari abgekündigt werden, wurde das Design vom ST kurzerhand aufgekauft und forgesetzt von Musiksoftware Firma C-LAB. Bis heute benutzen manche Musiker bevorzugt einen ST, weil PCs mit USB einfach kein zuverlässig sauberes Timing hinbekommen! (Genauso wie heute manche Leute bei Gamecontrollern WLAN statt Bluetooth benutzen wegen besserem Timing, gibt es auch ST-lose Musiker welche MIDI über Ethernet statt USB benutzen.))

Amiga

Ausgabe zu Analogsignale ist im PAULA Multi-IO Customchip, in Stereo an dessen Pins AUDA und AUDB, gefolgt von pro Stereokanal 2/4 eines LF347 Op-Amps. Die Tonformen entstehen aber nicht im PAULA, sondern kommen von Daten im Speicher, den Samples. Diese kommen aber nicht aus einem einzelnen festen Buffer pro Frame ablaufen (wie im Mac, ein Wort pro Sample, 370 Samples pro Frame), sondern sind weit flexibler angeordnet. Pro Wort im Speicher hat es zwei Samples (nicht eines wie Mac, keine verschwendeten unteren 50% Bits, welche dort für Floppy missbraucht werden). Samples sind Werte -128..127 (statt Mac 0..255). Der Anfang der Samples im Speicher kommt vom AGNUS, mit Adressen AUDxLCH+L (x=0..3) (statt Mac nur zwei feste Buffer). Wie COP1LCH+L nach Ende des Bildes werden sie nach Ende der Samples automatisch neu gesetzt für als Ringbuffer ausgeben, kein nachladen per Software notwendig.

Auch die Tonlänge is flexibel definierbar. In AUDxLED gibt man die Anzahl Worte (nicht Bytes/Samples!) an, nach denen wieder vom obigem Anfang der Samples gelesen wird. Daher muss nur eine Wellenform an Speicher verbraucht werden. Ausser bei hohen Frequenzen, wo man um diese genauer zu treffen eine Mehrfachwelle definieren kann, mit Nulldurchlauf erst bei der letzten Welle ihren Samplezeitpunkt. Sobald der letzte Durchlauf des Samplesatzes eines Tones gestartet ist, kann man die Adressen des ersten Welle des nächsten Tones anmelden. Dazu gibt es einen Interrupt. Um diesen nicht zu oft zu bekommen ist ebenfalls bei hohen Frequenzen Mehrfachwelle angesagt. Um beim Übergang Clicks zu vermeiden sollten beide Wellen mit 0 enden und anfangen.

Die Samplerate ist flexibel programmierbar, und ergibt geteilt durch die Anzahl der Samples die Frequenz. Dies alles vermeidet die Samples auf feste Videozeilen Samplerate umrechnen zu müssen (wie im Mac, was dort massiv Prozessor kostet). Eingestellt wird die Rate in den NTSC 3.5795MHz bzw PAL 3.5469MHz Taktzyklen der 320 Pixel/Zeile. Wegen maximal einem Wort (und somit 2 Samples) pro Zeile, und 228 bzw 226 Takte pro Zeile, ist minimal 124 bzw 123 Takte pro Sample (sowie maximal 65535), somit maximal 31.4kHz. Die Samplerate sollte mindestens 7kHz über dem höchsten Ton liegen um Aliasingfehler zu vermeiden. Um solche Fehler zu reduzieren hat es aber auch einen Tiefpassfilter, der ab 4kHz aufwärts das Signal reduziert, aber bekanntlich sehr schlecht ist. Auf 2000B/B2000 und 500 kann man diesen Tiefpass abschalten per einem CIA A Bit.

Werden weniger als maximale Samples benutzt wird automatisch mit weitere nachladen abgewartet. Werden mehr eingestellt werden ab und zu welche wiederholt. Es hat zudem 4 separate Audiokanäle (im Gegensatz zum Mac 1, was auch Töne mischen meidet, was dort ebenfalls Prozessor kostet). Wobei aber nur fest je 2 pro Stereokanal sind, 0+3 rechts sowie 1+2 links, ein eigenartige Anordnung. Jeder Audiokanal hat eine Lautstärke, in AUDxVOL gesetzt mit 7bit aber nur Wertebereich 0..64 davon (mehr als Mac 3bit, was hier auch Töne skalieren meidet, was dort ebenfalls Prozessor kostet). Damit kann man Wellenformen mit vollem Wertebereich definieren, um Treppenfehler zu vermeiden. Selbige Wellenfom auf beiden Stereokanälen abspielen mit nur anderer Lautstärke erlaubt sie horizontal zu positionieren.

Als Spezialeffekt kann ein Audiokanal vorzu von einem anderen modifiziert werden. Man kann Samplerate und/oder Lautstärke setzen, mit den eins weniger nummerierten Kanal umfunktionieren. Aber dies geht nur mit 0..2 auf 1..3 wirkend, keine Wirkung von 3 auf 0. Vielleicht ist das auch der Grund für obige eigenartige Anordnung.

In der Musik hat der Amiga trozudem eher wenig an Bedeutung. Die 8bit seiner Wavetable entsprechen nur Telephonqualität, und sind so nicht ausreichend für professionelle Musik. Sie haben aber auch keinen Wert in Chiptunes, mangels den PSG ihren charakteristischem Primitivsynth Klang. MIDI ist auch nicht vorhanden, wenn auch der RS232 Port mit etwas externer Hardware zu MIDI gemacht werden kann, danke sehr flexibler Bitrate generieren (was PC und Mac nicht können). Das kann sich trotzdem nicht mit dem eingebauten MIDI vom ST messen, geschweige denn mit dessen Vorsprung, dank nur einstecken und loskomponieren. Zudem fehlt dem Amiga ein 400 Zeilen Monitor für optimal Noten editieren. Und schliesslich ist der Amiga schlicht teuerer, wegen seiner Videofähigkeiten, welche aber in der Musik irrelevant sind (der Preis trifft auch PC und Mac).

(Der STE addiert Pulse Code Modulation (PCM) Audio. Dieses hat 2 separate Audiokanäle (im Gegensatz zum Mac 1 und Amiga 4). Die Samples sind 8bit mit Werte -128..127 (wie Amiga, entgegen Mac 0..255). Maximale Samplerate ist 50.066kHz, welche noch um /2 oder /4 oder /8 reduzierbar ist, um Speicher zu sparen. Diese kommt angeblich von pro Videozeile ausgeben von 1 Wort = 2 Bytes = 2 Samples per DMA holen (wie Amiga), aber obiges deckt sich gar nicht mit der Video Horizontalfrequenz (bei Farben 15.7kHz bzw Schwarzweiss 35.7kHz). Diese sind entweder nutzbar als 2 Stereokanäle 1 Sample (D15..8=Links und D7..0=Rechts) oder Mono als 2 Samples. Sie werden zu Analog gewandelt mit zwei DAC0802 Chips, gefolgt von zwei Tiefpassfilter, die ab 16kHz aufwärts das Signal reduzieren (weit mehr als Amiga 4kHz). Für Lautstärke und Balance sowie Klangregler wird ein LMC1992 Chip benutzt, der per Microwire Interface zu konfigurieren ist.)

(Der PCM Generator erscheint an $FF8900..$FF89FF. Man kann die Anfangsadresse und Endadresse der Samples einstellen (im Gegensatz zu Amiga Anfangsadresse und Länge). Auch hier kann man die Adressen des ersten Welle des nächsten Tones anmelden, sobald der letzte Durchlauf des Samplesatzes eines Tones gestartet ist. Der Interrput kommt hier via einen der Timer im 68901MFP. Damit ebenfalls nicht aus einem einzelnen festen Buffer pro Frame (wie Amiga, entgegen Mac). Das sieht auf den ersten Blick nach Wavetable aus. Aber es hat nur einen einzelnen Sampleset, ohne mehrere zu mischen, und das erst noch mit beide Stereokanäle parallel im Set drin. Also doch die ganzen Prozessorlast Probleme vom Mac, nur mit Buffer flexibler zu handhaben.)

(Damit ist dies auf etwa doppeltem Mac Niveau, aber immer noch unterhalb vom Amiga. Wie soviel anderes beim STE war es halbwegs bis gut nachgezogen auf was anfangs schon hätte sein sollen, aber kam zu spät. Wie beim nicht ausreichend verbesserten Video, welches nichts änderte für Spieler, wegen meistens nicht benutzt, war es hier nicht relevant für Musiker, weil wie Amiga bloss 8bit Telephonqualität.)

(Der Falcon030 addierte noch einen 56001 DSP als Audio Koprozessor. Der konnte wenigstens für Musik benutzt werden, als in Software definierten Synthesizer. Aber der kam 1992 weitaus zu spät. Ausser das war genau der Grund warum C-LAB nur den Falcon030 weiter produzierte und sogar expandierte.)

Tastatur

ST

(LK201 ist auch der ideele Vorläufer vom IBM Enhanced Keyboard. Aber dort wurde LK201 mit AT vermischt. Insbesondere musste IBM alle gewohnten Cursor+Edit Tasten vom Numerikblock im neuen Cursor+Edit Block beibehalten, was Home/End addierte, damit LK201 seine Search und Select verdrängte. Und sie haben die Pfeiltasten eine Reihe nach unten bewegt. Und haben dabei in 1986 einen Layout Klassiker erzeugt, der die Welt bis heute dominiert!)

Gar nicht mithalten kann der ST aber bei den Tastenmechanismen. Wie Apple beim Mac hat Atari keine Jahrzehnte an Forschungstradition in Tastaturen herstellen, sind eine reine Rechnerfirma. Also haben sie ebenfalls schlicht Tastaturkomponenten eingekauft. Leider keine guten. Verwendet werden von Silitek die Dome with Slider Mechanismen. Diese entsprechen im schlabrigen Verhalten einer modernen Gummimatten Tastatur, nur eben mit pro Taste einen eigenen Mechanismus mit einem Gumminoppen drin, also ohne die maximale Kostenreduktion. Erfreuliche Ausnahme gilt nur beim MegaST, in dessen Tastatur von Cherry die MX Black Schalter verbaut wurden, deren Platinenloch Anordnung und Halterungsrahmen Bauform und Tastenkappen Aufsteckform inzwischen zum Weltstandard geworden sind. Beim TT030 und MegaSTE aber leider nicht mehr so, bei STE sowieso nicht.

Als mechanische Kontakte sind sie direkt vom Mikrocontroller lesbar. Es wird dazu ein 6301V1 verwendet. Wie beim IBM Enhanced Keyboard seiner Model M werden 8 Tasten aufs mal eingelesen. Wegen vieler Tasten ist die Matrix 15 lang (IBM AT 12, Enhanced 16). Der Mikrocontroller zieht somit jeweils eine von 15 Ausgangsleitungen (P31..P37 und P40..P47) auf 0, kann damit Strom versenken, weil zu 0V abfliessend. Dies aber nur durch alle gedrückten Tasten von der Reihe, während Tasten aller anderen Reihen mit 1 keinen Strom versenkt bekommen. Daher erscheinen an den 8 Eingangsleitungen (P10..P17) nur in dieser Reihe gedrückte Tasten als 0, ohne solche ist alles 1. Wenn 2 Tasten einer Reihe und eine gleichpositionierte einer anderen Reihe gedrückt werden entsteht der Eindruck als wenn auch in der anderen Reihe 2 gedrückt sind. Das Extra ist als Phantomtaste bekannt. Daher befinden sich gerade Shift/Ctrl/Alt Tasten fast alleine in einer Reihe, was dann zu 15 statt 13 Reihen führt. (Ctrl ist alleine, L-Shift Alt R-Shift teilen nur mit F1..F3, mit Rest 11x8 voll ausgebucht.)

Der Mikrocontroller sendet die Daten zu einer weiteren 6850UART im Rechner. Sie erscheint an Adressen $FFFC00..$FFFDFF, mit GLUE Signal /6850CS, und decodiert selber noch A2=0 (im Gegensatz zu MIDI A2=1) (ab MegaST auch A5=0). Dessen Registeradresse RS kommt von Prozessoradresse A1, also in 1 Wort Schritt. Die Datenleitungen sind an Prozessordaten D8..D15, also erscheint sie an Bytes mit geraden Adressen. Bekommt wie MIDI 500kHz vom GLUE, tut aber neben dem implizierten /16 der UART noch ein /4 davor, für 7812.5Hz Bitrate, damit der 6301V1 nachkommt, dies trotz dass dieser eigentlich eine eigene UART drin hat, weil diese bei 4MHz Takt nur /16 oder /128 (benutzt) oder /1024 oder gar /4096 kann! Rechner TxD geht an 6301V1 P23, RxD kommt von P24.

Wegen UART und beide TxD und RxD Pins verdrahtet ist dies per Definition bidirektional. Dies mit einfacher 1930er Fernschreibersignal Logik statt der komplexen AT Rechner 8042 zu Tastatur 8048/6805 Protokoll Geschichte. Kostet eine UART im Rechner und einen Mikrocontroller mit UART, was aber selbst der Billigrechner ST sich leisten kann, der teure AT also erst recht könnte. Die Daten von der Tastatur sind Make/Break Codes, Bit7 0=Make=gedrückt oder 1=Break=losgelassen plus 7bit Tastennummer (wie PC und XT). Kommandos zur Tastatur können diese konfigurieren. Inklusive $01 Reset Tastatur sowie $11 und $13 als erlaube bzw stoppe Daten zum Rechner senden.

Neben Tastatur wird der 6301V1 auch für anderes eingesetzt, Joysticks und Maus sind dort angehängt, sowie eine resetfeste (aber nicht stromlosfeste) Echtzeituhr darin. Die Erweiterungen dafür werden weiter unten behandelt in den passenden Kapiteln.

Amiga

Wie Apple beim Mac haben Amiga und Commodore keine Jahrzehnte an Forschungstradition in Tastaturen herstellen, sind eine reine Rechnerfirma. Also haben sie ebenfalls schlicht Tastaturkomponenten eingekauft. Verwendet werden von Mitsumi die Standard Mechanical Type 2 in der Mitsumi original Tastenkappen Aufsteckform.

Als mechanische Kontakte sind sie direkt vom Mikrocontroller lesbar. Es wird dazu ein 6500-1 verwendet. Es werden aber nur 6 Tasten aufs mal eingelesen. Mit 89 Tasten ist die Matrix 16 lang. Der Mikrocontroller zieht jeweils eine von 16 Ausgangsleitungen (PC.0..PC.7 und PD.0..PD.7) auf 0, dann erscheinen an den 6 Eingangsleitungen (Bit2..Bit7, welcher Port ist nicht dokumentiert) die Tasten. Wegen Phantomtasten meiden sind die Tasten 1*Ctrl 2*Shift 2*Amiga und 2*Alt explizit nicht Teil der Tastenmatrix, an eigenem Port (Bit0..6, welcher Port ist wieder nicht dokumentiert).

Der Mikrocontroller sendet die Daten zum Rechner synchron seriell. Durch ein 4-adriges Kabel mit 4P4C RJ11 Stecker (selbigen wie teilweise am Kabel von Telephon zu Höhrer benutzt wird, wie Mac). Pins 1 5V (+5V), 2 Takt (KCLK), 3 Datenbits (KDAT), 4 0V (CGND). Dies wird sicher mit reinem Bitbanging gemacht. Von angenommen Bit0+1 vom Eingangsleitungen Port (auch hier nicht dokumentiert). (Im Gegensatz zum Mac ist das Pinout hier unvertauscht kompatibel mit Telephonhöhrer Kabeln.)

Die Daten gehen im Amiga zur 8250CIA-A ihrem Shiftregister. Diese hat im Gegensatz zur 6522VIA keinen Bug mehr, der wurde bereits in der 6526CIA geflickt. Daher könnte die Verbindung bidirektional getacktet benutzt werden), wird es aber nicht. Es hat keinerlei Kommandos an die Tastatur (wie PC und XT, im Gegensatz zu AT und Mac und ST). Gesendet wird 8bit Daten ohne Start/Stop. Pro Bit mit dieses anlegen, 20µs, Takt=0, 20µs, Takt=1, 20µs, nächste Daten, ..., für 60µs pro Bit, 17kHz Bitrate. Nach senden eines Zeichens wird auch Datenleitung=1 gesetzt und gewartet auf eine Bestätigung in Form von Datenleitung=0 für mindestens 85µs. Bis dann wird nichts mehr geschickt, es hat dazu einen 10 Tasten Buffer. Die Daten von der Tastatur sind Make/Break Codes, Bit7 0=Make=gedrückt oder 1=Break=losgelassen plus 7bit Tastennummer.

Als Ausnahme wird Caps Lock nur bei gedrückt werden geschickt, aber mit 0=Make falls LED ein oder 1=Break falls LED aus. Mit LED angenommen an Bit7 vom nicht-Phantomtasten Port (auch nicht dokumentiert). Womit die Tastatur den Caps Lock Zustand kennt und dem Rechner vorgibt. Dieser tut sie nur kopieren. (Im Gegensatz zum AT wo der Rechner den Caps Lock Zustand kennt und der Tastatur mitteilen muss. Womit erwiesen ist, dass bidirektional nicht einmal notwendig ist, die enorme komplexe AT Rechner 8042 zu Tastatur 8048/6805 Protokoll Geschichte, plus 286er zu 8042 Protokoll, wegen den LEDs vom Rechner aus synchron steuern, unsinnig übermässig aufwendig ist. Typisch IBM Design.)

Gesendet wird aber mit Daten in inverser Logik (0=5V und 1=0V), Grund mir unbekannt. Zudem ist Bitreihenfolge 6..0 und dann erst 7, wegen im Falle von Sync verlieren. Kommt nach 143ms keine Bestätigung eines Bytes wird Syncverlust angenommen und so lange mit diesem Abstand Daten=1 gesendet bis Antwort kommt, womit wieder Sync ist. Und das "kaputtierte" Byte wird zu einem 1=Break, was als falsche Taste loslassen weniger schadet als eine falsche Taste drücken. Dies gefolgt von Byte $F9 als Warnung senden, weil der Rechner den Syncverlust nicht bemerken kann, und dann das als gescheitert angenommene Zeichen nochmals. Nach Reset geschieht das selbige, alles 1 ausgeben bis der Rechner antwortet, nur ohne $F9 danach. Statt dessen wird bei gescheitertem Selbsttest $FC geschickt, gefolgt von LED blinken, bei gelungen $FD, dann alle gedrückten Tasten ausgeben, dann $FE, dann einschalten leuchtende LED aus, dann Normalbetrieb.

Zudem geht nur das Taktsignal von der Tastaturleitung auch in die 4 kaskadierten LM2901 der Resetlogik. Damit kann die Tastatur nach eine Tastenkombination erkennen (Ctrl plus beide Amiga Tasten) mit einem langen Taktpuls=0 von mindestens 500ms (maximal bis mindestens eine der Tasten losgelassen wird) einen Reset auslösen. Dies erlaubt Reset ohne am Rechner eine explizite Resettaste zu brauchen (was man bei PCs zumeist nachrüsten musste), oder sich auf noch laufende Interrupt Software auf dem Hauptprozessor zu verlassen (wie bei PC Ctrl-Alt-Del).

Danach wird bei manchen 1000 und 2000 zuerst eine Warnung $78 geschickt, was der Rechner wie eine normale Taste bestätigen muss, sonst gilt er als tot und es wird wird hart Reset gezogen. Falls bestätigt kommt eine zweite $78 mit nur noch innert 250ms Datenleitung=0 vom Rechner, sonst auch hart Reset. Dann wird maximal 10s erlaubt um Anstehendes zu erledigen (wie Disk konsistent bringen), gefolgt von Rechner mit Datenleitung=1 den Abschluss bekanntgeben, sonst ebenfalls hart Reset. Nach Datenleitung=1 sehen kommt sofort Reset.

Ab Amiga 500 und 2000 haben alle ein vom DEC LK201 inspiriertes Layout. Auch hier nicht exakt. Cursortasten sind wie LK201 angeordnet (höher als IBM, tiefer als ST), aber es hat nur 2 Edittasten, Help und Del, sowie weiterhin nur 10 Funktionstasten. Tastaturkomponenten varieren je nach was per Zufall gerade von Commodore eingekauft wurde. Selbiges gilt auch für Mikrocontroller. Mit 97 oder 98 Tasten. Daten werden gesendet durch ein 4-adriges Kabel mit DIN5 Stecker. Pins 1 Takt (KCLK), 2 Datenbits (KDAT), 3 unbenutzt, 4 0V (GND) und 5 5V (+5V), wie bei XT und AT. Ob mit XT oder AT Signalisierung ist mir nicht bekannt. Ab Amiga 4000 hat es MiniDIN6 Stecker und PS/2 Belegung, sicher mit AT Signalisierung.

Joystick

Als Folge davon standardisierte Atari einen universellen Anschluss. An diesem können diverse Geräte ihre passenden Funktionen implementieren. Pins 1 Auf, 2 Ab, 3 Links, 4 Rechts (alle Digital), 5 Paddle-R (Analog), 6 Feuertaste (Digital), 7 5V, 8 GND, 9 Paddle-L (Analog).

Alle vier Richtungspins 1..4 sowie Feuertaste 6 sind normale Tasten. Sie haben gedrückt Verbindung nach 0V und offen keine Verbindung, und sind so in beliebigen Rechnern mit jedem beliebigen Digitalchip einlesbar.

Beide Paddles 9 und 5 sind Potentiometer (Pots) nach 5V. Sie brauchen im Rechner pro Pin einen Kondensator, den der Rechner nach 0V entlädt, mit danach via dem Pot laden lassen, und einen Analogsensor der die Zeit messen kann bis der Kondensator durch den Pot Widerstand geladen worden ist. Je nach Drehwinkel vom Pot, und damit dessen Widerstandswert, fliesst mehr oder weniger Strom, und laden geht schneller oder langsamer. Der Rechner misst die Ladezeit und schliesst davon auf den Winkel.

Auf diesen Stecker aufbauend gab es einiges an Geräte:

• 1977 Joysticks CX10 und CX40 haben einen digitalen Stick vom 1+2+3+4 zu 8, sowie eine Feuertaste von 6 zu 8. Diese erkennen 8 Bewegungen, in 4 Richtungen sowie 4 Kombinationen davon, neben in Mitte stehen. Damit sind 9 von 16 Bitmuster möglich. Diese wurden massivst geclonet, weil einfache simple Elektromechanik ohne jegliche Elektronik drin. Ein Gehäuse bauen war das schwierigste daran!
• 1977 Lenkknopf CX20 hat einen Winkelgeber (Spinner) von 1+2 zu 8, sowie eine Taste von 6 zu 8. Der Winkelgeber liefert eine Quadratur Pulsfolge von 00 01 11 10 00 ... in einer Richtung drehend und 00 10 11 01 00 ... in die andere. Sie können beliebig weit drehen, ohne Anschlag, aber nur Richtung und Geschwindigkeit der Drehung messen, keine absolute Position.
• 1977 Paddles CX30 sind 2 Stück (L und R) an einem Stecker. Erster sein Pot von 9 zu 7 und Taste von 3 zu 8, zweiter sein Pot von 5 zu 7 und Taste von 4 zu 8. Diese liefern einen von der Winkelposition der Drehscheibe abhängigen Widerstandswert, den der Rechner analog ausmessen kann. Originale Atari haben 1MOhm oder 680kOhm Pots, aber die meisten VCS/2600 Spiele nutzten nur den Bereich bis etwa 250..300kOhm hinauf. Manche Dritthersteller benutzen daher 470kOhm oder 500kOhm, wegen mehr Drehwinkel und somit präziser steuern. Commodore ihre hatten 470k und das ist beim Amiga offiziell so spezifiziert. Sie können absolute Position messen, aber nicht beliebig weit drehen, wegen Anschlag an jedem Ende der etwa 270° Drehung.
• 1978 Tastenfelder 3x4 Tasten CX21 (unmarkiert) und CX23 (subset) und CX50 (markiert mit 123/456/789/*0#) gehen von 1..4 umgeschaltet als Ausgänge zu 5+6+9 als Eingänge. Digitaleingang 6 wird wie gehabt als Taste verdrahtet, aber Analogeingänge 5+9 brauchen einen kleinen Widerstand nach 5V (der den Kondensator schnell laden kann) aber bei Tastendruck nach 0V gezogen wird (was mangels Spannung den Kondensator nicht mehr laden kann).
• 1983 Trackball CX22 und CX80 haben zwei Winkelgeber, vergleichbar dem einen im Lenkknopf CX20. Den oben sichtbaren Ball rotieren, durch mit Hand darüberstreichen, wirkt auf zwei Achsen (horizontal und vertikal), welche je einen Winkelgeber antreiben. Die Hardware testet in einem Modus bei einem der Bits=1 werden ob der andere 0 oder 1 ist, und bestimmt daraus die Drehrichtung. Weiter werden im anderen Modus die Pulse als solche übertragen. Horizontal Pins 1+2 zu 8, vertikal Pins 3+4 zu 8, mit 1 und 3 die Drehrichtung (1=Rechts/0=Links bzw 1=Ab/0=Auf) sowie 2 und 4 die Bewegungsschritte. Dazu noch zwei Tasten, beide von 6 zu 8. Es gibt Umbauten, um die Tasten zu trennen, mit zweite dann von 9 zu 8. (Ein Trackball ist strikte einfach eine auf dem "Rücken" liegende Rollkugelmaus, oft mit grösserer Kugel. Oder noch strikter ist eine Maus einfach eine auf dem "Bauch" liegende Trackball, zumal der Trackball noch älter (1950er) als die Maus (1960er) ist.)

ST

Daher ist das interne Kabel zur Rechnerplatine ein 18pin breites Bandkabel, damit Signale von den beiden DE9m Buchsen am Rechner zur Tastatur kommen können. Pins 1 GND, 2 unbenutzt (Verdrehsicherung), 3+4+5+7 Joystick1 Recht+Links+Ab+Auf, 6 Joystick1 Feuertaste und Maus TasteR, 8+9+10+12 Joystick0/Maus Rechts/YB+Links/YA+Ab/XA+Auf/XB, 11 Joystick0/Maus Feuertaste/TasteL, 13 5V, 14 RxD, 15 TxD, 16 /Reset, 17 Joystick1 Pin 5 Ausgang, 18 4MHz Ausgang(!). Damit hat es vor allem 5+6=11 von 17 von den Joystick und Maus Anschlüssen her, die Tastatur selber nutzt nur 4 der 17! Joystick0/Maus Feuertaste/TasteL geht an 6301V1 P21, Joystick1 Feuertaste und Maus TasteR an P22, Joystick1 Pin 5 an P20.

Ab STF wurden die beiden Joystick und Maus Anschlüsse direkt auf die Tastaturplatine verlegt, aber sie wurden schlecht zugänglich unterhalb(!) des Rechners angeordnet. Das ergab ein schmaleres Kabel zur Rechnerplatine. Im MegaST wurde die Tastatur separat, mit Joysticks und Maus Anschlüsse gut zugänglich hinten an der Tastatur und nur ein 6-adriges Kabel mit RJ12 Steckern hin zum Rechner, Pin 1+2 +5V, 3 TxD, 4 RxD, 5+6 GND. Die beste Version, neben auch die besten Tastenmechanismen.

Wegen dieser Verdrahtung kann ein Spiel nicht direkt auf die Joysticks zugreifen. Es muss deren Zustand vom 6301V1 berichtet bekommen, nach dieses bestellen. Mit Kommandos $14 und $15 als erlaube bzw stoppe Joystick Bewegung senden, sowie $16 als einmalig abfragen, oder $17 regelmässig Bericht senden. Das wird gefolgt von wie ankommende Tastendrücke auswerten. Entweder eine Pseudotaste ($FE..$FF je nach welcher Joystick bewegte) gefolgt von Joystickzustand (Bit0..3 Richtungen Pins1..4, Bit7 Feuer Pin6). Oder nach Kommando $19 nur Joystick 0 als simulierte Cursortasten liefern.

Wegen dem 6301V1 Firmware ROM nur Joysticks kennen und nichts anderes, ist es unmöglich Lenkknopf oder Trackball anstelle von Joystick zu benutzen, trotz vorhandenen Leitungen. Paddles oder Tastenfelder scheitern zudem an mangelnder Analoghardware hinter den Paddle-R und Paddle-L Pins. Es hat nicht mal einem simplen NE558 wie im PC Game Control Adapter. Selbst nur mehr Feuertasten scheitern an komplett unverdrahteten Pins ohne Logik um diese auch nur digital zu lesen, man ist auf 1977 Atari VCS 4+1bit Joysticks limitiert, nicht mal 4+3bit. Hier wurde zu sehr gespart, oder wohl eher wegen überhastet schlicht nicht genug weit gedacht um die Situation bei aktuellen Spielen zu erkennen. (Aufwand wäre nur den ohnehin für die Maus vorhandenen 4*NAND OC Gatter Chip 7401 durch einen 74LS244 ersetzen, der die 2*2 mehr Feuertasten durchstellen könnte. Oder gar hinter diesem einen NE558, mit dem bestehenden Steuersignal der 4*NAND OC Gatter auch als NE558 sein Trigger nutzen.)

Theoretisch ist die 6301V1 Firmware sogar umgehbar. Sein ganzer Speicherinhalt (ROM+RAM+IO) ist per Kommandos auf der Leitung zum Rechner auslesbar mit $21, er antwortet mit Pseudotaste ($F6) und Daten, sowie auch teilweise (RAM+IO) beschreibbar mit $20 gefolgt von Adresse+Anzahl+Bytes, und sogar geladenes Programm ist aus dem RAM ausführbar mit $22 gefolgt von Adresse! Praktisch fehlt dazu Doku zu RAM Platzbelegung. Und die nur 128Bytes RAM wären ohnehin sehr limitierend. Inzwischen haben Leute das ROM ausgelesen und disassembliert, und dabei festgestellt, dass das RAM komplett ausgebucht ist, kein Programmplatz frei ist. Also ist dieses Feature komplett nutzlos!

(Der ST wäre hier deutlich verbessert, wenn anstelle vom C64 der VC20 Pate gestanden hätte. Dort ging der nur eine DE9m Joystick Anschluss intern an den Userport D0..D3+D4. Dieser Ansatz h¨tte hier leicht variert werden können, mit an den Druckerport D0..D3+D4 gehen. Das wäre weit flexibler gewesen, weil von Spielen direkt zugreifbar, kein Umweg über den 6301V1. Spart zudem eine DE9m Steckbuchse und Kabelbreite zur Tastatur und Firmware, sowie Protokoll Doku und Treiber und API Doku, und es erlaubt erst noch Lenkknopf oder Trackball. Mit zudem D5+D6 an die leeren Paddle Pins würden sogar zwei mehr Feuertasten drin liegen. Aber keine Paddles an einem NE558 wie PC Game Control Adapter, wegen diesem die Druckersignale stören, ausser er wäre hinter einem abschaltbaren Gatter, mit dem unbenutzten Ausgangs Pin IO A7 vom YM2149F als Schalter. Selbst zwei Joysticks hätten am Druckerport gepasst, falls nur die Bewegungen an D0..D3 und D4..D7 wären sowie Feuertasten am einten unbenutzten Eingangs Pin I3 vom 68901MFP sowie am Drucker /ACK (Pin I0 vom 68901MFP). (Wobei der Pin I3 beim MegaST vom Blitter in Beschlag genommen wurde.))

(Besser aber die Paddle Pins umnutzen, für besseren erweiterten Joystick. Dazu wie oben nur 5 Eingänge plus die zwei nutzlosen bzw unbenutzten Ausgangs Pins IO A6+A7 vom YM2149F an die leeren Paddle Pins verbunden. Dies hätte sogar drei mehr Feuertasten erlaubt, falls einer der Ausgänge die Joystick Richtungen Pins umschalten kann per 4*2:1 OC Multiplexer (74157), zu 4 mehr Eingänge, mit festem Indikator Pin1=0 plus Pin2..4 drei mehr Feuertasten B C sowie S (ähnlich Sega MegaDrive/Genesis). Mit beiden Ausgängen auf 2* 2*4:1 Multiplexer (74153) würden sogar noch 2*4=8 mehr Eingänge drin liegen, mit ein Pin4=0 als weiteren Indikator plus Pin1..3 drei weitere Feuertasten X Y und Z sowie 4 weitere variable wie Schultertasten LT RT LB und RB oder zweiten Satz Richtungen. Oder auch eine Umschaltbox, für 2 oder 4 oder gar 8 Joysticks an nur einem Anschluss. Diese mit für Portauswahl weiteren Multiplexern (2: 2*74157, 4: 3*74153, 8: 5*74151) plus 1/2/3bit Zähler, für dessen Kommando schritt(+1)/reset(=0) Modus vom ersten Ausgang, und mit anderem dieses Kommando triggern. Diese wäre bereits mit nur einem Joystickanschluss nutzbar, mit nur 1 direkt, und eher 4 oder 8 geschaltet, oder aber mit zwei davon, mit A6+A7 an beide, mit dann 2 direkt, und eher 2 oder 4 geschaltet. Neben den (Pseudo-)Bitplanes ist Joysticks derart schwer limitiert wohl der zweitgrösste Designfehler im ST.)

Der STE brachte 2 erweiterte Joystick Ports, auf DE15f Buchsen (selbige wie VGA!). Diese haben beide Pin 1..4 Eingang für Richtungen (74LS244 Chip) oder Ausgang (74LS373 Chip), 5+15 Paddles (2* LM556 Analogchip plus Zeitzähler im GSTMCU), 6+10 Eingang für 2* Feuer (halbe 74LS244), 7 +5V, 8 unbenutzt, 9 GND, 11..14 nur Eingang (74LS244). Diese können direkt für komplexere spezielle Joysticks benutzt werden, oder indirekt per Y-Kabel in 2 DE9m Buchsen aufgeteilt werden, ersterer bidirektional mit Paddles, zweiterer nur unidirektional ohne. Sie erscheinen an $FF9200..$FF93FF. Alle Pins Joyport0 4..1 (Stick0) + Joyport1 4..1 (Stick1) + Joyport0 14..11 (Stick2) + Joyport114..11 (Stick3) erscheinen als Bit0..15 an Adresse $FF9202, die Tasten Joyport0 6+10 und Joyport1 6+10 an Adresse $FF9200 Bit0..3von15. Die beiden Joyport0+1 Pins 4..1 sind beschreibbar an $FF9202, erscheinen dann bis erneut geschrieben wird oder ein Lesevorgang sie wieder auf Eingang schaltet. Die Paddles verwenden 2 LM556 und werden vorzu automatisch gescannt mit 500kHz Zähler und an $FF9210/2/4/6 ausgelesen. Wie so viel anderes beim STE war es gut nachgezogen auf was anfangs schon hätte sein sollen, und hier sogar darüber hinaus, aber zu spät.

Amiga

Die digitalen Bewegungen sind nicht nur vom Prozessor sichtbare Tasten bzw Winkelgeberpulse, sondern in Hardware implementierte bidirektionale Pulszähler. Daher erscheinen sie in zwei summarischen Registern JOY0DAT und JOY1DAT, mit je Port Bit0..7 horizontale und Bit8..15 vertikale Bewegung, als 8bit mit Vorzeichen. Wenn mit Joysticks verwendet sind Bit1 und Bit9 die Pins R und L, aber als Seiteneffekt der Mauszähler sind Auf und Ab nicht direkt sichtbar, Ab ist Bit0 XOR Bit1, Auf ist Bit8 XOR Bit9.

Die Feuertasten (und Maustaste-L) gehen an die 8250CIA-A, Register CIAAPRA. Joystick 0 an PB6, Joystick 1 an PB7, mit 0=gedräckt.

Die Paddles (und Maustaste-R) gehen wiederum an PAULA. Auch hier hat es ganze Kondensator Ladezeit messen, nicht nur vom Prozessor sichtbare nicht/geladen Ausgabe, sondern in Hardware implementierte Zeitzähler. Die Messung wird gestartet mit auf Register POTGO schreiben, am Anfang einer Bildausgabe. Danach erscheinen sie bis Ende vom Bild in zwei summarischen Registern POT0DAT und POT1DAT, mit je Bit0..7 POTnX Analogwert und Bit8..15 POTnY Analogwert. Damit sind Pin 9 Paddle-L in POTnY, Pin 5 Paddle-R in POTnX.

Diese Paddles Pins können aber auch für 2 weitere Feuertasten Eingabe missbraucht werden, in Register POTINP. Aber für Eingabe brauchen sie einen Widerstand nach 5V um den Kondensator schnell zu laden, der bei Tastendruck nach 0V gezogen wird. Dazu können sie auf Ausgabe(!) geschaltet werden mit dann 1 ausgeben um auf 5V zu ziehen. Das wird von den 3x4 Tastenfeldern benutzt, aber auch von den zweiten oder gar dritten Tasten an Joystick/Maus/Trackball, wobei Pin 9 zweite ist und Pin 5 dritte.

(Diese Belegung wird auch vom Sega Master System verwendet, zweite an Pin 9, wenn auch mit +5V unsinnigerweise auf Pin 5 statt Pin 7 gelegt. Daher kann man deren Joypads statt Joysticks auch an VCS/2600 und 800 und C64 und ST und Amiga verwenden. Aber Achtung, die davon erweiterte MegaDrive/Genesis verwendet dann Pin 7 als Auswahl der erweiterten Joypad Tasten, ist daher mit Amiga (und allen anderen) komplett inkompatibel, bis hin zu Hardwareschaden!)

Die Paddles Pins können auch beliebig ausgegeben werden, falls mit POTGP Bits 8..15 beschrieben (ungerade Bits schalten je einen Pin auf Ausgangsmodus, dazu passende gerade Bits mit Nummer -1 sind die Ausgabedaten). (Dieser Ausgangsmodus würde auch obige Multiplexer sowie externe Umschaltbox erlauben.)

Maus

ST

Dessen Signale gehen wie die der Joysticks direkt zum 6301V1 Tastatur Mikrocontroller. Es sind ja auch genau die selbigen Anschlüsse! Man kann sogar die Maus entfernen für dessen Anschluss als zweiten Joystick Port benutzen, weil selbige Steckbuchse. Dabei eigenartig ist, dass der Mausanschluss Joystick 0 nummeriert ist, und der normalerweise genutzte freie Joystickanschluss als 1! Dabei benutzt die Maustaste-R das unbenutzte Paddle-L Pin, mit dahinter aber selbiges Tastatursignal wie Joystick 1 seine Feuertaste! Vermutlich wegen Pinmangel am Mikrocontroller.

Die XA XB YA und YB von der Maus (und auch Joystick 0) gehen durch einen Satz von 4*NAND OC Gatter, damit sie bei Pulsfolgezustand ungleich 11 nicht die Tasten einlesen stören. Typ nicht spezifiziert, aber vermutlich 7401. Beim Joystick 1 hat es keine solchen. (Andere Quellen haben einen 74LS244 statt 4*NAND, was neben Joystick0/Maus auch Joystick1 abtrennen könnte. Photos von der MegaST Tastaturplatine haben einen solchen drauf. Aber mangels Verdrahtung kann er die leeren 2*2 Pins nicht als Feuertasten durchstellen.) Diese Gatter werden mit einem Steuersignal aufgemacht, von 6301V1 P20 gesteuert. Erstaunlich wird dieses auch beim Joystick 1 an Pin 5 (Paddle-R) ausgegeben, als 0=deaktiviert/1=durchlassen. Es gilt hier wenn XA/YA Wechsel von 0 zu 1, falls XB/YB=0 ist unterwegs in "positive Bewegungsrichtung", falls X2/Y2=1 nach "negativer Bewegungsrichtung". Der Mauszustand kann in diversen Formen an den Rechner geschickt werden, stets eine Pseudotaste ($F7 oder $F8..$FB) gefolgt von passenden Mausdaten.

(Mit Joysticks an Druckerport und nur Maus an der Tastatur wäre all dies ohnehin irrelevant. Noch besser auch mit Maus nicht an der Tastatur. Dazu entweder wie bei dieser eine weitere dritte 6850UART. Allenfalls wie bei teils PC Mäusen als RS232 verdrahtet. Aber besser mit alle Joystick und Maus (und auch Echtzeituhr) Funktionen nicht mehr in der Tastatur braucht diese gar keine Kommandos senden, ist keine bidirektionale Verbindung mehr notwendig! Dann anstelle der 6850UARTs einfach in GLUE zweimal die simple PC Tastaturanschluss Schaltung, und statt 6301V1 die billigere 6805 verwenden. Wenn auch in Tastatur und Maus zwei davon, wobei wiederum die Maus dann nur noch 4 statt 8 Adern Kabel und Pins Stecker braucht. Dann gleich als Spezifikation eine standard PC Clone Tastatur vorsehen.)

(Im Extrem sogar viermal die PC Schaltung, mit drei und vier an die beiden Joystick Stecker, mit hier Pin2=0 direkt vom Ausgangs Pin IO A7 vom YM2149F via Paddle Pin als Indikator, sowie PC Signale an Pin3+4. Womit durch weitere 6805 beliebiges anschliessen möglich wird, als noch besseren intelligenten Joystick. Mit DIN5 zu DE9f Stecker Adapter sogar weitere Tastatur oder Maus anhängen. Aber auch direkt beliebig aufwendigere digitale Joysticks als Pseudo-Tastatur Subsets zu machen, oder Trackballs als Pseudo-Maus Varianten, oder analoge Joysticks als sich selber. Mit Umwandler auch bestehende Lenkknopf oder Trackball als Maus, sowie bestehende Paddles als analog. Das erlaubt erst noch Trackball Winkelgeber und Analog Potentiometer auswerten ohne den Prozessor zu verschwenden. Wie es jede Maus ab PS/2 und jeder Joypad seit Playstation 1 Analog macht, und alles moderne an USB sowieso. All dies trotz keine Spezialhardware wie Quadraturzähler oder Ladezeitmesser im Rechner, weil eine 6805 das nebenbei erledigen kann, mit ersteres direkt und zweiteres nur PC Game Control Adapter NE558 Schaltung. Logisch müsste eine Umschaltbox jetzt auf einer 6805 basieren mit einem Spezialchip für mehrere mal die PC Schaltung.)

Amiga

Man kann wieder die Maus entfernen für dessen Anschluss als zweiten Joystick Port benutzen. Auch hier genauso eigenartig, dass der Mausanschluss Joystick 1 nummeriert ist, und der normalerweise genutzte freie Joystickanschluss als 2. Zu bemerken ist, dass Maustaste-R auf den Paddle-L Pin 9 geht, daher mit obigem POTINP zu lesen ist, im Gegensatz zu Maustaste-L das Feuertaste ist, daher am 8250CIA-A erscheint, mit 0=gedräckt. (Ab Amiga 3000UX gab es auch diverse Dritthersteller mit Pin 5 Maustaste-M (Paddle-R), auch in POTINP erscheinend.)

Die V H VQ und HQ von der Maus (und auch Joystick 0, und ebenso Joystick 1) gehen an PAULA Multi-IO Customchip als Joystick/Trackball Pins. Es gilt hier wenn V/H Wechsel von 0 zu 1, falls VQ/HQ=0 ist "increment" bei unterwegs nach rechts oder abwärts (zu Benutzer), falls X2/Y2=1 ist "decrement" bei nach links oder aufwärts (weg von Benutzer).

(Auch hier wäre Maus an eigenen Anschluss besser. Erst recht zumal es zwei 8250CIA hat, und die 8250CIA-B ihr Shiftregister unbenutzt ist, mit dessen Pins am Druckerport als Duplikate verdrahtet, welche nicht wirklich benötigt werden. Wieder eigene 6500-1 in der Maus notwendig, aber auch nur 4 statt 8 Adern Kabel und Pins Stecker.)

Seriell

ST

Der 68901MFP hat dedizierte Pins SO für TxD und SI für RxD, aber auch 8 generische PIO Pins. Diese sind im ST alle Eingang, um die alle Ausgang im YM2149F zu komplementieren. Diese lesen diverse Sachen: I0 ist Drucker Busy/Acknowledge, I1..I2 sind RS232 DCD+CTS, I3 ist unbenutzt, I4 ist Tastatur+MIDI IRQ, I5 ist Floppy+Harddisk IRQ, I6 ist RS232 RI, I7 ist Monitor MONO 4. Die RS232 bezogenen Signale gehen an die standard RS232 DB25m Buchse. Pin 1 Shirm, 2 TxD, 3 RxD, 4 RTS, 5 CTS, kein 6 DSR, 7 GND, 8 DCD, 20 DTR, 22 RI.

RS232 verlangt nach Signalen mit +/-12V, nicht TTL 5V/0V. (Strikte ist bis 5V hinunter senden und bis 3V empfangen legal, und bis 15V hinauf senden.) Dazu wurden im ST die häufigen Spannungswandler 1488 (von 5V zu +/-12V) und 1489 (von +/-12V zu 5V) benutzt, welche je 4 Signale wandeln (wie im PC/XT/AT). Wegen 3 Ausgangsleitungen (TxD+RTS+DTR) reicht ein 1488, aber wegen 5 Eingangsleitungen (RxD+CTS+DSR+DCD+RI) bräuchte es zwei 1489. Es hat aber keine zweite 1489, daher ist kein DSR Signal vorhanden. Vermutlich war das unbenutzte I3 am 68901MFP dafür gedacht. (Hier wäre das selten genutzte RI weglassen sinnvoller gewesen, wie es die meisten Hersteller machten, Amiga inklusive.)

Schlimmer hat es einen heftigen Designfehler in der Software, im Umgang mit CTS, welches nach jedem Byte verschicken einmal vom Empfänger seinem RTS gepulst werden muss, weil sonst friert die Datensendung nach dem ersten Byte ein! Dieser wurde ab TOS 1.04 geflickt, leider mit einem neuen Bug addiert, wonach RTS/CTS Betrieb gar nicht mehr einschaltbar ist! Ab 1.06 ist auch der endlich geflickt, aber das ist erst im TT030 und MegaSTE. Alle ST/STM/STF/STFM/MegaST sind RS232 unbenutzbar.

Der 68901MFP erscheint an Adressen $FFFA00..$FFFBFF, mit GLUE Signal /MFPCS. Dessen Registeradressen A1..A5 (nicht als A0..A4 benamst!) kommen von Prozessoradressen A1..A5, also in 1 Wort Schritten. Die Datenleitungen sind an Prozessordaten D8..D15, also erscheint sie an Bytes mit geraden Adressen. (Ab MegaST nur noch wenn A6=0, weil sonst eine 68881 FPU am internern Slot dran ist.) (Im TT030 auch noch nur wenn A7=0, weil sonst mit A7=1 eine zweite 68901MFP dran ist.)

In TT030 und MegaSTE hat es weiter einen 8530SCC drin (selbiger wie im Mac). Dieser kann im TT020 125kBit/s, im MegaSTE sogar 250kBit/s. Dessen SCC DMA erscheint an $FF8C00..$FF8C7F (nur TT030 aber nicht MegaSTE), und SCC selber an $FF8C80..$FF8CFF, beide an ungeraden Adressen.

Amiga

Timing im PAULA für Bitrate ist in 279.4ns/3.5795MHz Zeitslots geteilt durch n, nach n-1 in SERPER Bit0..14 eintragen (Bit15 ist 9/8bit empfangen Modusschalter). Deswegen kann man neben normalen RS232 Bitraten auch MIDI Bitrate erzeugen. Für senden SERDAT beschreiben mit gewollte 8oder9 Datenbits (von Bit0 aus nach links), dann Parity falls und wie gewollt, dann 1oder2 Stopbits=1, und noch Rest Leerbits=0. Dies wird gefolgt von shift nach rechts hinaus bis nur noch Nullen in SERDAT verbleiben und die letzte 1 auf der Leitung ist. Wieder im Amiga einen nicht-traditionellen Ansatz, komplett flexibel mit Bitzahl und Parity und Stopbits durch Datenmuster von Software vorgeben, statt festverdrahtete Chipeinstellungen schalten. Für empfangen kann man lesen von SERDATR für Empfangsstatus (in Bit15..11) und ankommende Stopbit+Daten 1+8oder9 (in Bit 9..0). Es hat auch hier keinerlei Parity, das muss stets bei Bedarf in Software erzeugt und auch getestet werden.

Erstaunlich mit reversem DB25f statt DB25m, aber das trotz die Pinanordnung als DTE (Rechner/Terminal/Drucker) und nicht DCE (Modem) welches DB25f hat. Dies ist eine fragwürdige Designentscheidung. (Es wurde ab den 500/2000 korrigiert.)

Dazu werden noch diverse von RS232 nicht benutzte Pins am Amiga 1000 anderstweitig verwertet, um externe Hardware Extra Fähigkeiten zu geben, ohne mehr Steckbuchsen am Rechner unterzubringen. Pin 14 -5V, 15 Audio Aus L, 16 Audio Ein mischbar zu R, 17 EB Taktsignal, 18 /IRQ 2, 21 +5V, 23 +12V, 24 3.5795MHz Takt, 25 /BRESB Resetsignal. Eine eigenartige Sammlung! Und sie ist auch noch bei späteren Modellen stets anderst, 500/2000/3000 stellen 9 +12V und 10 -12V (keine 1/- 5v mehr), 11 Audio Aus und 18 Audio Ein (trotz 15 und 16 nicht anderst nutzen).

Parallel

ST

(Von den 8+4+5+8 PC Pins sind somit nur 8+1+1+8 belegt, der Rest wird verschwendet, trotz vorhandener Signale! Das YM2149F IO A6 an Monitor GPO ist praktisch nutzlos, weil nur ein einzelnes Signal und kein 5V dort. Das IO A7 unbenutzt ist ohnehin komplett nutzlos. Es wäre sinnvoller sie am Druckerstecker als zwei weitere Ausgänge zu nehmen, mit drittem noch feste 5V. Feste 5V stören wohl am wenigsten am /AUTO FD Pin 14, damit also A6 an INIT 16 und /SLCT IN 17. Ebenso ist ein 68901MFP Pin I3 unbenutzt, sinnvoller am Druckerstecker als weiteren Eingang, am ehesten PE 12 oder /ERROR 15. Oder gleich alle 4 fehlenen Eingänge an einen simplen 74365 Chip. Damit würde ein einfacher Userport entstehen, der ideal gewesen wäre für simple Laboranwendungen, wie EPROM oder PAL oder Mikrocontroller Programmiergeräte. Oder auch nur für besseren Joystick Support, zumal dann die beiden Feuertasten an die restlichen 2 Gatter der 74365, statt an 68901MFP I3 und I0.)

Amiga

Eigentlich ist dies ein teilweise belegter PC Printer Adapter. Aber mit 5V und /RESET auf PC GND Pins entsteht ein Kurzschluss, sobald ein Kabel oder eine Druckerumschaltbox mit Pins 18..25 zusammengelegt angeschlossen wird! Die 5V auf PC Ausgang legen wäre sinnvoller gewesen, wieder idealerweise an /AUTO FD Pin 14. Auch Eingang 15 auf GND ziehen kann den Ausgang beim Drucker kurzschliessen. Diese leer lassen wäre sinnvoller. Und alle 14+16+17 fest auf 0 kann problematisch werden. Diese leer lassen wäre sinnvoller. (Auch dies wurde in 500/2000 korrigiert, mit 5V per Pullup Widerstand an Pin 14 (/AUTO FD) und /RESET an Pin 16 (/INIT). Aber wegen Pullup sind die 5V nicht mehr als Stromversorgung brauchbar.)

Dazu kommt wie bei obigem RS232 wieder mit verkehrtem Stecker, DB25m statt DB25f. Dies wegen RS232 verkehrt? Oder RS232 verkehrt weil hier bereits? Auf jeden Fall beides sinnlos verkehrt. Auch hier ist dies eine sehr fragwürdige Designentscheidung. (Es wurde ebenfalls ab den 500/2000 korrigiert.)

Echtzeituhr

ST

(Es gab aber dazu eine Akku Modifikation für die Tastatur, um den 6301V1 bei ausgeschaltetem Rechner durchlaufen zu lassen. Wegen diesem aber ein NMOS Chip sein hielt der Akku maximal 24h, was für über Nacht ausschalten ausreichte, falls danach mindestens 2h Betrieb als Ladezeit waren. Aber übers Wochenende reichte es nicht mehr, am Montag war also neusetzen angebracht, Akku reduzierte dies machen müssen lediglich auf 1 von 5 Arbeitstagen.)

Erst im MegaST kam ein Ricoh RP5C15 Uhrenchip. Dieser erscheint an Adressen $FFFC00..$FFFDFF, mit GLUE Signal /6850CS, und decodiert selber noch A5=1, im Gegensatz zu MIDI+Tastatur 6850UARTs bei A5=0. Dessen Registeradressen A0..A3 kommen von Prozessoradressen A1..A4, also in 1 Wort Schritten. Die Datenleitungen sind an Prozessordaten D8..D15, also erscheint sie an Bytes mit geraden Adressen. (Der RP5C15 ist auch in STE und MegaSTE drin.)

Im TT030 kam ein anderer Motorola MC146818A Uhrenchip (selbiger wie im AT). Dieser erscheint an Adressen $FF8961..$FF89603. Dessen Registeradresse A kommt von Prozessoradresse A1, also in 1 Wort Schritten. Die Datenleitungen sind an Prozessordaten D16..D23, also erscheint sie an Bytes mit ungeraden Adressen. (Die Situation in Falcon030 ist mir komplett unbekannt.)

Amiga

Erst in 500 und 2000 kam ein OKI MSM6242RS Uhrenchip dazu. Dieser war im 2000 stets vorhanden, und konnte im 500 als Teil von der A501 512k Speichererweiterung addiert werden. Sie erscheint an Adressen $DC0000..$DCFFFF.

Software

ST

Floppys bekamen so, neben PC kompatiblem MFM Format, auch vom GEMDOS her ein FAT12 Filesystem kompatibel zu MSDOS. (Mit viel Speicher und standard Floppy plus fakultativ ACSI Harddisk war der ST somit sehr gut für Büroanwendungen.) Ein Vorteil kam vom Wechsel von Concurrent CP/M 68 auf GEMDOS, im Nachhinein sogar ein grosser Glücksfall, weil es dank MSDOS 2.11 kompatiblem FAT12 auch dessen Subdirectories kann. Dazu kommt noch Cluster statt Sektoren auf Harddisks benutzen. Was zusammen mit Subdirectories dem ST ersparte, ansonsten ein limitiertes CP/M Filesystem mit maximal 8MByte Partitionen ohne Subdirectories zu bekommen. (Wobei Atari ihre Software sich weigert mehr als 16MByte Partitionen anzulegen, sie teilt die Megafile Laufwerke in 2*10M bzw 2*15M bzw 4*15M auf. Dies vermutlich wegen Clustergrösse auf 8*512=4096Bytes limitieren statt 16*512=8192Bytes erlauben.)

Allerdings war der Bootsektor wegen 68000 Program Codezahlen darin nicht PC kompatibel. PCs verstanden diesen nicht, selbst wenn nur Daten auf der Floppy waren, trotz nicht von ihnen booten. Solange aber eine Floppy auf PC formatiert wurde, verstand GEMDOS auf dem ST diese, konnte aber wegen 8088 Code nicht von ihr booten. Kein Problem bei reinen Datendisks. Ab TOS 1.04 oder 1.06 erstellt GEMDOS auch vom PC verstehbare Bootsektoren. (Der ST verwendet sogar noch einen modifizierten PC 437 Zeichensatz und Fonts. Womit selbst PC Extended-ASCII .TXT Files grossteils kompatibel sind! Zumindest solange keine Graphikelementzeichen darin sind, weil die meisten dieser durch mehr Schriftzeichen ersetzt wurden, um neben Umlaute auch noch Griechisch und Hebräisch abzudecken!)

Das TOS befindet sich alles in 192k ROM, nicht nur der GEMDOS Kernel sonden auch die GEM Libraries (GDI Treiber und AES GUI) mitsammt ein paar wenige Standardfonts sowie dem Desktop mitsammt ein paat Utilities. Daher ist das System beim Einschalten sofort da und praktisch unzerstöbar (wie bei 8bit Basic Rechnern). Es hatte ebenfalls keinerlei nachladen, auf Floppy sind rein Apps und Daten, Betrieb mit einem Einzellaufwerk ist voll OK. (Ausser in ersten Halbjahr, wo System von Floppy geladen wurde, in ROM nur der Bootloader dazu war. Aber selbst dann war es einmal ein 192k ROM Image reinziehen, nicht anderst als PC MSDOS booten, und selbst bei Reboot blieb dies erhalten so lange nicht durch überschrieben zerstört.)

GEM wurde realistisch für PCs mit Hercules Graphics Card (HGC) geschrieben. Diese hatten 720x350 1bpp aus 32k RAM. Das sind kleiner als die bereits grenzwertige Lisa mit 720x364. Der ST ist hier mit seinen 640x400 bereits weit besser, dank den 400 Zeilen und erst noch mit fast quandratischen Pixeln, aber immer noch grenzwertig. Strikte sind dies +50% Videospeicher auf +50% Bildschirm gegenüber dem unausreichenden Mac mit 512x342. Schwach ist beim ST aber das fehlen von einem 6x12 Font (was der Mac hat) und damit auch die +50% Pixel in +50% Text umsetzen, und damit erst Platz bekommen für mehrere 80x25 Fenster darstellen! Ohne dies ist er genauso unausreichend wie der Mac.

Strikte lief GEM auch auf PCs mit CGA 640x200 1bpp. Was genau dem ST Farbmonitor 640x200 2bpp entspricht, mit nur Farbdetails addiert, Desktop Hintergrund grün. Auch hier wäre ein fast unlesbarer 6x6 Font notwendig. Es braucht aber so 8x8, damit sind die Fenster sinnlos. Der 6x6 ist strikte sogar vorhanden, und für Icon Unterschriften verwendet. Nur genau der 6x12 fehlt für den weit passenderen Monomonitor 640x400. Vermutlich wegen Platzmangel im ROM.

Damit gilt auch hier alles was zu Mac und GEM/Windows Desktop und mangelnde Auflösung gesagt wurde. Erst die 32bit Generation lieferte auch hier genug Video für brauchbare Desktop GUIs. Prozessor (über 10MHz) und Speicher (ab 1MByte) und Bandbreite (ab 10MByte/s) und Video (ab 800x600) und Monitor (ab 17"). Also Atari TT030 wenn mit dem TTM194 19" Schwarzweissmonitor. Gerade mit der ganzen minimalistischen ST Zielsetzung wäre davor eigentlich ein normaler COMMAND.COM plus einen Dateimanager wie Norton Commander oder PC Shell oder Xtree oder Dired weit besser gewesen.

Der ST konnte sogar noch reine GEMDOS Programme, mit Dateiendung .TOS(!) oder .TTP (statt GEM Programme, mit .PRG). Bei .TTP (Tos Takes Parameters) fragt GEM per Dialogbox nach Parametern. Bei diesen laufen lassen tritt GEM zur Seite und der ganze Bildschirm kann mit VT52 Emulation angesprochen werden (analog zu MSDOS mit ANSI.SYS geladen, allerdings dieses dann teilweise VT100 Emulation). Darauf aufbauend gab es zumindest ladbare Kommandozeilen Interpreter von Drittanbietern. (Macintosh vor MPW auf Mac Plus hatte nicht mal diese Option, und auch MPW war dann stets in einem GUI Fenster drin.)

Ansonsten ist das TOS System sehr einfach strukturiert, und damit auch einfach aus dem Weg zu räumen. Was man auch oft machen will, zumal GEM alles andere als gut ist, ein sehr billiger minimaler Mac Abklatsch. Das war schon auf PC so, und auf ST nicht besser. Allerdings hatte Atari vom GEM auf 68000 portieren her eine Sourcecode Lizenz, konnte es zumindest unabhängig von DR etwas weiterentwickeln. Dies im Gegensatz zu DR, welche dieses aus Angst vor Apples Anwälten kastrierten, statt wie Microsoft auf Konflikt gehen und grossteils gegen Apple gewinnen.

(Der ST wäre mit 2*2 64kx8bit ROM Chips (=256k) statt 3*3 32kx8bit (=192k) besser dran gewesen. Ideal mit nur GEMDOS im erstem Paar und nur GEM im zweiten. Noch besser mit nur 1*2 64kx8bit ROM Chips (=128k) und GEM entweder von Floppy oder aus einem ROM Modul, mit beide davon zwecks häufigeren Umgrades vom Userinferface austauschbar (im Gegensatz zu GEMDOS, welches als Mechanismus stabil bleibt). Noch besser mit ROM Modul wegen fakultativ sein als grössere 256k, neben eingebautem GEMDOS stets nur 128k.)

Amiga

Der Amiga lädt den Kernel plus Standardlibraries in 256k schreibgesperrtem Writable Control Store (WCS) RAM, von der Kickstart Floppy. Danach kommt die Workbench GUI ins normale RAM. Wegen WCS teuer sein hatte es anfangs nur 256k normales RAM. Wegen Mangel an RAM mussten dauernd Workbench Teile von Floppy nachgeladen werden (wie beim Mac), was langsam war und das Laufwerk teilweise blockierte für Files, nach viel Diskjockey verlangte, oder nach externem zweitem Laufwerk um dies zu vermeiden. Mehr RAM wäre billiger als das Laufwerk gewesen (alles wie beim Mac). Nur dass beim Amiga die A1050 Erweiterung anstecken ausreichte um von 256k zu 512k zu kommen (statt Mac Board ersetzen oder umlöten um von 128k zu 512k zu kommen).

Der Amiga hat Multithreading auf Basis von Exec Kernel. Strikte hat er sogar eine Form von Multitasking, aber kein vollertiges, weil keine PMMU und damit auch keine Prozesstrennung. Ebenso hat er kein Resourcetracking ohne dem geplanten aber genau daran gescheiterten Commodore Amiga Operating System (CAOS). Was mit der komplexeren Speicherallokation auf die Tasks abschieben anfangs zu vielen Abstürzen führte, mit dabei alle Tasks verlieren. Was Commodore Jahre an Bugsuche abverlangte, bis AmigaOS 1.3 endlich komplett stabil war. Womit dies dem Amiga einen Ruf von unstabil einbrachte, der auch noch lange anhielt, nach alle Software endlich ausgereift war. Dazu war noch im originalen 256k Speicher ohnehin unpassend wenig Platz für mehrere Programme plus ihre Daten. Das ganze System war für eine eigentlich bessere Spielkonsole mit Homecomputer Fähigkeit total überdimensioniert, aber der eingestellte Systemsoftware Designer hatte Interesse an einem solchen. Multitasking war hier genauso ein Fehldesign wie Desktop auf Mac und PC/XT/AT und ST und auch Amiga. (Im Vergleich dazu konnte der ST TSR Programme und Hotkeys benutzen, wie MSDOS. Dies reichte aus und war einfacher und stabiler bei beiden.)

Der Amiga hat ein extrem langsames Filesystem. Dessen verteilte Struktur ist für Floppys ungeeignet, erst recht den spurweise statt sektorweise gelesenen und geschriebenen vom Amiga. Dies ist wegen Versagen der mit eigenem Betriebssystem beauftragten Gruppe, weil dieses eine weitaus zu komplexe Spezifikation hatte, daran scheiterte, scheints ein weiterer Fall von Second System Syndrome. Also musste ein fremdes System schnell adaptiert werden. Dieses AmigaDOS kam vom TRIPOS System (TRIvial Portable Operating System) von Cambridge, welches auf sektorweise MFM Harddisks ausgelegt war. Spurweise lesen und modifizieren wurde zusammen mit dessen sehr ineffizientem Ersatzfilesystem extrem langsam. Es spaltete sogar jeden 512Byte Diskblock in 24Byte Metadaten und 488Byte Nutzdaten. Erstere abklappern oder gar updaten maximierte die Menge an ganze Spuren lesen. Aber auch die Anordnung von Filenamen ist berüchtigt ineffizient, kann ganze Spuren lesen nicht ausnutzen. Dieses Original/Old File System (OFS) wurde mit AmigaOS 1.3 durch Fast File System (FFS) ersetzt, das immer noch langsam war, nur "schnell" relativ zu OFS. (Interessanterweise hat BSD Unix ebenfalls ein FFS, das auch nur schnell ist relativ zu AT&T seinem langsamen originalen Unix File System (UFS).)

Der Amiga kann ebenfalls PC kompatibles Floppy Format. Wobei er aber einen ISO 8859-1 (Latin-1) Zeichensatz und Fonts verwendet (des selbige wie Windows für DOS sowie BSD und Linux sowie frühes MacOSX). Was mit PC 437 nur Basis-ASCII kompatibel ist, ausser die Software kann Zeichensatz konvertieren. Ebenso kann er Mac kompatibles Floppy Format. Auch hier ist er mit Mac Roman nur Basis-ASCII kompatibel, ausser die Software kann konvertieren.

Die GUI Workbench wurde ausschliesslich für Amiga geschrieben. Dieser hatte damals nur 13" Monitor, mit 640x200 2bpp (oder gar nur 320x200 4bpp) aus 32k RAM. Ein Fenstersystem darauf ist so unbenutzbar wie auf CGA oder ST Farbmonitor, und dazu noch bei mehr bpp ausnutzen gebremst. Auch hier wäre ein fast unlesbarer 6x6 Font notwendig. Es braucht aber so 8x8, damit sind die Fenster hier genauso sinnlos. Damit gilt auch hier alles was zu Mac und GEM/Windows und ST Desktop und mangelnde Auflösung gesagt wurde. Erst die 32bit Generation lieferte auch hier genug für brauchbare GUIs. Also Amiga AGA falls man auf Auflösung statt Farben losging.

Die GUI wurde zudem für NTSC Fernseher statt RGB Monitor ausgelegt, wegen die Amiga 14.31818MHz mit Pixel Viererfolgen genau dessen 3.5795MHz treffend. Das führte in AmigaOS 1.0 zu einer Farbwahl von Schwarz/Weiss/Blau/Orange, totales Augenpfeffer. Dies ist erst noch komplett sinnlos, weil die 14.31818MHz Pixel von 640 realistisch nur auf einem RGB Monitor benutzt werden können, mit kein NTSC in Sicht, aber bei NTSC Fernseher deren 7.1591MHz Pixel von 320 mit Pixelviererfolgen die 3.5795MHz nicht mehr treffen (und PAL Fernseher ohnehin nicht)! Später in 2.0 (erst auf 500 und 2000 laufend, und diese hatten anfangs 1.3) wurde umgestellt auf Schwarz-Weiss-Grau-Blau Schattierungen, was weit besser aussieht. (Auch dies war komplett vorhersehbar, weil bereits in Atari 800 und C64 vorweggenommen, mit deren Hellblau auf Dunkelblau Textdarstellung!)

Wegen dem komplexen einstellbaren Videospeicher kennt das System ein Konzept von "Screens". Diese sind je ein Videospeicher, mit eigener Hardwarekonfiguration (Planezahl und -anordnung, Zeilenlänge und -anzahl). Es gibt davon drei Sorten: Vom jeweiligen Program angelegtes eigenes, mit beliebiger Konfiguration, nur von diesem Program genutzt, welches dann als Vollbild angezeigt werden muss. Vom einem anderen Program angelegtes aber öffentlich nutzbares, mit von diesem vorgegebener Konfiguration, per Name von anderen Programmen auffindbar. Sowie ein fest vorgegebenes vom Workbench Desktop angelegtes solches öffentliches.

Gerade mit dem Copper kann der Amiga neben Bild rollen auch horizontale Bänder von Screens separat behandeln. Neben in Spielen f%uuml;r Menuzeilen/-bereiche oben sowie Statuszeilen/-bereiche unten, kann dies auch die Workbench ausnutzen. Damit kann diese das Bild von einem Programm seinem Screen bis zu einer Zeile anzeigen lassen, und dann das Bild eines anderen Programmes seines Screens ab der nächsten, so in Zeilenbläcken mehrere Programme anzeigen, neben auf Prozessor dem Multitasking dahinter haben. Das ergibt quasi vollbildbreite "Fenster" ganz in Hardware, ohne Rahmen aber mit Titelzeilen!

Die Screens können an einer passenden volles Bild breiten Titelziele ergriffen und nach unten geschoben werden, um andere dahinter liegende freizulegen, oder gar um diese dann als Vollbild sichtbar zu machen. Diese nach unten ziehen zeigt wieder das vorhergehende. All das bereits seit AmigaOS 1.0 vorhanden. Nur dieses Vollbild System wäre besser gewesen als zu kleine Fenster in Software. Wobei die Fenster innerhalb vom Workbench für Directories noch habwegs Sinn machen, da diese oft keine 80 Zeichen an Breite brauchen. In der Hinsicht funktioniert die GUI, solange volle Applikationen sie mit eigenem Vollbild umgehen. Sie ist aber trotzdem überdimensioniert, weil Directories kann man auch mit Pannels anzeigen.

Der Workbench kann zudem entweder CLI Kommandozeilen Fenster oder GUI Filemanager Fenser haben, ebenso beides gemischt. Strikte wird ohnehin eine CLI mit einem Bootscript gestartet, und dieses wirft dann Desktop Elemente an. Dieses Bootscript ist anpassbar, um den Desktop gar nicht zu laden. Es kann auch mehrere CLIs starten. Das unterliegende System kann alleine mit Device Open Kommandos ganze CLI Fenster als virtuelle Terminals erzeugen, mit Fensterparameter als Teil vom Terminal Devicenamen mitgeben! Eine erweiterte Shell wurde in 1.3 addiert.

Spiele können ohnehin auch direkt anstelle von Workbench gebootet werden, ohne überhaupt den Desktop auf der Bootfloppy zu haben, mit nichts im Weg. Dies ist sehr sinnvoll, zumal die Graphik von Workbench aus kollidiert mit spielefreundlicher Speicherallokation der Bitplanes mit Planeinterleave. Dann sind auch keine Screens vorhanden, weil direkt gebootete Spiele ohnehin die volle Bildkonfiguration übernehmen, und keine weitere Programme starten werden, also keinen Platz mit Titelziele verbrauchen wollen.

Schlussbetrachtung

Der ST lieferte eine einfache geradeaus Big-CPU Architektur, mit voller Taktfrequenz und exzellenter Mono Graphik und ordentlicher Farbgraphik, ein vierfacher PET oder Apple II, auch ein besserer Herkules und doppelte CGA. All das mit mehr als Leistung als AT, trotz zu absolut hammerbilligen $600 selbst unter PC/XT Clones! Er war damit ideal für jegliche textuelle Büroanwendungen und Technisches. Eigentlich der Rechner den man anstelle vom IBM PC/XT/AT hätte haben wollen. Er wurde lediglich vom Amiga total überschattet, als diese nur 1 Monat danach herauskam.

Der Amiga lieferte viele komplexe Koprozessoren, mit exzellenter Farbgraphik und Spieleffekte, und bessere Joysticks, ein vierfacher Atari 800. Das ist einiges mehr Leistung, wenn auch für deutlich mehr Geld, aber immer noch eingies unter AT und Mac. Er war damit ideal für Kunst/Illustrationen und Visualisierung und Spiele. Er wurde von den Kosten und Lieferproblemen zurückgehalten.

PC konnte man eigentlich nur noch rechtfertigen, falls man Software hatte, welche nur auf PC läuft. Dann hatte man die schlechte Wahl von AT schweineteuer und trotzdem etwas langsamer, oder XT weit langsamer und immer noch teuer, oder XT Clones auch noch teuer. Mac konnte man eigentlich nur rechtfertigen, falls man dessen beste GUI haben wollte, wenn auch am zweit teuersten und die schwächste Hardware, und GUI diese eigentlich überfordernd, damit nur wenigst schlechte GUI. Ansonsten war ST oder Amiga die bessere Wahl.

Zwischen den beiden war es nur eine Frage von wo dem Benutzer seine Prioritäten lagen. Welcher besser ist kann nur beantwortet werden mit welcher passt besser zum jeweiligen Benutzer. Will man die $700 Differenz in mehr Farben und Koprozessoren setzen, weil man diese braucht. Dann ist Amiga angesagt. Oder will man sie aufsparen für früher Peripherie oder gar Harddisk besorgen, und erst noch +10% Prozessor und mehr Speicher bekommen, und allenfalls besseres Mono Video. Dann ist ST die billigere oder gar bessere Wahl. Egal welches zu einem passt, bekam man etwas besseres als AT und Mac boten.

Beide ST und Amiga legten so anfangs einen heftigen Vorsprung hin. Bei 8bit hatte Apple II in 1977 mit 8k Bitmap einen Basiswert gelegt. Atari 800 in 1979 und C64 in 1982 erweiterten dies mit 2bpp und Sprites. Apple IIe in 1983 und CPC in 1984 konterten mit 16k und 4bpp, aber ohne Sprites. PC/XT/AT CGA war 1981 auch nur 16k mit nur 1oder2bpp ohne 4bpp und zudem in miesen Farben. PC/XT/AT HGC war zwar 32k aber nur 1bpp und dazu sehr unquadratische Pixel (wie Lisa auch). Mac in 1984 hatte 22k, aber auch nur 1bpp und weniger Pixel. Die ST und Amiga in 1985 lieferten mit doppelter Busbreite plus inzwischen doppelte Taktung vierfache Bandbreite 32k mit 2oder4bpp, plus ST Mono doppelte Zeilenzahl mit 1bpp, das beste bisher!

Aber beide ST und Amiga bleiben dann zu lange stehen, AT und Mac evolvierten und holten sie auf. In nur 5 Jahren bis 1990 hatten PC und Mac 32bit Speicher, und holten Bild mit Pagemode Zugriffe aus dem Video RAM. So wurden ST und Amiga bereits in 1987 eingeholt, wenn auch weit teurer. Mit MCGA 320x200 8bpp (strikte als x400 gezeichnet, was als Doublescan bezeichnet wird) sowie VGA 640x480 4bpp wurden sie 1987 überholt. Dann erst recht von SVGA abgehängt und XGA komplett so. Wenn auch PS/2 sehr teuer war, aber AT Clone lieferten dies auch immer billiger. Mac II lieferte ebenfalls 1987 640x480 4bpp, sogar mit Erweiterung 8bpp. Dann erst recht mehr im IIcx. Wenn auch ab Mac II stets sehr teuer.

Ich erachte in gegen diese mitziehen derart versagen als den Anfang vom Ende von beiden Systemen, und den Firmen dahinter. Schon nur in 1988 (statt 1989) bei STE bzw (statt 1990) bei ECS verdoppeln zu aus 64k RAM hätte beide gerettet. Nur geschah das nicht.

Strikte hatte TT030 sogar doppelt dieses in 1990, mit Bandbreite sogar vervierfacht, aus 152k (wie VGA). Das mit Schwarzweiss 1280x960 mit 1bpp für 2*A4 oder A3 auf 19". Aber auch mit Farben VGA 640x480 mit 4bpp und über-MCGA 320x480 mit 8bpp. Nur war dieser später und auch teuer. Falcon030 konnte sogar noch mehr, sogar 16bpp. Aber in 1992 weit zu spät.

Leider bekam der billige STE in 1989 kein verdoppeln auf damit vergleichbares halbsoviel, aus 64k. Selbst MegaSTE in 1991 war nicht besser. Dies bräuchte nicht mal doppelbreites 32bit RAM, könnte auch mit nur Pagemode Doppelzugriffe auf 16bit RAMs gemacht werden. Das mit Schwarzweiss, entweder auf horizontalem mit 800x600 1bpp SVGA (oder sogar bis 820x620) für A4 auf 15". Oder besser auf vertikalem Monitor mit genau verdoppelten 640x800 1bpp 71.25Hz, oder sogar einen solchen zu horizontal kippbar mit dann 800x640. Oder allenfalls noch bestehende 640x400 mit 2bpp. Aber auch mit Farben auf 640x200 4bpp und 320x200 8bpp (wie MCGA), selbst wenn bloss 256von4096 Farben. Oder allenfalls noch bestehende 2bpp/4bpp mit 400 Zeilen und 71.25Hz. Mit in 64k Modi, oder zumindest 8bpp, gleich auf Chunks wechseln (wie MCGA). Was vierfach Apple IIe Double Hires oder vierfach CPC wäre. Ohne dies bleibt der STE nur vierfach Apple II Plus bzw zweifach Apple IIe und CPC, und damit auch nicht vergleichbar mit vierfach C64, wie es ein vierfacher CPC gewesen wäre.

Amiga bekam vergleichbares zu TT030 vervierfachen mit AGA erst in 1992, auch aus 152k. Wieder in 1992 weit zu spät, und dies trotz Chipsatz in 1990 fertig sein aber liegengelassen.

Aber leider bekam das billigere ECS in 1990 kein verdoppeln als damit vergleichbares halbes, aus 64k. Auch hier braucht es kein breites RAM, nur Pagemode Doppelzugriffe auf die RAMs reichen (wie AGA es dann machte, neben 32bit haben), was gerade auch mit dem stark gekoppelten Amiga Chipsatz besser passt. Damit pro Zeitslot 2 statt 1 Wort holen. Erlaubt ebenfalls Farben auf 640x200 4bpp und 320x200 8bpp. Oder Productivity Modus mit 2bpp/4bpp 640x480. Ebenso Sprites mit 4bpp. Problem wäre aber bei 8bpp die harte Limite auf 6 separate Bitplane Mechanismen. Entweder zwei weitere addieren (wie in AGA), oder wieder in 64k Modi, oder zumindest 8bpp, gleich auf Chunks wechseln (wie auf CD32). Oder allenfalls statt 8bit Playfield auf 4bpp bleiben, aber diese in nur halbe Zeitslots holen, mit die anderen nutzbar um Sprites zu verbreitern durch in-Zeile Fortsetzungen nachladen, um somit breite Sprites aus nur einem Generator zu holen (wie es die SNK NeoGeo MVS Spielhallenautomaten machen). Oder gar schaltbar, 8bpp und normale Sprites für Paintprogramme, oder 4bpp mit mehr Sprites für Spiele.

Damit haben TT030 3 Jahre und AGA sogar 5 Jahre nach VGA und Mac II, erst mit 1987 gleichgezogen! Gebraucht hätte es STE und ECS als einen damals eigentlich ausreichenden Halbweg Zwischenschritt anzubieten, zumindest auf MCGA 8bpp hinauf. Und das in 1988, immerhin 3 Jahre nach 1985. Dann TT030 und AGA in 1990. In 1993 hätte dann weitere Verdoppelung auf SVGA 800x600 kommen sollen, plus Amiga dann verbesserten Blitter mit Playstation 1 Niveau an 3D bringen müssen.

Aber all das fand nicht statt, das Resultat von grundsätzlich sehr guten Systemen, aber schrottigen Firmen dahinter. Also konnte der PC mit MCGA/VGA ausholen und überholen. Das wurde zum Grund für ST in 1993 eingestellt und Atari 1996 konkurs, ebenso für Commodore 1994 konkurs und Amiga dabei untergehen. Ursache für diese Versagen war bei beiden Firmen aber komplett verschieden:

Atari hat schlicht ihre Resourcen verzettelt mit einem Projekt neben ST auch PCs herzustellen. Sie haben dabei drei verschiedene 8088 Modelle geliefert, die letzteren beiden nichts was Taiwan nicht von sich aus schon lieferte. Dann kam 386, erst als letztes 286. Der sich prompt am besten verkaufte, weil dort inzwischen der Massenmarkt lag. Wonach sie in Lieferschwierigkeiten kamen, Rechner anderstwo einkauften. Dann haben sie ihre PC Reihe zugunsten eingekaufter eingestellt. Sobald ihre eigentlichen Kunden (die Einkäufer von Grosshändlern) lernten direkt beim Originalhersteller einzukaufen fiel alles auseinander. Dies war komplett vorhersehbar, zumal Kosten sparen durch Mittelmänner umgehen zu den Kernphilosophien von Jack Tramiel gehärte! Resultat war viele Resourcen in Leerlauf verschwendet, welche in STE und TT030 verbessern hätten gehen können. Dann hat Atari diese in 1993 abgeschossen um sich auf Konsolen zu konzentrieren, aber beide Lynx und Jaguar sind gnadenlos gescheitert, Atari ging so konkurs. Wieder komplett vorhersehbar, wenn man den Konsolenmarkt kennt, wo Benutzer keine Software schreiben können, sie auf Softwarefirmen anziehen angewiesen sind und diese wiederum auf Benutzer anziehen. Weshalb der etablierte Anbieter wegen Vertrauen in seine Masse oben bleibt, ausser er begeht zu grossen Fehler. Und Atari war schon einmal mit solchem Fehler ausgescheiden, verlor alles an Vertrauen.

Commodore hat dagegen schlicht aus temporärem Geldmangel am falschen Ort gespart, an der Entwicklung. Jay Miner gibt bei Hi-Toro eine Anfangskapitalisierung von $7mio an, Commodore hat $24mio für Amiga hineingebuttert, und R J Mical meint im Nachhinein sie hätten realistisch insgesammt $49mio haben sollen. (Als vergleich konnte JAck Tramiel Atari problemlos finanzieren, mit $120mio hinter sich.) Commodore hat dabei vermutlich sich übernommen, gerade auch bei ihrer ohnehin prekären Finanzsituation, nachdem die TED Rechner (16, 116, Plus/4) scheitern (wie zu erwarten war bei der komplett daneben liegenden Spezifikation) und der C128 kein grosser Erfolg werden (wie zu erwarten war bei der zu schwachen Spezifikation). Sparen ging bis hin zu in der Entwicklung Personal entlassen, Knowhow verlieren, gefolgt von nachdem mangels verbesserter Amigas der Verkauf immer geringer wurde permanenten Geldmangel, noch mehr an der Entwicklung gespart, dies wiederholt so. Noch schlimmer wurden die wenigen Entwicklungen welche trotzdem stattfanden wiederholt weggeworfen statt in Produkte umgesetzt (AGA war 1990 fertig aber Rechner damit kamen erst 1992). Dem Hauptfinanzier war nur die Dividende dieses Jahr wichtig, er wählte Manager nach diesem Kriterium. So haben sie ihr eigenes Saatkorn gegessen, den Amiga abgewürgt, gingen daran konkurs.

(Genau wegen Krach mit diesem Finanzier, wegen seinen Vorstellungen, war der Commodore Gründer Jack Tramiel dort weggegangen und hat Atari übernommen! Gefolgt von Grossteil vom Kern der Firma, welche auch kein Vertrauen in diesen Finanzier seine Manager hatte. Was erst zu Commodore desorganisiert sein führte, deswegen sie die Fehler mit TED und C128 spezifizieren machen, sowie den Amiga wegen RAM Umbau verzögerten und selbst dann nicht liefern können.)

(Man beachte noch, dass Apple auch nur knapp überlebt hat. Sie waren schon angeschlagen von den Apple III praktisch in den Sand setzen (weil überhastet und unausgereift verkauft), gefolgt von Lisa kein Erfolg sein (weil schlicht zu teuer). Dazu kam der Mac wegen zuerst nur 128k RAM unbrauchbar sein. Aber mit Steven Jobs seine Annahme von stets zunehmendem Verkauf, nach anfangs stark verkaufen, wegen etwas total neues sein. Wonach aber die Verbreitung bald in sich zusammenbrach, sobald der Mangel erkannt wurde. Danach kam trotzdem weiter von immer steigendem Verkauf ausgehen, nicht auf Kritik hören. Dies resultierte in massiv zuviele Bauteile einkaufen aber wenig davon verkaufen, gefolgt von Apple daran fast Konkurs gehen! Nur mit 1800 Mitarbeiter an Lohnkosten abbauen hat Apple gerade noch überlebt. Und auch das nur langfristig, weil Apple IIe und IIc sich immer noch gut verkauften, und IIGS gerade rechtzeitig kam als diese beiden nicht mehr zogen, um das Loch zu stopfen bis der Mac II ausgereift und IIcx genug billig wurde.)

(Genau vergleichbares Loch, nachdem der C64 nicht mehr genug zog, mit dem zu schwachen C128 nicht stopfen können, war der Anfang vom schweren Geldmangel bei Commodore, gefolgt von zuwenig haben um den Amiga ausreichend schnell zu verbessern, gefolgt von dessen Verkauf einbrechen, gefolgt von Konkurs.)

Noch schlimmer wurde dies, als die dummen Abspielkonsolen nach mit NES wieder aufleben dann mit MegaDrive und SNES expandierten. MegaDrive in 1988/89 lieferte mit Amiga absolut vergleichbare Actionspiel Graphik, ebenso SNES in 1990/91 halbwegs so, wenn auch wegen seinen Limiten eher für Adventure oder RPGs benutzt. Beide nur aufgeholt wegen der Stagnation. Damit versagen ST und Amiga den Atari 800 und C64 zu folgen und die dummen Abspielkonsolen fertig auszurotten, und wurden statt dessen zwischen Konsolen und PCs/Macs in die Schere genommen. Was zum Abwandern der Benutzer und Ende dieser letzten beiden verbleibenden Homecomputer Hersteller führte, und ab 1990 zum Kontrast von einfachen aber zugenagelten Konsolen zu flexiblen aber komplizierten PCs, statt den besseren einfachen und flexiblen aber stehengebliebenen Homecomputern.

Diese Seite ist von Neil Franklin, letzte Änderung 2025.07.25