Forum64

hey,
zu dem "kernal loadroutine auf 8 ändern" ist mir was eingefallen.
Wäre doch möglich ein flag einzurichten (im highmemory des speichers, dass normale c64 programme nicht verwenden), das entscheidet, ob auch ,8 loadaufrufe die routine für ,1 verwendet.

So braucht man nachladespiele nicht fixen. (solange sie die normale kernalroutine verwenden...also kein fast- oder irqloader).
Einfach das flag setzen, und schon funktioniert das nachladen...

Ha..... hab was noch viel besseres !!!!!!!

Man braucht das Kernal ja garnicht neu flashen.
Man kann die Games ja mit einem gepatchten Kernal laufen lassen, dass nur
um RAM liegt (natürlich auch im highmemory, damit es von den Games nicht überschrieben wird).
Das geht gaaaaaaaaaaaaaaanz einfach!!!!! Einfach vor dem Spielstart das "original" Kernal ins High-Ram kopieren, die paar Bytes in der Kernalloadroutine ändern und dann auf dieses neue Kernal umschalten. Das bleibt dann ja aktiv, bis man den Resetknopf des DTVs drückt!!!

Coole Sache....

SO DENNIS !!!!!

JETZT BRAUCHEN WIR EIN ENCODER, DER AUCH WIRKLICH NOCH PACKT!!!!
(für die Levelfiles der Games)

Das Packen ist nicht wirklich kompliziert hier ist eine Seite die das Verfahren sehr gut erklärt mit Basic Beispiel Code: vb-tec.de/rle-lauf.htm

nah.... so wie ich das sehe, ist das halt eine seite, die das packen "an sich" ein bisschen erklährt...

darum geht es hier aber nicht. HIER muss ja ein packer geschrieben werden, der die daten GENAU SO PACKT, dass der schon vorhandene depacker das wieder richtig entpackt.
(Wobei die Methode die da verwendet wird auch nicht besonders kompliziert ist).
Wir hier sind wohl nur zu faul, was zu coden

So wie ich die Seite lese ist es nicht allgemeine irgendeine Methode sondern ganau die richtige. Sonst hätte ich das überhaupt nicht gepostet.

Neh! Ist NICHT die richtige Methode für den DTV!

Der DTV hat ein Sequenz-packer ! (klar, damit kann man dann auch Equalchar-packen) Und da wird dann auch mehr als nur 1 Markierungsbyte verwendet.
(1. für die Anzahl an Bytes und das 2. Byte für die Entfernung die die Sequenz zurückliegt. Wobei beim 1. Byte das höchste Bit entscheidet, ob eine Squenz wiederholt wird (und somit das 2. Byte benötigt wird) oder ob "neue" Bytes folgen. Ein 00 gibt dann das Ende des Files an.)

Wenn ich das richtig Verstanden habe heißt das 0x01 bis 0x7f bedeutet das die nächsten 2 bis 128 Byte kopiert werden sollen 0x80-0xFF heißt, dass das nächste Zeichen 128 bis 2 mal wiederholt werden soll und 0x00 gibt das Dateiende an.
Oder ist das falsch wenn ja wo gibt es den mehr Infos?

$01-$7f ist richtig.

$80-$ff ist anders... (eben so, wie ich es in meinem vorherigen post beschrieben hatte).
Länge ist dann Byte-128 (oder eben AND $#7f) und das nächste Byte gibt die Position an (um '256 - nächtes_Byte' zurück)

Mehr Infos dazu? -> Keine Ahnung ob es die irgendwo gibt. Ich hab halt einfach in das Kernal und die gepackten Files angeschaut.

Jo, denke jetzt hab ichs. Sorry hat ne Weile gebraucht bis der Groschen gefallen ist. Danke.

keine problem! wenn du nun noch ein programm dafür schreibst...um so besser

Hab die Quelle nur überflogen aber könnte die selbe Kompression sein: http://www.cs.tut.fi/~albert/Dev/pucrunch/

also der pucruncher wird es sicher nicht sein....

das ist einfach was marke eigenbau... aber ja auch nicht so kompliziert, um ein packer zu schreiben...

Ich dachte ja nur das es evtl. hilfreich sein könnte, da es sehr ähnlich arbeitet (glaub pucrunch geht noch etwas weiter) und gut dokumentiert ist.

Du könntest mir aber eine Gefallen tun und mal eine Datei sowoh gepackt als auch ungepackt anhängen. Hab kein DTV und auch kein Flashdump würds gern mal Probieren.

yo...
hier die 2 files für das original intro file vom dtv. (encoded und decoded - wobei das decodete noch die startladeadresse am anfang hat, die NICHT im encodeten file enthalten ist).
man sieht am anfang, wie das encodete mit $31 'neuen' bytes anfängt.
dann kommt das steuerbyte, dass aussagt, dass die nächsten 3 bytes wiederholungen sind ($83), und zwar von der postition um 8 bytes zurück ($f8 ).
danach kommen dann wieder $10 neue bytes...usw...

am ende sieht man schön, wie "kompliziert" die mehrfache wiederholung eines einzelnen zeichens (wenns dumm läuft und dieses eine zeichen nach einem kopieraufruf erfolgt) realisiert wird.

am ende stehen im ungepackten file $19 mal die 00.
dafür wird zunächst die 00 EINMAL als "neu" aufgeführt. (mit $01, $00)
und dann $18 mal von position - 1 kopiert (mit $98, $ff).
die position erhöht sich natürlich mit jedem weiteren byte, so dass immer das eben geschrieben byte wiederholt wird. (es wird NICHT immer das selbe byte von der ersten position genommen. hier überlappen sich ja quasi nur die lese und schreibpositionen, so dass im endeffekt immer das gleiche byte rauskommt)

zuletzt noch ein 00 als steuerbyte-ende.

Okay das entpacken funktioniert soweit ich bastel noch am packen rum.