Treiber-Software , aber wie ??

Es gibt 57 Antworten in diesem Thema, welches 9.429 mal aufgerufen wurde. Der letzte Beitrag (30. Mai 2012 um 12:15) ist von CotS.

  • da ist bestimmt was schiefgelaufen , beim bearbeiten im Monitor. Vieleicht mache ich das falsch mit dem Befehl M 1002 bzw. M1003...?

    Merkwürdig ist erst mal, dass die beiden Bytes (09 80) in deiner bearbeiteten Version enthalten sind. Daher wird der Fehler dann eher auf meiner Seite liegen, wenn du nicht gerade vor der Prozedur auf dem C64 der Datei am PC schon zwei Bytes hinzugefügt hast.


    Deines klappt !

    Fein. :)

  • Hallo Cat,
    hallo trb,

    es ist folgendes passiert:

    Du hast die "Original-Datei" (Jann Version) genommen und an die Adresse $1004 per SMON geladen.
    Diese beginnt mit HxD (Hexeditor) betrachtet wie folgt:

    09 80 5E FE C3 C2 CD 38 30 ....

    Genau so, mit insgesamt 16384 Bytes (16KByte = 27(C)128 EProm) müssen die Daten auf dem EProm landen, kein Byte mehr und kein Byte weniger!
    Dadurch, dass Cat die Datei nicht an die Stelle $1002 sondern $1004 geladen hat, hat sie nun unabsichtlich zwei Bytes zu viel eingefügt!

    Ich meine die "Original-Datei" hätte per SMON an die Adresse $1002 geladen werden müssen, wie von trb ursprünglich vorgeschlagen!
    Dann per SMON wieder abspeichern und zwar von $1000 bis einschließlich $5001, dies ergibt 16386 Bytes (16384 Byte + 2 Byte ($00, $10) Ladeadresse.
    Und wenn der QB-II sich dann beim Laden der .bin-Datei (PRG auf Disk) verhält wie ich vermute, werden die zwei Bytes am Anfang der PRG-Datei als Ladeadresse interpretiert und verworfen.
    Die restlichen dann genau noch 16384 Byte werden auf das EProm geschrieben und die Welt ist in Ordnung!

    Ich hoffe das war verständlich und ich habe mich hoffentlich nicht auch noch vertan, verrechnet, etc. :anonym


    Have fun...

    TheChief

    PS: 230 Volt können verdammt tötlich sein aber nur einmal pro Person... :bgdev

  • Hm, vielleicht sehe ich meinen eigenen Denkfehler nicht? Wenn man die BIN-Datei (also die ohne Commodore-Ladeadresse) auf dem C64 in den Speicher lädt, werden die ersten beiden Bytes als Ladeadresse interpretiert, sprich: diese Bytes finden sich nach dem Laden nicht im C64 wieder (in diesem Fall also: 09 80). Neben diesen beiden Bytes, die durch das Laden der BIN-Datei auf dem C64 verloren gehen, muss der BIN-Datei aufgrund des DOS noch eine Ladeadresse hinzugefügt werden, also weitere zwei Bytes. Insofern sehe ich meinen Fehler nicht, falls ich einen gemacht habe in der Anleitung.

  • Jetzt verstehe ich auch meinen Denkfehler. TheChief hat vollkommen recht, aber die Nacht war zu weit fortgeschritten, als dass ich die Antwort noch begriffen hätte: Am C64 ist es natürlich unnötig, bei einer ins RAM geladenen Datei eine Ladeadresse hinzuzufügen. Das geschieht beim Speichern automatisch.

  • Also heisst das nur laden, speichern (nix hinzufügen ? auch nicht 09 80 ?) und dann brennen ?

    LG
    Cat

  • Doch, die beiden Bytes müssen hinzugefügt werden, da sie beim Laden verschwinden bzw. als Ladeadresse interpretiert werden. Aber es müssen keine weiteren Bytes ergänzt werden. Also BIN-Datei nach $1002 laden, die nun fehlenden Bytes ergänzen und alles speichern von $1000 bis einschließlich $5001 (bedeutet also S"FILE",8,1000,5002).

  • Ühh ?? Wieso denn nicht S"FILE" 1000 5001 ? (,8 kann man bei S-MON weglassen).

    LG
    Cat

  • Weil es sich - warum, wieso auch immer - als Standard etabliert hat, in einem Monitor beim abzuspeichernden Adressbereich die Endadresse als Endadresse+1 anzugeben. Wird bei SMON bestimmt auch so sein.

  • Ok, das ist dann wieder Insider-Wissen. die 1000 muss ich nicht als Startadresse angeben ?

    PS: habe mich übrigens im HEX-Editor gleich ran gemacht und das Ding auf Deutsch "übersetzt", also
    die Masken und Befehle, wo es ging... :whistling:

  • Beim Speichern bekommt die Datei automatisch als Ladeadresse $1000, weil du ab dieser Adresse speicherst. Die Ladeadresse ist für QBII aber prinzipiell egal, weil jede Datei dort immer in den dafür vorgesehenen Bereich geladen wird (zufälligerweise ist der auch ab $1000).

  • ok !!
    Kann ich die Datei eigentlich auch im VICE z.B. "laufen"-lassen, um mir z.B. anzusehen, ob ich beim Übersetzen was versemmelt habe ?
    Wenn ja ,wie ??

    LG
    CAT

  • Meines Wissens geht das nicht, da das niemand umgesetzt hat. Wäre ja auch nicht sonderlich sinnvoll. Bitte melde dich an, um diesen Link zu sehen. kann man nachlesen, welche Cartridge-Typen emulationstechnisch überhaupt irgendwie vorkommen.

  • Zitat

    Kann ich die Datei eigentlich auch im VICE z.B. "laufen"-lassen, um mir z.B. anzusehen, ob ich beim Übersetzen was versemmelt habe ?
    Wenn ja ,wie ??


    du kannst versuchen es mal als normales 8k bzw 16k gamecartridge zu starten.... viele software von epromkarten und -brennern läuft so prinzipiell.

  • du kannst versuchen es mal als normales 8k bzw 16k gamecartridge zu starten.... viele software von epromkarten und -brennern läuft so prinzipiell.

    Ne, das funktioniert leider nicht.

  • PS: habe mich übrigens im HEX-Editor gleich ran gemacht und das Ding auf Deutsch "übersetzt", also
    die Masken und Befehle, wo es ging... :whistling:


    Das funktioniert meistens nicht weil Original und Übersetzung üblicherweise unterschiedliche Längen haben und spätestens dann der nachfolgende Code wegen falscher Sprungadressen nicht mehr funktioniert.

    Wenn mit C64 Eproms gebrannt werden sollen muss die Datei am Anfang zwei Bytes (und das ist egal was da drinsteht) als Ladeadresse haben, diese werden dann durch das Brennprogramm ignoriert.
    Oder andersrum wird eine Datei ohne diese Ladeadresse benutzt werden die ersten 2 Byte ignoriert und das ganze Programm im Eprom funktioniert nicht weil sich der Offset um 2 Bytes verschiebt.

  • Das funktioniert meistens nicht weil Original und Übersetzung üblicherweise unterschiedliche Längen haben und spätestens dann der nachfolgende Code wegen falscher Sprungadressen nicht mehr funktioniert.


    Hi, bin ja nicht doof - ;-)) - das habe ich beachtet und bin mit der Übersetzung immer im "Rahmen" geblieben, also nix überschrieben oder so. Hat gut geklappt. Ein Testbrand mit 'nem 128er Eprom war erfolgreich. Meisst bin ich mit dem Deutsch "kürzer" als die engl Vorgaben und da bleibt sogar noch Platz ...

    LG
    Cat

  • Ich danke euch für die Hilfe !!

    LG
    Cat