Forum64

D011 ist nur zum Einschalten des Btmap-Modus, der Wert ist in allen Bereichen gleich.
DD00 wählt eine 16KB-Bank aus, der VIC kann nämlich nur innerhalb von 16KB sehen und arbeiten.
Für Deine einfache Frage musst Du also nur das "OR 3" bei $DD00 weglassen und die anderen Pokes unverändert ausführen, dann hast Du die Bitmap bei $E000 und den Screen dazu bei $C400.

Spannender ist $D018, aus der AAY64:

Das ist das eigentliche Register, mit dem Du Bildschirmspeicher, Zeichensatz- und Bitmap-Adresse festlegst.

Schritt für Schritt:
1) Die 16KB-Bank aussuchen. und nach $dd00 poken: $0000-$3fff=3, $4000-$7fff=2, $8000-$bfff=1, $c000-$ffff =0
2) Screenram innerhalb der Bank muß durch $0400=1024 teilbar sein. Adresse/1024*16 ergibt die oberen 4 Bits von $d018.
3) Zeichensatz muß durch 2048 teilbar sein, Adresse/1024*16 ergibt die unteren 4 Bits von $d018. Das ergibt sich dann von alleine, daß das unterste Bit keine Bedeutung hat.
4) Bitmap hat nur die Wahl zwischen oberen oder unteren 8KB, muß also durch 8192 teilbar sein, gleiche Formel wie beim Zeichensatz.

Wichtig für die Wahl ist noch, daß von $1000-$2000 und $9000-$A000 immer nur das Zeichensatz-ROM erreichbar ist, egal, ob für Bildschirm, Bitmap oder Sprites. Drum fährst Du mit den Bänken ab $4000 oder $C000 für Grafikzwecke ziemlich gut.

$4000 ist die einzig wirklich "reine" VIC-Bank, also für alles perfekt, weil da weder ROMs noch Zero-Page oder deren Erweiterung oder Basic-Start rumspuken normalerweise.

$C000 ist perfekt für Grafik, eben weil der VIC (anders als beim Char-ROM) das Kernel-ROM automatisch ignoriert und aufs RAM zugreift. So kann man einen ohne ROM-Ausschalterei nicht nutzbaren Bereich wunderbar einsetzen.

Ich fand das hier immer hilfreich:
http://codebase64.org/doku.php?id=base:v…mory_organizing

Letztlich was Hoogo gesagt hat als Tabellen, natürlich HEX.

PS: Bei der Tabelle immer daran denken, vom VIC-Bank-Start zu rechnen.

$E000 ist also in der fraglichen Tabelle $2000!

Jetzt musst Du Dich nur noch entscheiden, wo das Screen-RAM (default $400/DEZ1024) in der Bank liegen soll, dann sollte das mit $D018 sich aus der Tabelle erklären.

Nochmal ganz langsam:
Also
1.) in $dd00 Vic-Bank 3 wählen -> die unteren zwei Bits löschen
2.) in $d011 Biimapmodus anschalten -> Bit 5 setzen
3.) in $d018 Position der Bitmap relativ zur Vicbank setzen -> Bit 3 setzen

Deinen Screen hast Du danach, wenn Du sonst nichts geändert hast bei $c400 (schätze mal, dass ist Dein erstes z)
z1 müsste dann $c800 sein, bzw eigentlich $c7e7 oder $c7e8 (schon wieder vergessen, was in C ++x oder x++ bedeutet) ... und "normalerweise" (Vic Bank I) gehört da $07e7/$07e8 rein ... sonst überschreibst Du Dir die Spritepointer. Ist zwar in dem Beispiel egal, aber vielleicht für die Zukunft wichtig.

Bildschirm $0400 und Bitmap $E000 wie in Deinem Code geht technisch nicht. Beide müssen in der gleichen 16K-Bank liegen. Wie Spider sagt, mit Deinen Pokes hast Du den Bildschirm bei $c400 eingerichtet.

Evtl. kann $d016 noch interessant werden, wenn zwischen Multi-Color und Text-Modus hin- und her geschaltet werden soll, $d012 falls man vorhat, das screen zu splitten in Text und Grafik.
http://codebase64.org/doku.php?id=base:built_in_screen_modes

Aber für reines Bankswitching und Einschalten eines Zeichensatzes sollten die zuvor erteilten Ratschläge und evtl. das hier genügen:
http://www.c64-wiki.com/index.php/VIC_bank (da sind auch Basic-Beispiele drin)

Hallo, hier Basicfan,

Hier der BAS-Code für das Umschalten in den Grafik-Modus unter dem Kernal-ROM.



Schönen Gruß, Dirk

Dafür musst Du halt das Kernal-ROM aus- und RAM einblenden. Einzustellen in Speicherstelle $01.
Hier eine Übersicht über mögliche RAM/ROM Kombinationen:

Quelle: http://codebase64.org/doku.php?id=base:memory_management

EDIT: die "gängigste" Variante, wenn man kein Kernal nutzt und möglichst viel RAM haben will, aber dennoch Zugriff auf VIC/SID-Register haben will ist wohl #$35.

Kann man ein- und ausblenden wie man lustig ist :)
Von $d000-$dfff ist VIC/SID etc... also IO, keine ROM-Rountinen. Von $e000-$ffff ist ja das Kernal-ROM. Falls Du also hin und wieder mal ROM Routinen brauchst, kannst Du das kurz anschalten. Das Basic-ROM von $a000-$bfff braucht man logischerweise nur in Basic. Aber der cc65 spuckt doch ASM aus, oder? (wundere mich eh die ganze Zeit, dass der Thread hier im Basic-Bereich ist).

Für Ladeaktionen ist es meist von Basic aus betrachtet am besten, wenn man die Grafik nach 40960, also unter das BASIC-ROM lädt.

So ist die Grafik-Bitmap gleich an der gewünschten Stelle und man muß lediglich die Farb-Bereiche am Ende an die richtige Stelle kopieren, wozu man allerdings ein Hilfsprogramm benötigt, welches das ROM während des Kopiervorganges ausblendet, da ein paar Speicherstellen am Ende sich noch im BASIC-ROM-Bereich befinden (192 Bytes).
Der Rest ist kein Problem, da er sich bereits im oberen RAM befindet, auf das man problemlos zugreifen kann.
Ansonsten ist es besser im Basic-Programm-RAM zu arbeiten, da man dort mit allen Basic-Befehlen zugreifen kann.

Schönen Gruß, Dirk

Unters Kernel-ROM geht genauso gut, auch in Basic.

Mit Grafik-Anwendungen ja, aber das Laden ist besser unter das BASIC-ROM, da sich die Farb-DATEN hinter der Grafik befinden.
Beim Laden ans Kernal-ROM würde vermutlich dann die Zero-Page mit den Farbdaten überschrieben werden.

Schönen Gruß, Dirk

Aber nein!

Ich weiß nicht, wie oft ich schon darauf verlinkt habe:
http://www.c64-wiki.de/index.php/kernel#…g_von_BASIC_aus

Das hier

funktioniert auch tadellos unter dem Kernel-ROM ohne die ZP irgendwie zu beeinträchtigen. EInfach statt 64 mal 224 ($e0) oder Höheres probieren. Lässt sich zwar nicht PEEKen ohne Kernel abzuschalten, aber der VIC sieht dort nur RAM, egal ob da nun Zeichensatz oder Bitmap liegen.

Quoted from "BASIC-FAN"

Mit Grafik-Anwendungen ja, aber das Laden ist besser unter das BASIC-ROM, da sich die Farb-DATEN hinter der Grafik befinden.
Beim Laden ans Kernal-ROM würde vermutlich dann die Zero-Page mit den Farbdaten überschrieben werden.

Was ist das denn für eine verschrobene Theorie?!? =)

Das nützt aber doch nichts, wenn die nachzuladende Datei zu groß ist um unter das Kernel zu passen

Allerdings spricht auch nichts dagegen, Bitmap und Farbdaten in seperaten Dateien unterzubringen.

Edit: das war auf TheRyks Beitrag bezogen.

@Colt: Ehhh? Etwas, was größer ist als 8 kb, sollte man natürlich nicht nach $e000 laden, nein, aber ich dachte, das versteht sich von selbst.