Oh Mann, Leute, Ihr schreibt hier so viel, daß man überhaupt nicht mitkommt...
[I/O, Video]
Danke für die vielen Beiträge und Beispielbilder zur Verdeutlichung. Allerdings habe ich den Eindruck, daß hier ein Mißverständnis vorliegt.
VGA bedeutet das, was auch für den Commander X16 gilt:
"at a fixed resolution of 640x480@60Hz"
Das heißt, daß alle Bilder immer mit genau dieser Auflösung ausgegeben werden: 640 Pixel horizontal. Oder so wie es schon in den alten Schriften der heiligen VGA von Antiochia steht: "640 Pixel sind es, und bis 640 Pixel sollst Du zählen. Nicht 720. Auch nicht 576, es sei denn, Du zählst weiter bis 640. Die 1920 scheidet völlig aus."
Das heißt, daß alle Bitmaps automatisch eine Breite haben von 640/320/160/80/40 Pixeln. Auch wenn man als Programmierer eine niedrigere Auflösung wählt, z. B. von 160, muß der Videocontroller dafür sorgen, daß daraus wieder 640 Pixel horizontal werden, denn das und nur das ist der Standard.
Jedem steht es natürlich frei, von dieser Bitmap nur einen Teil zu verwenden und in den ungenutzten Pixeln der Bitmap einen beliebigen eigenen Rand zu malen, meinetwegen auch mit Blümchen oder Wölkchen. Aber es ändert nichts daran, daß das Bild, das an den Fernseher/Bildschirm geschickt wird, weiterhin ein Bild ist im Format 640x480. Was der Fernseher dann mit diesem Bild macht, ist allein seine Sache. Er kann es in die Breite ziehen oder schwarze Balken anzeigen oder sonstwas.
Aus diesem Grunde würde ich RexRetro mit seiner Einschätzung recht geben, wenn er eine softwaremäßige Auflösung von 640x360 vorschlägt. DIese kann man später, wenn man über einen HDMI-Anschluß verfügt sehr leicht in HD (*2) oder FullHD (*3) umwandeln. Das hätte natürlich auf alten VGA-Bildschirmen den Nachteil, daß auf diesen dann ein großer schwarzer Rahmen oben und unten zu sehen ist, aber damit könnte ich vielleicht leben.
Als einzige Möglichkeit für eine andere hardwaremäßige Auflösung sehe ich noch 640x400@70, da diese horizontal die gleiche Frequenz aufweist wie 640x480@60. Dann wäre auf einem VGA-Bildschirm der Rand etwas schmaler, aber dafür die Pixel in der Höhe gestreckt. Wie sich das auf eine Darstellung auf einem 16:9-Gerät auswirkt, und ob andere Geräte überhaupt in der Lage sind, diese Auflösung sauber zu erkennen, weiß ich nicht.
So oder so handelt es sich bei einer VGA-Ausgabe um eine Übergangslösung bis wir alle über fette FPGAs mit eingebautem HDMI-Anschluß verfügen. Für eine Emulation spielt es sowieso keine Rolle, es sei denn man möchte auch am Laptop FullHD sehen.
Von daher würde ich für die von RexRetro genannten Auflösungen plädieren, da sie mir nach einiger Überlegung noch am praktikabelsten erscheinen. Grundsätzlich gilt, daß man auch als Programmierer lieber mehr Zeichen in der Breite hat als in der Höhe. 80 Zeichen halte ich auch beim Programmieren für ein Muß. Die Anzeige des PICO-8 ist mir persönlich viel zu schmal. Was die Zeichenhöhe anbelangt, so hat RexRetro ebenfalls damit recht, daß es sich ja um einen Bitmap-Modus handelt und nicht um Zeichensatz. Es ist daher überhaupt kein Problem, einen Font von 7 oder 8 oder 9 Zeilen Höhe zu verwenden. Bei 360 / 8 hätte man 45 Textzeilen zu 8. Bei 180 / 8 ergäbe das 22 Textzeilen mit einem Rest von 4 Zeilen, die man für eine Umrandung etc nutzen könnte. Nebenbei wäre eine zusätzliche leere 9. Zeile zwischen den Textzeilen sogar ganz gut für eine bessere Lesbarkeit. Daher denke ich nun, daß man sich mit sowas arrangieren kann.
Was meinen Videocontroller anbelangt, so ist bei diesem wie früher beim AppleII die Datenmenge pro Auflösung nicht stets gleich, sondern variabel. Der Apple//e kannte z. B.
- 40x48 LowRes (ca. 1 kb)
- 80x48 Double LowRes (ca. 2 kb)
- 280x192 HighRes (ca. 8 kb)
- 560x192 Double HighRes (ca. 16 kb)
Das heißt in meinem Fall, daß man horizontal eine Auflösung auswählen kann von 40, 80, 160, 320 oder 640.
Vertikal kann man auswählen aus 45, 90, 180, 360.
Davon unabhängig ist die Anzahl der Farben: 2, 4 oder 16. Eine Farbpalette von 256 Farben würde ich ausschließen, weil ich sie a) nicht wirklich für Retro halte, und b) das Pixeln dadurch völlig anders wird (wie Retrofan oft beschrieben hat). Bei noch mehr Farben (HiColor 65536) kommt noch hinzu, daß die Datenmenge viel zu groß wird für a) die CPU, b) den Speicher, c) den Datenbus. Solche Auflösungen benötigen eine eigene Videokarte mit abgetrenntem Videoram. Das hat für meinen Geschmack dann überhaupt nichts retromäßiges mehr.
Kurz: Nach letztem Stand der Dinge wären mögliche Auflösungen u. a.:
- 640x180x2
- 320x360x4
- 40x45x16
...
[Ram]
Mein persönliches Design geht aus von 512 kb Ram. Das ist - wie Daybyter schreibt - die Menge an SRam auf dem Shield und zufällig das, was der Amiga500 auch hatte. Mehr Speicher wird man für einen Retrorechner eher nicht benötigen, da man heutzutage die Möglichkeit hat, sehr schnell neue Daten von SD-Karte nachzuladen (kein Vergleich zum 1541-Laufwerk aber auch den Diskettenlaufwerken des Amiga oder AtariST).
Das Ram ist über einen 16 Bit-Datenbus angebunden (256x16). Ein breiterer Datenbus würde einen Haufen mehr Anschlüsse (Pins) am FPGA erfordern, die wir aber nicht haben. 16 Bit sind jedoch ausreichend, damit bei einer Auflösung von 640@16 Farben sich Videocontroller und Prozessor nicht zu häufig in die Quere kommen. Zur Erinnerung: Am Amiga500 bedeutete 640@16 Farben, daß der Prozessor um nahezu die Hälfte gebremst wurde.
[Sprache. Zeileneditor]
1.) Bitte keine Zeilennummern.
2.) Bitte keine Zeilennummern.
3.) Bitte keine Zeilennummern.
4.) Bitte keine Zeilennummern.
5.) Bitte keine Zeilennummern.
Was habt Ihr gegen einen Texteditor? Warum wollt Ihr Euch mit einem Screeneditor herumquälen? 
Als jemand, der damals[tm] seine ersten Programmierschritte auf dem AppleII mit UCSD-Pascal und einem Texteditor gemacht hat, fand ich diese Fixierung auf den umständlichen zeilenorientierten Screeneditor immer als etwas merkwürdig. Da auch sämtliche Assembler auf dem C64, die ich so kannte, diese krude Eingabemethode verwendeten, habe ich mir schon damals[tm] einen kleinen 80 Zeichen-Editor (virtuelle 80 Zeichen realisiert als scrollendes 40 Zeichen-Fenster) für die Assemblerprogrammierung gebastelt. Viel, viel leichter zu bedienen mit viel mehr Übersicht über die Programmstruktur. Von daher habe ich nicht vor, unter dieses Niveau von damals[tm] zu gehen. Ein Zeileneditor ist für mich persönlich komplett ausgeschlossen.
[Sprache, Direktmodus]
Die gleiche Frage wie beim Zeileneditor drängt sich auch hier auf: Wozu braucht man das? Um DOS-Befehle einzutippen? Ernsthaft? Auch das haben wir damals[tm] beim UCSD-Betriebssystem (von 1979!) schon mit einem simplen Menüsystem (genannt "Filer") gemacht: "L" für "List Directory". "C" für "Change fIle name" usw. Wozu soll man immer irgendwelche Befehle eintippen? Das war damals[tm] schon nerviger Blödsinn und allein den Tatsachen geschuldet, daß a) es kein Platz im Rom gab, um ein anständiges Menüsystem unterzubringen, b) der C64 gar kein Betriebssystem kennt, sondern jedes Gerät seine eigenen Befehle hat, die man (noch umständlicher) erst dahin schicken muß. Nicht ohne Grund haben damals[tm] schon zig Steckmodule diese Befehlstipperei abgelöst durch einfaches Drücken einer Funktionstaste. Will man wirklich davor zurückfallen? Also, wer's mag, kann sich ja sowas programmieren, den Sinn darin sehr ich allerdings nicht.
[Sprache, Editor]
Man erkläre mir bitte den Unterschied zwischen
a) dem Tippen von "RUN" <RETURN>
und
b) dem Drücken auf die <F1>-Taste.
Beide Male wird das aktuelle (im Editor vorhandene) Programm gestartet. Ob dazu gehört, daß es vorab tokenisiert oder gar vollständig kompiliert wird, ist dabei völlig egal. In beiden Fällen benutzt man die Tastatur, um das Programm zu starten, und einmal drückt man mehr Tasten und das andere Mal nur eine.
Gerade wenn man Programmierer ist, wird man Methode b) nach einiger Zeit deutlich bevorzugen, weil einfach schneller und nicht so umständlich: Man tippt einen Text im Texteditor ein, drückt auf <F1>, das Programm wird gestartet, und am Ende kehrt man automatisch in den Editor zurück. Simpler geht es doch gar nicht. Wozu sich das Leben unnötig schwer machen?
[Sprache, Interpreter/Compiler]
Idealerweise wäre die Sprache geeignet sowohl für einen Interpreter auf der Zielmaschine zum unmittelbaren Entwickeln/Austesten als auch für einen Compiler z. B. als Cross-Compiler auf dem PC. Schließlich wurde auch damals[tm] schon Basic häufig (in Bytecode) übersetzt.
Voraussetzung dafür aber ist, daß die Sprache
a) an sich leicht übersetzbar/interpretierbar ist. D. h. es gibt nur wenige spracheigene Schlüsselwörter und Konstrukte. Grafikbefehle o. ä. sind keine sprachinternen Befehle, sondern können nach Belieben durch Bibliotheken ergänzt werden. Das setzt voraus, daß sie die gleiche Syntax aufweisen wie selbstdefinierte Prozeduren/Funktionen. (Gegenbeispiel Basic: Hier gibt es häufig einen Mischmasch von Klammern und Nichtklammern wie "line 0,0 to 279,191" und "chr$(13)" oder "sin(1234)".)
b) keine Features aufweist, die sich nur per Laufzeit ergeben. Das "NEXT" in Basic ist so ein Fall. Der Aufwand für den Compiler, herauszufinden, auf welches FOR sich dieses NEXT bezieht, ist immens. Bitte nicht. Das kann man auch anders und besser lösen.
c) Variablen haben einen festen Datentyp. Dieser wird deklariert, damit Interpreter und Compiler ihn in ihren Bezeichnerbaum eintragen können und sofort bescheid wissen, wie sie vorgehen müssen, wenn sie auf den Bezeichner treffen.
Nebenbei: (Klassisches Retro-)Basic hat m. A. n. neben den Zellennummern noch ganz andere Nachteile:
1.) Es gibt keine lokalen Variablen. Ganz schlecht für eine strukturierte Programmierung.
2.) Es gibt keine Parameter bei Funktionen oder Prozeduren.
3.) Es gibt keine Trennung zwischen INTEGER und FLOAT/REAL bzw. CHAR und STRING (sehr ungünstig fürs Kompilieren).
4.) Es gibt keinen boolschen Datentypen.
5.) Es gibt keine Verbundstrukturen.
6.) Es gibt keine getrennten Namensräume und damit auch keine vernünftige Möglichkeit für eine Bibliothek.
7.) Es gibt keine public/private-Markierung....
Okay, an dieser Stelle sollte man besser aufhören, weil es einfach zu viele Dinge gibt, die es in Basic nicht gibt, aber für eine saubere und auch schnellere Programmentwicklung nötig wären.
Einen Compiler direkt auf der Zielmaschine laufen zu lassen, halte ich nicht für unmöglich, aber eher unrealistisch. Vielleicht könnte man den VBCC-Compiler mit sich selbst kompilieren und dann auf der Zielmaschine zum Laufen bringen, doch vermute ich mal, daß er sich mit 512 kb nicht begnügen wird. Die Zwischensprache, auf der heutige Compiler aufbauen, braucht pro Node schon einen so großen Haufen Bytes, daß man mit einem nativen Compiler nur sehr kurze Programme übersetzen könnte. Generell halte ich es aber für eine gute Idee, den VBCC-Compiler als möglichen Sprachencompiler heranzuziehen, vorausgesetzt sein Erschaffer willigt ein.
Da sich C jedoch als Interpreter- oder Einsteigersprache weniger gut eignet, hatte ich wiederholt eine Oberon-ähnliche Sprache vorgeschlagen. Sie ist einerseits Basic sehr ähnlich, andererseits aber mächtig genug auch für sehr große Programme. ZeHas Beispiel einer FOR-Schleife sähe darin z. B. so aus:
FOR i := 1 TO 10 BY 2 DO
...
END
Nun kann man sich darüber streiten, ob es BY oder STEP heißen soll, aber daran sollte es eigentlich nicht scheitern, oder?
Was die Machbarkeit anbelangt, so habe ich vor vielen Jahren solch eine Sprache bereits auf dem PC als Interpretersprache entwickelt. Das geht also. Wie hoch die Geschwindigkeit auf der Zielmaschine dann sein wird, kann man jetzt noch nicht sagen; ich gehe aber davon aus, daß es deutlich schneller wird als BASIC 2.0. Ein Schritt, den man auf jeden Fall vorher machen sollte, ist die vollständige Tokenisierung des Programmtextes, d. h. nicht nur Bezeichner werden in Tokens umgewandelt wie bei BASIC 2.0, sondern auch alle Konstanten (Zahlen, Zeichen, Strings...) Dabei kann je nach Aufwand auch eine Teilprüfung auf syntaktische Korrektheit ausgeführt werden, so daß diese beim Interpretieren wegfallen kann. Wenn also die Tokens bereits besser vorbehandelt sind als beim BASIC 2.0, dürfte bei einer ca. 8 Mhz-CPU (in Relation zum 68000) genügend Power da sein, um damit auch kleine Spiele schreiben zu können.
[Rom]
Generell gilt für Sprache, Betriebssystem usw., daß sich diese nicht im Rom befinden, sondern auf SD-Karte und damit beliebig austauschbar sind. Und ja, dieses Konzept gab es auch schon damals[tm], nämlich wieder auf dem AppleII, der sowohl DOS 3.3 (hauptsächlich für Basic) als auch das UCSD-System (für Pascal oder Fortran) oder ProDOS (für fortgeschrittene Applikationen o. ä.) booten konnte.
Wichtig: Ein Flashrom hängt zumeist nicht direkt am Datenbus. Der Prozessor kann nicht direkt darauf zugreifen, um sich z. B. Befehle zu holen. Stattdessen ist das Flashrom über eine serielle Leitung (SPI) mit dem Rechner verbunden. Um darauf zuzugreifen, muß der Prozessor erst einen Befehl an das Flashrom senden und kann dann anschließend die Bytes Bit für Bit in Empfang nehmen. Aus diesem Grunde kopieren die Retrosysteme ihr "Rom" nach dem Einschalten in ein Ram. Ob man aber jetzt die Daten aus einem Flashrom lädt oder von SD-Karte, spielt keine Rolle. Das Booten wird dadurch nicht langsamer und bleibt genauso schnell wie beim C64, d. h.: Einschalten und da.
Mein Vorschlag wäre daher:
a) Ein kleines Autostartrom sucht nach einer SD-Karte als bootbares Medium.
b) Ist eine SD-Karte mit speziellem Bootbereich vorhanden, wird letzterer geladen und gestartet.
c) Wird kein bootbares Medium gefunden, kann aus dem Flashrom eine Ersatzdatei geladen werden, die dann gestartet wird.
Noch einmal kurz zusammengefaßt:
1.) Sowohl die Hardwarebasis (FPGA, Emulator..) ist letztendlich irrelevant.
2.) Die Wahl der Sprache ist ebenso irrelevant. Es kann Basic geben oder Forth oder C oder Oberon...
3.) Das Betriebssystem ist irrelevant. Es kann mehrere verschiedene Lösungen geben, einmal vielleicht eine Art CP/M oder andermal eher etwas wie GEOS.
Das Einzige, was zählt, ist, daß es $irgendjemanden gibt, der diese Dinge entwickelt.
Auf keinen Fall würde ich aber irgendeine Programmiersprache oder ein OS als verbindlich vorschreiben, weil es genau das ist, was mich an den PCs (oder Retrocomputern, die meinen, sie müßten sich so verhalten) nervt. Vielmehr soll jeder sich selbst eine Sprache/ein OS/einen Emulator/einen FPGA zusammenbasteln können. Vielfalt statt Einfalt. Das ist die Freiheit, die ich mit alten Retrorechnern verbinde, und die ich gerne wieder haben möchte. Darum geht es mir.
) Bei der C64-Version würde ich aber heute anders vorgehen und diese zunächst mit einem automatischen Disassembler (sowas wie Deinem Z80-Disassembler) vorbearbeiten. Was würdest Du denn anschließend mit dem Code anstellen wollen?
Track 35, Sektoren 1 bis 6... Welch Wunder, daß bei den anderen Versionen die Demo nie funktionierte. Da die Sektoren bei Dir nun richtig übernommen werden, kann man wohl davon ausgehen, daß die Demo jetzt korrekt abläuft. 
Disassemblierung ist somit die einzige Möglichkeit zu erfahren, wie die Programme von damals funktionieren. Nur als Beispiel: Neulich habe ich die Grafikroutinen von "Mission Asteroid" (sowie weitere ähnliche Spiele von Sierra Online) disassembliert und dabei festgestellt, auf welch interessante Art und Weise sich der/die Programmierer dabei von hinten ins Knie geschossen haben. All dieses Programmierwissen wird wohl verloren gehen, was auch daran liegt, daß es zum einen kaum Interesse daran gibt. Der Kreis derer, die sagen "Oh, schön zu sehen, wie das funktioniert, wollte ich schon immer mal wissen..." ist halt sehr gering. Zum anderen steht auch stets die Frage im Raum, inwieweit solch ein archäologisches Disassemblieren mit Zurschaustellung des disassemblierten Codes legal ist. Persönlich hätte ich mir schon längst gewünscht, daß ein Magazin wie "Return" in einer Kolumne diverse alte Programmiertechniken bespricht und darstellt (ohne den Aspekt, daß sie jetzt besonders gut sein müssen). Selber könnte ich wahrscheinlich Tonnen an Material dafür liefern. Doch neben der mangelnden Nachfrage gibt es wohl auch den rechtlichen Aspekt, der dagegen spricht.
Übrigens auch die erste mir bekannte Version, bei welcher die Demo einigermaßen funktioniert. Andere Versionen stürzten an der Stelle ab, oder die Demo hängte sich zu Beginn auf.
Aber ernsthaft: Wäre es nicht vielleicht sinnvoll, dem Thread ein bißchen mehr Struktur zu geben und z. B. mal Module zu bestimmen, über die dann ein wenig sauberer getrennt diskutiert werden kann? Man muß ja nicht gleich für jedes Modul einen eigenen Thread starten (halte ich für keine gute Lösung). Doch es könnte u. U. helfen, wenn man die wichtigsten Definitionen festhält, daraus Unterbereiche (Module) ableitet und Posts beim Schreiben danach kennzeichnet, z. B. "[Grafik]". Sowas in der Art. Nur so als Vorschlag...
