Thema: Eigene Interrupt-Service-Routine (Real Mode)

[fabuloes]

Hallo,

Wie genau setze ich eine eigene Funktion als ISR (z.B. einen Tastaturhandler, der bei einem IRQ 1 von der Tastatur aufgerufen wird)? Ich habe schon versucht einfach die Adresse der Funktion per Zeiger an die Stelle 0x4 (die Stelle in der IVT für Tastatur IRQs), aber die Funktion wird bei einem IRQ 1 einfach nicht aufgerufen.

Kann mir das jemand nochmal genau erklären?

[kevin]

Doch, das sollte schon passen. Hast du Segment und Offset richtigrum angegeben?

Ansonsten bleiben die üblichen Gründe, warum ein IRQ nicht ankommt: Der Interrupt könnte im PIC maskiert sein, oder das Interrupt-Flag der CPU aus, oder du könntest ein EOI vergessen haben und deswegen kommen keine weiteren IRQs mehr. Bei der Tastatur kommt noch dazu, dass man die Daten auslesen muss bevor sie den nächsten Interrupt auslöst (aber dann würdest du wohl genau einmal den ISR anspringen).

[XanClic]

IRQ 1 ist nach dem Start des Computers Interrupt 9, das ist mit Sicherheit ein Grund, warum dein Interrupthandler nicht aufgerufen wird (der sich um Interrupt 1, die Debugexception, kümmert).

[fabuloes]

Also Danke erstmal für die schnelle Antworten

@taljeth
Also ich habe bisher nur versucht die Adresse, die mir der Adressoperator & liefert mit einem Zeiger an der Stelle 0x24 (also jetzt IRQ 9) zu setzen, da ich bei der Sache mit Segmentierung und Offsets nicht so ganz durchblicke. 
Das Interruptflag müsste gesetzt sein (ist doch nur aus wenn der cli-Befehl ausgeführt wurde?), und ein EOI dürfte ich nicht vergessen haben können, da ich selbst noch keine Interrupts vorher verwendet habe. Achja das Keyboard ist initialisiert ( outb(0x60,0xF4) ), und der Eingabepuffer des KBC müsste auch leer sein

Also ich habe versucht die Adresse an 0x24 (Müsste eigentlich IRQ 9 sein) zu setzen, aber es tut sich immer noch nichts.
Ich wäre sehr dankbar wenn sich jemand die Mühe macht, den Teil mit der Manipulation der IVT mal mit einem Codeschnippsel zu verdeutlichen. 

[erik.vikinger]

Hallo fabuloes,


Ob der Adressoperator & wirklich einen FAR-Pointer liefert dürfte nicht bei jedem C-Compiler gewährleistet sein, im Zweifelsfall mit __FAR o.ä. nachhelfen (da sollte die Compiler-Doku passend Auskunft geben können). Auch die Variable wo Du die Adresse Deiner Interrupthandler-Funktion hin speicherst muss natürlich einen FAR-Pointer aufnehmen können. Des weiteren muss der Compiler bei einer C-Funktion wissen das die als Interrupt angesprungen wird, der Compiler erzeugt dann anderen Prolog- und Epilog-Code, was auch wieder mit einem compilerspezifischen Attribut zu managen ist. Das man innerhalb einer solchen Funktion nicht einfach mal ein printf (aus der normalen libc) benutzen kann sollte wohl klar sein.

Wenn Du ganz allgemein noch nicht so richtig mit Segmentierung (egal ob im Real-Mode oder im Protected-Mode) zurecht kommst dann solltest Du Dir da vielleicht erst einmal das nötige Wissen aneignen. Segmentierung hat ein paar extra Stolperfallen parat die es bei Flat-Memory nicht gibt und mit denen muss man sich recht gut auskennen wenn man da einigermaßen Unfallfrei durchkommen möchte. Glaub mir ich weiß was ich da schreibe.

Bevor man einen Wert in der Real-Mode-IVT verändert sollte man ihn aber auf jeden Fall sichern, schon damit man ihn am Programme-Ende wieder ordentlich restaurieren kann. Des weiteren sollte Dein Interrupthandler dann eventuell den vorherigen Interrupthandler anspringen falls er selber nicht zu tun hat. Dieses Interrupt-Chaining ist unter DOS ein recht beliebtes Spiel aber das funktioniert nur dann wenn alle Mitspieler sich auch ordentlich an die Regeln halten!


Grüße
Erik

[PNoob]

C und Realmode? welchen compiler benutzt du?

PNoob

[fabuloes]

Also ich benutze den GNU C Compiler, und ich hab jetzt ein bisschen recherchiert und rausgefunden, dass es beim gcc gar keine FAR LAbels oder Makros gibt

Danke an erik.vikinger, ich habe mich noch mal um die Segmentierung gekümmert, aber ich versteh das immer noch nicht so wirklich.
Mit einem 32-Bit Prozessor kann ich doch bis zu 4GB RAM direkt adressieren (also 0x00000000 bis 0xFFFFFFFF), und da ich im Realmode arbeite müsste ich doch jede beliebige Adresse per Zeiger erreichen können oder (also ohne Segmentierung)?

Tut mir Leid wenn das vielleicht eine ziemlich kiddiemäßige Frage zur Adressierung ist 

[erik.vikinger]

Hallo,

Also ich benutze den GNU C Compiler

Dann erstellst Du definitiv kein echtes DOS-Programm sondern etwas das mindestens einen DOS-Extender o.ä. benötigt.

und ich hab jetzt ein bisschen recherchiert und rausgefunden, dass es beim gcc gar keine FAR LAbels oder Makros gibt

Logisch, der gcc hat von Segmentierung absolut gar keine Ahnung.

Mit einem 32-Bit Prozessor .....

Im Real-Mode ist auch der allerneuste x86-Prozi nur ein uralter 16 Bitter und kann nur 1 MB adressieren (von ein paar nicht empfehlenswerten Spezialtricks mal abgesehen).


Grüße
Erik

[kevin]

Vielleicht auch mal an dieser Stelle die Frage, von der ich erwartet hätte, dass sie viel früher kommt: Warum in aller Welt willst du Real Mode haben?

[PNoob]

also mit dem gnu C Compiler erstellst du definitiv kein realmode Programm/Kernel, sondern in 32/64 Bit Programm/Kernel du musst dich bereits im PMode/Longmode befinden.
Im RM arbeitet man nicht mit 32 Bit Adressen sondern mit 20 Bit adressen und die sind unterteilt in segment und offset.

Jetzt ist die Frage, was willst du? ein OS schreiben wie die meißten hier, wenn ja im RM(alles andere nur nicht empfehlenswert) oder im PM, oder willst du was ganz anderes erreichen?

PNoob

[freecrac]

Also ich benutze den GNU C Compiler, und ich hab jetzt ein bisschen recherchiert und rausgefunden, dass es beim gcc gar keine FAR LAbels oder Makros gibt

Danke an erik.vikinger, ich habe mich noch mal um die Segmentierung gekümmert, aber ich versteh das immer noch nicht so wirklich.
Mit einem 32-Bit Prozessor kann ich doch bis zu 4GB RAM direkt adressieren (also 0x00000000 bis 0xFFFFFFFF), und da ich im Realmode arbeite müsste ich doch jede beliebige Adresse per Zeiger erreichen können oder (also ohne Segmentierung)?

Tut mir Leid wenn das vielleicht eine ziemlich kiddiemäßige Frage zur Adressierung ist 

Im 16 Bit Realmode ist die 21. Adressleitung abgeschaltet und alle Segmente(ohne die man nicht adressieren kann) sind auf 64 Kib begrenzt.  Die jeweilige Adresse bildet sich aus dem Inhalt  eines 16 Bit Segmentregisters zusamen mit einem 16 Bit Offset. Auch wenn man 32 Bit Offsetregister zur Adressierung kombinieren kann muss man darauf achten, das die berechnete Adresse nicht das jeweilige 64 Kib grosse Segment überschreitet.

Dirk

[fabuloes]

Also vielleicht sollte ich noch sagen, das ich die OS-Entwicklung nicht mit lowlevel begonnen hab, sondern hierüber:http://www.tutorials.de/c-c-tutorials/304626-ein-betriebssystem-mit-c-entwickeln.html

Dort wird ein einfacher Kernel mit dem GNU C Compiler und Assembler erstellt, und ich habe mir da auch keine weiteren Gedanken über den Compiler gemacht.
Zur Frage "Warum im Realmode?": Ich wollte einfach klein anfangen, und mein Ziel war nicht unbedingt ein umfangreiches OS zu kreieren, sondern viel mehr ein bisschen hardwarenah zu programmieren, und ein wenig Grundverständnis für Betriebssysteme (wenn auch nur im RM) zu sammeln, und sich vielleicht später mal mit dem PM genauer zu beschäftigen.

Welchen Compiler empfehlt ihr zur OS-Entwicklung?

[PNoob]

Für OS-Dev ist gcc genau richtig.
Das Tut ist btw. auch von hier das hat FreakyPenguin dort veröffentlicht. aber fang am besten gleich im PM an. Da Programmierst du genauso Hardwarenah wie im RM.


PNoob

[DerHartmut]

Das Grundverständnis für moderne Betriebssysteme findest du nicht im Realmode. Dort lernst du auch lediglich wie man es vor gut 20-25 Jahren gemacht hat und heute nicht mehr machen sollte.

[kevin]

Fang hier an: http://www.lowlevel.eu/wiki/OS-Dev_für_Einsteiger

Und Real Mode macht die Sache nicht einfacher, sondern schwieriger, weil du dich mit Problemen rumplagen musst, die längst gelöst sind. Das Tutorial, das du verlinkt hast, bezieht sich auch auf Protected Mode.

[erik.vikinger]

Hallo,

.... von der ich erwartet hätte, dass sie viel früher kommt ....

Er wollte Interrupts hooken und da hab ich nicht gleich an OS-Dev gedacht. Außerdem ist das hooken von RM-Interrupts ja ein gar lustig Spiel bei dem man viel lernen kann (ob einem dieses Wissen heute noch wirklich was nützt sei mal dahin gestellt).

.... und ein wenig Grundverständnis für Betriebssysteme (wenn auch nur im RM) zu sammeln, und sich vielleicht später mal mit dem PM genauer zu beschäftigen.

Das ist so als würdest Du lernen wollen einen Pferdewagen zu führen (auf dem Dorf) um es dann später beim Auto-Führerschein (in der Großstadt) leichter zu haben. Das wird so nix!


Grüße
Erik

[PNoob]

Moin

Das ist so als würdest Du lernen wollen einen Pferdewagen zu führen (auf dem Dorf) um es dann später beim Auto-Führerschein (in der Großstadt) leichter zu haben. Das wird so nix!

Das ist man nen echt passender Vergleich.

PNoob

[fabuloes]

Okay danke nochmal taljeth, ich schau mir die Basics nochmal an  

Dann bau ich meinen bisherigen Code mal um.

Danke an alle die sich beteiligt haben

[erik.vikinger]

Hallo,

Das ist man nen echt passender Vergleich.

Deswegen hab ich den ja auch hingeschrieben.
Obwohl das bei x86 nicht ganz richtig ist: wenn fabuloes im PM auch die Segmentierung richtig nutzen möchte (so wie ich Segmentierung nutzen will) dann kann einem der RM schon einen kleinen Wissensvorsprung verschaffen. Wenn er aber hingegen auf Flat-Memory setzen möchte, so wie alle anderen in der Herde auch, dann ist die Erfahrung mit dem RM eher kontraproduktiv.


Grüße
Erik