letzter Beitrag von Retrofan am
REU schneller, da DMA-Chip.
GeoRam langsamer, da kein DMA-Chip vorhanden.
O.K. die 64'er hatte nicht immer recht.
Wenn es um das kopieren/austauschen von grösseren Speicherbereichen (nicht selten bei GEOS), ist die REU schon schneller.
Intressant finde ich auch das in der GeoRam Code (Programme, Berechnungen?) ausgeführt werden können.
Ohne weitere Maßnahmen ist die Codelänge dann aber jeweils auf 256 Byte beschränkt.
Finde ich jetzt sehr interessant.
Hatte es auch so in Erinnerung:
REU schneller, da DMA-Chip.
GeoRam langsamer, da kein DMA-Chip vorhanden.
O.K. die 64'er hatte nicht immer recht.
Hängt vom Anwendungszweck ab.
Du willst eine Hires-Bitmap im Speicher haben?
Die 8000 Bytes kann die REU mit 1 Takt/Byte rüberschaufeln, 8000 Takte gesamt, ungefähr die Rasterzeit eines halbe Frames.
Mit GEORam muss man die Daten häppchenweise sichtbar machen und von Hand rüberkopieren. 10 Takte/Byte scheinen mir angemessen, ~80.000 gesamt, die Zeit von 5 Frames. Flackerfreie Filme anzeigen geht damit nicht!
Du willst was aus dem Speicher entpacken oder kleine Datenpakete verarbeiten?
Die REU muss die Daten erstmal rüberkopieren, sagen wir mal in Häppchen von 256 Bytes, macht 256 Takte.
Mit einer GEORam sind die Daten dann einfach bereit.
Zum Thema hier könnte die GEORam praktisch für Multiplikationen, Adressumrechnungen, Raumschiffdaten, Tabellen zum Linienziehen sein.
Die REU könnte schnell den Bildschirm löschen. Und aus der Fähigkeit, internen und externen Speicher zu vergleichen kann man bestimmt auch noch was machen.
...erwähnte "Tiefensuche" wird meistens so durchgeführt, daß bei einem Polygon der Mittelwert aller Z-Werte berechnet wird. Bei einem Rechteck ... kann in Einzelfällen zu Fehlern kommen, d. h. ein eigentlich nicht sichtbares Polygon wird über ein anderes eigentlich sichtbares gemalt...
Ja, in meinem Anwendungsfall tritt der Fehler praktisch ständig auf. Ich muss noch mal die alten 64er-Sonderhefte durchgehen, vielleicht findet sich da was.
Ich versuche grad, einen Z-Strahl durch sich überlappende Stellen zu schiessen und die Tiefe dort zu verwenden. Aber da stolpert man auch von einem Sonderfall in den nächsten.
Ich weiß auch nicht, ob das mit einem EOR-FIller wirklich möglich wäre. (Es werden alle vier Farben und deren Mischmuster verwendet.) Daher haut die Malroutine die Bytes einfach nacheinander in die Bitmap.
Ich überlege, wie ich das wohl angestellt hätte...
Im innersten wäre das schnelle Zeichnen waagerechter Linien über ganze Charbreiten.
Drumherum die krummen Anfangs- und Endechars und Sonderfall kurzer Linien.
Drumherum das Durchlaufen 2er Tabellen mit Anfangs- und Endpunkten. Ich gehe davon aus, dass zu wenig Register da sind, um gleichzeitig 2 Linien zu berechnen und auch noch zu zeichnen.
Drumherum das Berechnen der linken Linie(n) und der rechten.
Drumherum das Zeichnen eines Dreiecks mit dem erkennen der Sonderfälle.
Unschlüssig bin ich mir über das Löschen.
Ich denke, grobe Schwarze Rechtecke je Objekt dürften OK sein, braucht nur MinMax über die Punkte eines Objekts. Sowas wie ein MinMax je Bildschirmzeile scheint mir mehr Overhead zu machen, als man beim Löschen einspart.
Da war doch auch mal in einer C=-Hacking-Ausgabe eine schnelle Hires-3D-Routine mit gefüllten Flächen, muss ich noch mal raussuchen.
@Ace: Ja, bei bestimmten Dingen ist die GeoRAM langsamer als die REU von Commodore. Bei anderen schneller. Aber beide sind auf jeden Fall schneller als etwas von Tape oder Disk nachzuladen. Damit kann man mit beiden einen flüssigeren Ablauf erreichen, wenn es im Speicher eng wird.
Und beide sind recht weit verbreitet, wenn man es in Relation zu irgendwelchen Beschleunigerkarten oder -umbauten sieht.
Und weiter kann GeoRAM mit Standard-Bauteilen nachgebaut werden. Notfalls sogar auf einer Lochrasterplatine.
Zum Thema hier könnte die GEORam praktisch für Multiplikationen, Adressumrechnungen, Raumschiffdaten, Tabellen zum Linienziehen sein.
Die REU könnte schnell den Bildschirm löschen. Und aus der Fähigkeit, internen und externen Speicher zu vergleichen kann man bestimmt auch noch was machen.
Für Multiplikationen benutzt man heutzutage am besten die Quadrattabellen, da das Verfahren am schnellsten ist. Diese benötigen aber 2Kb. Unter Adreßumrechnungen kann ich mir nichts vorstellen. Falls Du damit Adreßtabellen meinst wie z. B. für die Anfangsadressen einer Bildschirmzeile, so wäre die Handhabung viel zu langsam, denn Adressen bestehen aus 2 Bytes. Das macht es notwendig, die GEORam beim Holen der Adresse umzuschalten, was viel zu langsam wird. Die schnellste mir bekannte Routine zum Linienziehen auf dem C64 benötigt keine Tabelle. Andere Formen des Linienziehens benötigen meist mehr als nur eine Tabelle, so daß auch hier wieder langsam umgeschaltet werden müßte. Das Löschen pe REU wäre möglich. Für einen Vergleich habe ich jedoch noch keinen Anwendungsfall gesehen.
Ich überlege, wie ich das wohl angestellt hätte...
Ja, so ungefähr, jedoch würde ich die Linienberechnung gleichzeitig beim Füllen des Polygons vornehmen. Das Speichern der linken und rechten Grenze in ein Array und nachträgliches Wiederhervorkramen dürfte langsamer sein als eine Berechnung on-the-fly.
Das Ziehen zweier Linien gleichzeitig wäre aufgrund der möglichen großen Differenzen in der Länge mit zuviel Overhead verbunden, als daß es sich lohnen könnte.
Unschlüssig bin ich mir über das Löschen.
Die Methode, nur die ausgesuchten Bereiche des Bildschirms zu löschen, die vorher gemalt worden sind, sieht zu Beginn recht praktisch und vor allen Dingen schnell aus. Tatsächlich ist sie aber zu kompliziert und im Mittel auch zu langsam.
Der Nachteil hierbei ist, daß in zwei Listen jeweils für beide Bitmaps des Double-Bufferings die Rechtecke festgehalten werden müssen. Diese Rechtecke könnten sich z. B. ergeben aus den Grenzwerten aller Polygone eines Objekts. Dafür müssen also erst einmal diese Grenzwerte ermittelt werden.
Beim Löschen der Rechtecke sieht man sich wieder mit dem ungünstigen Speicheraufbau der Bitmap konfrontiert. Bei einer horizontalen Linie befinden sich die Bytes stets mit einem Abstand von 8 auseinander, so daß man nicht einmal mittels einer einfachen Schleife über ein Indexregister alle Bytes einer ganzen Zeile erreichen kann, sondern das Highbyte des Zeigers an einer Stelle miterhöhen muß. Außerdem würde man beim Löschen die indirekte Adressierung verwenden, da ja zeilenweise gelöscht werden soll, in der Form "LDY #8: STA (zp), y: LDY #$10: STA (zp), y: LDY #$18: STA (zp), y [...]". Zwar müßte man beim Löschen nicht mehr auf pixelgenaue linke und rechte Grenzen achten wie beim Füllen, dennoch würde jedes Schreiben der Bytes 2 + 6 Taktzyklen kosten, was ziemlich viel ist.
Ale weiterer Nachteil kommt noch hinzu, daß unter Umständen Bildschirmbereiche doppelt gelöscht werden, weil zwei Objekte hintereinander stehen.
Von daher wäre es wahrscheinlich einfacher, man würde sich nicht die linken und rechten Grenzen merken, sondern allein die obere und untere und die dann auch nur für alle 8 Zeilen (also blockweise). Dann hätte man eine Löschschleife, die mittels "STA abs, y" den Bildschirm direkt löschen kann, ohne das Y-Register stets neu setzen zu müssen. Der Einsprungspunkt und der Endpunkt mittels RTS würden dabei gepatcht werden, also
Ob das aber am Ende wirklich viel bringt, glaube ich nicht, besonders dann nicht, wenn sehr viele verteilte Objekte auf dem Bildschirm zu sehen sind (nicht zu vergessen auch die Sterne bei einem Weltraumspiel). Daher verwenden eigentlich alle mir bekannten Weltraumspiele den Brute-Force-Ansatz, stets immer den ganzen Bildschirm zu löschen, da dadurch auch das Programm kleiner und weniger komplex wird. Bei Flugsimulatoren würde man stattdessen das Löschen durch das Malen des Himmels, der Horizontlinie und des Bodens ersetzen, und bei einem Spiel wie "Decent", bei dem stets Wände rundherum gemalt werden müssen, erübrigt sich das Löschen ohnehin.
warum definieren wir nicht c++ source code der auf jeder maschine und betriebssystem läuft als den neuen c64?
Wenn ich das richtig verstehe, schlägst Du eine simple, abstrakte Maschine vor als Grundlage zur Programmierung von Programmen. Nun ist der Gedanke an sich nicht neu und auch wert, daß darüber nachgedacht wird, jedoch
a) hat das mit dem C64 nichts zu tun,
b) wird es auf Basis einer spezifischen Hochsprache nicht gelingen, sondern nur auf einer - wenn auch abstrakten - Register- oder Stackmaschine. Schließlich soll der C++-Code ja irgendwie übersetzt und nicht als Scriptsprache interpretiert werden. Daher wäre es zuerst einmal nötig, sich Gedanken über eine virtuelle Maschine zu machen, so wie bei Java oder LLVM.
Hast du zufällig die Interruptroutine disassembliert vorliegen oder kannst zumindest die Adresse nennen?
DIe folgenden Adressen beziehen sich auf die deutsche C64-Version von Elite:
Wie man sieht, ist die IRQ-Routine schön gepackt, d. h. eine Routine führt die Interrupts für oben und unten aus. Der Nachteil dieser Methode liegt aber darin, daß sie langsamer ist, als wenn man zwei getrennte Interrupts verwendet hätte. Außerdem wird das Umschalten zwischen Cockpit- und vollständige Hires-Graphik dadurch bewerkstelligt, daß die Tabellen bei $a8d5 (für $d018) und $a8db (für $d016) gepatcht werden, da beide Interrupts stets aktiv sind, auch wenn bei der Nur-Hires-Graphik ein Interrupt für den Sound ausreichen würde.
Auch hier die Frage: Kannst du vieleicht sagen, wo der Radarcode liegt und/oder wie umfangreich/rechenintensiv die ist?
In der deutschen Version von Elite befindet sich die Routine von $b3f2 bis $b4ad mit Aufruf einer Unterroutine zum Malen einer senkrechten Linie bei $b08c. Die Routine ist an sich nicht sonderlich umfangreich, arbeitet aber genauso wie die Linienroutine für die 3d-Graphik. Die senkrechten Radarlinien werden per EOR in die Bitmap gemalt und auf diese Weise auch wieder gelöscht. Das bedeutet, daß sie in der Standardroutine zur Objektanimation (ab $a287) zuerst aufgerufen wird, um den alten Stand zu löschen. Danach wird das Objekt weiterbewegt, und anschließend die Routine noch einmal aufgerufen, um die Radaranzeige zu malen.
Innerhalb der Radaranzeige werden keine großartigen Berechnungen vorgenommen, da sich die Position der Radaranzeige direkt aus den Koordinaten der Objekte ergibt. Lediglich ein Clipping der Linie wird durchgeführt.
Ha(tte)st du schon eine Memorymap vom originalen C 64-Elite erstellt?
Nein, für die C64-Version hatte ich noch keine Memorymap erstellt, nur für die AppleII-Version, die sich aber von der Speicherverteilung her unterscheidet.
Nur so grob in etwa:
$400..$7ff = Variablenbereich ($700 = ???)
$800..$2021 = Datenbereich
$2022 = Einsprung in das Programm
$4000..$5fff = Bitmap
$6000..$63ff = Farbram Hires
$6400..$67ff = Farbram Multicolour (Cockpit)
$6a00 = Logarithmus Highbyte
$6b00 = Logarithmus Lowbyte
$6c00 = Inv Logarithmus
$6d00 = Adresse der Bitmapzeile Low
$6e00 = Adresse der Bitmapzeile High
$6f00 = Adresse der Farbramzeile Low
$6f19 = Adresse der Farbramzeile High
$6f32 .. = Programm
$b6f0..$ffff = Daten (das Ram bei $d000..$dfff wird genutzt)
Und noch als Ergänzung zu der Idee, die Graphik mittels Zeichensatz darstellen zu können: Nope, funktioniert nicht. Bei der Berechnung wurden nicht der linke und der rechte Rahmen berücksichtigt. Um diesen zu gestalten, braucht es mindestens 2 Zeichen mehr. Dadurch reduziert sich die Anzahl der Zeilen, die man mittels Zeichensatz darstellen kann von 8 auf 7, was zum einen die Anzahl der Interrupts erhöht, aber auch eine gewaltige Lücke am Ende des Zeichensatzes zurückläßt, so daß die Frage entsteht, ob sich der ganze Aufwand überhaupt lohnt.
Immerhin habe ich beim Austesten noch etwas anderes feststellen können: WIe oben ersichtlich verfügt das Programm über zwei vollständige Farbrambereiche, einmal für die normale Hires-Anzeige, einmal für die Cockpitanzeige. Da das Farbram für die Cockpitanzeige jedoch nur per Rasterinterrupt ab der 18. Zeile eingeschaltet wird, sind die oberen 18 * 40 = $2d0 Bytes von $6400 bis $66cf völlig ungenutzt. Interessanterweise ist dies auch bei der C128-Version der Fall. Diesen Speicherbereich könnte man als Einfallstor benutzen, um Elite zu hacken.
Theoretisch mag es Situationen geben, wo die GeoRAM schneller ist als eine REU. Aber gibt es auch Praxisbeispiele, wo die GeoRAM tatsächlich diesen Vorteil gegenüber einer REU deutlich macht?
Aber selbst wenn die GeoRAM in der Regel langsamer ist, wird sie in vielen Fällen immer noch schneller sein als die meisten anderen Speicherlösungen alleine, weil keine Mechanik zu bewegen ist, wie bei Band- und Diskettenlaufwerk.
Unter dem Gesichtspunkt ist es dann egal, ob die REU (etwas) schneller ist.
Und die GeoRAM beinhaltet nichts spezielles an Hardware. Die REU lässt sich nicht so einfach nachbauen.
Um die Farbanzahl trotzdem rein optisch zu erhöhen, setzt man daher gerne Dithering ein. So kann man aus 2 C64-Farben durch Mischen drei machen. Voraussetzung hierfür ist aber, daß die Farben gut mischbar sind. Als Graphikexperte kennst Du sicherlich eine Liste der Farben, die sich optisch gut mischen lassen, oder?
Meine alten Testbilder habe ich auf die Schnelle nicht wiedergefunden aber ich habe ein neues angelegt:
In Zeile A sieht man alle original C64-Farben nach Helligkeit sortiert – wobei sich immer 2 Farben (außer schwarz und weiß) eine Helligkeit teilen. In Zeile B sieht man die Mischungen aus den jeweiligen Helligkeits-Paaren. Die Farben mischen sich so gut, dass der Raster quasi nicht zu erkennen ist. In den beiden C-Zeilen sieht man dann die Farbmischungen der Farben, die nur einen Helligkeitswert Unterschied haben. Auch hier ist der Raster noch recht unauffällig – aber schon sichtbar (vor allen hin zu schwarz). In den 3 Zeilen ab D sieht man die gleichen Farben, wie darüber, nur mit einem Streifenraster statt einem Schachbrett-Raster. Die 1. der 3 Zeiten zeigt eine Besonderheit, nämlich je 2 identische Mischungen nebeneinander, nur in unterschiedlicher Farb-Reihenfolge. Selbst VICE zeigt, dass das unterschiedliche Ergebnisse bringt.
Das zu "guten" Mischfarben, allerdings benötigst du für 3D-Schattierungen ja eigentlich keine so feinen Abstufungen, bzw, kannst dir das bei Verwendung von nur 4 Farben gar nicht leisten, zu ähnliche zu nehmen (du hättest zu wenig Kontraste im Bild). Deshalb habe ich als Letztes einen Farbverlauf von Blau über Hellblau und Cyan hin zu Weiß dargestellt, jeweils mit 5 unterschiedlichen Rastern für die Übergänge. Das soll zeigen, dass du ja nicht nur 50%-Mischungen erzeugen kannst, sondern mit unterschiedlichen Rastern weichere Abstufungen. Übrigens sehen nicht alle Ordered-Dither Muster bei den doppelt breiten MC-Pixeln gut aus, weswegen ich meistens die Raster per Hand definiere.
Super! Vielen Dank, Retrofan! 
Gerne. Wenn du bei einem besonders schnellen Turbo noch Rechenzeit übrig hättest, könntest du diese nicht nur in zusätzliche Frames investieren, sondern alternativ in bessere Darstellung. Rein theoretisch müsste sowas, wie FSAA (Full Scene Anti-Aliasing, Kantenglättung) auch auf dem C64 möglich sein, wenn man Rechenzeit verbraten darf. Das Verfahren erzeugt Zwischentöne an Kanten, um Übergänge weniger stufig (jaggie) aussehen zu lassen. Dafür wird zumeist Oversampling verwendet, man berechnet also das Bild (inkl. Jaggies) in höherer Auflösung (doppekt, vierfach oder noch höher) und rechnet das Ergebnis dann auf die Zielauflösung herunter und erzeugt dadurch Zwischentöne an harten Kanten. Ich habe das mal ausgetestet und ein Bild mit harten Objektkanten direkt auf 160 x 200 Pixel reduziert (kein FSAA, Bild 1) und alternativ das Bild zuerst (horizontal) auf die doppelte Auflösung (Hires, 320 x 200) gerendert und dann erst das Bild auf 160 x 200 Pixel reduziert. Dabei wurden Pixel, die aus einem hellen und einem dunklen Pixel hervorgegangen sind, durch einen Zwischenton repräsentiert. Das Ergebnis aus dem, für 8-Bitter ungewöhnlichen, Verfahren sieht man in Bild 2 (mit FSAA). FSAA auf einem C64 wäre aber schon ziemlich verrückt.
DIe folgenden Adressen beziehen sich auf die deutsche C64-Version von Elite:
Danke dir für das Listing, sehe ich mir mal genauer an.
Und noch als Ergänzung zu der Idee, die Graphik mittels Zeichensatz darstellen zu können: Nope, funktioniert nicht. ... Immerhin habe ich beim Austesten noch etwas anderes feststellen können: WIe oben ersichtlich verfügt das Programm über zwei vollständige Farbrambereiche ... Da das Farbram für die Cockpitanzeige jedoch nur per Rasterinterrupt ab der 18. Zeile eingeschaltet wird, sind die oberen 18 * 40 = $2d0 Bytes von $6400 bis $66cf völlig ungenutzt.
Echt Schade die Sache mit dem Zeichensatz. Weißt du vieleicht auch, wieviel Speicherplatz die Musik belegt?
So abwegig ist das gar nicht. Schon einmal einen Stapel Disketten kopiert ? Ich mache das zB. nur noch über REU und zwei Drives. Den Komfort möchte ich persönlich nicht mehr missen.
IIIIhhh. Du hantierst noch mit Disketten rum? In einem Zeitalter von SD2IEC und Co???? 
( Das ist natürlich nur ein Scherz. 
)
GEOram... Easyflash... REU...
Existiert bei den ganzen Lösungen für Speicherweiterungen eigentlich auch so eine Art "Best of GEOram, Easyflash und optional REU"? Also eine Art Georam, wo mehr als 256 Byte auf einmal eingebelendet werden. 8 oder 16 KByte wie beim Easyflash, aber als RAM halt. Es gab ja unzählige Bastelanleitungen in diversen Magazinen.
Wünschenswert wäre noch ein "Blitter" wie in der REU, der per DMA Speicherbereiche kopiert, austauscht usw.
Das heisst dann Tapecart
So, jetzt kommt was von einem völlig durchgedrehten Vertreter der Eigentlich-Pro-Vanilla-C64-Fraktion:
Wenn wir hier schon von unterschiedlichen Turbos und RAM-Erweiterungen und 3D-Grafik sprechen: Warum den ganzen ollen Kram unterstützen, wenn man auch was ganz Neues machen könnte. Als ich über Kantenglättung etc. nachdachte, musste ich natürlich auch über 3D-Beschleunigung nachdenken. Die PC-CPUs bekamen es ja trotz vieler MHz auch irgendwann nicht mehr gebacken, 3D-Szenen adäquat zu berechnen und da schlug die Stunde der 3D-Beschleuniger. Die Voodoo-Karte war Anfangs ja ein reiner 3D-Beschleuniger, der zusätzlich zur normalen Grafikkarte verbaut wurde.
Wenn man also wirklich 3D auf dem C64 machen will, wäre es dann nicht eine Überlegung wert, einen 3D-Booster zu konzipieren, eine art Voodoo64? Das C64-Programm übergäbe die Geometriedaten an eine ARM-CPU o.ä., die in einem Modul steckt. Die berechnet die Szene mit Wireframes, Flat- oder auch Gouraud-Shading, fügt auf Wunsch Texturen aus einer Bibliothek hinzu, ergänzt optional Anti-Aliasing und gibt die Animationsframes als C64-Multicolor-Bitmaps abwechselnd in 2 Speicherbereiche des C64 zurück, die der VIC sehen kann. Das C64-Programm muss dann nur noch (natürlich neben der restlichen Spiel-Logik) die beiden Screens umschalten und bekommt so wunderbare, gedoublebufferte Darstellung zurück.
Ok, das hat dann teilweise nur noch wenig mit einem C64 zu tun, obwohl es größtenteils immer noch C64-Programmierung wäre und die reine Darstellungsqualität auch nur das wäre, was ein C64 normalerweise so darstellen kann (eben MC-Bitmap oder vielleicht noch FLI) – aber wer ein Turbo Chameleon nicht mehr als C64 durchgehen lässt, der hätte mit diesem 3D-Beschleuniger wahrscheinlich auch so seine Probleme. Bei den heutigen Möglichkeiten dürfte so ein Modul für vielleicht 30€ (als Bausatz) zu machen sein, Preistendenz fallend. Wenn es dafür ein oder zwei coole 3D-Games (Descent64, Starfox64, Wolfenstein3D, Elite Plus o.ä. ...) gäbe, würden sich schon ein paar Hardware-Verrückte den Booster holen.
Existiert bei den ganzen Lösungen für Speicherweiterungen eigentlich auch so eine Art "Best of GEOram, Easyflash und optional REU"? Also eine Art Georam, wo mehr als 256 Byte auf einmal eingebelendet werden. 8 oder 16 KByte wie beim Easyflash, aber als RAM halt.
Ja. Nennt sich Turbo Chameleon 64. Der 64k-Adressraum der CPU ist in mehreren Blöcken aufgeteilt, denen man jeweils eine bytegenaue Speicherposition aus den gesamten 32 MB zuweisen kann. Davon sind die 16 MB der REU praktisch frei verwendbar. Auch das ROM und RAM der emulierten Floppy kann man auf diese Weise direkt der C64-CPU zugänglich machen.
Wenn man also wirklich 3D auf dem C64 machen will, wäre es dann nicht eine Überlegung wert, einen 3D-Booster zu konzipieren, eine art Voodoo64?
Wenn es mit den Spieletiteln optional mitgeliefert würde und ohne Öffnen und Basteln an der Elektronik des Rechners (also nur durch Anstecken an einen der Ports) funktionierte, würde ich das wohl sogar kaufen. Aber nicht, wenn ein Eingriff in den Vanilla-C64 nötig ist oder ich mir das Teil irgendwo anders mühsam besorgen müsste.
Wenn es mit den Spieletiteln optional mitgeliefert würde und ohne Öffnen und Basteln an der Elektronik des Rechners (also nur durch Anstecken an einen der Ports) funktionierte, würde ich das wohl sogar kaufen. Aber nicht, wenn ein Eingriff in den Vanilla-C64 nötig ist oder ich mir das Teil irgendwo anders mühsam besorgen müsste.
Ist sowas technisch möglich?
Vielleicht kann sich ja jemand der da Plan hat was dazu sagen...
Turbo Chameleon 64. Der 64k-Adressraum der CPU ist in mehreren Blöcken aufgeteilt, denen man jeweils eine bytegenaue Speicherposition aus den gesamten 32 MB zuweisen kann. Davon sind die 16 MB der REU praktisch frei verwendbar. Auch das ROM und RAM der emulierten Floppy kann man auf diese Weise direkt der C64-CPU zugänglich machen.
Ui, und die Grafikausgabe läuft dann immer noch (parallel) über den VIC-II oder nur über den VGA-Port des TC64?
Ist sowas technisch möglich?
Vermutlich ja. Man muss sich ja "nur" überlegen, wie die Daten ("Framebeschreibungssprache" rein, Bitmap raus) zwischen Modul und RAM kopiert werden. (eventuell auch die Bitmap an sich direkt auf $A000-$BFFF mappen)
