Beiträge von ivettaB im Thema „Packer gesucht für Bereich $0350-$ffff“

    Es gibt Bitte melde dich an, um diesen Link zu sehen., aber der basiert auf VICE 1.18.

    oje übel - und schade.

    Ist der FPGA so teuer - diese Altera mir gar nicht so teuer vor Jahren mal geschaut.

    Also im DTV 64 Joystick ist ja so was drinnen und der Stick hat 20 Euro damals gekostet (leider die NTSC Version gekauft..)

    Alternativ kann man auch eine Mediatek CPU nehmen (chinaware -> eine geklaute ARM CPU) habe ich in div. Videogeräten / mediaplayern aus China gefunden... kostet unter 2 Dollar in HK. Ist halt nicht so genau wie eine FPGA Emulation.

    schön wäre es so ein FPGA Ding ,das tragbar wie Sega Noman oder Atari Lynx zu haben. Mit LCD und Akkulaufzeit von 4 Stunden..

    aber nicht für 300 Euro - sondern zu einem normalen Preis von 20-39 Euro (Bandaimässig eben)

    Sorrry wegen OFF Topic :smile:
    Gibts eigentlich auf der Sony PSP einen guten C64 Emulator ?

    Bitte melde dich an, um dieses Bild zu sehen.

    Nur mal so...

    "Ultimate 64 was immer das ist."

    Kein Google?

    Bitte melde dich an, um diesen Link zu sehen.

    doch eh aber nicht nachgeschaut. Ich habe eh einen echten C64 wenn ich emulieren willl nehme ich einen Raspi oder den Vice am PC. Das reicht eigentlich für meine Zwecke. Aber Danke.

    Hab nicht genau reingelesen, ist das dieses FPGA Ding das den C65 emuliert mit diesem VIC III und dem Coolen DMA Blitter Controller und viel RAM ? Schade das es kaum Software für C65 gibt... obwohl die Demos sehr cool sind...

    Ich finde nur fragwürdig, diese $33 unterbieten zu wollen.

    Und das verlinkte Programm habe ich damals gebaut, bevor ich mir einen neuen Nick ausgeguckt habe.

    Bin auch drüber. Ich wollte den Stack $0100-01ff und $0002-00ff aus dem Colorram restaurieren....

    zb. so:

    das muss anders gehen aber wie?

    hmm. Muss dann schon ein LZW derivat sein (sequenzpacker) Aber alleine durch Videoram und Charsets kann man immer was mit RLE

    packen.

    Der LZW muss extrem klein sein damit möglichst viel Platz für das Dekompr. Spiel bleibt

    Vielleicht kann man den Exo zwingen nur 4bit (16 Werte) wörterbuch zu nehmen . K.A

    war da nicht so ein switch -m256 oder -p 256 ? habs vergessen

    vielleicht geht -m16 auch aber er schrieb in der Doku (martin) das diese schalter das compressat grösser machen also schlechter packen

    > Du spricht etwa von Videodaten ? Die lassen sich ja schwer pressen wenn viele Pixel (details) im Bild sind..

    sehe ich auch so. Mein RLE hat für Spiele komplett ausgereicht von Geschw. und Speicherverbrauch und zweiteres kann ein Exomzer dann auch noch 50% verkleinern wenn das sein muss...

    Mir war es wichtig $0200-ffff sauber zu können.

    Aber eine gute Idee hat es schon:

    Jetzt weiss ich das ich den Stack und Zeropage 02-255 im Farbram verstecken kann und meinen depak sagen könnte stelle am Ende diese Daten wieder her mittels Schleife bei $03-$13 und sprung ins Spiel.... ned übel !

    schon klar.... nibbles eben (4bit sind keine 8bit) :wink:
    aber macht das der Exomizer nicht eh schon so ?

    Habe die Sourcen meines RLE depak eh dazugegeben.

    Aber das auf 33 bytes (-2 wegen Port $00/01) also 31 bytes zu reduzieren .... weiss nicht ob das dafür steht.

    - init teil (zeile 255-273) muss da weg uns ins hauptprogram nach dem MoveBlock (steht ab $0100)

    - Zeile 275 - 382 ist der reine Depak der im Stack bei $0100 steht sollte -> den auf 33 bytes kürzen ist eine Challenge (geht natürlich - einfach wirds nicht)

    Die Spiele die ich packte gingen alle Stressfrei (ausser Sonic natürlich) - werde schaun ob Sonic sich mit obigen Packer korrekt crunchen lässt...

    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 :wink:

    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 Bitte melde dich an, um diesen Link zu sehen.-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 ?

    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

    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.

    hat 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)

    Gibt auch Bitte melde dich an, um diesen Link zu sehen.. :)

    Edit: Ach, da war jemand schneller. :D

    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 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....

    Bitte melde dich an, um diesen Link zu sehen.