Wer nach dem C64 erwartete, es wird nun alles einfacher mit den Homecomputer 16/32-Bittern ab 1985, der wurde eher beim Atari ST glücklich oder vom Sinclair QL. Das waren Computer mit viel RAM und einem fantastischen Prozessor (Motorola 68000), der endlich auch auf Entwickler zugeschnitten war und nicht tot gespart war wie der 6502. Der Atari ST war billig, den Jack Tramiel trieb auch hier sein Spiel für billig und für die Massen, darum wurde an Grafik aber vorallem an Audio gespart (Der Amiga war ja auch mal als Atari Produkt im Gespräch, endete aber bei Commodore).
Der Amiga eingeführt kurz nach dem Atari ST 1985+ war das Homecomputer-Highend-Produkt (neben dem Macintosh und anderen 68000er based Workstations) und am Anfang auch eher teuer (mit wenig RAM 256k), erst der Amiga 500 (1987+) änderte dies grundlegend.
Als Entwickler* sieht die Sache dabei im ersten Moment super aus: Wow, der Amiga, der kann soviel, soviel mehr als der C64 und auch als der Atari ST. Die Facts sind überragend, verschiedenste Bildschirmmodis, die Möglichkeit den Bildschirm mit verschiedenen Screens zu füllen, Hardwarescrolling, Sprites, digitalisierter Sound und sogar Aufgaben können an den Co-Prozessor abgegeben werden. Zudem ist die Grafik skalierbar über Bitplanes. Pro Bitplane kann man die dargestellten Farben vergrösseren. 1 Bitplane 2 Farben, 2 Bitplanes 4 Farben bis zu 5 Bitplanes mit 32 Farben und mit Spezialmodis noch mehr. Was allerdings auch sehr viel mehr Rechnzeit braucht. Aber was will Entwickler* mehr?
Hier muss vermutlich ein Unterschied eingeführt werden zwischen: Entwickler* für die Demoscene und Entwickler* für die Gamedesignscene. Für Erstere* ist der Amiga bis heute eine technische Herausforderung – ein Instrument aus dem bestehenden noch mehr herauszuholen. Die grosse Challenge oder ein Spiel. Für Zweitere* ist der Amiga nur Mittel zum Zweck. Natürlich gab und gibt es auch Mischformen, wie man an vielen Games als technischen Meisterleistungen schnell erkennt. Aber eben nicht unbedingt.
Es scheint, so zumindest die letzten Aussagen in Diskussionen mit Zeitzeugen sogar eine Auseinandersetzung gegeben zu haben: C64 gegen Amiga (jenseits der Diskussion Amiga vs Atari ST). Was ist das bessere System? Eine auf den ersten Blick unsinnige Auseinandersetzung, da aus einer Fortschrittsperspektive heraus natürlich der Amiga die nächste Generation war und damit doch schon ‚moderner‘ sein sollte und tatsächlich technisch auch ist.
Diese Interpretation verschleiert natürlich einige wichtige Kategorien: Zugänglichkeit (etwa in Preis) des Produkts (der Amiga war Anfangs sehr teuer) etc und die Frage: Was kriegt man für bessere Leistung? (dies alles aus Konsumenten Sicht). Und lohnt sich das Ganze? Das Ganze ist also auch eine Sozial-ökonomische Sache, wer kann sich das leisten? In einem Interview bringt es jemand (PD) auf den Punkt bei Atari vs Amiga: „Niemand konnte sich die zwei teueren Systeme gleichzeitig leisten, ausser vielleicht die Reichenkids“. Beim C64 war das ja bekanntlich anders, Jack Tramiel hat die anderen Systeme unter anderem durch einen harten Preiskampf vom Markt gedrängt mit einem Computer, der auf möglichst billig ausgelegt war.
Bei einem OralHistory-Interview zum Thema FirstContact, Community & Hardware habe ich dann auch noch nachgefragt: Für was nutzten sie ihre 16Bit Computer wie Atari ST und Amiga. Und das war insofern interessant, aber nicht repräsentativ, dass 2/4 der Amiga-Nutzern ihren Computer fast ausschliesslich zum Gamen nutzten. Einer nutzte ihn auch noch zum Musik machen daneben und einer auch noch zum Grafiken erstellen. Auf die Frage aber, was denn die wichtigste Textverarbeitung gewesen sei, war unklar, ob es überhaupt eine Textverarbeitung auf dem Amiga gab.
Anders auf der Atari ST-Seite, da gaben 2/2 an, den Computer auch sonst genutzt zu haben für Textverarbeitung, also im Büroumfeld. Dabei kam 1stWord und die Nutzung von Calamus zur Sprache. Es kam dann auch die Frage auf, ob der Atari ST nicht auch ein billiger = erschwinglicher Macintosh-Clone gewesen sei. Dasselbe könnte man sich selbst im Umfeld der Music fragen. Wo Atari ST (nach Aussagen von Studioausrüstern) auch als billige MIDI-Alternative zum Mac benutzt wurden.
Dies würde natürlich auch noch ein weiteres Schlaglicht auf die Identity-Frage werfen: Atari ST vs. Amiga. Eine Frage, die auch im PC-Bereich als Abgrenzung genutzt wurde gegen alles mit Maus: Kann man damit auch mehr machen als Spielen?
// Todo: Vielleicht könnte man statistisch das Problem auch so evaluieren: „Hattet ihr einen Printer und für was habt ihr den benutzt?“ Dies wäre auch im Game Design Bereich interessant, denn hat damals noch jemand Source-Code ausgedruckt? Oder gar Bilder?
Was in heutigen Programmiersprachen gang und gäbe ist, die Technik Dinge von X nach Y zu kopieren und dort anzupassen, ist in Assembler nicht so einfach möglich. Der Grund: In heutigen Programmiersprachen gibt es keine Sprungmarken mehr, diese müssen aber mühsam angepasst werden Assembler. Es darf ja (ausser bei modernen relativ adressierbaren Assembler) keine zwei gleichlautende Sprungmarken geben. Anders gesagt: Copy&Paste ja, aber zu einem Preis: Generierung von vielen neuen Labels und damit auch jede Menge möglicher Fehler und viel Neu-Testing.
Und dies trifft Videogames besonders, da Videogames geradezu von Bedingungen leben (ifs, loops etc).
Gridrunner (Jeff Minter) – 68000 ATARI ST Assembler:
// {} vs a: b: // Mehr Subroutinen in Assembler > Frage an die Entwickler // Vgl dazu die Demoscene
Eine der grössten Probleme im Retrogaming ist die visuelle Adäquatheit von Spielen. Meist werden heutige Spiele auf TFTs gespielt, die aus einzelnen ‚Pixeln‘ bestehen. Diese bilden in keiner Weise die Realität des Visuellen Outputs des Gamings der Homecomputerzeit ab.
Wer Assembler programmiert (oder auch Basic mit Goto Zeilennummern/Sprungmarkenmöglichkeiten) stellt schnell fest, hier kann man viel mehr machen als in modernen strukturierten Programmiersprachen (mit derselben Anzahl von Zeichen). Moderne strukturierte Programmiersprachen ähneln mehr einem modernen Rezept, während unstrukturierte eher einem Hypertext ähneln.
Moderne strukturierte Programmiersprachen und ihr Baumkonzept
Moderne (strukturierte) Programmiersprachen und ihre Ablaufdiagramme sind eine Teilemenge (nicht eigentlich) der viel grösseren Menge der Maschinensprachen mit ihren JMP und GOTO Befehlen. Der Code springt in Unterroutinen und kehrt dann wieder zurück in den nächst höheren Prozess.
Dadurch entsteht eine Art Baum und wie bei Treestrukturen üblich, ist es jederzeit klar, wo sich der Programmpointer(‚man‘) befindet. Jeder Punkt ist klar definiert, weil der Rückweg immer klar ist – den Tree up. Je tiefer der Tree ist, umso grösser die Verwaltungsaufgabe, schliesslich muss man sich immer merken, wie man zurückkommt.
Prinzipiell hat C. Böhm ( https://en.wikipedia.org/wiki/Corrado_Böhm ) früh – 1963 – gezeigt, dass sich alle unstrukturierten Programmiersprachen in strukturierte überführen lassen. Er hat dazu eine theoretische Programmiersprache entwickelt mit sehr wenigen Befehlen. Eine wiedererfundene Version dafür kennt man heute Brainfuck von U. Müller, das nur von den Befehlen +-[] etc lebt. Diese Sprache hat natürlich einen Preis, die Source-Codes sind riesig.
Der Vorteil ist sofort klar: Lesbarere Strukturen (Trennung zwischen Fakten und Regeln klar), da es klare Ablaufdiagramme gibt.
An verschiedenen Stellen (raussuchen) wird darauf hingewiesen, dass gerade 8Bitter wegen RAM (auch in Sachen Tools) und kleinem Stack nicht in der Lage sind wirklich höhere strukturierte Programmiersprachen zu bieten. Es fällt auch auf, dass es wenige strukturierte Programmiersprachen gibt auf diesen Systemen und viele erst heute nachträglich entwickelt werden, um zu zeigen, dass es doch funktioniert.
// ToDo: Checken der These, dass es bei 8Bit-Homcomputern wenige Compiler und Hochsprachen gibt, weil das RAM fehlte bzw. die Stacks zu klein waren für gute Compiler.
// Trees sind deswegen bekanntlich sehr beliebt, da sie machttechnisch grösstmögliche Kontrolle erlauben. Natürlich lassen sich damit nur eine beschränkte Datenstruktur oder auch Prozessstruktur abbilden – aber für viele Systeme reicht es (oder eher muss es reichen).
Unstrukturierte Programmiersprachen – willkommen in rhizomatischer Ausführung
Assembler dagegen ist das potentiell offen in der Struktur. Es kann kreuz und quer Daten uns Code verteilt werden (nicht der beste Stil) – letztlich besteht darin auch kein Unterschied – das eine sind ausführbare Daten, das andere interpretierte Daten – aus Sicht des Programs.
Prinzipiell gibt es wenige Befehle. LDA (load A), STA (store A), CMP, JMP. Dadurch entstehen logisch stringente Programme. Ebenso ist das Rechenwerk meist sehr eingeschränkt (etwa beim billigen 6502): Register A,X,Y. All dies macht die Programm lang und oft schwer lesbar.
Als Flaschenhals kommt hinzu, dass viele Operationen nicht im allgemeinen (langsamen) RAM ausgeführt werden können, sondern nur im ‚Rechenwerk‘ und darum dahinein geladen werden müssen bsp. lda #1 (Lade 1 ins A-Register).
Der wichtigste Unterschied zu strukturierten Programmiersprache ist aber sicherlich die Möglichkeit des „Springens“ JMP (oder GOTO) und alle Flag-Abhängigen-Sprünge aus „Compares wie CMP“ wie BEQ (gleich), BNE (ungleich), BCC (kleiner als), BCS (grösser als) etc.
Ein fiktives Beispiel:
lda #10
ohje:
clc
adc #1
clc // clean the state-register
cmp #4
beq it_is_four // same
bne it_is_notfour // not the same
it_is_four:
jmp end_of_all
it_is_notfour:
jmp oh_je
end_of_all:
Dies ermöglicht dann alle möglichen Versionen von Ausführungen. Komplizierter wird das Ganze dann auch noch, wenn sich der Source-Code über mehrere Seiten erstreckt. Und selbstverständlich lassen sich Dinge in Unterroutinen verpacken, das Problem allerdings dann da: Handling der Parameter (auf den kleinen Stack oder in eigene Variablen?).
Im konkreten Programmierprozess müssen durch die Sprungmarken auch immer wieder neue Sprungmarken gefunden werden. Dies ist bei weitem aufwändiger als etwa in C. Die Haupbenennungsaufgaben sind quantitativ die Variablen/Members und die Methoden.
Die Variablen sind ähnlich aufwändig in Assembler:
a: .byte 0 vs byte a = 0;
Dasselbe gilt für die Funktionen/Methoden:
render_me:
[...]
rts
vs
void render_me() {
}
Viel aufwändiger wird es hingegen bei jeder kleine If-Abfrage bzw. in Sachen fornext (was ja eine verkürzte Schreibweise ist C). Hier müssen immer wieder neue Sprungmarkennamen gefunden werden (auch wenn moderne Assembler hier auch lokale relative Namings ermöglichen).
ldx #10
count_down:
clc
cpx #4
is_not4
is_not4:
inx
clc
cmp #0
bne count_down
vs
for (int i=0;i<10;i++) {
if (i==4) {
}
}
Selbstverständlich klingt, das im ersten Moment nicht nach viel. Das Problem potentiert sich aber dann mit jeder neuen Abfrage und jeder ForNext-Schleife.
