Hallo Dietrich,

Dietrich hat geschrieben:@Alexander: Das ist ein Missverständnis: BOF schaltet Modul und BASIC aus, BON schaltet das Modul aus und das BASIC an. Ein einfacher Poke, der das Modul abschaltet, wäre also ausreichend gewesen, damit BON und BOF funktionieren. Zwar schade, aber so schlimm ist das nun auch wieder nicht. Super ist jedenfalls, dass soooo viele Tools auf dem UUC drauf sind. Und sogar mit einem schicken Auswahlmenü

Danke

Welche Stellen hast Du insgesamt eigentlich genau wie gepatcht und welche "nicht offiziellen" OS-Routinen rufst Du auf? Wie schaltet man das Modul an (so dass bei Reset das Auswahlmodul kommt) und wie schaltet man es aus? Dann kann ich u.U. beim QMEG-OS 4.1 darauf Rücksicht nehmen.

Ich muß ehrlich gesagt noch einmal nachschauen. Es war nur für dieses Modul und danach eigentlich auch nicht wieder nötig, ein DOS mit einzubauen und von daher erwischt Du mich jetzt etwas kalt. Ich melde mich auf jeden Fall noch mal bei Dir.

Viele Grüße
Alexander

Gruß Dietrich

Hi!

Jürgen hat mir gestern gemailt, daß mit meinem neuen Patch (fast) alle Programme auf der Cart laufen, nur MyDos hängt sich beim Starten auf.

Könnte es sein, daß da evtl. ein SIO-Aufruf mit dem RAM OS passiert?

Andere Kandidaten wären sonst der Keyboard Interrupt, da patche ich $FC20 von "LDA $D409" auf "JSR $CFB8", oder der PowerUp (Reset) Code - da patche ich $C2B3 von "LDA $033D" auf "JMP $CC18".

so long,

Hias

Hi,

ich habe seit heute Nachmittag das Hias OS (1.30) im XE. Zum Testen war noch nicht viel Zeit, dass kommt Morgen dran. Bislang sieht es aber gut aus. Einzieg die Hotkey's gehen ab und an nicht. Da muss ich aber noch genauer hinsehen.

(Mit dem Spos 1.36N scheint das UUC gar nicht wollen )

Hi,

HiassofT hat geschrieben:Hi!

Jürgen hat mir gestern gemailt, daß mit meinem neuen Patch (fast) alle Programme auf der Cart laufen, nur MyDos hängt sich beim Starten auf.

Könnte es sein, daß da evtl. ein SIO-Aufruf mit dem RAM OS passiert?

Sicherlich setzen MyDOS und XDOS entsprechende SIO Aufrufe ab. Bei einigen Anwendungen geschieht dies bei aktivem RAM OS.

Andere Kandidaten wären sonst der Keyboard Interrupt, da patche ich $FC20 von "LDA $D409" auf "JSR $CFB8",
oder der PowerUp (Reset) Code - da patche ich $C2B3 von "LDA $033D" auf "JMP $CC18".

Ich hole mir maximal den Scancode über 0xD209 (nur im Menu) und verarbeite diesen direkt. Das sollte eigentlich keinen Schwierigkeiten machen. Einen Reset veranlasse ich auch nur über die Systemadresse (0xe474).

Interrupts schalte ich während des kopierens/entpackens auch ab. Gerade Eingaben von der Tastatur machen tierisch Stress. ;-(

Viele Grüße
Alexander

so long,

Hias

Hi,

HiassofT hat geschrieben:Hi!

Jürgen hat mir gestern gemailt, daß mit meinem neuen Patch (fast) alle Programme auf der Cart laufen, nur MyDos hängt sich beim Starten auf.

Könnte es sein, daß da evtl. ein SIO-Aufruf mit dem RAM OS passiert?

Sicherlich setzen MyDOS und XDOS entsprechende SIO Aufrufe ab. Bei einigen Anwendungen geschieht dies bei aktivem RAM OS.

Andere Kandidaten wären sonst der Keyboard Interrupt, da patche ich $FC20 von "LDA $D409" auf "JSR $CFB8",
oder der PowerUp (Reset) Code - da patche ich $C2B3 von "LDA $033D" auf "JMP $CC18".

Ich hole mir maximal den Scancode über 0xD209 (nur im Menu) und verarbeite diesen direkt. Das sollte eigentlich keine Schwierigkeiten machen. Einen Reset veranlasse ich im übrigen auch nur über einen Sprung auf die hierfür vorgesehene Adresse (0xe474).

Interrupts schalte ich während des kopierens/entpackens auch ab. Gerade Eingaben von der Tastatur machen tierisch Stress. ;-(

Viele Grüße
Alexander

so long,

Hias

Hallo Alexander!

Koche hat geschrieben:

HiassofT hat geschrieben:Könnte es sein, daß da evtl. ein SIO-Aufruf mit dem RAM OS passiert?

Sicherlich setzen MyDOS und XDOS entsprechende SIO Aufrufe ab. Bei einigen Anwendungen geschieht dies bei aktivem RAM OS.

Danke für die Info, das wird dann wohl die Ursache sein.

Interrupts schalte ich während des kopierens/entpackens auch ab. Gerade Eingaben von der Tastatur machen tierisch Stress. ;-(

Was für Probleme hattest Du denn da? (ja, ich bin ein neugieriger Mensch :-)

Den meisten "Stress" hatte ich bisher eigentlich beim vorübergehenden Einschalten des Moduls, wenn im VBI TRIG3 mit GINTLK verglichen wird (und sich das XL-OS dann in eine gemütliche Endlosschleife begibt wenn es da einen Unterschied feststellt).

Das ließ sich aber auch recht einfach lösen (ohne irgendwelche Interrupts sperren zu müssen): ein einfaches "INC CRITIC" vor dem Code der das Modul einschaltet, und dann ein "DEC CRITIC" nachdem das Modul wieder abgeschaltet wurde - den TRIG3/GINTLK Check macht das OS im Deferred VBI und der wird garnicht erst ausgeführt wenn CRITIC gesetzt ist :-)

so long,

Hias

Hias hat geschrieben:Den meisten "Stress" hatte ich bisher eigentlich beim vorübergehenden Einschalten des Moduls, wenn im VBI TRIG3 mit GINTLK verglichen wird (und sich das XL-OS dann in eine gemütliche Endlosschleife begibt wenn es da einen Unterschied feststellt).

Dieses Problem kommt mir auch sehr bekannt vor. Ist meist die Ursache, wenn meine Modulsoftware mal mit dem QMEG-OS läuft, aber nicht mit dem XL-OS

HiassofT hat geschrieben:Hallo Alexander!

Koche hat geschrieben:

HiassofT hat geschrieben:Könnte es sein, daß da evtl. ein SIO-Aufruf mit dem RAM OS passiert?

Sicherlich setzen MyDOS und XDOS entsprechende SIO Aufrufe ab. Bei einigen Anwendungen geschieht dies bei aktivem RAM OS.

Danke für die Info, das wird dann wohl die Ursache sein.

Interrupts schalte ich während des kopierens/entpackens auch ab. Gerade Eingaben von der Tastatur machen tierisch Stress. ;-(

Was für Probleme hattest Du denn da? (ja, ich bin ein neugieriger Mensch

"tierisch Stress" war etwas überzogen , aber der Entpacker verfranzt sich grundsätzlich wenn der Keyboardintr. aktiv ist und jemand auf die Tasten haut.

Den meisten "Stress" hatte ich bisher eigentlich beim vorübergehenden Einschalten des Moduls, wenn im VBI TRIG3 mit GINTLK verglichen wird (und sich das XL-OS dann in eine gemütliche Endlosschleife begibt wenn es da einen Unterschied feststellt).

Das ließ sich aber auch recht einfach lösen (ohne irgendwelche Interrupts sperren zu müssen): ein einfaches "INC CRITIC" vor dem Code der das Modul einschaltet, und dann ein "DEC CRITIC" nachdem das Modul wieder abgeschaltet wurde - den TRIG3/GINTLK Check macht das OS im Deferred VBI und der wird garnicht erst ausgeführt wenn CRITIC gesetzt ist

Ich weiß und hatte ich ursprünglich auch eingebaut. Ich setze aber in meinem eigenen iVBI (der ist nur für die Dauer der "Programmedatenschaufelei" aktiv) GINTLK = TRIG3 und konnte es daher entfernen.

Viele Grüße
Alexander

so long,

Hias