Thema: Bildschirm löschen bzw. leeren

[hrungaaz]

Servus,

erstmal großes Lob an die lieben Leute, die sich solche Mühe für das Wiki gegeben haben.
Ich habe nach langem Rumgewurschtel und Tools installieren (unter Windows, ich denke der Fall ist für euch klar  ) geschafft ein bootfähiges Image, welches GRUB benützt zu erstellen, so wie es in "Teil 4 - Hello World" des Wikis beschrieben ist.
Da ich nirgends eine Anleitung gefunden habe, wie man nun den Bildschirm löscht.

[...] ein wunderschönes Hello World in die linke obere Ecke. Den Rest des Bildschirms zu löschen haben wir leider vergessen, so dass das über irgendwelche BIOS-Meldungen geschrieben wird.

Nun, da ich nicht - so wie wir hier in Bayern sagen - auf der Brennsuppe dahergeschwommen komme, schonmal kleine Programme für meinen Taschenrechner in Assembler geschrieben habe und über passable C-Kenntnisse (oder vielmehr C++) verfüge, habe ich folgende schleife in die init()-Funktion hinzugefügt:

Code: [Auswählen]

//...
int n;
while (n < 0xB8FA0)
{
video[n] = 0x0;
n++;
}
//...

vorher wurde 'video' als Pointer auf die Adresse 0xB8000 definiert.
Im Wiki steht, der Videospeicher ist 4kB groß d.h. 4000 Byte entspricht FA0 in hexadezimal.
Dann rechnet man zu 0xB8000 noch FA0 dazu, und man bekommt die letzte Adresse im Videospeicher - oder?
Mithilfe der schleife wird dann jedes Byte auf 0 (Schwarz) gesetzt. Somit hätte ich ja dann quasi auch den Bildschirm gelöscht.
Und es funktioniert sogar!
Leider gibt Bochs vor dem Ausführen einige PANIC-Meldungen aus, welche ich alle mit 'Continue' quittiere.
Das Hello World wird korrekt auf einem schwarzen Bildschirm ausgegeben, so wie ich es wollte.
Die Frage ist nur, kann ich das auf meinen PC loslassen? Ich meine Bochs wird nicht umsonst PANIC schieben.

mfg rungaaz

[kevin]

Hm, auf den ersten Blick... Wie wäre es damit, n auch noch zu initialisieren? Und wie ist video deklariert? Als char* bzw. uint8_t*?  Falls nicht: Du wärst nicht der erste, der auf die C-Pointerarithmetik reinfällt.

Ansonsten zeig mal die genauen bochs-Meldungen her, da sollten auch noch ein paar Hinweise auf den Fehler drin stehen.

Was den realen PC betrifft, ist die Wahrscheinlichkeit nicht groß, dass du irgendwas kaputt machst. Wenn du irgendwann mal auf die Festplatte schreibst, würde ich mir Gedanken machen, ob das ausgerechnet die Festplatte sein muss, die die wichtigsten Daten enthält, aber mit ein bisschen falschen Speicher überschreiben geht in der Regel nichts kaputt (auch wenn es mit viel Pech theoretisch möglich wäre, das eine oder andere lahmzulegen).

[MNemo]

vorher wurde 'video' als Pointer auf die Adresse 0xB8000 definiert.
Im Wiki steht, der Videospeicher ist 4kB groß d.h. 4000 Byte entspricht FA0 in hexadezimal.
Dann rechnet man zu 0xB8000 noch FA0 dazu, und man bekommt die letzte Adresse im Videospeicher - oder?

Ja, dass ist die letzte bzw. die Adresse danach. Aber die brauchst du gar nicht. Wenn char* video = 0xb8000, dann hast du das
Ende schon mit video[0xfa0] erreicht(bzw. überschritten) und nicht erst mit video[0xb8fa00].

[kevin]

Ups, MNemo hat natürlich recht. Da habe ich nicht gründlich gelesen.

[hrungaaz]

Also video wurde folgendermaßen definiert: char* video = (char*) 0xB8000
Ach, jetz peil ich das. Die Schleife muss folgendermaßen lauten:

Code: [Auswählen]

int n (0); //Oder int n = 0; Ist glaub ich Jacke wie Hose
while (n < 0xFA0)
{
    video[0xB8000 + n] = 0x0; //ansonsten würde man ja den Speicher von 0x0 bis 0xB7FFF auch löschen, was ich ja nicht will.
    n++
}
So, die genauen Panic-Meldungen werde ich noch Posten, aber nicht jetzt, da ich gerade nicht zuhause bin.

Und danke für die Nachsicht im Bezug auf die Forenwahl.

[kevin]

Wenn video 0xb8000 ist, dann ist video[0xb8000 + n] an der Adresse 0x170000 + n. Das ist nicht, was du wolltest.

[hrungaaz]

Aber ich dachte, 0xB8000 wäre die erste Adresse im Videospeicher.
Und da muss man natürlich 4kB dazurechenen, um die letzte Adresse zu erhalten.

Achja, stimmt, video zeigt ja schon auf 0xB8000...


[EDIT]
Also, nochmal  

Code: [Auswählen]

int n (0);

while (n < 0xFA0)
{
    video[n] = 0x0;
    n++;
}

Das dürfte dann hinhauen.
Ich werds testen, und ich werde auch den Code posten.
Aber wie gesagt, erst später, wenn ich zuhause bin.

Wie wäre es damit, n auch noch zu initialisieren?

n ist doch dann automatisch 0 - oder?

[Svenska]

Dann musst du schon schreiben

int n = 0;

Die Klammern sind falsch.

Eleganter wäre

for( n = 0; n < 4000; n++ )
  video[n]=0;

[hrungaaz]

Also in C++ ist int n (0); äquivalent zu int n = 0;
Ob das in C anders ist, weiß ich nicht.
Wie gesagt, ich bin gerade nicht zuhause, um das auszutesten.

 - Ja, wohl war, aber ich bin kein Fan von For-Schleifen.

[Svenska]

Keine Ahnung, da ich mich in C++ nicht besonders auskenne. Da der gcc ein C/C++-Compiler ist, wird er das vielleicht auch können - festlegen mag ich mich da nicht.

For-Schleifen sind aber unglaublich praktisch, um Listen zu traversieren, außerdem kürzer:

void* anfang=...; void* tmp;
for( tmp = anfang; tmp!=NULL; tmp=tmp->next )
  guck_dir_element_an(tmp);

[MNemo]

Dann musst du schon schreiben

int n = 0;

Die Klammern sind falsch.

Wenn er sein Kernel in C++ schreibt, sind sie nicht falsch.

Wie wäre es damit, n auch noch zu initialisieren?

n ist doch dann automatisch 0 - oder?

Nein! n enthält das was zufällig gerade auf dem Stack liegt bis du ihm einen bestimmten wert zugewiesen hast.
Wenn n global definiert ist landet es nicht auf dem Stack sondern in der .bss Sektion, die wenn du glücke hast
vorher mit 0 gefüllt worden ist, aber verlassen solltest du dich da nicht drauf.

[kevin]

Nein! n enthält das was zufällig gerade auf dem Stack liegt bis du ihm einen bestimmten wert zugewiesen hast.
Wenn n global definiert ist landet es nicht auf dem Stack sondern in der .bss Sektion, die wenn du glücke hast
vorher mit 0 gefüllt worden ist, aber verlassen solltest du dich da nicht drauf.

Wie kaputt C++ an dieser Stelle ist weiß ich nicht, aber C99 garantiert dir bei einer globalen Variablen, dass sie mit 0 initialisiert wird.

[hrungaaz]

Ich finde in While-Schleifen ist man einfach freier.

Nein! n enthält das was zufällig gerade auf dem Stack liegt bis du ihm einen bestimmten wert zugewiesen hast.
Wenn n global definiert ist landet es nicht auf dem Stack sondern in der .bss Sektion, die wenn du glücke hast
vorher mit 0 gefüllt worden ist, aber verlassen solltest du dich da nicht drauf.

- Achso, das wäre also dann quasi so, als würde man einen Pointer nur deklarieren.

Was soll das eigentlich heißen. Ich habe auch unter Windows entwickelt und es war leicht alles einzurichten.

Immer diese Windows Feinde hier...

Gut, stimmt auch wieder, aber es gab eine Zeit, da hatte ich noch extrem wenig Erfahrung, da habe ich es einfach nicht zustande gebracht, das ganze unter Windows einzurichten. Nun, da ich mehr Erfahrung habe, ist das kein Problem mehr gewesen. Aber damals hätte ich es unter Linux womöglich schon zustand gebracht.
Außer ich hätte wegen meiner damals mangelnden Linux-Kenntnissen die nötigen Tools nicht kompilieren können, was dann aufs Gleiche hinausgelaufen wäre.

[hrungaaz]

Ja, gut, das stimmt auch wieder.
Es ist nur so, ich bin quasi mit Windows aufgewachsen.
Ich habe schon ein wenig Kenntnisse in Linux aber weitaus nicht so viele wie unter Windows.
Und wie gesagt, ich habe es jetzt auch unter Windows zu stande gebracht.

und komme nicht auf die Idee dir einen 64Bit Cross gcc für Windows zu kompilieren

Keine Angst, das hatte ich ohnehin nicht vor.

[MNemo]

Nein! n enthält das was zufällig gerade auf dem Stack liegt bis du ihm einen bestimmten wert zugewiesen hast.
Wenn n global definiert ist landet es nicht auf dem Stack sondern in der .bss Sektion, die wenn du glücke hast
vorher mit 0 gefüllt worden ist, aber verlassen solltest du dich da nicht drauf.

Wie kaputt C++ an dieser Stelle ist weiß ich nicht, aber C99 garantiert dir bei einer globalen Variablen, dass sie mit 0 initialisiert wird.

OK. Sieht so aus als ob sich gcc/g++ darauf verlässt das die .bss Sektion mit Nullen gefüllt wird. Und in der ELF-Spezifikation steht dass sogar drin. Irgend wie hatte ich in Erinnerung das das nur eine Empfehlung sei -- kein Muss. Das läuft in meinem ELF loader glaub ich noch schief.

- Achso, das wäre also dann quasi so, als würde man einen Pointer nur deklarieren.

So in etwa.

@offfff topic

Da sitzt du einen Tag dran und es geht immer noch nicht.

Immer diese … Kämpfen Tage lang mit Ihren Tools, aber unter Windows ist trotzdem alles ganz easy ..?..

[kevin]

OK. Sieht so aus als ob sich gcc/g++ darauf verlässt das die .bss Sektion mit Nullen gefüllt wird. Und in der ELF-Spezifikation steht dass sogar drin. Irgend wie hatte ich in Erinnerung das das nur eine Empfehlung sei -- kein Muss. Das läuft in meinem ELF loader glaub ich noch schief.

Besser gleich fixen, in tyndur hatten wir genau deswegen schon echte Bugs. Die zu debuggen macht keinen Spaß, denn auf den ELF-Loader kommt man erst als allerletzes.

Edit: Huch, du schreibst ein eigenes OS? Ich hatte dich immer irgendwie als einen von der Fraktion der Theoretiker angesehen. Gibt's irgendwo was zu sehen?

[MNemo]

Edit: Huch, du schreibst ein eigenes OS? Ich hatte dich immer irgendwie als einen von der Fraktion der Theoretiker angesehen. Gibt's irgendwo was zu sehen?

Ja, ich schreibe ein eigenes OS(Namen hat es (immer-)noch nicht). Ich gehöre auch etwas zu der Fraktion der Theoretiker, das ist nicht der erste versuch für einen OS, und diesmal hab ich mir halt vorgenommen das alles besser zu planen. Deshalb ist da nicht viel zu sehen. Und so intensive arbeite ich da auch nicht dran.  Und die quellen sind auch nicht offen. Von daher eher uninteressant.

[hrungaaz]

Eine Frage: Kann es sein, dass an jeder Adresse 16BIT stehen?
Wenn ja, muss ich in meiner schleife nicht überprüfen, ob n < 0xFA0 sondern n < 0x1F40 - oder?

[kevin]

Wenn du es als char* deklariert hast nicht.

Und halbieren, nicht verdoppelt wäre der richtige Ausgleich für diesen Fall.

[hrungaaz]

Verzeih mir die Frage, aber ist ein char wirklich 16BIT groß?

Und halbieren, nicht verdoppelt wäre der richtige Ausgleich für diesen Fall.

- Ja, verdammt, stimmt.  
Mit der Zeit schwindet irgendwie das logische Denken...