Thema: [solved] probleme mit [bios]-nein, eher videomode 13h

[Yarcanox]

Ich nutze das Bios um in 320x200 mit 256 farben zu kommen.
Das funktioniert zwar, aber ich kann danach nichts auf dem Schirm anzeigen.

Man könnte natürlich denken, das liegt am Code, aber ich habe es von jemandem anderen testen lassen und es ging wunderbar: Schwarzer Bildschirm mit drei roten Pixeln oben, genau so, wie es sein soll.
Wenn ich nun das ganze bei mir nicht im Bochs-Emulator (wo es geht) laufen lasse, sondern real boote, sehe ich einen schwarzen Bildschirm und irgendwo unten links ein lila-pixel.
Ich habe daraufhin den Kernel geändert und noch ein paar mehr Pixel hingeworfen, aber das Bild blieb das gleiche, fast so, als würde er die Pixel von einem falschen Eck aus dem Videospeicher lesen.

Wird wohl daher ein Fehler vom Video-BIOS sein, oder?
Dann müsste ich also direkt per VGA und übern I/O-port an die graka ran, nicht? Damit könnte ich ja auch 320x200x8bit einschalten und nutzen. Ich finde aber keine gescheiten Tutorials dazu, die sind alle darüber, wie man es MIT BIOS reinkriegt, was ja bei mir nicht geht.

Kann ich das Videobios vllt updaten? Man sagte mir, das wäre ein anderes als das normale Mainboard-BIOS und könne auch nicht so leicht geupdated werden.

Wenn irgendeiner einen Tipp hat, was die beste Variante ist, um auch bei mir drei rote Pixel auf den Schirm zu kriegen, oder eine Idee hat, warum es nicht geht (vllt liegts ja doch nicht am Bios), soll sich melden.

Der Code ist: http://eloxoph.net/code.asm

Das kotzt mich jetzt schon an, dass es woanders geht und gerade bei mir nicht, und das unter Umständen nur, weil das BIOS nen Bug hat... hatte ich gerade meine ersten Pixel, und jetzt darf ich wahrscheinlich alles nochmal neu mit VGA machen

[nooooooooos]

Und wenn du Vesa nimmst...Vielleicht geht das mit BIOS oder da gibt es doch noch so ein PM-Interface...

Es gibt halt einfach ein paar Sachen, die man fast nicht ohne das BIOS hinkriegt...Du kannst dir hächstens die Linux-Sourcen anschauen...


Gruss
Noooooooooos

[Yarcanox]

Interessant ist für mich auch die Frage, ob es wirklich am BIOS liegt, ich befürchte aber schwerlihc, dass dem so ist.
Und was ist VESA? VGA oder VESA is ja egal, Hauptsache irgendwas, das mir den gewünschten Grafikmodus ohne jahrelanges Treiberbasteln gibt. Wichtig wären links, weil gerade zu VGA finde ich einfach nix gescheites (VESA kenn ich nicht und hab dementsprechend noch nicht danach gesucht)...

[Yarcanox]

ist 0A000h eigentlich durch den VGA-standard bestimmt? also ist bei 320x200x8 die Adresse automatisch? Oder kann das bedienende Interface (in meinem Fall das Bios) das frei wählen?
Wenn es festgelegt ist durch die Grafikkarte/den Grafikmodus, dann kann es ja fast nicht am BIOS liegen :/

[kevin]

Die ist fest, der VGA-Framebuffer liegt immer bei 0xA0000.

[Yarcanox]

ich hab ja oben beschrieben was passiert. quellcodelink ist auch da. dann liegt das also wahrscheinlich gar nicht am BIOS? wenn das darauf keinen einfluss hat?
weil in die memory schreiben tu ja ICH, nicht das bios, und der grafikmodus ist augenscheinlich aktiviert worden, auch auf meinem PC. nur dass das falsche angezeigt wird, obwohls sonst überall geht.

hat jemand ne idee, worans liegen könnte? ich bin assemblerneuling und überseh daher an jeder ecke was und finds ewig nicht, für hilfe wär ich also dankbar. wenn ihr auch nur eine vage idee habt, was ich testen könnte, damit es auch auf meinem eigenen pc funzt, dann sagt's ruhig

[Yarcanox]

ok ich habe nun mit stundenlangem rumprobieren etwas erreicht: zuerst einmal fand ich heraus, dass der fehler bei den deskriptoren liegen muss, weil wenn ich direkt vor diesen abbreche, geht es noch wunderbar. sobald diese "deklariert" wurden und der sprung in den kernel getan ist, geht nix mehr (32bit-mode-umschaltung kommt erst danach und ist somit irrelevant).

Jetzt habe ich an den Deskriptoren rumgefummelt, und tatsächlich eine Änderung erziehlt (anscheinend mochte er überlappende Deskriptoren nicht, das hab ich jetzt geändert):
Aber statt den zwei roten Pixeln auf schwarzem Grund, die ich momentan als Testbild habe und wieder einmal im Emulator anstandslos funktionieren und wahrscheinlich auch woanders (die drei Pixel gingen auch im emu und auf zwei realen PC's, nur meinem eigenen nicht), sehe ich bei meinem PC die loading-schrift, die im textmodus gesetzt wird.
Es ist, als hätte ich die Textmodusauflösung niedriger gestellt (nun gut, das ist sie wohl definitiv auch) und die Textfarbe auf türkis gestellt (der Text ist türkis auf schwarzem Grund statt Standardhellgrauweiß auf Schwarz).

Weiteres rumwursteln an den Deskriptoren hat bis jetzt keine Erfolge gebracht, das Bild bleibt gleich (ändern wie erwartet tut es sich nur im Bochsemulator).

[nooooooooos]

Also als erstes würde ich ein flaches Speichermodell implementieren. Das heisst, alle Deskriptoren sind von 0 - FFFFFFFF. So ist dein System viel einfacher zu überschauen, weil du nur für jeden Ring einen Daten+Code Deskriptor brauchst, und wenn du mal Multitasking hast noch mindestens einen für ein TSS. Das benützen die meisten OS auch neuere Windows+Linux. Das bedeutet du kannst die Offsets immer so machen wie es im Speicher physikalisch ist (ausser du hast Paging). Dadurch musst du die Segmentregister nie wechseln(was Zeit bringt) und weil es weniger kompliziert ist ist das ganze auch wengier Fehleranfällig.

Zweitens würde ich dich bitten, mal nur das wichtigste zum Problem zu extrahieren. In diesem Falle glaube ich ist das nur der Bootloader, weil ja da schon falsch angezeigt wird nicht? Dann könntest du wenns immer noch nix bringt den Textmode weglassen usw. bis du den Fehler findest.

Drittens könnte noch etwas mit dem A20 nicht stimmen, weil da gibt es etwa 3-4 Varianten es einzustellen...Vieleicht ist dein PC mit deiner Variante nicht zufrieden. Kannst mal hier schauen: http://www.win.tue.nl/~aeb/linux/kbd/A20.html

Viertens würde ich das Interrupt-Bit vom Anfang an bis zum einschalten der IDT mittels cli lassen...(Kann aber kaum was ausmachen)



Gruss
Noooooooooooos

[FreakyPenguin]

Ich würde dir auch empfehlen, ein flaches Speichermodell herzunehmen.

Drittens könnte noch etwas mit dem A20 nicht stimmen, weil da gibt es etwa 3-4 Varianten es einzustellen...Vieleicht ist dein PC mit deiner Variante nicht zufrieden.

Sollte ja beim Schreiben in den Videospeicher keine Probleme machen. Das einzige was eventuell sein könnte ist, dass er die GDT direkt in den Videospeicher schreibt.


Yarcanox:
Versuchst du im Real Mode oder im Protected Mode in den Videospeicher zu schreiben? Vielleicht wärs nicht schlecht, wenn du die relevanten Codeausschnitte mal herzeigst.

[Yarcanox]

Der Code ist ja oben unter dem Link, aber wenn du noch mal die Deskriptoren explizit sehen willst:

Code: [Auswählen]

jmp  go


      limit   dw 0                                    ; Größe der GDT
      base    dd 0 
    GDT:
           


    ; Deskriptor 0, wird nicht benutzt => 0
       des_dummy   times 8 db 0

    ; Deskriptor 1, CODESEGMENT DESKRIPTOR => 8
       des_code    dw 01C00h            ; Segemntlänge
                   dw 08000h            ; Basisadresse
                   db 0                 ; Auch Basisadr
                   db 10011010b            ; Zugriff
                   db 00000000b            ; Länge und flags
                   db 0                    ; Auch Basisadr       

    ; Deskriptor 2 => 8 => 8h
;       des_data    dw 09C00h            ; Segemntlänge
;                   dw 00000h            ; Basisadresse
;                   db 0                 ; Auch Basisadr
;                   db 10010010b            ; Zugriff
;                   db 00000000b            ; Länge und flags
;                   db 0                    ; Auch Basisadr
                   
   ; Deskriptor 2 => 16 => 10h
       des_videodirect    dw 0FA02h            ; Segemntlänge
                   dw 000h            ; Basisadresse
                   db 0ah            ; Auch Basisadr
                   db 10010010b            ; Zugriff
                   db 00000000b            ; Länge und flags
                   db 0                    ; Auch Basisadr   

   ; Deskriptor 3 => 24 => 18h
       des_video   dw 0FFFFh            ; Segemntlänge
                   dw 0A28h           ; Basisadresse
                   db 019h                 ; Auch Basisadr
                   db 10010010b            ; Zugriff
                   db 00000000b            ; Länge und flags
                   db 0                    ; Auch Basisadr       

go:
Ich befinde mich also, wenn go: erreicht ist, noch immer im Realmode, die Umschaltung folgt erst danach. Aber die Deskriptoren sind schonmal angelegt.
Wenn ich direkt vor jmp go eine Endlosschleife mache und damit davor stoppe, ist alles wie erwartet. Wenn ich das direkt hinter go: tue, geht es nicht mehr, zumindest auf meinem PC. Wie gesagt, das Problem besteht nur auf meiner Intel Pentium 4 3 Ghz-Maschine mit 512 Ram (DDR glaub ich), auf allen andern getestesten Maschinen läuft es.

Die Deskriptoren wie oben aufgelistet sind, wie sie gerade aktuell sind. Ich habe Überschneidungen verhindert, indem ich die Größen entsprechend geändert habe, und des_data ganz deaktiviert, weil ich ihn eigentl. auch nicht brauche.

Damit hab ich eben bei mir nicht einfach ein lila pixel, sondern wie oben beschrieben den Inhalt des Textmodes rüberkopiert in den Grafikmodus wie in einem Screenshot, nur dass der Text türkis ist - auf anderen PCs läuft es wie erwartet und ich kann problemlos Pixel setzen etc, nur auf meinem PC lässt sich dieses Bild nicht manipulieren, er zeigt es immer an, egal was ich tue und an den Pixeln im Videomemory rumpuhle.
Wie gesagt, BEVOR die deskriptoren kommen, geht noch alles.

Ich hoffe die Infos waren jetzt ausführlich genug

PS: Wie man sieht, ist der des_videodirect, der auf den Videoram zeigt, in der Basisposition etwas komisch angegeben. Seltsamerweise liefert nur diese komische Art und Weise von 0A000h das korrekte Ergebnis auf allen PCs - außer auf meinem, wie gesagt. Vllt. hilft das auch weiter

PS2 & Edit No1 @ forenregeln: darf man hier im Forum eigentl. banner in die signatur machen? und wie groß dürfen die dann sein, um kein Ärger bei den Mods hervorzurufen?

[FreakyPenguin]

Wie Oben schon gesagt, würde ich dir empfehlen ein flaches Speichermodell zu benutzen. Einfach 2 Deskriptoren machen. Daten und Code: Basis=0 Limit=4Gb.

Ich vermute, dass der Fehler im Bootloader ist. Um das zu bestätigen müsste ich mir den Code aber genauer anschauen, und im RM hab ich auch schon ewig nix mehr gemacht. Wenn ich heute noch Zeit finde, kann ich das Ding mal debugen.

PS2 & Edit No1 @ forenregeln: darf man hier im Forum eigentl. banner in die signatur machen? und wie groß dürfen die dann sein, um kein Ärger bei den Mods hervorzurufen?

Edit: Solange taljeth nix sagt ists gut .

[nooooooooos]

Aber wenn du sagst, dass vor der GDT alles auch auf deinem PC stimmt, dann heisst das, dass es im späteren Code wieder rückgängig gemacht wird oder was?

Für die Anweisungen im PM brauchst du UNBEDINGT ein [BITS 32] nach dem Jump in den PM. Setz das mal....


Gruss
Noooooooooos

[Yarcanox]

Nur dass es keine Missverständnisse gibt: Ich bin an der Stelle, um die es geht, noch nicht im PM, von daher ist ein Bit, das ich beim Jump in diesen setzen muss, für den Fehler ja nicht wichtig, weil ich noch gar nicht in den PM gegangen bin!
Der Fehler ist ja vor dem Wechsel in den PM.

[nooooooooos]

Also das muss dennoch ganz sicher rein...

Damit ich dich richtig verstehe, bei Anhalten vor dem LGDT Befehl (und dem Initialisieren der Variablen) geht alles wie es muss auf allen PCs und nach diesem Befehl geht es auf allen PCs ausser auf deinem wo wieder die Anfangsnachricht türkis im Textmode angezeigt wird?

[Yarcanox]

NICHT im textmode! sie wird im grafikmodus gezeigt, die auflösung wird also gewechselt auf eine niedrigere, 320x200 eben. nur dass er nur den text anzeigt, anstatt einen schwarzen bildschirm mit 3 roten pixeln, wie es auf allen anderen testpcs der fall ist

BigEdit:

ok, vergesst den ganzen code ab dem punkt hinter go:, ich hab da jetzt ne endlosschleife zum erneuten testen rein, und bis dahin geht schon genug schief, als dass man auch noch den Code dahinter nach fehlern durchsuchen müsste

Ich habe nun erstaunliches festgestellt:

Zuerst muss ich einmal sagen, dass ich nach dem Loading am anfang im Textmodus ganz zu Beginn im Bootloader einen kleinen Interrupt eingebaut habe, der auf einen Tastendruck wartet, und den Text zu "Press a key" geändert habe.
Nun habe ich festgestellt, dass es der Fehler von oben nicht immer aufrtitt, um genau zu sein, gibt es drei Varianten, die mir nach vielem Testen begegnet sind:

1. Variante: Es funktioniert. Nach dem Tastendruck, nachdem das Programm in den Grafikmodus wechselt und in der Endlosschleife zum Stillstand kommt, schwarz. Der Wechsel in den PM und das Setzen der 3 roten Pixel danach ist ja erstmal weggelassen

2. Variante: Ich sehe das "Press a key"-Zeug vom Textmodus im Grafikmodus in anderer Auflösung & türkis. Wenn ich nun aber eine Taste drücke, tut er diesen Tastendruck offensichtlich noch einmal verarbeiten, obwohl ich mich ja angeblich in einer Endlosschleife nach den Deskriptoren befinde! Das heißt, der Code läuft da irgendwie doppelt. Als ich nun eine Taste drückte, kam es zu Fall 3, der auch ab und zu direkt beim Grafikmoduswechsle nach dem Tastendruck passiert:

3. Variante: Auch eine altbekannte Situation: Ein schwarzer Bildschirm, aber unten links ein lila Pixel. Und ich wette, dass ich das Bild auch nicht ändern könnte, wenn ich wollte, aber wie gesagt, der Pixelsetzcode und das alles ist erstmal außen vor gelassen.

Eigentlich sollte immer Variante 1 geschehen, so passiert es auch im Emulator.
Die verschiedenen Varianten passieren für mich nicht reproduzierbar, es scheint total zufällig.

[nooooooooos]

Also ist jetzt da überhaupt kein PM mehr zu sehen? Hast du den PM und alles andere Zeug nur mittels einer Endlosschleife nicht zum Ausführen gebracht oder auskommentiert?

Kannst du mal den neuen Code online geben? Noch besser wäre die gesamte Entwicklungsumgebung...

Passiert die Variante2 also "PressKey" im Grafikmodus in lila sofort oder erst nach dem drücken einer Taste?

Ich check einfach nich, wie Buchstaben im Grafikmodus ausgegeben werden können...



Greez
Nooooooooos

[Yarcanox]

endlosschleife, nicht auskommentiert.

der code ist derselbe wie ich im ersten post verlinkt habe. einzige änderung: nach ausgeben vom loading am anfang warten auf tastendruck, die deskriptoren wie beschrieben geändert und nach dem go: eine endlosschleife.

ALLE Varianten passieren erst nach dem Drücken einer Taste. Ich hab doch erklärt, dass er erst auf nen Tastendruck wartet, bis er in den Grafikmodus wechselt. Und dann zeigt er den Text aus dem Textmodus in der niedrigeren Grafikmodusauflösung 320x200 in türkis, als hätte ich ihn da hingepixelt.

[Yarcanox]

bitmaster hat den code durchgetestet und das problem gefunden: der stack landet bei einigen rechnern so ungünstig, dass er das bios oder funktionen von diesem überschreibt. eine andere stackposition hat das problem nun vollkommen beseitigt