Bildschirmpixel direkt ändern
10 CALL 1208
20 POKE &3000,10
Im Folgenden wird einfach in das Bildschirmemory geschrieben. Der Aufbau ist seltsam: Eventuell alte Rechner als Grundlage?
WeiterlesenEnde der 80er Jahren waren Computer teuer und die Computerräume an Schulen nicht unbedingt gut bestückt. Erfahrung: „IBM PC I“s etwa im Thurgau. Siehe dazu auch hier. Im Kanton Zürich es Apple geschafft hatte, zum Schulcomputer zu werden mit ihren Mac.
Damit stellte sich die Frage etwa in der Ostschweiz: Wie bringen wir den Leuten (Erfahrung: Oberrealschule = MINT Kantonsschule in Frauenfeld) das Programmieren bei? Die Antwort hiess etwa: SHARP 1403. 100%tig japansiche Technologie. Das war eigentlich ein Taschenrechner. Dafür wurde er auch benützt (neben dem HPs). Und er war auch in BASIC programmierbar. Einzeilig, aber programmierbar. Anders als die programmierbaren HP-Rechner mit ihrer eigenen Programmiersprache (Erfahrung: Damals nötigte die Bernina-Nähmaschinenfabrik ihre Drehbankarbeiter zur Programmierung von HP-Rechnern!) war dieser SHARP 1403 eigentlich ein vollwertiger Taschencomputer. Er besass sogar eine ! QWERTY-Tastatur und hatte ein BASIC. Also perfekt geeignet für eine Kantonsschule – auch preislich – damit Programmierunterricht zu geben.
Damit war es auch möglich (BASIC sei Dank), auch interaktive Programme zu gestalten (Siehe dazu Interview Lührmann mit ‚Basic interaktiv vs FORTRAN‘).
WeiterlesenDie 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.
WeiterlesenEs 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.
WeiterlesenIm Rahmen des CHLUDENS Projekt entstand ein weiteres Spiel: IdentityWars.
Mehr dazu hier: https://gamelab.zhdk.ch/projects/ch-ludens-identitywars
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.
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..