Posts from Stephan Scheuer in thread "Heute so gecodet..."

Das die letzten "Kleinigkeiten" mehr Zeit benötigen als das Ganze davor, kenne ich nur zu genüge.

Ich bin auch schon seit zwei Monaten an meinem Decompi bei. Das PRINTPlease login to see this link.,SPC(12) oder PRINTPlease login to see this link.,TAB(12) wird nun fast prefekt rekonstruiert. Ich habe, um das Problem

zu lösen, noch zwei Arrays eingerichtet um, unter Anderem, die RAM-Adressen von PRINT# dort abzulegen. Stimmen die RAM-Daresse des Pass1-Wert und Pass2-Wert überein,

wird PRINTPlease login to see this link.,SPC(12) oder PRINTPlease login to see this link.,TAB(12) geschrieben. Bei dem CMD4 Befehl habe ich es genau so gecodet, und das wird perfekt decompiliert. Veröffentlicht wird der Decompiler

erst, wenn PRINTPlease login to see this link.,SPC(12) oder PRINTPlease login to see this link.,TAB(12) zu 100% funktionieren. Die Please login to see this link. und (12) sind nur Beispielwerte.

Hier mal der Bug
----------------
11093 OPEN4,4,7
11098 CMD4
11100 PRINT#4,AT$
11104 PRINT#4,SP$+CHR$(45)+LG$;
11115 PRINTTAB(40);               ; - muss "PRINT#4,TAB(40);" sein 
11120 PRINT#40                    ; - zeilennummer und befehl sind falsch bzw. stammen aus der oberen zeile
11121 PRINT#4,DT$

11173 PRINT#4,AA$(I);
11194 PRINTTAB(TB-LEN(AA$(I)));  ; - muss "PRINT#4,TAB(TB-LEN(AA$(I)));" sein
11203 PRINT#TB-LEN(AA$(I))       ; - zeilennummer und befehl sind falsch bzw. stammen aus der oberen zeile
11204 PRINT#4,G(I);

Und wie funktionieren beim Basic ohne Zeilennummern Sprünge, wie z.B. GOTO 1500. Etwa über Labels?

Quote from atomcode

Hier noch die Version für Selbstmodifizierungsphobiker ..

Code

                    [...]
                   sta $02
                   lda $d800,y             ; ---- low nibble
                   and #$0f
                   ora $02
                    [...]

So ähnlich hatte ich das auch gemacht. Anstatt "ORA $02" zu nutzen, hatte ich das mit "akku01 ORA #$00" gemacht. Der Akku wird entsprechend modifiziert.

Ich hatte das eben gecodet, um den Exomizer Leveldecruncher kurz zwischenzupuffern, weil im Spiel keine $0178 zusammenhängende Bytes frei waren. Es funktioniert.

Gerade so gecodet, eine Routine um das Farb-RAM als Datenpuffer zu nutzen, wenn es mal knapp mit dem Speicher wird.

nibble = $c000

irgendwas_machen = $1000

!to"farbram-buffer.prg",cbm

!cpu 6502

* = $cc00
; ---------------------------------------
; ---- das farbram als puffer nutzen ----
; ---------------------------------------
                   lda #$37                ; ---- i/o bereich aktiv
                   sta $01
                   lda #$0b
                   sta $d011               ; ---- screen aus
                   ldy #$00
loop01             lda nibble ,y           ; ---- low nibble
                   sta $d800,y
                   lsr
                   lsr
                   lsr
                   lsr
                   sta $d900,y             ; ---- high nibble
                   iny
                   bne loop01
                   jsr irgendwas_machen
                   lda #$37
                   sta $01
                   ldy #$00
loop02             lda $d900,y             ; ---- high nibble
                   asl
                   asl
                   asl
                   asl
                   sta akku01+1
                   lda $d800,y             ; ---- low nibble
                   and #$0f
akku01             ora #$00
                   sta nibble,y
                   iny
                   bne loop02
                   rts

Ich hätte da nach meinem Empfinden mittels Brute Force gearbeitet, um das beste Ergebnis zu erhalten. Ist meine Überlegung blödsinnig oder könnte man das auch so machen.

Cool. Gibt es sowas auch um PETSCII Animationen zu erstellen, also soetwas wie kleinere Trickfilme.

Ok, Danke! Dann werde ich mir mal den Levelcrusher Disasseblieren und diesen an meine Wünsche anpassen. Eine üble Arbeit, und es dauert bis es fertig ist. Aber wenn es funktioniert, bin ich happy.

Beim Exomizer gibt es übrigens den RAW-Modus. Damit ist es möglich, Dateien die länger als 64KB sind, zu (level)crunchen.

Nur habe ich zu wenig Information gefunden, wie eine RAW-Gecrunchte Datei decruncht wird.

Falls es interessiert, die Maniac Mansion Supercpu Version ist Exomizer 64kb gestückelt Levelgecruncht. Ungecruncht 4064 Blöcke und gecruncht 1685 Blöcke.

Ich habe auch den Rasterzeileninterrupt am die 20Mhz angepasst. Also kein langer Strich am unteren Bildschirmrand. Das ist nur eine Spielerei von mir.

Lempel-Ziv wollte ich nutzen "Byte Boiler und co." Nutzen möchte ich das mit meinen Supercpu Anpassungen. Die Haptdatei ist häufig über 512KB lang. In seltenen fällen auch 2MB.

Z.Z packe ich das mit dem Exomizer Levelcruncher. Zuerst teile ich die Hauptdatei in 64kb parts und der Exomizer Levelcruncher linkt alle Dateien zu einem File zusammen.

Den Exo-Decruncher habe ich in 24Bit umgecodet, so dass die Hauptdatei in einem Stück on-the-fly geladen und decruncht wird. Weil ich aber nicht ständig die Riesendatei

Stückeln möchte, kommt nur ein Cruncher mit einer 24Bit Adressierun in Frage.

OK. Danke, die Batterie werde ich jetzt sofort rauslöten.

OK, danke!

Das mit den Banks auf dem Amiga wusste ich überhaupt nicht . Ich musste mich aber irgendwie Verständlich machen, was ich möchte. So fiel mir nur Bank ein.

Dann nutzen die eine 24bit Adressierung und 16Bit ASM-Code. C64 Cruncher nutzen eine 16bit Adressierung und 8Bit ASM-Code.

Für die Supercpu werde ich dann natürlich auch eine 24bit Adressierung und 16Bit asm-code nutzen. Nochmals Danke für die Info. Ich hatte schon sehr viele Seiten, bezüglich

Cruncher und 65816 Code gesucht. Gefunden hatte ich einige, nur konnten diese nur maximal 64KB Crunchen.

Ich habe gerade meinen Amiga 3000 aus dem Keller geholt und werde den mal anschließen, ob der noch funktioniert.

Der Würfel, ist das eine Vektor Animation (drehender Würfel)? Wenn ja, bei der Anzahl an Farben hat die CPU ordentlich was zu tun, um die Farbabstufungen zu berechen, wenn sich der Würfel dreht.

Bei Demos dreht sich alles um Tackzyklen. Beim PC, beim Amiga, beim C64 ect.

Ich hätte noch eine Frage. Auf dem Amiga gibt es Levelcruncher, so wie auf den C64 "Dark Squeezer, Level Crusher ect.". Crunchen die Programme auf dem Amiga mit einer 24Bit Adressierung,

also Bankübergreifend (16MB) oder nur 64KB auf einmal. Diese Frage stelle ich, weil ich schon lange vorhatte sowas für die Supercpu zu coden. So könnte ich mir von den Amiga-Cruncher

so einige Tipps holen bezüglich des 16Bit coding.

Ich habe vom Amiga-Coding keine Ahnung. Deswegen fragte ich ja so neugierg nach.

Die Supercpu Version von DOOM wurde mittels MIPS-I Recompiler erstellt. Ich habe mir mal auszugweise den 65816 Code angesehen und muss sagen, dass ich das nie so gecodet hätte.

Ich dachte, dass man dort höhere Programmiersprache nutzt. Wie z.B. auf dem PC mit C++. Aber wie ich sehe, ist dem nicht so. Einige Befehle kenne ich vom 6502 und andere vom 65816.

Mal eine Frage zum Amiga-Coding.

Wird dort auch direkt in ASM gecodet? Mir sind im oberen Bild die Befehle "JMP und JSR" aufgefallen.