Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: FalShen am 16. October 2006, 19:55
-
Ich hab mir TeeJay's PMode tutorial durchgelesen, und danach Code erstellt. Ich hab ihn mit dem mitgelieferten Code verglichen und angeglichen.
Ich kriege nur noch 'Exception 13'.
Dann hab ich mit verschiedenen Artikeln/Tutorials von Bona Fide verglichen. Das selbe.
Schlußendlich habe ich TeeJay's Code compiliert, wie es angegeben war, und war sehr überrascht, dass das Ergebnis das selbe war.
Okay, bin ich nun einfach zu blöde? Sicher ist, dass ich kurz vorm Computer-aus-dem-Fenster-Schmeißen bin, weil's mich echt nervt.
Ich brauche Hilfe! Ich will doch bloß in den Protected Mode umschalten!!
TFYA
-
Ich meine über TeeJays Beispiele schon das ein oder andere Mal gehört zu haben, daß sie nicht ganz fehlerfrei sind. Am besten wird man dir aber helfen können, wenn du den Code postest, mit dem du es versucht hast.
-
Erstmal: Willkommen bei Lowlevel
Aber jetzt zu deinem Problem:
Hast du nach dem PM Change mindestens noch eine Endlosschleife, oder einen Kernel drin? Sonst laueft der Prozessor irgendwo ins Speichernirvana, was selten besonders gut kommt :wink:
Mit welchen Befehlen kompilierst/linkst du denn deinen Kernel ?
Ansonsten wärs vielleich nicht schlecht, wenn dudeinen code mal zegen wuerdest.
-
Oder du kannst es mit dem Codeschnipsel von stefan2005 probieren.
Ist glaub ich in der 4. Ausgabe des Magazins.
Das ist viel weniger kompliziert....
Eine grosse Fehlerquelle ist auch ein vergessenes "h" oder eine "0" vor einer Hexzahl.
Nooooooooooooos
-
Na ja, der Code is wirklich derjenige von TeeJay's Pmode Tutorial auf seiner Website. Außerdem hab ich den code für's A20 gate hinzugefügt.
Zum kompilieren hab ich Nasm 0.98 und GCC 4.1 unter Linux benutzt. Ein endlos-loop ist vorhanden. Und kompiliert had ich's wie auf der website gesagt (kann auch die makefile posten)
-
Hab mir jetzt DJGPP runtergeladen, selbes Ergebnis. Danach hab ich noch ein wenig geändert, hier und da, und nun tut sich ein neues problem auf: Bochs shreibt in seine Logfile, dass the PMode eingeschaltet ist, aber auch, das irgendwie von der Floppy gelesen wird, und alles angehaltend ist. Dass muss nun noch for dem C-Kernel sein, da die Bildschirmausgabe nix liefert... Das A20 ist es auch nicht, habs mal auskommentiert, das selbe. So hier der Code, das meiste ist einfach von TeeJay's page (is'n bisschen lang, sorry admins):
Kernel16.asm:
[BITS 16]
jmp start
NULL_Desc:
dd 0
dd 0
CODE_Desc:
dw 0xFFFF
dw 0
db 0
db 0x9A
db 0xCF
db 0
DATA_Desc:
dw 0xFFFF
dw 0
db 0
db 0x92
db 0xCF
db 0
gdt:
Limit dw 0
Base dd 0
start:
cli
mov eax, cs
mov ds, ax
shl eax, 4
mov [CODE_Desc+2], ax
mov [DATA_Desc+2], ax
shr eax, 16
mov [CODE_Desc+4], al
mov [DATA_Desc+4], al
mov eax, cs
shl eax, 4
add eax, NULL_Desc
mov [Base], eax
mov [Limit], WORD gdt - NULL_Desc - 1
lgdt [gdt]
mov eax, cr0
or eax, 1
mov cr0, eax
db 0xea
dw PMODE
dw 0x8
[BITS 32]
PMODE:
jmp PMODE
mov word [CODE_Desc+2],0
mov word [DATA_Desc+2],0
mov byte [CODE_Desc+4],0
mov byte [DATA_Desc+4],0
mov eax, 2
shl eax, 3
mov ds, ax
mov es, ax
mov ss, ax
mov eax, 0
mov fs, ax
mov gs, ax
mov esp, 0x1FFFFF
jmp 0x8:0x10000 + PMODE2
PMODE2:
A20:
.1:
in al, 0x64
test al, 00000010b
jnz .1
mov al, 0xD0
out 0x64, al
.2:
in al, 0x64
test al, 00000001b
jz .2
in al, 0x60
or al, 00000010b
push eax
.3:
in al, 0x64
test al, 00000010b
jnz .3
mov al,0xD1
out 0x64, al
.4:
in al, 0x64
test al, 00000010b
jnz .4
pop eax
out 0x60, al
jmp END
times 512-($-$$) db 0
END:
Kernel32.asm:
[BITS 32]
extern _main
global start
start:
call _main
stop:
jmp stop
main.c:
unsigned char *VID_MEM = (unsigned char*)0xB8000;
int main()
{
VID_MEM[0] = 'S';
VID_MEM[1] = 0x1B;
return 0;
}
-
PMODE:
jmp PMODE
Kommt er denn bis zu dieser Endlosschleife?
bitmaster
-
Hab die jetzt entfernt (danke, hab ich nicht gesehen), aber er bleibt wohl jetzt beim jump zum PMODE2 stehen. Bochs sagt, CS is 0x8 und EAX is 0x0, also glaub ich, dass es dort ist... Bin im PMode, hab CS und SS bei 32 bit... weiß nicht, wo's jetzt hakt...
-
Probiers mal mit dem PM Codeschnipsel der Ausgabe 7. Die ist nich so kompliziert und beinhaltet viel weniger Fehlerquellen.
Nooooooooooos
-
Ummm... würde ich ja gerne... aber... ich weiß nicht, irgendwie hat sich die Seite doch stark verändert in den letzten stunden... :?
-
Schon?? Nimm einfach das:
;;; Ein kleines Beispiel, wie man in den 32-Bit Protected Mode wechselt
;;; Bei Fragen kann man sich einfach an stefan.marcik@web.de oder
;;; an die ICQ-Nummer 338417614 wenden.
[BITS 16]
...
...
cli ; Interrupts ausschalten
lgdt [gdtr] ; GDT Pointer laden
mov eax,cr0 ; In PMode wechseln, indem das niedrigste
or al,1 ; Steuerungsbit von cr0 ge�ert wird
mov cr0,eax ; muss �mweg �in anderes Register gemacht werden
jmp codesel:PMode ; FarJump zu einer 32-Bit PMode Funktion
[BITS 32]
PMode:
mov ax,datasel ; Segmentregister laden
mov ds,ax
mov ss,ax
mov esp,0x90000 ; Stack aufsetzen
...
...
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; == GDT == ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
gdtr: ; Desktiptortabelle
dw gdt_end-gdt-1 ; Limit
dd gdt ; Basisadresse
gdt:
dd 0,0 ; Null-Deskriptor
codesel equ $-gdt
dw 0xFFFF ; Segmentgr�0..15
dw 0x0000 ; Segmentadresse 0..15
db 0x00 ; Segmentadresse 16..23
db 0x9A ; Zugriffsberechtigung und Typ
db 0xCF ; Zusatzinformationen und Segmentgr�16...19
db 0x00 ; Segmentadresse 24..31
datasel equ $-gdt
dw 0xFFFF ; Segmentgr�0..15
dw 0x0000 ; Segmentadresse 0..15
db 0x00 ; Segmentadresse 16..23
db 0x92 ; Zugriffsberechtigung und Typ
db 0xCF ; Zusatzinformationen und Segmentgr�16...19
db 0x00 ; Segmentadresse 24..31
gdt_end
Noooooooooooooooos
-
Ich würd' für die Selectors lieber
codesel equ (1<<3)
datasel equ (2<<3)
schreiben.
Dann bist du auf der sicheren Seite... denn ein Selector ist
NICHT das Offset des Deskriptors in der GDT!!
Sondern der Index des Deskriptors bei 0 beginnend.
Dieser Eindruck entsteht bloß, da der Index um 3 Bits
linksverschoben ist.
;)
-
Langer Rede kurzer Sinn - schaut auf meine homepage:
www.rcfriz.de
und findet auf alle Fragen,die Ihr habt, komplette Antworten.
Mein dort veröffentlichtes FDOS1 enthält fertig ausgetesteten, also fehlerfreien Code und ist ein kleines OS, das man sehr einfach selbst erweitern kann mit Prozeduren, die man unter einen Funktionskopf legen kann. Es ist in jedem Detail ausführlich kommentiert. Ausserdem habe ich deutsche Dokumentation beigepackt.
Wer höher hinaus will als nur bis zum pmode, kann sich in mein ASMOS vertiefen, das - so weit ich blicken kann -, wirklich neu und sehr fortgeschritten im Ausbau ist.
-
Meins ist aber noch neuer und fortgeschrittener und einfach vieeeel besser als Windwos^^
Aber grad alles kopieren solltest du aber doch nicht, denn dann lernst du nix.
-
Na ja, tolle Werbung :-P
FDOS is zwar 'gut' dokumentiert... aber ich hab trotzdem nicht durchgesehen, zumal die Herangehensweise an den PMode sehr anders ist.
Das Windows Hauptfeature had mein OS ja schon.... es funzt nicht :wink:
Jetzt hab ich wieder Exception 13...
Hier der Code... Ich bin übrigens kurz vorm aufgeben...
[BITS 16]
start:
cli
xor ax, ax
mov ds, ax
lgdt [gdtr]
mov eax, cr0
or al, 1
mov cr0, eax
jmp codesel:PMODE
[BITS 32]
PMODE:
mov ax, datasel
mov ds, ax
mov es, ax
mov ss, ax
mov esp, 0x90000
xor ax, ax
mov fs, ax
mov gs, ax
A20:
.1:
in al, 0x64
test al, 00000010b
jnz .1
mov al, 0xD0
out 0x64, al
.2:
in al, 0x64
test al, 00000001b
jz .2
in al, 0x60
or al, 00000010b
push eax
.3:
in al, 0x64
test al, 00000010b
jnz .3
mov al,0xD1
out 0x64, al
.4:
in al, 0x64
test al, 00000010b
jnz .4
pop eax
out 0x60, al
jmp END
gdtr:
dw gdt_end-gdt-1
dd gdt
gdt:
dd 0
dd 0
codesel equ (1<<3)
dw 0xFFFF
dw 0
db 0
db 0x9A
db 0xCF
db 0
datasel equ (2<<3)
dw 0xFFFF
dw 0
db 0
db 0x92
db 0xCF
db 0
gdt_end:
times 256-($-$$) db 0
END:
-
Hast du vieleicht deinen Bootloader und dien Makefile auch noch???
An dem hier kann es einfach kaum liegen....
Noooooooooooos
-
also der code funzt bei mir mit ein paar kelien erweiterungen
[ORG 0x7c00] ; als boot disk getestet
... der Code ...
times 510-($-$$) db 0
dw 0xaa55 ; Boot Signatur (für boot disk)
times 1474560-($-$$) db 0
-
Der Bootloader is TeeJay's FAT12 bootloader, mit der einen einzigen Veränderung, dass er nach Kernel.sys und nicht Kernel.bin sucht... Mir fällt gerade auf... müsste ds dann nicht auf das segment 0x1000 zeigen...? Ocer muss ich [ORG 0x10000] einfügen oder so was?
-
Vllt liegt der Fehler in deinem Code, wie du da oben schon vermutest, in
der Segmentadresse des Datensegmentes. Du setzt die nämlich auf
0x0000
xor ax, ax
mov ds, ax
Die setz mal auf 0x1000, wenn der Bootloader den Kernel nach 0x10000 lädt.
Sonst findet er den GDT Pointer nämlich nicht. Denn der liegt ja dann an:
0x1000:_gdtr
-
Okay, es funktioniert immer noch nicht... Ich frage mich so langsam echt, wieso es immer bei anderen funktioniert, aber bei mir nicht.
Es geht nicht, und ich sollte es dabei belassen. Danke für die Versuche mir zu helfen.
-
Hast du mal geschaut, wo der GPF genau auftritt? Was mir so auf den ersten Blick auffällt, ist das jmp END womit du mitten ins Nichts springst, also in Speicher, wo stehen kann, was will. Schließ das Ding mal mit einer Endlosschleife ab.
-
Gute Idee... die Logfile sagt: jump_protected: gate type 0 unsupported
Soll dass heißen, der sieht die Selektoren als Call Gates oder was?
und hier die build.bat:
nasm -f bin -o kernel16.bin kernel16.asm
nasm -f aout -o kernel32.o kernel32.asm
gcc -Os -ffreestanding -c -o main.o main.c
ld -T link.ld -o ckernel32.bin kernel32.o main.o
MergeKernel kernel.sys kernel16.bin ckernel32.bin
copy kernel.sys a:\kernel.sys
Für WXP und DJGPP
-
Wenn ich dich richtig verstanden habe, soll hinter dem END: dein C-Kernel anfangen, oder wie? Zumindest politisch nicht ganz korrekt, würde ich sagen, da würde ich noch ein jmp main hinsetzen.
Ansonsten wäre es nach wie vor gut zu wissen, an welcher Codezeile der GPF denn nun auftritt.
-
Also, hab jetzt folgendes gemacht: hab den A20 übersprungen und die Endlosschleife direkt nach dem END gemacht, also nur den jump in den protected mode. Und es geht immer noch nicht.
Ich kann dir nicht sagen, in welcher zeile der fehler nun auftritt, da mir bochs das nicht in der logfile angibt.
-
Dann steck den Fehler mit jmp $ ab, oder nimm den Bochs-Debugger (Tut: http://www.chris-soft.de/tutorials/bochs/).
Das wird aber warscheinlich nich sonderlich viel bringen. Gib uns mal dein MakeFile; Vieleicht liegt es daran, dass es bei allen anderen funzt.
Nur nicht aufgeben, das kommt schon!!
Noooooooooooos
-
Um ehrlich zu sein, die Sache, die mich am meisten nervt, ist, dass nur der Desktop in meiner Wohnung nen Floppy hat, allerdings, 24/7 von meiner Mutter komplett besetzt wird. Heißt, dass ich nur einmal am Tag oder nach langem Betteln mal testen darf.
Kennt irgendwer eine Art Floppy-Emulator für Windows oder Linux? Würd mir irgendwie helfen...
Die makefile ist die build.bat da oben. Die Linux makefile sieht nicht anders aus, nur mit cat anstatt MergeKernel.
-
Ah...hab ich übersehen...Ja einen guten Emulator gibts: Bochs.
Schau mal im Netz, das obengenannte Tut beschreibt auch den Umgang mit Bochs allgemein.
Noooooooooooos
-
Ich glaube, er meint was anderes. ;)
Unter Linux kannst du ein Floppy-Image fast wie eine ganz normale Diskette mounten: mount -oloop floppy.img /mnt (als root, solange du das nicht in der fstab hast). Das Image kopierst du dir entweder einmal von deiner richtigen Diskette oder du erstellst eins mit dd if=/dev/zero of=floppy.img bs=1024 count=1440; mkdosfs floppy.img.
-
Vielen Dank für den mounting Tipp, wusste ich noch nicht...
Ich hab, glaube ich, den fehler eingeengt. bochs sagt, zum Zeitpunkt des faults sind eax und cr0 gleich 00000011b, also PMode ist eingeschaltet. Direkt danach würde der befehl JMP codesel:PMode kommen... Bochs sagt auch, CS und SS sind noch 16 bit breit... also... keine Ahnung, hab ich was vergessen?
-
Wenn dieser Code nicht an Segment 0 geladen ist, solltest du noch Segment * 16 zur Basis im GDTR addieren.
-
Ocer muss ich [ORG 0x10000] einfügen oder so was?
ja (wenn dein kernel nach 0x1000 geladen wird )
-
okay, nun ist CS 32 bit breit, und enthält 0x8, wie es - glaub ich - sein soll. DS ist immer noch 0x1000, somit ist der nun einen befehl weiter, mov ax, datasel, oder die Exception tritt auf bei mov ds, ax......
-
oder die Exception tritt auf bei mov ds, ax.....
du benutzt anchscheinend nicht den debugmodus von bochs
versuch ma
damit findet man schnell raus wo der fehler ist
-
Dieses Bochs-Tutorial brachte mir nicht viel... wie komme ich in den 'debug-mode'? Bochsdbg.exe verhielt sich genauso wie bochs, also... keine Ahnung...
hier der ausschnitt aus der logfile, wieß nich, ob's hilft...
00009148317i[CPU ] LOCK prefix unallowed (op1=0x53, attr=0x0, mod=0x0, nnn=0)
00009148317e[CPU ] interrupt(): gate descriptor is not valid sys seg
00009148317e[CPU ] interrupt(): gate descriptor is not valid sys seg
00009148317i[CPU ] protected mode
00009148317i[CPU ] CS.d_b = 32 bit
00009148317i[CPU ] SS.d_b = 16 bit
00009148317i[CPU ] | EAX=00000011 EBX=00001000 ECX=00170001 EDX=00000022
00009148317i[CPU ] | ESP=0000fffc EBP=00000000 ESI=000088f0 EDI=0000ffde
00009148317i[CPU ] | IOPL=0 id vip vif ac vm RF nt of df if tf sf zf af pf cf
00009148317i[CPU ] | SEG selector base limit G D
00009148317i[CPU ] | SEG sltr(index|ti|rpl) base limit G D
00009148317i[CPU ] | CS:0008( 0001| 0| 0) 00000000 000fffff 1 1
00009148317i[CPU ] | DS:1000( 0000| 0| 0) 00010000 0000ffff 0 0
00009148317i[CPU ] | SS:9000( 0000| 0| 0) 00090000 0000ffff 0 0
00009148317i[CPU ] | ES:9200( 0000| 0| 0) 00092000 0000ffff 0 0
00009148317i[CPU ] | FS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00009148317i[CPU ] | GS:0000( 0000| 0| 0) 00000000 0000ffff 0 0
00009148317i[CPU ] | EIP=0000001b (0000001b)
00009148317i[CPU ] | CR0=0x00000011 CR1=0 CR2=0x00000000
00009148317i[CPU ] | CR3=0x00000000 CR4=0x00000000
00009148317i[CPU ] >> lock push ebx : F053
00009148317e[CPU ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting
-
ich glaube das das mit dem bochsdbg.exe schon richtig ist (3 tage linux und Win schon ganz vergessen)
do solten wi immer zwei fenster aufgehen,
1. der 'Monitor'(bleibt schwarz, weil die ausfürung noch nicht gestartet wurde)
2. so ne art Konsole
für die Konsole gibts dann ne reihe befehle, mit denen du den programmmablauf steuern kanst
c normale ausfüren
s einzel schritt ausfüren
vb seg:offs brackpoint setzen (virtuell adresse)
lb addr brackpoint (lineare addresse)
pb addr brackpoint (physikaliche addresse
d n brackpoint nummer n löschen
q beenden
versuchs ma mit den kommandos
lb 0x1000 # um den bios boot forgang zu über springen
c # bis zum Brackpoint ausführen
d 1 # brackpoint wieder löschen (hier die nummer eintragen di nach dem lb befehl angezeigt wird
s # mit s bis zum programmabsturz for arbeiten (einfach enter widerholt den letzten konsolen befehl)
den fehler haften bereich erkänzt du an einer abweichung von deinem code ( der nächste auszu fürende code wird immer angezeigt) meist ist das ein jmp F000:0000 oder so
liste mit ein par mehr befehlen (was besseres hab ich auf die schnelle nicht gefunden)
http://bochs.sourceforge.net/doc/docbook/user/internal-debugger.html
edit:
00009148317i[CPU ] | EIP=0000001b (0000001b)siht so aus als fehlt ein [org 0x1000] den dein code liegt beschtimmt nicht bei 0x001B
-
Also... danke für den link, hat mir echt geholfen...
Das problem liegt offenbar nich mal in meinem Code. Der Fehler ist ein Befehl lock push ss, der irgendwie nicht funktioniert. Hab keine Ahnung wo der herkommt, ist nicht in meinem Code...
-
dann must du gucken wo dein code verlassen wird
warscheinlich mit nem
JMP 0x001B
(dein code ligt ja bei 0x1000 !?)
PS: hast du da jezt das [org 0x1000] drin ?
-
Hab ich schon längst!
ein [ORG 0x10000], da der bootloader den kernel nach 0x1000:0x0 packt.
-
Und beim Bootloader hast du auch ein entsprechendes??
-
Beim Bootloader natürlich ORG 0x7C00...
Oder was meinst du? Der Bootloader is der von TeeJay, den Code hier zu posten wäre sinnlos...
-
Jaja..dann stimmt das....
-
was ich vermute is, dass der nach 0x0008:0x0 springt, und zwar der realen adresse... ist irgendwo im bios.... keine ahnung was ich noch machen soll...
-
Ich weiß ja nicht, ob ich was falsch mache, dank GRUB hatte ich noch nicht mit solchen Zeug zu tun. Aber selbst mit [ORG 0x10000] kommt bei mir beim Sprung zu PMODE effektiv ein jmp 0x8:0x17 raus, was ja ganz offensichtlich falsch ist.
-
ich bin absolut ratlos... hab jetzt (1<<3) durch gdt-$ ersetzt, wegen der adresse... aber immer noch nichts...
-
Das (1<<3) war schon richtig, aber mit dem jmp ist was faul, glaube ich.
-
dass denke ich auch... nur was?
-
Schieb mal das [BITS 32] vor den jmp. Mit 16-Bit-Adressen kommt man nicht ganz bis 0x10000, würde ich vermuten. ;) Wie gesagt, alle Angaben ohne Gewähr, ich hab sowas selbst noch nie gemacht.
-
Hab jetzt alles auf Bits 32 gesetzt, hat nur dafür gesorgt, dass... na ja... irgendwas passiert... aber er springt nicht zu dem code den ich gemacht hab...
-
Nein nein... Lass das [Bits 32] wo es ist...
Aber benutz mal statt
jmp codesel:PMode
des hier:
jmp dword codesel:PMode
Denn wenn die physikalische Adresse 0x10000 ist... Dann muss du ja
ein 32Bit Offset angeben... Und ich meine ich hab das bei mir dann
immer so gelöst, dass ich ein DWORD davor gesetzt hab...
Ist aber auch schon länger her XD ich benutze nämlich nun auch GRUB.
-
ICH GLAUB'S JA NICHT!
Danke! Danke! Es funktioniert!!!!
<insert mere joy here>
Tausend Dank........... an alle............
-
Na prima :)
Dann ist ja alles ok XD
Dann noch viel Spaß und Erfolg im Protected Mode ;)
-
Hm, stimmt, die 32 Bit gelten erst nach dem Neuladen von cs, oder wie war das? Dann sieht das mit jmp dword doch wesentlich sinnvoller aus. Bei diesen Themen immer nur ein bißchen mitlesen und dann sein Halbwissen weitergeben, ist vielleicht doch nicht das beste...
FalShen: Das mit [BITS 32] ganz an den Anfang habe ich übrigens nicht gesagt. Auch wenn mein Vorschlag nicht viel besser war. ;)
-
Sacht ma... wo is'n jetz' der Videospeicher? ds:0xB8000 geht irgendwie nicht...
-
Der Videospeicher sitzt an der Adresse 0xB8000. Das stimmt schon so...
DS muss dann einen Selector auf ein Segment mit der Basis Null enthalten.
-
Naja...vieleicht musst du den Screen zuerst noch reseten. Mit folgendem Bios-Int gehts:
mov ax,3 ;Bildschirm löschen
int 0x10
Noooooooooooooos
-
interrupts gehen doch nicht im protected mode.......
-
Musst du halt noch im RM schreiben.
-
Wäre das erste Mal, daß ich davon höre...
-
einfach memset() bzw. das Assembleräquivalent deiner Wahl drüberlaufen lassen.
@FalShen: Was heißt "geht nicht"?
-
is das nicht so? dass ich erst ein Interrupt Gate schreiben muss oder so?
-
Um irgendwas in den VideoRAM zu schreiben? Nein.
-
Aber um int 0x13 auszufürhren...
-
Jo, aber das bringt ja so nichts. Du kannst nicht einfach das interrupt gate auf die entsprechende BIOS funktion verweisen lassen, da das ja 16bit realmode code ist. D.h. du musst es sowieso selber schreiben und dann lohnt es sich auch wieder nicht das mit einem Interrupt zu machen, sondern da reicht dann ein normaler Funktionsaufruf.
-
Mal davon abgesehen, daß du den Interrupt an dieser überhaupt nicht aufrufen müssen solltest, sondern eigentlich alles funktionieren müßte, wenn du wirklich an 0xb8000 schreibst.