IRQ-Routine (SB, TP)
Verfasst: Sa 19. Mär 2011, 20:12
Kennt sich einer von Euch etwas genauer mit dem IRQ-Acknowledgement (Port[$20] := $20) aus? Meines Wissens, muß dieses am Ende einer Hardware-Interrupt-Service-Routine ausgegeben werden, damit der IRQ-Controller weiß, dass er den nächsten IRQ für eben diesen IRQ auslösen darf, oder?
z.B. für einen Tastaturhandler (IRQ2=Int9);
Das IRQ-Acknowledgement ist hier am Ende der Interrupt-Service-Routine angeordnet, was ich nachvollziehen kann. Es soll ja - wenn ich das richtig verstanden habe - dem IRQ-Controller sagen: „Ich bin fertig, Du darfst jetzt einen neuen Int-9 auslösen.“
Ganz anders meine Soundblaster-Beispiel-Routinen. Diese lösen das iRQ-Acknowledgement am Anfang der Interrupt-Service-Routine aus, wie es meines Wissens auch Creative verlangt.
Meine SB-Interrupt-Routine (f. SB IRQ5 u. IRQ7) sieht daher z.B. so aus:
{1} sagt der SB (Basis=$220), dass der gemeldete IRQ angenommen wurde,
{2} IRQ-Acknowledgement, welches nach Creative direkt nach der SB-Entlastung ausgegeben werden muss,
{3} meine sehr zeitaufwendige Sound-Vermixungsroutine.
So wie ich das jetzt verstanden habe, könnte also die Situation auftreten, dass mein PC zu langsam ist, und ein erneuter SB-IRQ aufgerufen wird, obwohl mein alter ja noch gar nicht abgearbeitet ist. Denn ich habe ja sehr frühzeitig das IRQ-Acknowledgement gegeben.
Ich dachte daher, dass ich zwei globale Variablen benutze, die mir als Flag sagen, ob mein PC zu langsam ist, nämlich
CalculatingSamples : boolean = false;
CPUtooslow : boolean = false;
Meine SB-IRQ-Routine sähe dann so aus:
Ich frage dann in meinem Hauptprogramm laufend ab, ob das Flag CPUtooslow gesetzt ist und beende dann ggf. das Hauptprogramm mit dem Hinweis, dass der PC (jedenfalls für die gewählte SB-Frequenz) zu langsam ist.
Jetzt habe ich genau diese Situation: mein PC (386sx16) vermixt bei 12 kHz die Samples tadellos, bei 16 kHz ist er aber schon zu langsam. Mein Rechner steht dann: es wird ausschließlich (total verzerrter) Sound ausgegeben. Mein Hauptprogramm hat irgendwie keine Chance, das Flag CPUtooslow abzufragen und wie gewünscht zu beenden. Auch Ctrl-Break etc. hilft nichts mehr. Auf NumLock oder andere Tasten reagiert das BIOS nicht mehr. Es hilft nur noch ein Reset, um dem Graus ein Ende zu setzen.
Irgendwie wird in der SB-IRQ-Routine auch mein Flag CPUtooslow nicht gesetzt. Denn würde es gesetzt, dürften ja überhaupt keine Samples mehr vermixt werden. Dies ist aber definitiv nicht der Fall: Das Vermixen geht einfach weiter, nur eben zu langsam.
Weiss jemand Rat? Oder – etwas verallgemeinert – kennt jemand eine Methode, wie per Software überprüft werden kann, ob eine CPU noch schnell genug ist, immer wieder hintereinander auftretende Hardware-IRQs abzuarbeiten?
z.B. für einen Tastaturhandler (IRQ2=Int9);
Code: Alles auswählen
PROCEDURE TastaturInt; interrupt;
BEGIN
inkey := Port[$60];
{ .... }
Port[$20] := $20;
END;
Das IRQ-Acknowledgement ist hier am Ende der Interrupt-Service-Routine angeordnet, was ich nachvollziehen kann. Es soll ja - wenn ich das richtig verstanden habe - dem IRQ-Controller sagen: „Ich bin fertig, Du darfst jetzt einen neuen Int-9 auslösen.“
Ganz anders meine Soundblaster-Beispiel-Routinen. Diese lösen das iRQ-Acknowledgement am Anfang der Interrupt-Service-Routine aus, wie es meines Wissens auch Creative verlangt.
Meine SB-Interrupt-Routine (f. SB IRQ5 u. IRQ7) sieht daher z.B. so aus:
Code: Alles auswählen
PROCEDURE SB_Int; interrupt;
VAR b : byte;
BEGIN
b := Port[$22E]; {1}
Port[$20] := $20; {2}
Vermix_ganz_zeitaufwendig_meine_Samples; {3}
END;
{1} sagt der SB (Basis=$220), dass der gemeldete IRQ angenommen wurde,
{2} IRQ-Acknowledgement, welches nach Creative direkt nach der SB-Entlastung ausgegeben werden muss,
{3} meine sehr zeitaufwendige Sound-Vermixungsroutine.
So wie ich das jetzt verstanden habe, könnte also die Situation auftreten, dass mein PC zu langsam ist, und ein erneuter SB-IRQ aufgerufen wird, obwohl mein alter ja noch gar nicht abgearbeitet ist. Denn ich habe ja sehr frühzeitig das IRQ-Acknowledgement gegeben.
Ich dachte daher, dass ich zwei globale Variablen benutze, die mir als Flag sagen, ob mein PC zu langsam ist, nämlich
CalculatingSamples : boolean = false;
CPUtooslow : boolean = false;
Meine SB-IRQ-Routine sähe dann so aus:
Code: Alles auswählen
PROCEDURE SB_Int; interrupt;
VAR b : byte;
BEGIN
b := Port[$22E]; {1}
Port[$20] := $20; {2}
If CalculatingSamples then CPUtooslow := true;
CalculatingSamples := true;
if Not CPUtooSlow then
Vermix_ganz_zeitaufwendig_meine_Samples; {3}
CalculatingSamples := false;
END;
Jetzt habe ich genau diese Situation: mein PC (386sx16) vermixt bei 12 kHz die Samples tadellos, bei 16 kHz ist er aber schon zu langsam. Mein Rechner steht dann: es wird ausschließlich (total verzerrter) Sound ausgegeben. Mein Hauptprogramm hat irgendwie keine Chance, das Flag CPUtooslow abzufragen und wie gewünscht zu beenden. Auch Ctrl-Break etc. hilft nichts mehr. Auf NumLock oder andere Tasten reagiert das BIOS nicht mehr. Es hilft nur noch ein Reset, um dem Graus ein Ende zu setzen.
Irgendwie wird in der SB-IRQ-Routine auch mein Flag CPUtooslow nicht gesetzt. Denn würde es gesetzt, dürften ja überhaupt keine Samples mehr vermixt werden. Dies ist aber definitiv nicht der Fall: Das Vermixen geht einfach weiter, nur eben zu langsam.
Weiss jemand Rat? Oder – etwas verallgemeinert – kennt jemand eine Methode, wie per Software überprüft werden kann, ob eine CPU noch schnell genug ist, immer wieder hintereinander auftretende Hardware-IRQs abzuarbeiten?