Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Nachrichten - Yarcanox

Seiten: [1]
1
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 :lol:
2
Das Wiki / Re: Ein Paar Vorschläge...
« am: 31. March 2007, 20:12 »
Man könnte auch einfach ein "Suche Mitarbeiter", "Biete meine Mitarbeit an" und ein "OS-Vorstellung"sforum machen. Das wäre programmiertechnisch gesehen die einfachste Variante, und würde sicher auch funktionieren...
Aber ein System wie es z.b. Developia.de hat, wäre natürlich schöner :-)

EDIT: Okay, hat wohl seinen Ursprung in 2004, trotzdem fänd ich die Idee nicht schlecht... man muss ja nicht gleich ein Developiasystem dafür Coden, die entsprechend benannten Foren mit jeweils einem "Postregeln"-Post, der auf eine einheitliche Threadüberschrift á la [Suche] oder [Biete] hinweist, reicht ja schon
3
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.

4
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.
5
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.
6
Der Code ist ja oben unter dem Link, aber wenn du noch mal die Deskriptoren explizit sehen willst:
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?
7
Lowlevel-Coding / Re: probleme mit bios
« am: 30. March 2007, 23:25 »
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).
8
Lowlevel-Coding / Re: probleme mit bios
« am: 27. March 2007, 21:51 »
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
9
Lowlevel-Coding / Re: probleme mit bios
« am: 27. March 2007, 20:42 »
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 :/
10
Lowlevel-Coding / Re: probleme mit bios
« am: 25. March 2007, 19:30 »
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)...
11
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 :x
Seiten: [1]

Einloggen