$DFxx für VIC-Mapping
Wie aufwändig wäre es, jede sichtbare Bildschirmzeile mit einem Memory-Offset zu versehen?
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von Krill am
$DFxx für VIC-Mapping
Wie aufwändig wäre es, jede sichtbare Bildschirmzeile mit einem Memory-Offset zu versehen?
$DFxx für VIC-Mapping
Wie aufwändig wäre es, jede sichtbare Bildschirmzeile mit einem Memory-Offset zu versehen?
Kaum sinnvoll möglich. Die Cartridge müsste wissen, wo Bitmap und wo die Farben liegen, um gleichmäßige Offsets anzuwenden.
Die Farben bei $D800 können nicht offgesettet werden. Alle Farben werden auch nur einmal alle 8 Zeilen gelesen.
Was wäre denn das Ziel? https://beamracer.net/ dürfte das erreichen.
$DFxx für VIC-Mapping
Wie aufwändig wäre es, jede sichtbare Bildschirmzeile mit einem Memory-Offset zu versehen?
Ich sehe jetzt spontan keine Möglichkeit 40 Zeichen/Bytes umzusetzen, also wäre jede Zeile 64 oder gar 256 Zeichen lang.
Der Rest muss dann ignoriert werden.
Ohne Textmodus-/ Grafikmodusumschaltung sieht das für mich schwer umsetzbar aus.
Wir entwerfen hier gerade eine ziemlich komplexe MMU die tatsächlich eine REU von der Leistungsfähigkeit überbieten kann und ohne DMA auskommt (die Daten werden. Nicht bewegt nur umgeschaltet).
Auch wenn ich mit meiner Aussage hier nicht auf Gegenliebe stoße so ein Chip gehört in den Computer, es ist ein hoch komplexer PLA Ersatz und wäre wohl mit uneingeschränktem Nutzen im CPU oder PLA Sockel am besten aufgehoben
mit jeweils einigen Verbindungen zum anderen Sockel.
Im Grunde genommen überlegen wir, wie hätte ein C128 (C64 Nachfolger) aussehen können.
Versuchen das ganze aber im Rahmen der Einschränkungen eines Ultimax Moduls umzusetzen.
Ich sehe jetzt spontan keine Möglichkeit 40 Zeichen/Bytes umzusetzen, also wäre jede Zeile 64 oder gar 256 Zeichen lang.
Der Rest muss dann ignoriert werden.
Das ist nicht das Hauptproblem.
Das Hauptproblem ist, dass am Cartridge-Port keinerlei Information anliegt, welche Zeile gerade ausgegeben wird. Und auch nicht, wann diese Zeile anfängt.
Man könnte die Rasterzeile auslesen und dann einen "Mini VIC" nachbauen, der Synchron läuft. Und ganz schnell ist man beim Turbo Chamaeleon.
Das sprengt alles den Rahmen.
Alles anzeigen$DFxx für VIC-Mapping
Wie aufwändig wäre es, jede sichtbare Bildschirmzeile mit einem Memory-Offset zu versehen?
Kaum sinnvoll möglich. Die Cartridge müsste wissen, wo Bitmap und wo die Farben liegen, um gleichmäßige Offsets anzuwenden.
Die Farben bei $D800 können nicht offgesettet werden. Alle Farben werden auch nur einmal alle 8 Zeilen gelesen.
Was wäre denn das Ziel? https://beamracer.net/ dürfte das erreichen.
Hilf mir Mal auf die Sprünge, das Farb-RAM bleibt doch wo es ist als extra RAM im IO-Bereich die Adresse ändert sich doch nicht. Ich kann doch nur den Textbildschirm relativ dazu verschieben.
Löst aber immer noch nicht das 40 Zeichen Problem.
Hier müsste man massiv Adressleitungen twisten.
Alles anzeigenIch sehe jetzt spontan keine Möglichkeit 40 Zeichen/Bytes umzusetzen, also wäre jede Zeile 64 oder gar 256 Zeichen lang.
Der Rest muss dann ignoriert werden.
Das ist nicht das Hauptproblem.
Das Hauptproblem ist, dass am Cartridge-Port keinerlei Information anliegt, welche Zeile gerade ausgegeben wird. Und auch nicht, wann diese Zeile anfängt.
Man könnte die Rasterzeile auslesen und dann einen "Mini VIC" nachbauen, der Synchron läuft. Und ganz schnell ist man beim Turbo Chamaeleon.
Das sprengt alles den Rahmen.
Ich denke ich weiss was ich übersehen habe die Sprites.
Es gibt nicht nur Text und Grafik sondern zusätzlich Sprites die aus dem Speicher gelesen werden.
Es ist in der tat schon fast eine VIC Emulation notwendig.
Ich dachte erst es genügt zu wissen ob Text- oder Grafikmodus aktiv ist und wo der Start ist.
Im Grunde genommen überlegen wir, wie hätte ein C128 (C64 Nachfolger) aussehen können.
Versuchen das ganze aber im Rahmen der Einschränkungen eines Ultimax Moduls umzusetzen.
Nein, wir versuchen, eine einfache, günstige Hardware-Erweiterung für den C64 und C128 zu spezifizieren, um einem hypothetischen neuen OS genug RAM und ROM unterzuschieben, damit das vielleicht was werden kann.
So viel und so groß, wie unbedingt nötig.
So klein, einfach und günstig wie möglich.
Sonst sind wir ganz schnell wieder bei enthusi :
Was wäre denn das Ziel?
Ich bin am überlegen, wie man auch Bitmapscrolling beschleunigen könnte:
Also die Farbnibbles bleiben natürlich unveränderlich von $d800 bis $dbff. Dann sind im Multicolor-Modus immer noch 2 von 4 Farben pro 4*8-Pixelblock individuell. (Hires-Bitmap ignoriert ja eh das Farb-RAM.)
Der Erweiterung wird mitgeteilt, wo die Startadressen der 200 Pixelzeilen und der 25 Zeichenreihen sind. Anhand der Zugriffadresse kann dann die betroffene Rasterzeile ermittelt werden, ohne den VIC-Chip mitzuemulieren. Die Erweiterung addiert das gewünschte Offset dazu und legt die Grafik auf den Datenbus.
Was wäre denn das Ziel?
Ich bin am überlegen, wie man auch Bitmapscrolling beschleunigen könnte:
Einfach per VSP, also mit herkömmlichen VIC-Tricks. Man sollte dann nur gucken, dass keine Daten unter $1000 durch den VSP-Bug kaputtgehen, aber der externe Speicher ist sicher.
Einfach per VSP, also mit herkömmlichen VIC-Tricks.
Wenn auch vertikales Scrolling dazu kommen soll, gehen durch das Linecrunching leider die oberen Zeichenreihen verloren.
Ich bin am überlegen, wie man auch Bitmapscrolling beschleunigen könnte:
Also die Farbnibbles bleiben natürlich unveränderlich von $d800 bis $dbff. Dann sind im Multicolor-Modus immer noch 2 von 4 Farben pro 4*8-Pixelblock individuell.
Ihr denkt schon noch daran, dass es um ein OS (und gegebenenfalls passende Anwendungen, gerne im Hires-Bitmap-Mode) gehen soll, nicht um erweiterte Games? Also, wenn sich das automatisch mitergibt, dann natürlich gerne.
Vielleicht in diesem Zusammenhang irgendwie interessant?: Btmap-Scrolling mit REU
Ihr denkt schon noch daran, dass es um ein OS (und gegebenenfalls passende Anwendungen, gerne im Hires-Bitmap-Mode) gehen soll, nicht um erweiterte Games? Also, wenn sich das automatisch mitergibt, dann natürlich gerne.
Richtig, komplexe VIC-Erweiterung ist out of scope.
Vorstellbar wäre lediglich eine höhere Granulartität (wobei kleinere Speicherklötzchen als 256 Bytes kaum Sinn ergeben) mit einer Lobyte-Offset-Addierlogik für byteweise verschiebbare Daten.
Da bleiben dann diverse Einschränkungen, aber viele davon kann man bestimmt mit ausgefeiltem Beamracing wieder wettmachen.
Vielleicht in diesem Zusammenhang irgendwie interessant?: Btmap-Scrolling mit REU
Es soll ja genau kein DMA gemacht werden, sondern Speicherbereiche dynamisch umgemappt werden.
Also, wenn sich das automatisch mitergibt, dann natürlich gerne.
Ein CPLD soll ja auch nicht unterfordert sein
Vorstellbar wäre lediglich eine höhere Granulartität (wobei kleinere Speicherklötzchen als 256 Bytes kaum Sinn ergeben) mit einer Lobyte-Offset-Addierlogik für byteweise verschiebbare Daten.
Gebongt.
Vielleicht in diesem Zusammenhang irgendwie interessant?: Btmap-Scrolling mit REU
Es soll ja genau kein DMA gemacht werden, sondern Speicherbereiche dynamisch umgemappt werden.
Seht ihr eine Möglichkeit für ein Parallelbetrieb mit einer REU?
Es soll ja genau kein DMA gemacht werden, sondern Speicherbereiche dynamisch umgemappt werden.
Meine Frage ging eher dahin, ob man mit trickreichem Ummapping ähnliches bzgl. beschleunigter Bitmap-Scrolling-Performance erreichen könnte. Ich nehme eher an, dass nicht – wollte aber sichergehen.
Vielleicht in diesem Zusammenhang irgendwie interessant?: Btmap-Scrolling mit REU
Es soll ja genau kein DMA gemacht werden, sondern Speicherbereiche dynamisch umgemappt werden.
Seht ihr eine Möglichkeit für ein Parallelbetrieb mit einer REU?
Wenn man nur einen der beiden IO Bereiche nutzt könnte es möglich sein. Ich könnte mir sogar vorstellen das beides gleichzeitig in einem RAD Modul möglich ist.
Ob es aber mit einer echten REU auch klappt? und ob diese DMA in das externe RAM statt in das interne macht?
Mich stören z.B. bei GEOS diese FLIR-Dateien, die man sich ausgedacht hat, um die DOS-Nachteile zu umschiffen. Dadurch wird man aber inkompatibel zum klassischen DOS. Deswegen würde ich halt u.a. große Dateien (und auch segmentierte OS- und Programm-Module) in der Speichererweiterung verwalten und nicht auf dem Datenträger.
Ein neuartiges OS darf doch aber schon neuartige Dateitypen (wie z.B. GEOS-VLIR) mitbringen, oder?
Solange diese mit dem OS kopiert und generell gemanagt werden können, alles gut?
Beim klassischen DOS hat man ja eh schon mit REL-Dateien genug Probleme.
Aber eigentlich braucht man nur ein ordentliches SEEK. Dann kann man einfach in riesigen PRG-Dateien rumspringen.
Aber eigentlich braucht man nur ein ordentliches SEEK. Dann kann man einfach in riesigen PRG-Dateien rumspringen.
Dazu fällt mir IFFL ein. Kannst du das noch weiter ausführen?
Ein neuartiges OS darf doch aber schon neuartige Dateitypen (wie z.B. GEOS-VLIR) mitbringen, oder?
Solange das in CBM-DOS und FAT-formatierter SD-Karten abgebildet werden kann, gerne. Aber bitte nicht wieder, wie bei GEOS, mit eigenem Dateisystem, das man sich von der "normalen C64-Seite" aus auf dem Datenträger zerschießen kann. Auch wenn ich mir bei den Apps zwei Welten (Legacy und NewOS) wünsche, so möchte ich das auf DOS-Ebene eigentlich nicht. Was ein neues OS aber auf seiner Speichererweiterung inkl. internem "Startlaufwerk" so treibt, kann mir, dem Kernal und CBM-DOS egal sein – das sieht eh nur das neue OS.