Tipp: In einem Freeze-Monitor den gesamten Salat von $0350 bis $FFFF speichern und mit einem Hex-Editor die Checksumme prüfen.
Packer gesucht für Bereich $0350-$ffff
- TheRealWanderer
- Thread is Unresolved
-
-
Ich kenne mich mit den "aktuellen" Sachen nicht aus, nehme heute noch den Sledge Hammer und der Run Crunch von Ende 80er hinterher.
Da weiß ich wenigstens dass es funktioniert und ich auch nicht 25Std zum entpacken warten muss.
Aber ich glaube der Sledgehammer kann nur ab $0400 bis $FFFF - musste mal gucken.
Das Ergebnis vom packen finde ich heute noch beeindruckend.
-
-
Hucky Dein Posting gefällt mir. Ich bin auch immer der Meinung, dass 8 Bit genug sind. Ich mache im Emulator auch nur recht wenig, Cross-Geschichten eigentlich gar nicht.
coden tu ich aber mitlerweile eigentlich nur noch mit C64 II Tastatur, welche über Keyrah am Laptop angestöpselt ist und nutze Vice.
Allerdings mit SMON und SpeedDos Plus Kernal !!
Also so wie ich es früher gemacht habe, nur schön dabei aufm Sofa rumlümmeln ☺️
Will ich nicht mehr missen 😃
-
-
Coden tu ich entweder im Vice oder direkt am Cevi. Wobei ich die Fraktion Jiffydos bin
Den WinVice betrachte ich nicht als Cross-Developement, eher als unvollständigen/teildefekten Cevi. Immer mal wieder verhält sich das Ding nicht 100% wie echte Hardware, fällt meist nur in Kleinigkeiten auf. -
Ich habe mich vielleicht etwas kompliziert ausgedrückt, deshalb nochmal dieser "Nachklapp" mit einem Beispiel.
Wenn Du das Programm von $0350-$FFFF packst und dann wieder in diesen Bereich entpackst, dann sollte bei allen Packern die das können dasselbe vor dem packen im Speicher stehen wie auch nach dem entpacken. Das kannst Du natürlich auch gerne prüfen, Fehler halte ich hier für sehr unwahrscheinlich.
Es ist wahrscheinlicher, dass der Fehler entsteht, weil das Programm gewisse Werte oder auch Code im beim packen ausgelassenen Speicherbereich $0000-$034F erwartet.
Wahrscheinlichstes Beispiel hierbei: eine uninitialisierte Variable. Nimm an das Programm erwartet den Wert 0 in der Speicheradresse $00FE und funktioniert auch nur korrekt, wenn da auch wirklich die 0 drin steht. Der Entpacker verwendet aber genau diese Speicheradresse $00FE für irgendwelche Zähler und nach dem entpacken steht da nicht 0 drin sondern 9. Dann läuft das Programm nicht mehr korrekt. Adressen und Werte sind nur zur Verdeutlichung und können real natürlich anders sein.
Du könntest also pfüfen, welche Werte im ausgelassenen Bereich $0000-$034F ERST gelesen werden bevor sie GESCHRIEBEN werden (den Stack vielleicht erst mal außen vor lassen).
Ist wahrscheinlich also eher ein Problem beim Programm selbst als ein Problem bei den Packern.
-
Hucky: Da kannste Dir doch gleich in das C64C-Gehäuse ein Pi reinbauen
Mini-ITX _könnte_ evtl. sogar auch noch passen.
hab ich keinen Plan von 🙈
Und wenn ich es bis jetzt nicht gebraucht habe 🤔🤷♂️
-
Coden tu ich entweder im Vice oder direkt am Cevi. Wobei ich die Fraktion Jiffydos bin
Den WinVice betrachte ich nicht als Cross-Developement, eher als unvollständigen/teildefekten Cevi. Immer mal wieder verhält sich das Ding nicht 100% wie echte Hardware, fällt meist nur in Kleinigkeiten auf.ich hatte das Problem mal bei meinem Nuxieuhrprojekt bei AM / PM Umschaltung über CIA Register.
Hab mir dan was gecodet das es funktioniert ☺️
-
Wie der Titel schon aussagt, bin ich auf der Suche nach einem Packer, mit dem ich ein Programm, welches den Bereich $0350-$FFFF komplett verwendet, packen kann.
Leider kann exomizer Programme mit einem Startbereich unter $0400 nicht wieder funktionsfähig entpacken, da von $0334 - $03D0 von Exomizer genutzte Tabellen liegen.
Gibt es einen anderen Packer, der das kann, oder kann man exomizer irgendwie dazu bewegen, es zu können?
Hab ich zum selben Zeitpunkt gemacht für mein eigenes Sonic Georam projekt....
-
-
PLUSH PACKER
0033-ffff ? WTF echt jetzt ?
Wahnsinn.
Habe heute erst wieder meinen RLE gebraucht um mein neues Demo zu packen. Der Exo hat mir Spritedaten bei $0840 zerstört
und das egal ob ich erst Exo aufs demo schicker oder erst RLE und dann Exo mache - in jeden Fall is my demo shit
k.A wieso - also habe ich die 159 blocks mit meinem RLE einfach auf 68 blocks gedrückt
-
Wie schon vorher hier im Thread erwähnt, dürfte der Packer selbst eher nicht der Bösewicht sein.
Meist sind es uninitialisierte Variablen (also ein Bug im entpackten Programm), die dann zu kreativen Seiteneffekten führen, wenn irgendwas im Lowmem-Bereich anders als erwartet ist.
-
hmm interessant. Aber wie können Spritedaten bei $08c0 corrupt sein nur weil ich das programm exomiziert habe ?
ich schalte sprite ein, positioniere sage $07f8 das es bei $33 sein soll (bild) und habe Salat im Sprite (pixelmüll) aber nur wenn es gecruncht
ist. Die Bitmap fürs Sprite berechne ich in einer Schleife.
Display MoreCodehat doch mit Low Mem Sachen nix zu tun...
Das haben auch andere hier im Forum bemerkt wie zb hier:
Bei mir gibts das wenn ich es mit Exo packe, bei RLE bei mir nicht.
Aber bei den beiden Bildern habe es einige auf Ihren Emulator oder Ultimate64 (??? was immer das ist)
trotzdem. Nehme nicht an das die Emulation buggy bei denen ist aber man kann nie wissen.
Das grosse Bild ist meine Version vom Vice 2.4 (kein Pixel mülll)
-
Hast Du mal geguckt, ob die Daten direkt nach auspacken wirklich schon kaputt sind? Also VICEmon-Breakpoint auf den Einsprungpunkt Deines Programms, dann rumforschen, sobald nach RUN in den Monitor gebreakt wird?
-
Was nach dem Exomizer ebenfalls anders ist: das timing.
Ein (eher nicht so) beliebter Bug ist das setzen von $d012 ohne Beruecksichtigung von $d011 und dann kann das mal klappen und mal nicht
-
noch nicht. aber ! ich baue diverse Sachen auf und before ich die Sprites einschalte,
baue ich den Spriteinhalt mit obigen Program auf und danach werden die Sprites gesetzt und eingeschalten.
Ich kann nicht verstehen warum der Sprite falsch dargestellt wird und vorallem alle anderen 5 die das SELBE Bild (08c0) besitzen
korrekt sind , nur das erste nicht oder im Ultimate 1 & 2 ....
Das ist krank
-
NSU Cruncher von Action 0037-ffff
-
Was nach dem Exomizer ebenfalls anders ist: das timing.
Ein (eher nicht so) beliebter Bug ist das setzen von $d012 ohne Beruecksichtigung von $d011 und dann kann das mal klappen und mal nicht
nicht verstanden. Im Wiki hab ich das gesehen.....
"Zudem ist die IRQ-Reaktionszeit der CPU nicht konstant, sondern abhängig vom gerade ausgeführten Befehl, was zu einem Zittern des Balkens führen kann. Eine Möglichkeit dieses Problem zu lösen besteht darin, den Interrupt eine Zeile früher auszulösen und dann über das VIC-Register 53266 ($D012) zu prüfen, ob der Rasterstrahl des Monitors die gewünschte Zeile erreicht hat.
"
meinst du das ? ich sollte eine zeile vorher den IRQ setzen und danach ein
lda zeile+1
cmp $d012
bne *-1
sta $d001 ; y reg sprite 0
sta $d003 ; y reg sprite 1
machen ?
-
NSU Cruncher von Action 0037-ffff
ok plush war 33-ffff und gewinnt oder ?
