Pixelor

Dass ich wieder etwas mehr Zeit habe, lässt sich gut an meinen Aktivitäten erkennen. Mein Vorhaben war es, ein Entwicklungssystem unter MSDOS aufzubauen, ohne mir hierfür entsprechende Hardware anzuschaffen. Denn zum einen fehlt mir nun wirklich der Platz und zum anderen scheinen auch die Preise für alte MSDOS-fähige Hardware in die Höhe zu schnellen.

Also habe ich mich an zwei Möglichkeiten versucht: DosBox und MSDOS 6.22 unter VirtualBox.

Das Einrichten der DosBox war schnell erledigt. Auch die Compilersuite DJGPP mit der Bibliothek Allegro 4.2, der letzen DOS-fähigen Version, waren fix konfiguriert. Dann kam aber die Ernüchterung. Ein einfaches "Hello World" konnte nicht kompiliert werden. Zunächst nahm ich an, dass das wieder ein Thema rund um Protected Mode sei, weshalb ich hier einiges ausprobiert habe. Auch der vorherige Start des DOS-Extender mittels führte zu einem internen Compiler-Fehler. Auch die Stackvergrößerung mit brachte nicht die Lösung. Mit GCC habe ich fast mein Pulver verschossen und auch im Netz finde ich nichts, was geholfen hätte. Was mir bleibt, ist den Watcom C Compiler auszuprobieren, der wohl mit der Allegro-Bibliothek ebenfalls zusammenarbeitet.

Der Ansatz mit der VirtualBox schien sehr erfolgsversprechend zu sein. Die Einrichtung ist allerdings deutlich schwieriger, zumal der Shared-Folder-Mechanismus nicht funktioniert. Hier half es, das Festplatten-Image-Format VHD zu verwenden, weil man diesen unter Windows per (Computerverwaltung/Datenspeicher bzw. Datenträgerverwaltung) einhängen kann. Leider darf meine virtuelle DOS-Maschine nicht gleichzeitig laufen, wenn ich das VHD-Image eingebunden habe. Ich muss es also immer auswerfen, bevor ich wieder MSDOS in VirtualBox starten kann.

Auch in Sachen Treiber musste ich eine Menge zusammensuchen, um das CD-ROM, die Maus (ja, auch unter DOS: mouse.com) und die Soundblaster-Karte zum Leben zu erwecken. Das Editieren von AUTOEXEC.BAT und CONFIG.SYS mit den Devices inklusive HIMEM.SYS hat mich an alte Tage erinnert. Sollten die modernen PC nicht mehr funktionieren, dann kann ich wenigsten die alten DOSen wieder lauffähig machen Und weil alles soviel Spaß gemacht habe, hatte ich mir flugs Windows 3.1 installiert. Auch heute sehe ich in Windows 3.1 keinen großen Mehrwert, wenn man Amiga / Workbench oder Atari / GEMS vergleicht. Wie lange Jahre dauerte es bis es eine brauchbare GUI von Microsoft gab? Dauerte es echt 6 Jahre nach Atari, bis Windows 3.1 und weitere 3 Jahre bis mal was Brauchbares wie Windows 95 rauskam? Aus heutiger Sicht würde ich das fast einen Rückschritt nennen, wenn da nicht die Games wären, die schon recht früh für eine Festplatteninstallation vorgesehen waren und daher komplexer sein durften, ohne dass man DJ spielen musste. Aber ich schweife ab.

Ich war jedenfalls total happy als ich beim Abspielen von akkord.wav tatsächlich etwas hörte. Nach Installation von weiteren Treibern meldete sich Windows 3.1 aber mit einem Problem hinsichtlich des MIDI-Device. In der Tat konnte ich keiner MIDI-Datei einen Ton entlocken - unter DOS nicht und unter Windows nicht. Weil ich mir sicher war, dass ich alles korrekt eingerichtet hatte, ging ich auf die Suche im Internet. Und siehe da: OPL bzw. MPU-401 wird nicht unterstützt. Leider scheint das wohl auch bei anderer Virtualisierungssoftware der Fall zu sein. Ein Wechsel auf VMware würde demnach nichts bringen.

Nun, die Kompilierung funktioniert 1a. Aber ich hatte schon vorgehabt, ein Mini-Game mit blecherner MIDI-Musik zu programmieren. Das fällt somit ins Wasser. Auch WAV-Dateien sollen gemäß einiger Forenbeiträge nicht sauber sein.

Fazit: Als Spiele-Entwicklungssystem ist MSDOS unter einer Virtualisierungssoftware definitiv nicht zu gebrauchen. Ich verfolge weiter den Ansatz mit der DOSBox und einem anderen Compiler. Allerdings will ich mir doch noch ein Windows 98 unter VirtualBox installieren, um zu schauen, ob sich damit wenigstens etwas anfangen lässt. Denn zu Windows98-Zeiten waren Midi-Töne ohnehin längst out.

Zitat von »henrikf«

Ich nehme an, dass bei dem »Hello World«-Programm die Allegro-Bibliothek noch gar nicht zum Einsatz kam, oder?

Nein, noch nicht. Erst muss sichergestellt sein, dass der Compiler mitmacht. Und wenn ich lese, dass GCC unter MSDOS zum Einsatz kommt, bin ich erstmal misstrauisch. Selbst unter modernen Windows-Betriebssystemen bin ich schon auf den einen oder anderen Bug gestoßen. Hier aber weniger beim Kompilieren sondern eher beim Linken und zur Laufzeit (Bug in MinGW32).

Ich bleib dran, da auch ich das Thema echt spannend finde.

Bevor ich es vergesse: letzte Woche habe ich mit 68000-Assembler auf dem Atari ST angefangen. Hey, soo schwer ist das gar nicht... Traps und die Architektur müssen aber ebenso gelernt sein. Darum der ST und nicht der Amiga, der etwas komplexer sein dürfte. Davon ab: ich bin wohl ein verkappter ST-Fan, der ein Amiga hatte, worauf ich aber nur gedaddelt hatte. Ich hätte doch lieber etwas Vernünftiges damit machen sollen...

Wie ich schon schrieb, wollte ich noch einen kleinen Ausflug auf Windows 98 machen:



Mit dem Internet Explorer ist da überhaupt nichts mehr zu machen, weil SSL in der Urform aus Sicherheitsgründen von keiner Seite mehr unterstützt wird. Retrozilla ist der einzige Browser, der noch funktioniert.

Das Menü des Forums sieht natürlich auch nicht so aus wie in modernen Browsern. Sicherlich mache ich noch mehr mit dem Image...

Endlich! Ein funktionierendes Hello-World unter DosBox mit DJGPP und einem dazu passenden und funktionierenden GNU C-Compiler (GCC). Ihr glaubt gar nicht, wie viel Zeit dabei draufging. Die letzte MSDOS-fähige Version der Allegro-Bibliothek konnte ich damit problemlos kompilieren. Und das musste ich leider auch, da nichts von der fertig gebauten Allegro-Bibliothek einbinden konnte.

Ich bin immer noch nicht über ein "Hello World" hinaus. Das liegt aber daran, dass ich mit dem GNU Compiler nicht vollends zufrieden bin - allein aus nostalgischen Gründen. Denn ein simples "Hello World" kompiliert schon recht lange und erzeugt eine über 78800 Bytes großen Datei (nur stdio.h ist eingebunden). Zum Vergleich: derselbe Code kompiliert ohne Optimierungen mit Turbo C mindestens 8x schneller bei einer nur 8362 Bytes großen Executable. Mit Watcom erhalte ich eine 8698 Bytes große hello.exe.

Also Zähne zusammenbeißen und noch einmal mit dem Watcom-Compiler versuchen. Ich habe ja den Quellcode von Allegro.

Als ich mit Watcom startete, gab es erneut einen kleinen Dämpfer. GCC und ein GNU Make müssen für das Bootstrapping installiert sein. Und ich hatte das Zeug gerade eben noch von der Platte gefegt, um Platz zu schaffen. Das wmake vom Watcom Compiler ist offenbar zu beschränkt und daher muss wohl das GNU make ran. Damit wird dann eine Runner.exe per GCC gebaut werden, um anschließend die Arbeit irgendwie an den Watcom-Compiler zu delegieren. So ganz blicke ich da noch nicht durch.

Derzeit hängt die Kompilierung an der asmdef.c. Es sieht so aus, als hätte DosBox so seine Schwierigkeiten. Denn mal schließt sich DosBox sang- und klanglos, mal erhalte ich einen SIGSERV-Fehler. Ich versuche es noch mal mit dem vorigen Start des Extender go32-v2...:


Auf dem Bild sieht man übrigens nicht den ersten Schritt vom Make, sondern er führt quasi fort - nachdem ich noch ein paar Einstellungen in der DosBox vorgenommen habe. Make hat also definitiv seine Vorteile gegenüber einzelnen "gebatchten" gcc-Kommandos.

Turbo C kann ich leider nicht mit Allegro verwenden. Das ganze Build-System ist absolut nicht darauf ausgerichtet. Ich bräuchte gefühlt Wochen, um das hinzubekommen. Und dann kann mir noch die leicht andere C-Syntax - meist in Sachen far/near-Pointer - einen Strich durch die Rechnung machen. Das ist ein ganz eigenes Projekt. Turbo C würde ich nur verwenden, wenn ich auf "Bare Metal" gehe, wozu ich grundsätzlich auch Bock hätte. Ein kleines Spielchen nur mit Grafik dürfte damit jedenfalls recht schnell gemacht sein (habe mir mal die Speicherstruktur für VGA angeschaut). Aber sobald Sound dazukommt, wird's echt komplexer. Und dann kommt da irgendwann die 16-Bit-1-Meg-Grenze, wenn ich mehr machen möchte. Und schon bin ich im Protected Mode. Die Zeit würde ich dann doch lieber mit der Programmierung auf dem Atari ST vergeuden.

Sollte ich das Bauen mit OpenWatcom nicht mehr hinbekommen, ist die Entwicklungsumgebung mit DJGPP + GCC 4.21 + Allegro 4.2.3 gesetzt. Dann sind die Executables halt ein paar Kilobytes größer.

Fun Fact: Der von Watcom mitgelieferte Editor VI unter MSDOS hat mich als vi-Fan (set -o vi) entzückt, aber ist im Vergleich zu TurboC eben nur ein Editor anstatt eine auf DOS-basierte IDE. Eine richtige IDE erhalte ich mit Watcom nur, wenn ich das unter Windows 3.1 betreibe, das ich ebenfalls unter der DosBox installiert hatte. Aber ich muss euch sagen, ich komme mit den Fenster-in-Fenster-Interface (MDI) absolut nicht mehr klar


Update
Der Build mit dem Watcom-Compiler ist erfolgreich! Das war ein hartes Stück Arbeit. Ich vermute, das hat in der letzten Zeit so noch niemand unter DosBox gemacht. Das Build-Skript ist nämlich sowas von fehlerhaft. Oft musste ich händisch eingreifen und manches manuell und in korrigierter Form ausführen. Pfade mussten des Öfteren im Makefile angepasst werden, weil die normalen Slashes verwendet wurden. Ein einziges Mal musste ich eine Quellcode-Datei (display.h) anpassen. Hier musste ich ein typedef ausbessern. Die vielen Docs konnten nicht gebaut werden. Händisch wollte ich das Ganze nicht machen, da ich die Dokumentation ja bereits mit DJGPP + GCC gebaut hatte (ich lösche nichts mehr ).

Die meisten Beispiele funktionieren, womit bewiesen wäre, dass der Build tatsächlich erfolgreich war. Die Beispiele, die einen Mauszeiger und damit die Maus verwenden, frieren allerdings ein. Das dürfte sich bestimmt mit der richtigen mouse.com aus einem MS-DOS lösen lassen. MIDI-Musik klingt ebenso aus dem Lautsprecher.

Meine nächste Aufgabe: Das Pixelor-Logo als Sprite bewegen, vielleicht sogar schon mit einer Tastatur- oder Joystickabfrage. Mal sehen.

Zitat von »henrikf«

Viel Spaß übrigens bei der VGA-Programmierung.

Das ist ja gerade der Grund, warum ich mich entschieden habe, auf eine Bibliothek zu setzen, die mir das alles abnimmt: Allegro. Denn das ganze VGA-Universum ist nicht für Spiele gedacht, sondern für den professionellen Einsatz *hüstel*

Ein Pixel setzen geht dann nämlich einfach so:


Und das Ganze jetzt mit Direktzugriff:


Die beiden Quellcodes sind noch nicht getestet, aber das dürfte zumindest das Prinzip wiedergeben. Bei Allegro (oberster Source Code) habe ich mit weniger Zeilen quasi einen (halbgaren) Double Buffer drin. Ich müsste nur noch ein entsprechendes Timing einführen und zur richtigen Zeit switchen bzw. blitten. Im unteren Code greife ich direkt auf den Memory zu. Ich könnte das auch über eine BIOS-Funktion Interrupt 0x10 (in Dezimal: 16) machen, aber das wird gemäß Recherche um ein vielfaches langsamer sein, ist aber wohl kompatibler und wird gerade bei Bootmanagern gerne eingesetzt.

Ich hoffe, dass ich mit diesem Thread nicht den eigentlichen Themenrahmen von Pixelor sprenge. Das dürfte zwar nicht jeden Stammuser - zumindest im Detail - interessieren, aber ich hoffe, dass es den einen oder anderen Interessierten als Neuzugang dauerhaft auf Pixelor bringt. Und ein paar mehr Einträge ins Forum tut Pixelor sicherlich auch gut

Meine erster kleiner Test mit Allegro unter der DosBox! Läuft garantiert nicht unter einem Windows neuer als 98. Ich lehne mich weit aus dem Fenster und behaupte, dass es auf einer echten MS-DOS-Maschine ebenso funktionieren wird.

Hier ein erster Eindruck:


Das Sprite wird mit den Cursor-Tasten gesteuert und ein Abbruch erfolgt mit der ESC-Taste.

Wer sich den übersichtlichen Quellcode anschauen oder einfach nur die Exe (in der DosBox oder auf einem MS-DOS-PC) ausführen möchte, wird hier fündig:
https://github.com/oberning/allegro_test