Es gibt im Netz angeblich unendlich viele Webseiten zur Homecomputerscene. Wenn es dann aber darum geht, Code zu sehen etc, herauszufinden, wie die Probleme in echt gelöst wurden, ist das Angebot dann fade oder man muss alles zusammensuchen. In diesem Sinn ist die folgende Webseite recht interessant, es gibt Interviews und auch Hintergrundinfos.
Gehört eigentlich in jede Ausstellung zu gestern, die Verkaufsboxen. Alles in einem: Branding, Werbung, Inhalt, Comic, Game, Action und Mythos: „Piloten Kit“
Arcade vs Homecomputer: Knöpfe vgl. Consolen Simulation des zweiten Knopfs: Zynaps, R-Type und Co. Specialinterfaces wie Paddle, Drehknopf etc. Immer weniger vorhanden vgl.
Pro – nur diese Art von Concept – Standardisierung – Westen ohne Experiment vs vorallem japanische Arcades > Experimente
Contra – nur diese Art von Concept – Standardisierung > wenig Neuerung meist Mapping
Weiterentwicklung am PC: WASD-Joystick oder Cursor-Joystick und Mouse
// Todo: Der Lange Knopfdruck // Todo: Vectrex mit analogem Joystick
Die einfachste Art für eine Ausstellung das Color-Sudoku (8*16 Boxen mit je 3 neuen Farben) erfahrbar zu machen, ist direkt an einem Monitor ein Geflecht darüber zu legen. So dass man sieht wie das ganze ‚funktioniert‘. Eine andere Möglichkeit wäre natürlich eine App für ein Mobile Phone, wo man die Welt durch C64 (oder Apple)-Augen sehen könnte.
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.
Betrachtet man viele der 8Bit Computer im visuellen Bereich, so sind diese geprägt von massiven Einschränkungen sowohl in Auflösung wie auch Farbmöglichkeiten – gezwungermassen durch Rechenleistung und vorallem RAM-Preise.
Demgegenüber waren die Displays Fernseher/Monitore eher klein und die Pixel eher verschwommene gefüllte Kreise (CRT-Technik, Lochraster) als klar definierte Rechtecke wie bei heutigen grossen Display. Das ergab dann ein fast schon an Glasmalerei erinnerndes Erlebnis. Diese Aspekte wurden auch von einigen Designern* ausgenutzt, indem Farben bewusst gewählt wurden, die ineinander übergingen oder das Gegenteil damit dazwischen wahrnehmungsphysiologisch eine nicht existierende Farbe ‚entstand‘.
Kunsthistorisch muss man vermutlich weit zurückgehen, um solche Einschränkungen bei einem Medium zu finden, jenseits von Monochromen-Printsystemen oder Monochromfernsehern also technischen Systemen.
Welches Visuelle System verwendet schon festgelegt 16 Farben (im Multicolormode), die wiederum in 8×8 Pixelblöcken (Planes) aufgeteilt werden auf 40*11 Blöcken, in denen man wiederum nur 3 Farben bei einer Hintergrundfarbe wählen kann?
Die Colorconstraints in diesem Bild rot markiert. Die Linien zeigen die einzelnen Blöcke mit den Einschränkungen:
Die Auswirkungen dieser Einschränkungen werden auch schnell sichtbar und klar in den Artworks. Es ist eine Art Stil entstanden, der gezwungnermassen farbig grössere Flächen bildet. Dabei ist die Sujetwahl oft recht stereotyp und versucht manuell bestehende Bilder manuell zu digitalisieren statt die Einschränkungen aktiv zu nutzen. Viele dieser Bilder sind also eher Zukunftsgewandt als sich aktiv etwa mit Kunstrichtungen gerade jener Zeit auseinanderzusetzen (die ebenfalls teilweise sehr abstrakt unterwegs waren):
Fast in allen analogen Farbsystemen (aufbauend auf Farbpartikel) lassen sich Farben mischen. Im Falle des C64 nicht und dies ist keine selbstgewählte Einschränkung.
Man findet solche Einschränkungen vermutlich eher als Selbstbeschränkungen von einzelnen Künstlern und Kunstrichtungen etwa in der Abstrakten Malerei. Aber auch da ist mir noch kein Künstler* bekannt, der so rigoros sich an diese Art von FarbenSudoku (8x8Pixel mit 0+3 Farben) gehalten hat.
Dies zeigt sich auch exemplarisch im Falle der Retrogames, die ihr Retro in der Palettenwahl und grösse der Pixel sehen, aber nicht in den Restriktionen dieser ursprünglichen Systeme. Deswegen sollte man diese RetroArt/Games eher als „NeoRetro“ bezeichen.
// ToDo: Eine Augmented Reality App, die die Welt durch die Multicolor-Linse etwa das C64 „digitalisiert“ // ToDo: Klare Abklärung/Auseinandersetzung mit der 70er/80er Jahre Kunstscene
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.
In einem Telefongespräch meinte ein Entwickler letzthin, dass Computer (falls ich ihn nicht falsch verstanden habe) so etwas wie Hosentaschen gewesen seien. Da kannte man jeden Ecken, es waren einfach 64 * 1024 Bytes Memory im C64 und das sei alles gewesen, alles. Und man kannte jede Adresse oder zumindest die Ranges. Anders gesagt: Es war alles so klein und festgeschrieben, dass einfach alles vor einem lag. Wo findet man den aktuellen Modus des Screen, wo muss man reinschreiben, dass er sich ändert. Wo liegt das Memory für die Joysticks etc. Dinge die heute alles über Spezialhardware und oft deren Schnittstellen erledigt werden muss.
Und es ist tatsächlich so – dass die Leute in Lemon64 immer noch die absoluten Adressen in Hex angeben(!). Sei es in Assembler oder in Basic! (Pokes/Peeks) Nicht etwa in Konstanten aus Libraries, wie heute üblich.
Diese absolute Kontrolle ist selbstverständlich verloren gegangen und so gibt es einige Entwickler*, die danach aufhörten, denn in Windows etwa sei einfach nicht mehr alles unter Kontrolle gewesen.
Der Weg raus aus der Hosentasche in den vielfältigen Overall, wo dauernd, was anderes in der Tasche vielen war. Erklärt auch ein bisschen den Aufstieg der Hochsprachen auch in diesem Millieu. Kontrolle.
Es ist eine Sache Software/Games für alte Systeme auf Emulatoren zu entwickeln und eine andere sie dann lauffähig zu machen auf Orginalhardware. Die Unterschiede sind schnell erklärt: Viele Emulationen ’simulieren‘ über Probleme hinüber (Werte sind meist geleert oder null gesetzt, Hardware ist doch leicht anders etc).
Am Besten sieht man das etwa bei sehr spezialisierter Hardware wie der Vectrex (Beispiel VecZ). Beim Simulator gibt es kein Flimmern, keine Hardware am Anschlag, keinen Kathodenstrahl, der kondensiert die gesamte Helligkeit abbildet etc.
Aus diesen Gründen war es interessant zu sehen, ob das Spiel TheHolyCube einfach so läuft auf einem Orginal C64.
Das Spiel kann per FlashCard und einem SD2iEC (Simuliert ein C64-Diskettenlaufwerk – Karte und Stecker zum C64-Laufwerk) relativ leicht als .PRG ‚aufgespielt‘ werden.
Das Resultat: Es läuft – in den ersten Test ohne Probleme. Selbstverständlich ist der Screen ein modernes TFT und dadurch erscheinen die Pixel als Pixel und sind nicht verschwommen wie bei einem Orginal CRT. Dies muss als nächstes getestet werden, um dem ursprünglichen Phänomen und der Wirkung gerecht zu werden..
