So! Jetzt habe ich ja zumindest mal einen Namen, da ich ja ein Projekt angelegt habe und dafür schon mal einen Namen vergeben musste. Dieser Thread bezieht sich auf mein Posting aus Neuer Retro-Computer im 8-Bit Style und soll dazu dienen etwas Brainstorming zu betreiben für die Umsetzung. Allgemeine Diskussionen wären besser weiter im anderen Thread aufgehoben, hier soll es eben um die konkrete Umsetzung gehen. Designvorschläge für eine technische Umsetings oder ähnliches sind daher durchaus willkommen und auch erwünscht.
Das Projekt ist auf github gehostet: https://github.com/skeetor/chronos. Derzeit ist es aber noch nicht mehr als ein Hello World, weil ich erstmal die grobe Projektstruktur festelegen wollte und ein wenig experimentieren um ein Gefühl dafür zu bekommen, wie performant das sein kann, und verschiedene Dinge auszuprobieren. Angedacht ist das Projekt als C++ mit QT5. Im Source habe ich eine Technik implementiert die SEHR den Bildschirmspeicher schon mal simuliert und das sieht zumindest von der Performance ganz ok aus. Allerdings ist da noch keine zusätzliche Implementierung drin, also kann sich das auch noch ändern.
Das Projekt habe ich erstmal unter Debain Stretch umgesetzt, sollte daher auch relativ problemlos auf den Raspberry übertragbar sein. Ausserdem will ich das auch unter Windows laufen haben und werde das auch dementsprechend von vornherein mit einplanen.
Das Ganze ist so angedacht dass ich eine Hardwareumegbung simuliere, die in etwa dem entspricht was man auch von C64 und Co aus der Zeit kennt. Es soll sich inerhalb der Maschine dann auch so verhalten, dass man das zumindest theoretisch auch in einen echten Chip giessen und verbauen könnte (auch wenn das vermutlich nie passieren wird :)). Flaches Speichermodell, I/O Bereich der direkt angesprochen wird und Dinge wie z.B. Tastatur, Parallel Port, Grafi, etc. ansteuert. Was ich NICHT emulieren will ist die CPU, da das sonst deutlich komplexer wird. Heisst also, als CPU wird das eingesetzt was auf der jeweiligen Platform genutzt wird. Bedeutet also konkret, auf dem Raspberry läuft eine ARM CPU, unter Windows dann eben ein x86 usw.. Sollte ich eine CPU emulieren, würde ich ein 68k Derivat anstreben, da mir das am besten gefällt. Für den Endanwender hätte das erstmal keine grosse Auswirkung. Innerhalb des BASICs merkt man sowieso nicht welche CPU da drauf ist. Für Assemblerrpogrammierer hätte das natürlich die Konsequenz dass sie eben wissen müssen auf welcher Hardware das laufen wird, aber so ist das eben mit ASM.
Für Compilersprachen, wäre das Problem nicht so gravierend, weil man dann eben für verschiedene CPUs kompiliert, welches dann auf der jeweiligen Platform lauffähig wäre. Was man dafür allerdings zur Verfügung stellen müsste, wäre die grundlegenden Funktionen der C Bibliothek, zusammen mit dem Initialisierungsteil der bei C/C++ implizit dabei ist. Aber das ist sowieso noch in weiter Ferne, also muss ich mir da noch keine grossen Gedanken drüber machen. Das wäre auch eher ein Punkt der relevant würde, wenn das Teil tatsächlich auf Interesse stossen würde.
Im Moment habe ich angedacht eine Auflösung von max. 640x400 anzubieten. Das ganze kann halbiert werden, so dass man also dann
320x200
320x400
640x,200
640x400
als Auflösung zur Verfügung hat. Das wäre dann also für 40x25 bis 80x40 Zeichen Textmodus. Der Grafikmodus hat dann die gleiche Auflösung, mit 2, 16 und 256 Farben. Möglich wäre auch n noch was dazwischen (64?). Allerdings stellt sich mir auch die Frage, ob jemand z.B. 16 Farben überhaupt benutzen würde, wenn er auch 256 haben kann? Insofern stellt sich also die Frage ob das einen Unterschied machen würde und unterstützt werden müsste. Oder ob es reicht wenn man 2 und X Farben hätte (also dann nur 16 oder eben 256).
Das ganze läuft ja in einem QT Fenster, entweder als Fullscreen oder im Fenstermodus. Die Auflösung wird dann entweder "hart" gesetzt als Bild im Fenster mit der nativen Auflösung, dann müsste man vermutlich Scrollbars verwenden. Oder es wird skaliert, dann hätte man im besten Fall auch einen Rahmen wenn die Fensterauflösung nicht ganzzahlig teilbar ist. Persönlich gefallen mir die Scrollbars nicht so gut. Ich gehe aber davon aus, dass man auf jeden Fall skalieren können muss, da auf einem modernen Bildschirm bei hoher Auflösung ein Bild von 320x200 schon SEHR winzig wäre.