Ein 6809-Trick machte ein unspielbares Spiel flüssig
A great old-timey game-programming hack (2013)
Ein Student hatte ein grafisch beeindruckendes Arcade-Spiel auf einen 8-Bit-PC portiert, doch es lief zu langsam. Sein Freund optimierte die Kopierroutine für 28×28-Pixel-Kacheln auf dem 6809-Prozessor von 157 auf 98 Zyklen pro Zeile – 60 Prozent schneller. Das reichte nicht. Also suchte er im Handbuch nach einem ungewöhnlichen Befehl, der viele Bytes schnell bewegt. Die Geschichte zeigt, wie Programmierer damals mit exakten Offsets und Zykluszählung jedes Quäntchen Leistung aus der Hardware pressten.
Die Grafikhardware machte überhaupt nichts. Auf dem betreffenden PC musste man, um etwas auf den Bildschirm zu zeichnen, das selbst erledigen – Byte für Byte. Keine Texture-Mapper, keine Blitter. Nur Bytes. Bytes, die man selbst bewegen musste.
- rob74
> Hier die Kurzfassung: Die Grafikhardware hat überhaupt nichts gemacht.
Auf dem betreffenden PC musste man, wenn man etwas auf den Bildschirm zeichnen wollte, das selbst tun, Byte für Byte. Keine Texture Mapper, keine Blitter. Nur Bytes. Bytes, die man selbst bewegen musste.
Das ist nicht ganz korrekt: Die Grafikhardware nahm den Videospeicher und baute daraus ein Bild (Framebuffer-Grafik). Was schon mehr ist, als die frühesten Spielkonsolen taten.
- mikewarot
Damals in den MS-DOS-Tagen arbeitete mein Freund Ward Christensen bei IBM im Technical Sales Support. Sie hatten eine informell gepflegte Datei, die jedes einzelne Produkt auflistete, das sie zum Verkauf anboten, in einem Format, das auf einem PC gelesen werden konnte. Er war wirklich gut darin, sie mit seinem Texteditor zu durchsuchen, aber er wollte ein eigenständiges MS-DOS-Programm, damit seine Kollegen leicht danach suchen konnten. So entstand PCxREF, ein Turbo-Pascal-Programm, das ich schrieb und das eine Suchfunktion enthielt.
Mein erster Versuch war eine naive Suche mit dem eingebauten String-Matching. Wegen der Größe der Datei und der Geschwindigkeit der PCs dauerte eine Suche manchmal mehr als 30 Sekunden. Ward wollte es schneller, viel schneller.
Schließlich kam ich auf einen Algorithmus, der den Text, nach dem man suchen wollte, nahm und ihn in eine spezielle Art von Bitmasken-Tabelle umwandelte. Es war eine Tabelle mit 256 Bytes, initialisiert mit Nullen. Wenn das erste Zeichen der Zeichenkette, nach der man suchen wollte, ein D war, dann wurde das erste Bit der Maske für $44 und $64 gesetzt, um Groß-/Kleinschreibung zu berücksichtigen. Ein Platzhalter * war nur 1 Zeichen lang, setzte aber alle Bits für dieses Zeichen. Dann nutzte ich die 8088-XLAT-Instruktion und eine sehr kleine Schleife, um ein Zeichen des zu durchsuchenden Textes einzulesen, es als Index in die Maskentabelle zu verwenden und das mit dem vorhandenen Flag in einem anderen Register zu verunden, dann verschob ich es, prüfte auf CARRY (ein Treffer!) und wiederholte die Schleife, wenn es nicht null war.
Die Suche dauerte dann weniger als 3 Sekunden, wenn die ganze Datei im RAM geladen war. Die dünne […]
- taspeotis
Etwas verwandt [1]:
> Vor Jahren arbeitete ich bei Video Seven, einem heute verschwundenen Hersteller von Videoadaptern, und half bei der Entwicklung eines VGA-Clones. Der Mann, der den VGA-Chip von Video Seven entwarf, Tom Wilson, hatte monatelang rund um die Uhr gearbeitet, um seinen VGA so schnell wie möglich zu machen, und war zuversichtlich, dass er seine Leistung so ziemlich ausgereizt hatte. Als Tom jedoch die letzten Handgriffe an seinem Chipdesign vornahm, kam aus vierter Hand die Nachricht, dass ein Konkurrent, Paradise, die Leistung des Clones, den er entwickelte, durch den Einbau eines FIFO aufgemotzt hatte.
> Das war alles, was er wusste; es gab keine Informationen darüber, was für ein FIFO, wie viel es half oder sonst irgendetwas. Trotzdem nahm Tom, normalerweise ein umgänglicher, entspannter Typ, den hellwachen, gehetzten Blick eines Mannes mit zu viel Koffein und ohne Antworten an, als er versuchte, aus hoffnungslos dünnen Informationen herauszufinden, was Paradise getan hatte. Schließlich kam er zu dem Schluss, dass Paradise einen Schreib-FIFO zwischen Systembus und VGA gesetzt haben musste, sodass, wenn die CPU in den Videospeicher schrieb, der Schreibvorgang sofort in den FIFO ging und die CPU weiterarbeiten konnte, anstatt jedes Mal zu blockieren, wenn sie in den Anzeigespeicher schrieb.
> Tom konnte weder die Gatter noch die Zeit für einen vollständigen FIFO erübrigen, aber er konnte einen FIFO mit Tiefe eins implementieren, der es der CPU ermöglichte, einen Schreibvorgang vor dem VGA zu sein. Er war sich nicht sicher, wie gut das funktionieren würde, aber es war alles, was er tun konnte, also baute er ihn ein und tape-outte den Chip.
> Der FIFO mit Tiefe eins funktionierte tatsächlich […]
- green_wheel
Toller Artikel. Ich schätze, das Gras ist immer grüner, aber das Programmieren in jenen Tagen scheint wirklich cool gewesen zu sein. Heute ist alles Package-Manager hier und Toolchains da. Wir sind so weit von dem abstrahiert, was unseren Code tatsächlich ausführt. Artikel wie dieser lassen mich die CPU rufen hören: „Komm zurück zu mirrrrrr“
- pjc50
Ich versuche herauszufinden, welcher Computer tatsächlich den 6509 hatte; Kandidaten scheinen Dragon oder Tandy zu sein?
Genau wegen solcher Dinge war der Amiga so massiv erfolgreich, weil er eine Sammlung von Co-Prozessoren hinzufügte: https://en.wikipedia.org/wiki/Amiga_Original_Chip_Set
Jeder von ihnen hatte eine begrenzte, aber dedizierte Funktionalität zum Bewegen und Transformieren von Bytes im RAM. Der Blitter insbesondere war darauf spezialisiert, Speicher für Tile- und Sprite-Rendering zu bewegen.