cbm_load friert ein.

Es gibt 13 Antworten in diesem Thema, welches 1.731 mal aufgerufen wurde. Der letzte Beitrag (9. Dezember 2013 um 18:33) ist von Vernunftmensch.

  • In seltenen Fällen stürzt das hier ab. D.h. es friert der Bildschirm ein, die Lampe vom Laufwerk leuchtet dauern, aber das Laufwerk ist auch eingefroren, was ich an den Zahlen neben dem roten Licht sehe. Siehe Bild.

    Ich bin für jede Hilfe dankbar.

  • So auf den ersten Blick frage ich mich, warum zwischen Zeile 13 und 19 die vom System evtl. geänderte Zeropage nicht wieder gesichert wird. Du sicherst die ZP nur einmal ganz am Anfang und stellst vor jedem Load-Aufruf den gleichen Zustand wieder her? Die Abstürze müssen nicht daran liegen, aber das klingt ziemlich pappnasig.

    EDIT: Ach ja, und statt "___zp_retten2", "___zp_wiederherstellen" und "___zp_wiederherstellen2" würde ich Labelnamen wie "zp_to_own_buffer", "sys_buffer_to_zp" und "own_buffer_to_zp" vorschlagen. Und bevor Dir wieder der Speicher platzt, ersetz die vier Funktionen durch eine einzige namens "exchange_real_and_buffered_zp".

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Zitat

    So auf den ersten Blick frage ich mich, warum zwischen Zeile 13 und 19 die vom System evtl. geänderte Zeropage nicht wieder gesichert wird.

    Wenn ich die von cbm_load veränderte ZP abspeichere, bekomme ich seltsame Fehler.

    Zitat

    EDIT: Ach ja, und statt "___zp_retten2", "___zp_wiederherstellen" und "___zp_wiederherstellen2" würde ich Labelnamen wie "zp_to_own_buffer", "sys_buffer_to_zp" und "own_buffer_to_zp" vorschlagen. Und bevor Dir wieder der Speicher platzt, ersetz die vier Funktionen durch eine einzige namens "exchange_real_and_buffered_zp".

    Wenn es stabil läuft, dann mache ich mich daran.

    Soll ich ein Kopfgeld von 20€ auf den Bug anbieten? :hammer:

  • Wenn ich die von cbm_load veränderte ZP abspeichere, bekomme ich seltsame Fehler.

    Das ist zu präzise, geht es vielleicht einen Hauch nebulöser?
    War aber eine gute Idee, diese Probleme im Ursprungsposting nicht zu erwähnen, die hätten potentielle Helfer sicher nur verwirrt.

    Wer Ironie findet, darf sie behalten... :bgdev

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Zitat


    Das ist zu präzise, geht es vielleicht einen Hauch nebulöser?
    War aber eine gute Idee, diese Probleme im Ursprungsposting nicht zu erwähnen, die hätten potentielle Helfer sicher nur verwirrt.

    Es spukt, Darstellungsfehler bis hin zum Absturz.

    Im Anschluß sowohl die engine_mit.d64 und die ohne Rettungszeile engine.d64.

  • du musst vor dem aufrufen von LOAD die interruptquellen abschalten. das SEI vorher ist sinnlos, weil die IEC routinen intern selbst SEI/CLI machen.

  • Sind damit alle IRQ-Quellen aus?

  • nein.

    Edit: Aus Versehen auf Absenden geklickt :)

    um sämtliche möglichen Interruptquellen von CIABitte melde dich an, um diesen Link zu sehen. abzuwürgen musst du da $7f reinpoken, nicht $81. Das schaltet nur den Timer A Interrupt ein.

  • stürzt ebenfalls ab. Im Anhang die passende .d64.

  • so schaltet mal alle irq (und nmi) ab:

    (und mit kommentaren weiss man auch wann man was warum nacht...)

    aber erwartet der kenral nicht dass gewisse irq's laufen? bin da nicht so drinne - mag den kernal nicht so wirklich...

  • erwartet der kenral nicht dass gewisse irq's laufen?


    von IEC laden sollte gehen wenn alles aus ist (entweder tape oder rs232 brauchte die.... glaub ich =P)

  • Zitat

    so schaltet mal alle irq (und nmi) ab

    Interruptquellen sind damit abgeschaltet.
    Also ich habe jetzt im Vice x64.exe mehrmals das Tutorial mit Präziser Floppyemulation durch, keine Fehler.
    Aber im x64sc.exe kam ich bei mehreren Versuchen nicht ins Endlevel, weil vorher was mit dem Laden schief lief.

    Woran könnte das liegen?