Hallo zusammen,
ich habe die letzten Monate versucht meinen Wunsch nicht nur sehnsüchtig auf die neuen Spiele des jährlichen RGCD 16k Wettbewerbs zu warten, sondern auch mal selbst etwas Kleines einzureichen Realität werden zu lassen. Problem ist: ich bin totaler Anfänger. Nun hab ich mich mit meinem kleinen Puzzlespiel dank Codebase und co einigermaßen durchgemogelt, dabei aber vergessen mich mit dem Cart-Format auseinanderzusetzen. Seit ich vor ein paar Tagen nun erfahren habe, dass man die 16k Module nicht abschalten kann, habe ich nun mit viel Kopfschmerzen alle Daten umorganisiert um dem $8000-$BFFF Bereich aus dem Weg zu gehen und stehe nun vor der Frage, wie ich Daten hinter dem I/O Bereich rauskopieren kann.
Meine Grundkonfiguration für $01 ist nun also $35.
Einfach
lda $34
sta $01
Kopierschleife
lda $35
sta $01
ist ja anscheinend falsch. Wie kann ich an die Daten kommen? Lasst mich wissen, welche weiteren Infos ihr benötigt um die Frage zu beantworten.
Meine zweite Frage: ich habe inzwischen einen ordentlichen Haufen Timer- und Temporärwerte, die ich nach dem Motto "solange das Programm nicht abstürzt passt das schon" ab $02 aufwärts über die Zero Page verteilt habe. Welche Bereiche der ZP sollte man denn evtl. besser unangetastet lassen? Ich habe mir die Memory Map angeschaut, kann ohne Hinweise von jemandem mit Ahnung aber nicht sicher sein. Werde die Tage bestimmt noch mehr Fragen haben, auch wenn es inzwischen ziemlich unmöglich scheint, dass ich für den diesjährigen Wettbewerb mit dem Spiel fertig werde.
Danke.
Jan
letzter Beitrag von M. J. am
Anfängerfragen Programmierung 16k Cart Spiel
- Pyramidenkopf
- Erledigt
-
-
Hier wurde gestern von alx dazu eine Übersicht gepostet.
RAM unter I/O einblenden müsste also LDA #$31 / STA $01 sein im Falle von 16K Cartridges (wenn ich die Tabelle richtig gelesen habe).Über ZP-Adressen >= $02 brauchst Du Dir keine Gedanken machen, wenn Du Kernal aus hast (#$35 in $01).
EDIT: ABER BLOß die RAUTEN nicht vergessen
-
Zitat von spider-j
ABER BLOß die RAUTEN nicht vergessen
Hehe, ja die vergesse ich gerne mal.
Danke erstmal für die Antwort.
Das Kopieren aus dem I/O Bereich hing an einem ähnlich dummen Fehler wie mit den Rauten. Werde jetzt mal versuchen ein crt zu erstellen. Wenn wenigstens das schonmal funktioniert... -
Wenn du da Unterstützung brauchst, immer raus damit. Daran soll es ja jetzt nicht scheitern. Denk daran, das Cart selbst benötigt auch so eine Art Boot-Code. In der C64-Codebase ist da ein nettes Grundgerüst enthalten.
Ich benutze für die 16k carts immer $35 in $01 bzw. $34, wenn ich Daten unter $d000 kopieren will.
-
Hehe, ja die vergesse ich gerne mal. -
hättest dich ruhig in den anderen 16k compo Thread reintrauen können ...
-
Danke, Jungs.
Crt Erstellung hat anscheinend geklappt. Abgesehen von den restlichen Programmierproblemchen ist die größte Baustelle die Musik. Ich muss mich irgendwie noch schnell besser in Goattracker einfuchsen und lernen wie man einigermaßen vernünftige Instrumente erstellt und die Filter nutzt. Im Moment schmerzt das Gejaule ziemlich in den Ohren. Und dann wollte ich eigentlich auch zumindest die Abspielgeschwindigkeit der Musik auf NTSC Maschinen korrigieren. Hab aber noch keine Ahnung von Timer IRQs. Naja, NTSC ist eine Baustelle für einen anderen Tag. -
Ich hab auch noch ein kleines Game, dass mit Exomizer gepackt unter 16kb bleibt. Wie kann ich das denn in ein crt verwandeln? Mal abgesehen von einem Koalabild bei $8000, dass ich wohl noch verschieben muss, sollte es doch möglich sein, SID und anderes bei $0810-$5000 bzw. SID $6000 und so weiter entpacken zu lassen, oder?
-
Hatte hier mal ein Shellskript dazu gepostet. Sollte unter Windows aber mit minimalen Anpassungen aber auch irgendwie gehen. Im Zweifel direkt den acme Source durchstöbern und als Vorlage nehmen.
Skript zur Erstellung von 8k/16k CRT aus PRG Dateien -
Ich hab auch noch ein kleines Game, dass mit Exomizer gepackt unter 16kb bleibt. Wie kann ich das denn in ein crt verwandeln? Mal abgesehen von einem Koalabild bei $8000, dass ich wohl noch verschieben muss, sollte es doch möglich sein, SID und anderes bei $0810-$5000 bzw. SID $6000 und so weiter entpacken zu lassen, oder?
Ich habe dazu ein Python-Script geschrieben:
http://www.frank-buss.de/c64/prg2crt/index.html
Das verwendet allerdings ein Magic Desk kompatibles Cartridge. Zum Abschalten dann entsprechend am Ende die hier schon erwähnten Werte in 1 speichern. Banking braucht man auch nicht, also die Kopier-Schleife ein wenig umprogrammieren. Vielleicht besser gleich das Script von spider-j verwenden -
RAM unter I/O einblenden müsste also LDA #$31 / STA $01 sein im Falle von 16K Cartridges (wenn ich die Tabelle richtig gelesen habe).
Über ZP-Adressen >= $02 brauchst Du Dir keine Gedanken machen, wenn Du Kernal aus hast (#$35 in $01).
Ich benutze für die 16k carts immer $35 in $01 bzw. $34, wenn ich Daten unter $d000 kopieren will.
Wenn man auf das RAM unter dem I/O - Bereich $D000-$DFFF direkt vom eingeblendeten EPROM zugreifen möchte, muß man unterscheiden ob lesend oder schreibend.
Will man z.b. nur Daten vom EPROM ins RAM kopieren, kann man den I/O - Bereich mit LDA#$33 STA$01 für Schreibzugriffe öffnen.
Das EPROM ist dann nach wie vor von $8000 - $BFFF eingeblendet, was bei $01=#$34 oder #$35 nicht der Fall ist !Um auf Nummer sicher zu gehn, sollte jeder echt mal das Programm PLA.EXE von Jens Schönfeld benutzen, denn dieses Programm bezieht die angezeigte Logic DIREKT aus den original PLA-Daten des C64.
EDIT: oh, ich habe gerade zufällig gesehen, daß bei $01=#$33 die CPU-Writes ins Color-RAM gehen - oder wie soll man das deuten ?
bei $01=#$34 gehen die writes auch ins ColorRAM - is dat überhaupt relevant ? hmm ..... -
Wenn man auf das RAM unter dem I/O - Bereich $D000-$DFFF direkt vom eingeblendeten EPROM zugreifen möchte, muß man unterscheiden ob lesend oder schreibend.
Will man z.b. nur Daten vom EPROM ins RAM kopieren, kann man den I/O - Bereich mit LDA#$33 STA$01 für Schreibzugriffe öffnen.
Das EPROM ist dann nach wie vor von $8000 - $BFFF eingeblendet, was bei $01=#$34 oder #$35 nicht der Fall ist !
Ich verwende immer gerne diese Seite. Bei $33 sind die drei unteren Bits des Prozessorports 011, also Konfiguration #2. Das EPROM ist in dem Fall nicht mehr eingeblendet und ein Programm was dort läuft würde sich daher selbst den Boden unter den Füßen wegziehen. Bei $35 sind die Bits 101, also Konfiguration #3. Auch dort ist das EPROM nicht eingeblendet, aber auch das RAM und $d000 ist nicht erreichbar, da bei dieser Konfiguration der IO-Bereich dort eingeblendet wird. Um das RAM unter $d000 ansprechen zu können, muß man HIRAM=0 und LORAM=0 setzen (mal davon abgesehen, wenn GAME und EXROM beides 0 ist, dann ginge auch LORAM=1, aber das ist nicht die Konfiguration für 16k Cartridges). Also $34 in 1 speichern, oder $30 (da CHAREN egal ist, wenn LORAM und HIRAM 0 sind), um auch auf das RAM in $d000 zugreifen zu können. Nicht vergessen den Interrupt auszuschalten, da das KERNAL dann auch nicht mehr da ist.Die Frage ob man schreibend auf das RAM unter $d000 zugreifen kann, wenn dort das Char-ROM eingeblendet ist, beantwortet die Tabelle allerdings nicht. Würde ich einfach in VICE im Monitor schnell ausprobieren, wenn ich es wissen wollte.
-
Bitte nicht das Script vn Gartenzwerg (fuer die Compo!) benutzen. Das erstellt keine 16KB-Cart images (das ist nicht das selbe wie cart images die 16KB gross sind)
RGCD 16KB Game Compo 2014Nicht nur fuer die Compo, sondern auch sonst steht eigentlich alls Noetige fuer 16Kb carts hier:
http://www.rgcd.co.uk/2014/04/…dge-game-development.html
Bzw ist dort unter USEFUL LINKS / INFO verlinkt.Ich bin ab gleich den Rest der Woche im Urlaub - daher er etwas knapp formulierte Text
-
Da mein Skript scheinbar okay ist - naja, es benutzt ja eigentlich auch enthusis Code - biete ich gerne auch an, CRTs zu erstellen, falls noch jemand Probleme damit hat (oder nicht weiß, wie er das unter Windows benutzen soll).
Was ich in dem anderen Thread Sokrates angeboten hatte, kann ich ebenfalls auch jedem, der sonst nur mit dem Emu arbeitet anbieten:
'Real Hardware' Test des CRT, wenn auch nicht auf Eprom, aber zumindest auf MMCR, Chameleon und EasyFlash. -
Mein Problem ist imho Exomizer. Es hängt immer, wenn ich vom Modul aus die gepackte Datei anspreche (bei $8000something). Teilweise fängt Exmonizer an zu entpacken, hängt sich aber dann auf.
Testweise habe ich schon alle Daten rausgeworfen, die eigentlich unter $e000 entpackt werden sollten. Aber selbst bei Daten, die nur von $1000 bis weit unter $8000 entpackt werden sollen funktioniert es nicht.
Auch Exomizer einen anderen Wert bei $01 aufzuzwingen funktioniert bei mir nicht, zumal ich #$33 gar nicht zur Option habe. Meine letzte Commandline bevor ich aufgab sah so aus:
Mir ihr startet das Entpacken zumindest für den Bruchteil einer Sekunde...
Aber hab kaum Zeit dafür und beim Game selber fehlt eh auch noch einiges, sodass ich das ganze wiedereinmal skippe
-
Squidward:
Das ist auch ein etwas komplizierter Versuch, den Du da unternimmst. Du versuchst irgendwie, dass Exomizer vom CRT aus entpacken soll. Das kann im Bereich des Cartridges schon mal gar nicht klappen, weil Exomizer dann speziell dafür eine Routine mitbringen müsste, die immer hin und her schaltet. Wie's darunter aussieht weiß ich nicht.Die einfachste Variante ist das ganz "normal" zu packen, dann vom Cart mit dem Startcode (enthusis oder mein Sourcecode - wie gesagt: fast identisch) in's RAM kopieren und einfach normal starten (also statt basic run natürlich jump direkt zum Anfang: jmp $080d bei sfx).
Der Vollständigkeit halber: laut meinem Taschenrechner hier ist #55 = #$37 und nicht #$33.
EDIT: Ich seh gerade $01 Config hab ich mir aus irgendwelchen Gründen in meinem ASM Code gespart (bin vmtl. nicht davon ausgegangen, dass man seine Daten über's RAM verteilt, sondern einfach mit $0400-$7fff auskommt).
Müsst man dann noch ergänzen (in crt_code.asm). Wie gesagt: ich helfe auch gerne, in dem ich einfach das CRT für Euch erstelle.
EDIT2: Nee, Exomizer regelt das doch von alleine, oder? Das ganze Gerede über $01 hat mich irgendwie ganz wuschig gemacht -
Ahh, ok. Darauf bin ich mal wieder nicht gekommen zuerst das gepackte nach $80d zu kopieren und von dort zu starten. Das werde ich heute abend nochmal ausprobieren, danke.
Der Vollständigkeit halber: laut meinem Taschenrechner hier ist #55 = #$37 und nicht #$33
Ja, ich weiß. Aber Exomizer erlaubte meinen Wunsch-Wert $33 nicht, nur Werte zwischen $34 und $38.
-
Ich kopiere den exomizer decruncher (basierend auf dem beispiel code) aus dem crt raus und entpacke dann das spiel teil fuer teil. Es hat sich gezeigt dass es platzsparender ist verschiedene daten getrennt zu packen, also code, grafik, musik, ... Da der beispiel decruncher $01 nicht anfasst und neben schreib auch lese zugriff braucht kann also nicht direkt unter crt/kernal entpackt werden - dann kopiere ich gerne die gepackten daten ins ram unter exakt den selben platz im cartridge und schalte dann alles rom aus und entpacke was unter crt/io/kernal muss.
-
Das Problem bei Exomizer ist, dass er, wenn du Daten unterhalb von I/O packen willst, mit INC und DEC an $01 rumspielt. Da kommt leider dann in den seltensten Fällen was sinnvolles bei raus.
Bei den 16k Carts habe ich das Problem meistens umgangen, d.h. die Daten nach dem entpacken manuell da hoch kopiert. -
Ich kopiere den exomizer decruncher (basierend auf dem beispiel code) aus dem crt raus und entpacke dann das spiel teil fuer teil.
Das ist imho auch ohne CRT die sinnvollste, bzw. sauberste Methode. Einfach vom Assembler in der Binary den halben Speicher zu "nullen" und dann das Ergebnis durch den SFX Packer zu jagen ist so ein bisschen die "Vorschlaghammer"-Variante