Der Kernel - Software-Interrupts

Abstellen von Interrupts

Weit schwieriger als die Initialisierung eines (regelmäßigen) Ereignisses gestaltet sich das Abstellen. Hier muss man nämlich mehrere Ebenen berücksichtigen:

Die Interrupt-Quelle abstellen

Die 'fast ticker Datenspeicherung und Datenstrukturen: Chainschain' und die 'frame flyback Datenspeicherung und Datenstrukturen: Chainschain' des MAIN FIRMWARE JUMPBLOCK: KERNEL
Die Firmware des Schneider CPC: KERNELKernel ermöglichen es zunächst einmal nur, BCEF: KL INIT EVENT: EventblockEventblocks einzuhängen, die fortlaufend gekickt werden. In der 'ticker Datenspeicherung und Datenstrukturen: Chainschain' kann man durch den Reload-Wert Real: NullNull erreichen, dass der BCEF: KL INIT EVENT: EventblockEventblock nur einmal angestoßen wird. Trotzdem verbleibt auch hier der 'ticker Die Speicherkonfiguration im Schneider CPC: Blockblock' in der Trees: ListenListe. Eine Bearbeitung der 'ticker Datenspeicherung und Datenstrukturen: Chainschain' führt auch weiterhin zu geringen Zeitverlusten, weil sich der MAIN FIRMWARE JUMPBLOCK: KERNEL
Die Firmware des Schneider CPC: KERNELKernel ständig an diesem Die Speicherkonfiguration im Schneider CPC: BlockBlock vorbeihangeln muss.

Über die Vektoren &KERNEL: BCDD: KL DEL FRAME FLYBCDD KL DEL FRAME FLY, &KERNEL: BCE6: KL DEL FAST TICKERBCE6 KL DEL FAST TICKER und &KERNEL: BCEC: KL DEL TICKERBCEC KL DEL TICKER kann man die Die Speicherkonfiguration im Schneider CPC: BlockBlocks wieder vollständig aus den Interrupt-verursachenden Trees: ListenListen aushängen. Das kann auch die Event-Behandlungs-Routine selbst machen, wenn es nicht gerade ein express asynchrones Der Kernel - Software-Interrupts: EventsEvent ist.

Dadurch werden keine weiteren Kicks mehr erzeugt. Es kann aber sein, dass noch einige Kicks auf ihre Ausführung warten. Die würden dann trotzdem noch ausgeführt.

Bei Der Kernel - Software-Interrupts: Synchrone Eventssynchronen Events kann man dabei sowohl vom Haupt-Programm als auch von der Behandlungs-Routine aus nie sicher sein, dass in der 'synchronous pending queue' nicht noch ein Der Kernel - Software-Interrupts: EventsEvent wartet, wenn man die Interrupt-Erzeugung abgestellt hat.

Bei asynchronen Der Kernel - Software-Interrupts: EventsEvents existiert das Problem nur, wenn die Interrupt-Routine sich selbst aushängen will. Das Hauptprogramm hingegen kann sicher sein, dass, wenn es den Die Speicherkonfiguration im Schneider CPC: BlockBlock aus der Trees: ListenListe entfernt hat, auch keine Der Kernel - Software-Interrupts: EventsEvents mehr warten. Der MAIN FIRMWARE JUMPBLOCK: KERNEL
Die Firmware des Schneider CPC: KERNELKernel übergibt nach einem (Hardware-) Alle noch folgenden Anschlüsse fallen unter die Rubrik STEUER- oder auch CONTROLBUS:: INT - InterruptInterrupt die Kontrolle ja erst dann wieder an das Hauptprogramm zurück, wenn alle gekickten, asynchronen Der Kernel - Software-Interrupts: EventsEvents abgearbeitet sind und die 'asynchronous pending queue' leer ist.

Es kann nur sein, dass die asynchrone Routine so oft gekickt wird und so viel Rechenzeit verbraucht, dass das Hauptprogramm überhaupt nicht mehr zum Zug kommt! (Das sollte man wohl immer vermeiden.)

Break- und Sound-Events sind von Natur aus nur 'one shots', so dass sich hier ein Abstellen erübrigt. Vielmehr lebt man hier in ständiger Sorge, dass die Event-Blocks auch immer wieder scharf gemacht werden, wenn sie einmal losgegangen sind.

Behandlung abstellen

Sollen auch noch die ausstehenden Kicks ignoriert werden, muss man die BCEF: KL INIT EVENT: EventblockEventblocks selbst ruhigstellen.

Bei asynchronen Der Kernel - Software-Interrupts: EventsEvents tritt dieses Problem, wie gesagt, nur auf, wenn das die Interrupt-Routine selbst machen will. Das kann nötig sein, wenn ein 'one shot' programmiert werden soll.

Express asynchrone Der Kernel - Software-Interrupts: EventsEvents können sich selbst nur ruhigstellen, indem sie das Zähl- und Steuerbyte im BCEF: KL INIT EVENT: EventblockEventblock auf einen negativen Wert (-64) setzen. Normale, asynchrone Der Kernel - Software-Interrupts: EventsEvents können das auch machen. Alternativ dazu können sie aber auch den Vektor &KERNEL: BD0A: KL DISARM EVENTBD0A KL DISARM EVENT aufrufen, der aber nichts anderes macht. Dadurch können zwar auch weiterhin Kicks eintreffen. Sie führen aber nicht mehr dazu, dass das Der Kernel - Software-Interrupts: EventsEvent 'erfolgreich' angestoßen wird. Die eintreffenden Kicks werden einfach ignoriert.

Schliesst die asynchrone Event-Routine mit 'RET' ab, landet die Die ICs im Überblick: Die CPU Z80
Das Innenleben der CPC-Rechner: Die CPU Z80
Die Anschlussbelegungen der wichtigsten ICs im CPC: Die CPU Z80CPU wieder beim MAIN FIRMWARE JUMPBLOCK: KERNEL
Die Firmware des Schneider CPC: KERNELKernel, der die 'asynchronous pending queue' gerade pollt. Der testet nun genau das Zählbyte und sieht, dass keine Kicks mehr ausstehen und hängt den BCEF: KL INIT EVENT: EventblockEventblock aus der Queue aus. Fertig.

Bei Der Kernel - Software-Interrupts: Synchrone Eventssynchronen Event sieht die Sache etwas anders aus. Hier langt es nicht, den BCEF: KL INIT EVENT: EventblockEventblock durch Negativ-Setzen des Zählbytes kaltzustellen. Wenn sich der BCEF: KL INIT EVENT: EventblockEventblock zu diesem Zeitpunkt in der 'synchronous pending queue' befindet, wird er beim nächsten Pollen trotzdem aufgerufen, der MAIN FIRMWARE JUMPBLOCK: KERNEL
Die Firmware des Schneider CPC: KERNELKernel testet nicht, ob ein Die Speicherkonfiguration im Schneider CPC: BlockBlock, der in dieser Der Key Manager: WarteschlangeWarteschlange eingetragen ist, nicht vielleicht abgeschaltet wurde. (Liebe Leute von Amstrad: Das könnte er aber ruhig machen!)

Hier muss man den Vektor &KERNEL: BCF8: KL DEL SYNCHRONOUSBCF8 KL DEL SYNCHRONOUS aufrufen, der den BCEF: KL INIT EVENT: EventblockEventblock ruhigstellt (indem er das Zählbyte auf -64 setzt) und gegebenenfalls auch aus der 'synchronous pending queue' entfernt.

sukzessive Initialisierung

Bevor ein BCEF: KL INIT EVENT: EventblockEventblock erneut initialisiert werden darf, muss er abgeschaltet und aus seiner 'pending queue' entfernt sein. Sonst kommt der MAIN FIRMWARE JUMPBLOCK: KERNEL
Die Firmware des Schneider CPC: KERNELKernel mit seinen Trees: ListenListen durcheinander. Bei Der Kernel - Software-Interrupts: Synchrone Eventssynchronen Events kann das die Event-Routine selbst machen, wenn sie vorher KERNEL: BCF8: KL DEL SYNCHRONOUSKL DEL SYNCHRONOUS aufruft.

Bei asynchronen Der Kernel - Software-Interrupts: EventsEvents geht das jedoch nicht, weil KERNEL: BD0A: KL DISARM EVENTKL DISARM EVENT nur das Zählbyte auf -64 setzt, um den Die Speicherkonfiguration im Schneider CPC: BlockBlock kaltzustellen. Der Die Speicherkonfiguration im Schneider CPC: BlockBlock kann durchaus noch in der 'asynchronous pending queue' sein. Asynchrone Der Kernel - Software-Interrupts: EventsEvents können also nur durch das Hauptprogramm erneut initialisiert werden.

Wenn man den BCEF: KL INIT EVENT: EventblockEventblock selbst mit neuen Werten beschickt, muss man sicherstellen, dass er in der Zwischenzeit nicht gekickt werden kann. Am besten hängt man dazu den Event-verursachenden Die Speicherkonfiguration im Schneider CPC: BlockBlock aus der entsprechenden Ticker Datenspeicherung und Datenstrukturen: ChainsChain aus. Wenn das nicht geht, oder wem das zu umständlich ist, der muss darauf achten, dass das Zählbyte als letztes auf Real: NullNull gesetzt, oder für diese Zeit den Alle noch folgenden Anschlüsse fallen unter die Rubrik STEUER- oder auch CONTROLBUS:: INT - InterruptInterrupt verboten wird.