KERNELDie Zentrale BCC8: KL CHOKE OFFSetze den MAIN FIRMWARE JUMPBLOCK: KERNEL Eingaben: keine Ausgaben: LOW KERNEL JUMPBLOCK: 000B: LOW KL LOW PCHL KERNEL: BCC8: KL CHOKE OFFKL CHOKE OFF wird hauptsächlich von &MACHINE PACK: BD13: MC BOOT PROGRAMBD13 MC BOOT PROGRAM benutzt, und dafür sind auch die Ausgabe-Parameter gedacht. Schlägt ein Lade-Vorgang Der Linien-Algorithmus: Fehler 3fehl, orientiert sich MACHINE PACK: BD13: MC BOOT PROGRAMMC BOOT PROGRAM an diesen Werten von KERNEL: BCC8: KL CHOKE OFFKL CHOKE OFF, um zu einem lauffähigen Vordergrund-Programm zurückzukehren. Sind C und DE gleich Real: NullNull, so erfolgte der Aufruf von einem anderen RAM-Vordergrund-Programm aus. MACHINE PACK: BD13: MC BOOT PROGRAMMC BOOT PROGRAM kehrt im Fehlerfall dann zum Default-Vordergrund-ROM 0 (Basic-ROM) zurück. KERNEL: BCC8: KL CHOKE OFFKL CHOKE OFF löscht die Synchronous-Pending-Queue und alle Ticker-Chains bis auf die Der Kernel - Software-Interrupts: EventsEvents des Sound-Managers und der Der Key Manager: Tastatur-AbfrageTastatur-Abfrage. Außerdem wird der Alle noch folgenden Anschlüsse fallen unter die Rubrik STEUER- oder auch CONTROLBUS:: INT - InterruptInterrupt verboten, was aber bei Aufruf über diesen Vektor (der mit einem ROM-Konfiguration: RestartsRestart gebildet ist) nicht weiter interessiert, da dieser Alle noch folgenden Anschlüsse fallen unter die Rubrik STEUER- oder auch CONTROLBUS:: INT - InterruptInterrupts ja wieder zulässt. BCCB: KL ROM WALKSuche und initialisiere alle Speicheraufteilung durch ein Vordergrund-Programm: Hintergrund-ROMsHintergrund-ROMs. Eingaben: DE=Adresse des 1. Datentypen: Bytes CPC 464: Es werden alle ROM-Nummern von 1 bis 7 abgeklappert. Jedes Speicheraufteilung durch ein Vordergrund-Programm: Hintergrund-ROMsHintergrund-ROM (Kennung &01 auf Adresse &C000) wird initialisiert. CPC 664 und 6128: Es werden alle ROMs-Nummern von 0 bis 15 berücksichtigt. Vor der Initialisierung eines Speicheraufteilung durch ein Vordergrund-Programm: Hintergrund-ROMsHintergrund-ROMs wird noch getestet, ob es nicht vielleicht das laufende Vordergrund-ROM ist, das sich dann nicht wieder selbst initialisieren darf. Das ist interessant weil das AMSDOS-ROM, das als Speicheraufteilung durch ein Vordergrund-Programm: Hintergrund-ROMsHintergrund-ROM normalerweise die ROM-Select-Adresse 7 hat, nach Durchtrennen einer einzigen Leiterbahn auf der Platine zum Power-Up-ROM mit der ROM-Adresse 0 wird (und das Basic-ROM auf dieser Adresse ausblendet). Durch eine entsprechende Programmierung der Initialisierungs-Routine dieses Erläuterung zu den Anschlüssen 40 bis 45: 42 - ROMEN (0)ROMs wird der Schneider CPC damit zum CP/M-Rechner. Obwohl dieses Erläuterung zu den Anschlüssen 40 bis 45: 42 - ROMEN (0)ROM jetzt immer noch im ROM-Header als Speicheraufteilung durch ein Vordergrund-Programm: Hintergrund-ROMsHintergrund-ROM deklariert ist, ist es jetzt de facto das laufende Vordergrund-ROM. Die Erläuterung zu den Anschlüssen 40 bis 45: 42 - ROMEN (0)ROMs werden initialisiert, indem &KERNEL: BCCE: KL INIT BACKBCCE KL INIT BACK aufgerufen wird. Dort ist auch die Parameter: Parameter-ÜbergabeParameter-Übergabe beschrieben. BCCE: KL INIT BACKInitialisiere ein bestimmtes Speicheraufteilung durch ein Vordergrund-Programm: Hintergrund-ROMsHintergrund-ROM. Eingaben: C=ROM-Select-Adresse des gewünschten Erläuterung zu den Anschlüssen 40 bis 45: 42 - ROMEN (0)ROMs DE=Adresse des ersten Datentypen: Bytes CPC 464: Das gewünschte Erläuterung zu den Anschlüssen 40 bis 45: 42 - ROMEN (0)ROM wird nur initialisiert, wenn es sich auch um ein Speicheraufteilung durch ein Vordergrund-Programm: Hintergrund-ROMsHintergrund-ROM handelt, und die ROM-Select-Adresse im Bereich 1 bis 7 liegt. CPC 664 und 6128: Wie bei &KERNEL: BCCB: KL ROM WALKBCCB KL ROM WALK sind jetzt zusätzlich Erläuterung zu den Anschlüssen 40 bis 45: 42 - ROMEN (0)ROMs im Bereich 0 bis 15 erlaubt. Ebenfalls wird nun vorher getestet, ob das zu initialisierende Erläuterung zu den Anschlüssen 40 bis 45: 42 - ROMEN (0)ROM nicht vielleicht das laufende Vordergrund-ROM ist. Im Schneider CPC wird das frei verfügbare RAM dynamisch zugeteilt: Sobald der Rechner zurückgesetzt ist, wird das Vordergrund-Programm aufgerufen. Dabei übergibt der MAIN FIRMWARE JUMPBLOCK: KERNEL Es ist zu beachten, dass Speicheraufteilung durch ein Vordergrund-Programm: Hintergrund-ROMsHintergrund-ROMs nicht erwarten können, dass sie ihren RAM-Bereich immer an der selben Stelle zugeteilt bekommen! Als Erleichterung wird aber beim &0018 FAR Maschinencode über HIMEM: CALLCALL (LOW KERNEL JUMPBLOCK: 0018 - RST 3: LOW FAR CALLRST_3) in ein bestimmtes Erläuterung zu den Anschlüssen 40 bis 45: 42 - ROMEN (0)ROM immer das IY-Register auf den Wert gesetzt, den die Initialisierungs-Routine des Erläuterung zu den Anschlüssen 40 bis 45: 42 - ROMEN (0)ROMs im HL-Register zurückgegeben hatte. Alle Erläuterung zu den Anschlüssen 40 bis 45: 42 - ROMEN (0)ROMs müssen einen ROM-Header haben, der die ersten Datentypen: Bytes &C000 - DEFB ROMTYP - Vorder/Hintergrund/Erweiterungs-ROM
&C001 - DEFB MARKNR - Mark Number \
&C002 - DEFB VERSION - Version Number > Statistics
&C003 - DEFB MODIFI - Modification Level /
&C004 - ff - Resident System Extensions: external command tableExternal Command Table
Der erste Eintrag in der Tabelle externer Kommandos muss die Initialisierungs-Routine des entsprechenden Erläuterung zu den Anschlüssen 40 bis 45: 42 - ROMEN (0)ROMs sein. Der Aufbau dieser Tabelle ist bei &KERNEL: BCD1: KL LOG EXTBCD1 KL LOG EXT beschrieben. BCD1: KL LOG EXTMache dem MAIN FIRMWARE JUMPBLOCK: KERNEL Eingaben: BC zeigt auf Kommandotabelle
HL zeigt auf 4 Datentypen: Bytes
Maschinencode auf dem CPC: Resident System ExtensionsResident System Extensions (Maschinencode über HIMEM: RSXRSX) werden vom Hauptprogramm meist erst in's RAM nachgeladen und dann initialisiert. Solche Zusatzprogramme müssen ihre eigene Lage und die Lage ihrer Datenfelder mit dem Hauptprogramm selbst auskluengeln. Es ist dabei Aufgabe dieser Zusatzprogramme sich selbst dem MAIN FIRMWARE JUMPBLOCK: KERNEL Nach der Einbindung als Maschinencode über HIMEM: RSXRSX (mit diesem Vektor) sind diese Routinen aber dem MAIN FIRMWARE JUMPBLOCK: KERNEL Sowohl die Kommandotabelle als auch die freien 4 Datentypen: Bytes Die Kommandotabelle besteht aus zwei Teilen: 1. JumpblockDEFW BCD1: KL LOG EXT: 2. Namenstabelle (NAMTAB)NAMTAB - Zeiger auf die Namenstabelle
JP NAME1 - Vektor zum ersten Eintrag
JP NAME2 - Vektor zum zweiten Eintrag
....
2. Namenstabelle (NAMTAB)DEFM "name 1" DEFM "name 2" .... DEFB 0 Der BCD1: KL LOG EXT: 1. JumpblockJumpblock muss so viele Vektoren umfassen, wie in der Namenstabelle Namen eingetragen sind. Die Vektoren können auch mit ROM-Konfiguration: RestartsRestarts gebildet sein. Jeder Eintrag in der Namenstabelle kann bis zu 16 Buchstaben lang sein. Der letzte Buchstabe muss dabei jeweils mit &80 geodert sein (Datenbreite: Bits BCD4: KL FIND COMANDErfrage zum angegebenen Namen einer Maschinencode über HIMEM: RSXRSX oder eines Erläuterung zu den Anschlüssen 40 bis 45: 42 - ROMEN (0)ROMs die Ausführungsadresse und Speicherkonfiguration. Eingaben: HL zeigt auf den Kommando-Namen. Im letzten Buchstabe des Namens
muss Datenbreite: Bits
Die zurückgegebenen Werte sind geeignet, um mit &001LOW KERNEL JUMPBLOCK: 000B: LOW KL LOW PCHL Diese Routine durchsucht alle Kommandotabellen, ob sie nun von einer Maschinencode über HIMEM: RSXRSX stammen oder in einem Erläuterung zu den Anschlüssen 40 bis 45: 42 - ROMEN (0)ROM liegen. Dabei werden die zuletzt angefügten Tabellen zuerst durchsucht. Das ist wichtig, da bei gleichbenannten Routinen immer nur die erste gefunden wird. Die andere wird 'verdeckt'. Die Erläuterung zu den Anschlüssen 40 bis 45: 42 - ROMEN (0)ROMs werden von ROM-Nummer 0 an aufwärts durchsucht, bis zur ersten unbenutzten ROM-Nummer über 7 (CPC 464) bzw. 15 (CPC 664 oder 6128). Wird das Kommando in einem Vordergrund-ROM gefunden, wird ein Kaltstart dieses Programmes durchgeführt. Dann kehrt MAIN FIRMWARE JUMPBLOCK: KERNEL BCD7: KL NEW FRAME FLYInitialisiere einen Datenblock und füge ihn in die Trees: ListenListe aller Software-Unterbrechung bei jedem Strahlrücklauf des Bildschirms ein. Eingaben: HL zeigt auf den FRAME FLYBACK Die Speicherkonfiguration im Schneider CPC: BlockBLOCK LOW KERNEL JUMPBLOCK: 000B: LOW KL LOW PCHL Der mit HL angezeigt Die Speicherkonfiguration im Schneider CPC: BlockBlock wird entsprechend LOW KERNEL JUMPBLOCK: 000B: LOW KL LOW PCHL BCDA: KL ADD FRAME FLYFüge einen fertigen Datenblock in die Trees: ListenListe aller Software- Unterbrechung bei jedem Strahlrücklauf ein. Eingaben: HL zeigt auf den FRAME FLYBACK Die Speicherkonfiguration im Schneider CPC: BlockBLOCK
Ausgaben: keine
Unverändert: BC,IX,IY
Der mit HL angezeigte Die Speicherkonfiguration im Schneider CPC: BlockBlock muss fertig initialisiert sein und wird vom MAIN FIRMWARE JUMPBLOCK: KERNEL BCDD: KL DEL FRAME FLYEntferne einen Datenblock aus dieser Trees: ListenListe. Eingaben: HL zeigt auf den FRAME FLY Die Speicherkonfiguration im Schneider CPC: BlockBLOCK
Ausgaben: keine
Unverändert: BC,IX,IY
Wenn der angezeigte Die Speicherkonfiguration im Schneider CPC: BlockBlock in der FRAME FLYBACK Trees: ListenLISTE ist, wird er ausgehängt. Dadurch wird dieser Die Speicherkonfiguration im Schneider CPC: BlockBlock nicht mehr angestoßen. Handelt es sich um ein Der Kernel - Software-Interrupts: Synchrone Eventssynchrones Event, so können aber noch einige Alle noch folgenden Anschlüsse fallen unter die Rubrik STEUER- oder auch CONTROLBUS:: INT - InterruptInterrupts ausstehen, die noch abgearbeitet werden. Um auch das zu verhindern, muss man auch noch &KERNEL: BCF8: KL DEL SYNCHRONOUSBCF8 KL DEL SYNCHRONOUS aufrufen. BCE0: KL NEW FAST TICKERInitialisiere einen Datenblock und füge ihn in die Trees: ListenListe aller Software-Unterbrechung bei jedem Alle noch folgenden Anschlüsse fallen unter die Rubrik STEUER- oder auch CONTROLBUS:: INT - InterruptInterrupt ein. Eingaben: HL zeigt auf den FAST TICKER Die Speicherkonfiguration im Schneider CPC: BlockBLOCK LOW KERNEL JUMPBLOCK: 000B: LOW KL LOW PCHL Der durch HL angezeigt Die Speicherkonfiguration im Schneider CPC: BlockBlock wird entsprechend LOW KERNEL JUMPBLOCK: 000B: LOW KL LOW PCHL BCE3: KL ADD FAST TICKERFüge einen fertigen Datenblock in die Trees: ListenListe aller Software-Unterbrechungen bei jedem Alle noch folgenden Anschlüsse fallen unter die Rubrik STEUER- oder auch CONTROLBUS:: INT - InterruptInterrupt ein. Eingaben: HL zeigt auf den FAST TICKER Die Speicherkonfiguration im Schneider CPC: BlockBLOCK
Ausgaben: keine
Unverändert: BC,IX,IY
Wie &KERNEL: BCE0: KL NEW FAST TICKERBCE0 KL NEW FAST TICKER, nur dass der Die Speicherkonfiguration im Schneider CPC: BlockBlock bereits vollständig initialisert sein muss. BCE6: KL DEL FAST TICKEREntferne einen Datenblock aus dieser Trees: ListenListe. Eingaben: HL zeigt auf den FAST TICKER Die Speicherkonfiguration im Schneider CPC: BlockBLOCK
Ausgaben: keine
Unverändert: BC,IX,IY
Der durch HL angezeigt Die Speicherkonfiguration im Schneider CPC: BlockBlock wird aus der FAST TICKER Datenspeicherung und Datenstrukturen: ChainsCHAIN wieder ausgehängt, wenn er sich noch darin befindet. Dadurch wird die entsprechende Routine nicht mehr angestoßen. Bei Der Kernel - Software-Interrupts: Synchrone Eventssynchronen Events können aber noch Kicks ausstehen, die dann noch abgearbeitet würden. Um das zu verhindern, muss man auch noch &KERNEL: BCF8: KL DEL SYNCHRONOUSBCF8 KL DEL SYNCHRONOUS aufrufen. BCE9: KL ADD TICKERFüge einen Datenblock in die Trees: ListenListe des Universal-Timers ein. Eingaben: HL zeigt auf den TICKER Die Speicherkonfiguration im Schneider CPC: BlockBLOCK
DE = Startverzögerung (Count Down)
BC = Wiederholverzögerung (Reload Count)
Ausgaben: keine
Unverändert: BC,IX,IY
Der durch HL angezeigt Die Speicherkonfiguration im Schneider CPC: BlockBlock wird in die TICKER Datenspeicherung und Datenstrukturen: ChainsCHAIN eingehängt, wenn er sich nicht bereits darin befindet. Der im BCE9: KL ADD TICKER: TickerblockTickerblock enthaltene BCEF: KL INIT EVENT: EventblockEventblock muss vollständig initialisiert sein. Der BCE9: KL ADD TICKER: TickerblockTickerblock muss sich im zentralen RAM befinden und ist wie folgt aufgebaut: Tickerblock2 Datentypen: Bytes Der normale TICKER ist der universellste von allen Software-Timern: 50 mal in der Sekunde wird diese Trees: ListenListe abgearbeitet. Dabei wird zunächst nur der Count-Down-Wert heruntergezählt und dann erst die Routine angestoßen. Mit jedem Kick wird dann der Reload-Wert in den Count Down geladen, und dieser dann von neuem heruntergezählt. Ein Nachladewert 0 blockiert jedoch weitere Kicks. Der Die Speicherkonfiguration im Schneider CPC: BlockBlock verbleibt zwar in der Trees: ListenListe (und verbraucht nach wie vor Rechenzeit), wird aber nicht mehr angestoßen. Mit Hilfe dieses Mechanismus werden EVERY und AFTER in Einleitung: BASIC BCEC: KL DEL TICKEREntferne einen Datenblock aus der Trees: ListenListe des Universal-Timers. Eingaben: HL zeigt auf den TICKER Die Speicherkonfiguration im Schneider CPC: BlockBLOCK Ausgaben: CY=1 -> Der Die Speicherkonfiguration im Schneider CPC: BlockBlock war in der Trees: ListenListe DE enthält den verbliebenen Wert aus dem Count Down CY=0 -> Der Die Speicherkonfiguration im Schneider CPC: BlockBlock war nicht in der Trees: ListenListe Unverändert: BC,IX,IY Der mit HL adressierte Die Speicherkonfiguration im Schneider CPC: BlockBlock wird aus der TICKER Datenspeicherung und Datenstrukturen: ChainsCHAIN entfernt, wenn er in ihr eingehängt war. Dann enthält DE den Rest aus dem Count Down (entspricht dem Basic-Befehl REMAIN). Dadurch wird dieser Die Speicherkonfiguration im Schneider CPC: BlockBlock nicht mehr angestoßen. Bei Der Kernel - Software-Interrupts: Synchrone Eventssynchronen Events (wie Einleitung: BASIC BCEF: KL INIT EVENTFülle einen Event-Block vorschriftsmäßig mit den in Registern angegebenen Werten. Eingaben: HL zeigt auf den Der Kernel - Software-Interrupts: EventsEVENT Die Speicherkonfiguration im Schneider CPC: BlockBLOCK LOW KERNEL JUMPBLOCK: 000B: LOW KL LOW PCHL Der BCEF: KL INIT EVENT: EventblockEventblock wird mit den in LOW KERNEL JUMPBLOCK: 000B: LOW KL LOW PCHL Eventblock2 Datentypen: Bytes Der BCEF: KL INIT EVENT: EventblockEventblock ist normalerweise Teil eines TICKER, bzw. FAST TICKER oder FRAME FLYBACK Die Speicherkonfiguration im Schneider CPC: BlockBLOCKs. Auch für die Sound-Interrupts und das Break-Event muss so ein BCEF: KL INIT EVENT: EventblockEventblock eingerichtet werden. Bei Bedarf können auch EXTERNAL Alle noch folgenden Anschlüsse fallen unter die Rubrik STEUER- oder auch CONTROLBUS:: INT - InterruptINTERRUPTs mit Hilfe des Software-Interrupt-Mechanismus behandelt werden. Man muss dabei säuberlich zwischen den Interrupt-Quellarten (die gerade aufgelistet wurden) und den BCEF: KL INIT EVENT: Event-ArtEvent-Arten unterscheiden. Ist ein Der Kernel - Software-Interrupts: EventsEvent nämlich erst einmal angestoßen, sieht man nicht mehr, woher der Kick kam. Die BCEF: KL INIT EVENT: Event-ArtEvent-Art wird dabei in Datentypen: Bytes Event-ArtDatenbreite: Bits Anm.: Die Port C - Output: &F6xx: Bits 0 bis 3:Bits 1 bis 6 werden benutzt, um eine Art 'Gesamt- Priorität' zu bilden. Durch ein gesetztes Datenbreite: Bits BCF2: KL EVENTStoße einen Event-Block an. Dies führt zu einer Software-Unterbrechung. Eingaben: HL zeigt auf den Der Kernel - Software-Interrupts: EventsEVENT Die Speicherkonfiguration im Schneider CPC: BlockBLOCK Ausgaben: keine Unverändert: IX,IY Diese Routine ist dafür vorgesehen, vom Interruptpfad aus aufgerufen zu werden! Speziell ist hierbei an den EXTERNAL Alle noch folgenden Anschlüsse fallen unter die Rubrik STEUER- oder auch CONTROLBUS:: INT - InterruptINTERRUPT gedacht, um auch solchen Unterbrechungen den vollen Service des Event-Mechanismus bereitzustellen. Man kann sie zwar auch von einem normalen Programm aus aufrufen, doch ist das wohl nur in Ausnahmefällen sinnvoll. Weil der für den Vektor verwendete ROM-Konfiguration: RestartsRestart (LOW KERNEL JUMPBLOCK: 0008 - RST 1: LOW LOW JUMPRST_1 LOW MAIN FIRMWARE JUMPBLOCK: JUMPER BCF5: KL SYNC RESETLösche die Trees: ListenListe aller synchronisierbaren Unterbrechungen, die noch auf ihre Ausführung warten. Eingaben: keine Ausgaben: keine Unverändert: BC,DE,IX,IY Alle Der Kernel - Software-Interrupts: EventsEvents, die noch in der SYNCHRONOUS Der Kernel - Software-Interrupts: EventsEVENT PENDING QUEUE eingereiht sind, und auf ihre Ausführung warten, werden einfach vergessen. Die aktuelle Event-Priorität wird wieder auf 0 gesetzt. In den so ausgehängten Event-Blocks werden keine Änderungen vorgenommen. Die QUEUE (eine verkettete Trees: ListenListe!) wird geleert, indem ihr Anfangszeiger einfach auf 0 gestellt wird. Deshalb wird auch das Datentypen: Bytes BCF8: KL DEL SYNCHRONOUSStelle den BCEF: KL INIT EVENT: EventblockEventblock einer synchronisierbaren Unterbrechung ruhig und entferne ihn auch aus der Warteliste, falls er dort eingetragen ist. Eingaben: HL zeigt auf den Der Kernel - Software-Interrupts: EventsEVENT Die Speicherkonfiguration im Schneider CPC: BlockBLOCK Ausgaben: keine Unverändert: IX,IY Der durch HL angezeigte BCEF: KL INIT EVENT: EventblockEventblock wird ruhiggestellt und, falls nötig, aus der SYNCHRONOUS Der Kernel - Software-Interrupts: EventsEVENT PENDIG QUEUE entfernt. Dadurch werden alle noch ausstehenden Kicks vergessen. Um eine synchrone Der Kernel - Software-Interrupts: Interrupt-QuellenInterrupt-Quelle abzustellen, muss man erst den entsprechenden Die Speicherkonfiguration im Schneider CPC: BlockBlock aus der TICKER, FAST TICKER oder FRAME FLYBACK Datenspeicherung und Datenstrukturen: ChainsCHAIN entfernen, damit keine Kicks mehr erzeugt werden, und dann die ausstehenden Kicks mit diesem Vektor 'wegwerfen'. Die restlichen Der Kernel - Software-Interrupts: Interrupt-QuellenInterrupt-Quellen (EXTERNAL Alle noch folgenden Anschlüsse fallen unter die Rubrik STEUER- oder auch CONTROLBUS:: INT - InterruptINTERRUPT, BREAK oder Einleitung: Sound BCFB: KL NEXT SYNCHole die nächste synchronisierbare Unterbrechung aus der Der Key Manager: WarteschlangeWarteschlange, falls noch eine wartet. Eingaben: keine Ausgaben: CY=0 -> die SYNCHRONOUS Der Kernel - Software-Interrupts: EventsEVENT PENDING QUEUE ist leer CY=1 -> es war ein Die Speicherkonfiguration im Schneider CPC: BlockBlock in der QUEUE vorhanden HL zeigt auf den Der Kernel - Software-Interrupts: EventsEVENT Die Speicherkonfiguration im Schneider CPC: BlockBLOCK Operationen: BD5B / 349A / 349A: FLO SUBA=alte Event-Priorität Unverändert: BC,IX,IY War ein Die Speicherkonfiguration im Schneider CPC: BlockBlock in der SYNCHRONOUS Der Kernel - Software-Interrupts: EventsEVENT PENDING QUEUE vorhanden, so wird er aus dieser entfernt. Außerdem wird die aktuelle Event-Priorität dem neuen Der Kernel - Software-Interrupts: EventsEvent angepasst. Dadurch kann die Der Key Manager: WarteschlangeWarteschlange auch gepollt werden, während ein Der Kernel - Software-Interrupts: Synchrone Eventssynchrones Event abgearbeitet wird. Der Kernel - Software-Interrupts: EventsEvents mit niedrigerer oder gleicher Priorität werden dann vom MAIN FIRMWARE JUMPBLOCK: KERNEL Nun muss &KERNEL: BCFE: KL DO SYNCBCFE KL DO SYNC aufgerufen werden! Dieser Vektor übernimmt die Block-Adresse aus dem HL-Register, und ruft die dort eingetragene Event-Behandlungsroutine auf. Danach muss &KERNEL: BD01: KL DONE SYNCBD01 KL DONE SYNC aufgerufen werden, wofür alle Ausgabewerte von KERNEL: BCFB: KL NEXT SYNCKL NEXT SYNC benötigt werden. KERNEL: BD01: KL DONE SYNCKL DONE SYNC erniedrigt den Kick Count und fügt den Der Kernel - Software-Interrupts: EventsEvent Die Speicherkonfiguration im Schneider CPC: BlockBlock, falls nötig, wieder in die Pending Queue ein. Zum Schluss wird wieder die alte Event-Priorität eingestellt. Es ist recht unverständlich, wieso diese drei Die Fließkomma-Routinen: FunktionenFunktionen nicht in einem Vektor zusammengefasst wurden. Sie können praktisch nur in folgendem Zusammenspiel aufgerufen werden: Maschinencode über HIMEM: CALLCALL KERNEL: BCFB: KL NEXT SYNCKL NEXT SYNC JR NC,WEITER PUSH AF PUSH HL Maschinencode über HIMEM: CALLCALL KERNEL: BCFE: KL DO SYNCKL DO SYNC POP HL POP AF Maschinencode über HIMEM: CALLCALL KERNEL: BD01: KL DONE SYNCKL DONE SYNC WEITER: ... Variationsmöglichkeiten ergeben sich hauptsächlich nur durch den Einbau einer Schleife (Pollen, bis die Queue leer ist) und durch &HIGH KERNEL JUMPBLOCK: B921: HI KL POLL SYNCHRONOUSB921 HI KL POLL SYNCHRONOUS. Diese Routine testet nur, ob in der Pending Queue ein Die Speicherkonfiguration im Schneider CPC: BlockBlock wartet und ist dabei erheblich schneller als KERNEL: BCFB: KL NEXT SYNCKL NEXT SYNC, weil sie im RAM liegt und nicht über einen ROM-Konfiguration: RestartsRestart angesprungen werden muss. BCFE: KL DO SYNCFühre die mit &KERNEL: BCFB: KL NEXT SYNCBCFB geholte Unterbrechung aus. Eingaben: HL zeigt auf den Der Kernel - Software-Interrupts: EventsEVENT Die Speicherkonfiguration im Schneider CPC: BlockBLOCK Ausgaben: keine Unverändert: IX,IY Die Verwendung dieses Vektors ist bei &KERNEL: BCFB: KL NEXT SYNCBCFB KL NEXT SYNC beschrieben. BD01: KL DONE SYNCMuss nach &KERNEL: BCFE: KL DO SYNCBCFE aufgerufen werden. Eingaben: HL zeigt auf den Der Kernel - Software-Interrupts: EventsEVENT Die Speicherkonfiguration im Schneider CPC: BlockBLOCK Operationen: BD5B / 349A / 349A: FLO SUBA ist die alte Event-Priorität Ausgaben: keine Unverändert: IX,IY Dieser Vektor ist ebenfalls bei &KERNEL: BCFB: KL NEXT SYNCBCFB KL NEXT SYNC beschrieben. BD04: KL EVENT DISABLELege die Ausführung von normalen, synchronisierbaren Unterbrechungen auf Eis. Eingaben: keine Ausgaben: keine Unverändert: AF,BC,DE,IX,IY Wie bei &KERNEL: BCEF: KL INIT EVENTBCEF KL INIT EVENT erwähnt, bilden die Port C - Output: &F6xx: Bits 0 bis 3:Bits 1 bis 6 im Art-Byte (Class) eines Event-Blocks eine 'Gesamt-Priorität'. Datenbreite: Bits Eigentlich nicht vorgesehen aber durchaus möglich ist es, dass ein express-synchrones Der Kernel - Software-Interrupts: EventsEvent KERNEL: BD04: KL EVENT DISABLEKL EVENT DISABLE aufruft. Dadurch wird dann auch die Behandlung aller Express-Events ausgesetzt, weil jetzt sowohl Datenbreite: Bits Wird KERNEL: BD04: KL EVENT DISABLEKL EVENT DISABLE oder auch &KERNEL: BD07: KL EVENT ENABLEBD07 KL EVENT ENABLE von einer Event-Behandlungsroutine aus aufgerufen, bleibt der Zustand von Datenbreite: Bits Die Routine &KERNEL: BD07: KL EVENT ENABLEBD07 KL EVENT ENABLE hebt den Effekt von KERNEL: BD04: KL EVENT DISABLEKL EVENT DISABLE wieder auf, indem sie Datenbreite: Bits Einleitung: BASIC Einzige Ausnahme bildet dabei die BREAK-Behandlung: Hierfür wird ein express-synchrones Der Kernel - Software-Interrupts: EventsEvent benutzt. Deshalb kann man auch nach 'DI' noch breaken. Auch 'ON BREAK GOSUB' wird dadurch nicht beeinflusst. BD07: KL EVENT ENABLELasse die Ausführung von normalen, synchronisierbaren Unterbrechungen wieder zu. Eingaben: keine Ausgaben: keine Unverändert: AF,BC,DE,IX,IY Dieser Vektor ist mit &KERNEL: BD04: KL EVENT DISABLEBD04 KL EVENT DISABLE zusammen beschrieben. BD0A: KL DISARM EVENTStelle einen BCEF: KL INIT EVENT: EventblockEventblock ruhig. Eingaben: HL zeigt auf den Der Kernel - Software-Interrupts: EventsEVENT Die Speicherkonfiguration im Schneider CPC: BlockBLOCK Ausgaben: keine Unverändert: BC,DE,HL,IX,IY Der BCEF: KL INIT EVENT: EventblockEventblock wird dadurch ruhiggestellt, dass der Kickzähler auf einen negativen Wert (-64) gesetzt wird. Noch ausstehende Kick-Behandlungen gehen dadurch verloren. Diese Routine ist nur für asynchrone BCEF: KL INIT EVENT: EventblockEventblocks gedacht. Für Der Kernel - Software-Interrupts: Synchrone Eventssynchrone Events soll man &KERNEL: BCF8: KL DEL SYNCHRONOUSBCF8 KL DEL SYNCHRONOUS benutzen, da sich ein solches Der Kernel - Software-Interrupts: EventsEvent gerade in der SYNCHRONOUS Der Kernel - Software-Interrupts: EventsEVENT PENDIG QUEUE befinden könnte (weil es noch auf eine Kick-Bearbeitung wartet). Wird es dort nicht ausgehängt, wird es noch einmal aufgerufen. Der TICKER-, FAST TICKER oder FRAME FLYBACK Die Speicherkonfiguration im Schneider CPC: BlockBLOCK, von dem der BCEF: KL INIT EVENT: EventblockEventblock eventuell ein Bestandteil ist, wird dadurch nicht aus seiner Trees: ListenListe entfernt. Eintreffende Kicks werden in Zukunft einfach ignoriert. BD0D: KL TIME PLEASEErfrage den Stand des Interruptzählers. Eingaben: keine Ausgaben: DEHL enthält die Zeit in 1/300stel Sekunden Unverändert: AF,BC,IX,IY Für allgemeine Zeitmessungen lohnt es sich oft nicht, den CPC mit der Rechenzeit für einen BCEF: KL INIT EVENT: EventblockEventblock zu belasten. Verbrauchte Zeit lässt sich mit diesem Vektor bequem feststellen. In Einleitung: BASIC BD10: KL TIME SETStelle den Interruptzähler auf einen neuen Startwert. Eingaben: DEHL enthält den neuen Wert für den Interruptzähler Ausgaben: keine Unverändert: BC,DE,HL,IX,IY Der Zähler lässt sich auch stellen, um ihn beispielsweise an die Datums- und Uhrzeit-Eingabe in einem Programm anzupassen. Der gesamte Zeit-Messumfang des 4-Datentypen: Bytes BD5B: KL RAM SELECTNur CPC 6128. Wähle eine neue BD5B: KL RAM SELECT: Mögliche RAM-Konfigurationen:RAM-Konfiguration aus. Eingaben: neue BD5B: KL RAM SELECT: Mögliche RAM-Konfigurationen:RAM-Konfiguration Ausgaben: alte BD5B: KL RAM SELECT: Mögliche RAM-Konfigurationen:RAM-Konfiguration Unverändert: BC,DE,HL,IX,IY Vom Speicher und Peripherie: Das PAL im CPC 6128PAL, das für die RAM-Auswahl zuständig ist, werden nur die Port B - Input: &F5xx: Bits 1, 2 und 3: Mögliche RAM-Konfigurationen:CPU-Adressviertel Konfiguration wird normale Lage Operationen: BD5B / 349A / 349A: FLO SUBA -0- -1- -2- -3- verwendet bei: für Video-RAM --- ------------------ --------------------- -------------- 0 n0 - n1 - n2 - n3 Normalzustand n3=Screen 1 n0 - n1 - n2 - z3 Einleitung: CP/MCP/M: BIOS, BDOS etc. n1=Screen 2 z0 - z1 - z2 - z3 Einleitung: CP/MCP/M: TPA (n1=Screen) 3 n0 - n3 - n2 - z3 Einleitung: CP/MCP/M: n3=Hash-Tabelle (n1=Screen) 4 n0 - z0 - n2 - n3 Bankmanager n3=Screen 5 n0 - z1 - n2 - n3 Bankmanager n3=Screen 6 n0 - z2 - n2 - n3 Bankmanager n3=Screen 7 n0 - z3 - n2 - n3 Bankmanager n3=Screen n = normale RAM-Bank z = zusätzliches RAM |