Posts by Stephan Scheuer

Das steht so nicht im P-Code. Fast alles Decompiler interpretieren das aber blöderweise so.

Ganz schlim wird es, wenn das ein Compiler so erstellt.

10296 print#15,"b-a:";

10304 print#15,0;

10306 print#15,tr;

10308 print#15,s

10310 print#15,"u1:";

10317 print#15,2;

10319 print#15,0;

10321 print#15,tr;

10323 print#15,s

Der Basic Code funktioniert so nicht. Der unten gelinkte micht das so immer.

https://csdb.dk/release/?id=147419

Oder das hier. lauter nutzlose Zeilen

8270 i=0

8271 fori=0to63

12747 q=1

12749 forq=1to8

Andere Decompier mülllen den Basic Code mit unzähligen Klammern zu.

Das ist auch die eleganteste Lösung, die es gibt.

Ich hatte gestern gelesen, dass die NTSC-Version von "Ultima V" über einen Fastloader verfügt.

Die PAL-Version funktioniert mit dem NTSC-Only Schnelllader leider nicht, was den Game leider

ganz üble/grausame Ladezeiten beschert. Ganz schnell verliert man das Interesse am Spiel und

nur, weil da irgendwer nicht in der Lage war, einen PAL-Fix des Fastloader zu erstellen.

Naja, ich habe das dann gestern mal nachgeholt. Der Schnelllader funktioniert nun auch in

Verbindung mit der PAL-Version, so nach etwa 30 Jahren. Gut ding will weile haben oder so.

Die XOR-Verschlüsselung hatte nur den Sinn, es den Crackern schwer zu mache, den Code zu ändern. An dem Coden im Floppy-Ram war zudem auch recht schwer

ranzukommen. In gegensatz zum C64 , da kann man mittels Frezzer Cartridge einen Monitor aufrufen und den Code ändern, gibt es sogut wie keine Möglichkeit, den Code

im Floppy-RAM auszulesen, auch mit dem Action Replay nicht. Der IRQ-Lader verhindert das. Heute geht das ganz einfach mit dem Monitor im WinVice.

Übrigens, die meisten Kopierschutzverfahren waren einfach nur Schice und eine Geldverschwendung. Ich kenne gerademal 8 Kopierschutze, die man als sehr gut bezeichnen kann.

Richtig. Bei der Input64 waren alle Programme auf der Disk so verschlüsselt. Die XOR-Verschlüsselung wurde recht häufig bei diversen Kopierschutzverfahren genutzt.

Bei dem Game Portal von Activision ist jeder Sektor mit eine unterschiedlichen XOR-Wert verschlüsselt. Das entschlüsseln findet im Floppy-RAM, während der Ladens statt.

Achso, das wusste ich nicht.

Mit der unteren Spielerei kann man Breiche im RAM verschlüsseln oder entschlüsseln. Bei der Input64 wurde das so gemacht.

Das untere kleine Beispiel kann die Programme auf der Input64 entschüsseln.

LDA #$00

STA $FC

TAY

LDA #$10

STA $FD

LOOP1

LDA ($FC),Y

EOR #$55

STA ($FC),Y

INI

BNE LOOP1

RTS

Ja, das war ein wenig buglastig, genauso wie bei "Holiday Games". Äh, das war noch viel schimmer bei dem "Holiday Games". Aber ein Save im Easyflash hat im eigendlichem

Sinne, nichts mehr mit den Disk-Save Zugriffen zu tun. Die Saveroutine bei meiner Version funktioniert zu 100%. Ich werde Morgen oder Übermorgen die letsten Arbeiten machen (Trainer ect.)

Dann kannst du das "Prachtwerk" testen.

Ist so ziemlich dasselbe wie im post 4 von mir. Das wäre doch auch mal was. Die kürzeste Varriante um den Bildschirmspeicher zu löschen.

Jetzt aber nicht "PRINT"{clr}"

Hätte ich das kaputte Teil nicht ein Jahr lang rumliegen lassen, wäre,hätte,könnte.... Hätte der Hund nicht geschissen, hätte er einen Hasen gehabt.

So ist das halt. Selber Schuld. Aber wie gesagt, das fast fertige Game mache ich auf alle fälle fertig, dann war die Arbeit nicht umsonst.

Zumindest habe ich ein Disk-Kopierprogramm gecodet, das nur aus Basic besteht. Auch ein Erfolg

Das Timing, immer wieder erstaunlich. Sicher mache ich das Game nun fertig. Das fast ferige Spiel jetzt in den Ordner "War wohl nichts" zu packen, kommt gar nicht in die Tüte.

Ich hatte auch mal so angefangen und dann jede Woche, wenn es möglich war, irgendwas gecodet.

Nur ZP-Adressen um den Bildschirmspeicher zu löschen, würde ich nicht unbedingt machen. Das ist sowas wie mit Kanonen auf Spatzen zu schiessen.

Ja, ok da hat du recht. in dem fall werden die spritepointer gelöscht. Wird aber recht häufig so gemacht.

so, bitteschön.

ldx #$00

lda #$34

loop1

sta $0400,x

sta $0500,x

sta $0600,x

inx

bne loop1

ldx #$e9

loop2

sta $06ff,x

dex

bne loop2

rts

Sowas hier? Naja, nach 35 Jahren wüsste ich vom Assembler auch nicht mehr viel. Also immer fleißig üben.

ldx #$00

lda #$34

loop

sta $0400,x

sta $0500,x

sta $0600,x

sta $0700,x

inx

bne loop

rts

Hat das Spiel eine Autostart? Wenn ja, dann könnte dieser die Vectoren ab $0330-$0333 überschreiben.

So, für alle hardcore Basic-Fans habe ich gerade eben ein 1541-Diskbackup gecodet. 100% ML-Code Free. Getestet und funktionier. Viel Spass mit den Teil.

Danke Joker. Ich hatte meine Version auch fast fertig Der EF-Loader funktionierte fehlerfrei. Wurde von AW182 getestet. Heute wollte ich AW182 die fertige Version zum testen geben.

Naja, wer zu lange an einer Anpassung, oder anders gesagt, wer zu spät kommt....

Na, da bin ich aber mal echt neugiereig, wie du das gelöst hast. Ich komme nichtmal unter 100 Bytes. Habe zwar einige Ideen, daber das dann in Basic umzusetzen, da mangelt es mir, leider.

Ach, ich habe es mit Data Zeilen versucht, mit ein Viertel Bildschirm, nach links, rechts unten und links unten kopieren. mit selbstmodifizierenden Basic Code ect und pp.

Ich habe einfach nicht genug Know How in Sachen Basic Coding.

So, mit selbst erstellten Basic Code komme ich auf 144 Bytes. Und nun noch kürzer... wie?

Ich bin gerade am suchen. Wenn ich es finde, sage ich wie kurz der Code war. Vielleicht habe ich mich auch geirrt.

Im Moment ärgere ich mich richtig über die Decompiler und was diese teilweie für ein Mist produzieren und wie ich das bessr coden kann.