letzter Beitrag von clarkkent am
Als programmiertechnische Null frag ich hier mal einfach, ob mir bei meinem Problem jemand hier helfen kann:
Ein uraltes Spiel aus der HC 9/84 namens Crazy Jumpman muss leider immer vor dem eigentlichen Spielstart einen ewig dauernde Prüfsummencheck durchlaufen. Leider wird es danach nicht so gespeichert, dass das beim nächsten Mal nicht mehr notwendig ist - und das geht mir tierisch auf die Nerven.
Hilfe! 
Sollte sich basteln lassen
(sprich: ich setz mich jetzt dran)
Das Basicprogramm lädt das ganze Gelump aus den data statements ins RAM, erst das eigentliche Spiel an $a000 bis $b9ff (also unter dem BASIC ROM), dann noch einen Relocator in den Datasettenpuffer (bei 828). Der Relocator kopiert das Spiel dann von $a000 nach $8000.
Ich hab das mal nachvollzogen mit zwei Annahmen (die möglicherweise falsch sind):
1. Der Relocator im Datasettenpuffer wird nicht mehr gebraucht
2. Das Original bei $a000 wird nicht mehr verwendet
Im Ergebnis gibts zwei Dateien hier: Einmal das "Original" bei $8000 und dann einmal durch Exomizer gejagt, einmal ums etwas kleiner zu machen, aber auch, weil es sich mit Entpacker und allem normal per load/run starten lässt.
Beide lassen sich ausführen (die $8000-Datei per load ,8,1 laden und mit sys 32768 starten) und gehen dann auch ins Spiel, aber ohne weitere Gewähr 
Die "exomized" Variante macht genau das: load "die datei",8,1 / run -> los gehts.
cool! Ich muss noch probieren, ob das laden und speichern im Construction Kit funktioniert. Wenn ja, ist die Umwandlung super gelungen!
Da ich weder Spiel noch Editor kapiert habe, hier der Artikel dazu: https://archive.org/details/hc…1984-09/page/n67/mode/2up
Das Diskimage hier wäre die "maximierte Kompatibilität"-Variante (lädt aber deutlich langsamer und mit Transwarp u.dgl. ist da auch nichts zu machen): Es lädt die Daten genau dorthin, wo das offizielle Basicprogramm sie auch hinlegt und springt dann auch in den Relocator im Datasettenpuffer, genau wie das Original. Ich vermute, dass die Methode nicht notwendig ist, aber da ich die Dateien grad in der Hand hatte, hab ichs für den Fall der Fälle noch fertig gemacht.
Da ist ein Tippfehler im Listing im Heft: In Zeile 4970 des Basicprogramms müsste die 5-letzte Zahl eine 133 sein, keine 137. (hab ich im Scan auf archive.org abgeglichen)
So wird aus "lda #$01; sta $b9" (also: speichere 1 in Adresse $b9) dann halt "lda #$01; noop #$b9", was im Ganzen gesehen überhaupt nichts bewirkt (wobei das noop auch noch ein inoffizieller Opcode ist, auf manchen 6502-Ablegern also vermutlich sogar abstürzen würde). Und das bedeutet, dass beim Laden eines Levels die Standard Basicladeadresse verwendet wird, statt der Adresse, die in der Datei hinterlegt ist ($c000), analog zu load "zeug",8 vs. load "zeug",8,1 (diese 1 im Befehl entspricht der 1, die Crazy Jumpman in $b9 schreiben will). Das heißt, Laden hat überhaupt nicht funktioniert, weil Level in der falschen Ecke des Speichers landeten.
Da die Prüfsumme nichts meldet, die einen Druckfehler aber hätte finden können (so einfach das Prüfsummensystem auch konstruiert ist), ging die Fassung "zum Abtippen" wohl nicht durch eine gründliche Endkontrolle (siehe auch die vermurkste Funktion, um das fertig in den Speicher geschriebene Programm zu speichern).
Im Anhang gibts die gefixte Version, wieder einmal bei $8000 (sys 32768) und als "exomized"-Version, die sich normal laden und ausführen lässt. Laden, Speichern und geladene Level starten habe ich getestet, es funktioniert.
Auf der Suche nach dem Problem habe ich auch keine Hinweise dafür gefunden, dass die anderen Teile (im Datasettenpuffer oder die Kopie unter dem BASIC ROM) eine Rolle spielen, von daher brauchts die Multipart-Fassung eher nicht mehr.
Ich finde auch keine Korrekturmeldung zu Crazy Jumpman in irgendeiner online verfügbaren Ausgabe von "Mein Home-Computer", von daher frage ich mich, ob sich des Problems vor mir überhaupt jemals jemand angenommen hat. Wenn nicht, ist das wohl die erste gefixte Release dieses Spiels, seit es 1984 veröffentlicht wurde
Das ist ja ein Ding, vielen Dank fürs Nachforschen! Ich frage mich schon, wie das passieren konnte. Das Listing wird ja automatisch aus dem Originalprogramm erzeugt worden sein und das wiederum aus dem Quelltext. Ich kann mir nur vorstellen, dass da durch irgendein POKE versehentlich eine Speicherstelle geändert wurde und das dann keiner gemerkt hat. Wirft aber schon kein gutes Licht auf die Qualitätssicherung bei HC
Ist der "Peter Menke" aus Brunsbüttel vielleicht hier auch unterwegs, so dass wir ihn fragen können?
Viele der Listings damals, gerade die BASIC-Teile, waren teilweise buggy. Manchmal nur Kleinigkeiten, aber öfter als einmal schon mal eine ganze Ecke mehr kaputt.
nunja, wenn man dein Image aus dem Eingangspost startet zeigt an: (EINEN Fehler gefunden !
Also ich hab das immer als Keinen Fehler gefunden interpretiert…
Wow! Das ist Spitze (samt Luftsprung)!
Bedeutet das jetzt auch, dass man einen Level, den man ladet auch nochmals editieren kann? Das würde dann auch mein Problem damit beseitigen!
Wie kann man Peter Menke erreichen? Der würde sich sicher über den Fix freuen…
Also ich hab das immer als Keinen Fehler gefunden interpretiert…
Heißt es auch. pgeorgi hat ja geschrieben, dass der Wert richtig abgetippt und auch so in der Prüfsumme berücksichtigt ist, nur war er halt schon bei Erstellung des Listings falsch.
Ich kann mir nur vorstellen, dass da durch irgendein POKE versehentlich eine Speicherstelle geändert wurde
Mittlerweile ist mir noch eingefallen, dass 133 -> 137 auch ein gekipptes Bit sein könnte.
