Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: FalShen am 12. May 2007, 04:20
-
Ich schätze mal, jeder von euch hat diesen kleinen Abschnitt so in seinem Kernel zu stehen:
outport(0x03d4,0x0f);
outport(0x03d5,m_nCursor & 0xff);
outport(0x03d4,0x0e);
outport(0x03d5,m_nCursor >> 8);
Oder zumindest sehr ähnlich. Also, dieser Code funktioniert bei mir auf einmal nicht mehr. Zuerst dachte ich, es wäre ein neuer Bug von Bochs. Nein. Es ist auch kein Compilerfehler, hab den Assmblercode überprüft. Ich habe auch die outport Funktion in Assembler und in C geschrieben, kein Unterschied. Ich hab jetzt keine Ahnung was ich hier machen soll, denn der Cursor wird einfach nicht gesetzt.
An einer anderen Stelle lese ich die Register um meine Cursor-Variable zu updaten, das klappt.
outport(0x03d4,0x0f);
m_nCursor = inport(0x03d5);
outport(0x03d4,0x0e);
m_nCursor |= inport(0x03d5) << 8;
Auch der Versuch, den Cursor auf 0|0 zu setzen, also direkt 0x00 als Positionen zu übergeben, hat nicht funktioniert.
Nun sitz ich hier bis 4 Uhr nachts nur wegen diesem Fehler, und ich könnte schreien, weil ich nicht wieß, was es ist.
Was ist hier falsch? Ist das wiedermal so etwas, dass Code der sonst immer geht, nur bei mir wieder mal absolut nicht funktioniert? Hatte ich ja sch öfters...
-
Hi, dazu musste ich erstmal mein alte RM OS/M Betriebssystem Code rauskramen. Das habe ich dann auch gemacht und so schön wie das ist, ich verstehe meinen eigenen Code immer so schnell. Die Variable m_nCursor ist bei dir ein WORD groß, soll das erste Byte den X Wert beinhaltet und das zweite den Y Wert? Wenn ja dann ist das falsch. Man sendet nicht Spalte + Zeile. Man multipliziert die gewünschte Zeile mit 80 (80 = Anzahl der Zeilen) und addiert die gewünschte Spalte hinzu. Also ungefähr so:
Zeile*80+Spalte
Diesen Wert kopiert man dann z.B. in die Variable m_nCursor. Dann das erste Byte senden und dann das zweite (oder so wie ich anders herum, kA ob die Reihenfolge egal ist). Aus deinem Code geht natürlich nicht hervor ob du vorher die Berechnung machst und es also richtig machst. Aber du sagst ja, 0,0 geht auch nicht, also muss es ein anderer Fehler sein. Also mein ASM-Code sollte das gleiche machen wie dein C-Code:
mov al,0Eh
mov dx,03D4h
out dx,al
mov al,bh
mov dx,03D5h
out dx,al
mov al,0Fh
mov dx,03D4h
out dx,al
mov al,bl
mov dx,03D5h
out dx,al
Nur das hier halt in bx der Wert ist, welcher bei dir in m_nCursor ist. Also fürhst du die obene Berechnung auch durch, wird dein Code an der richtigen Stelle ausgefürht etc. ? Ob man jetzt erst den 0Eh-Wert senden muss und dann den 0Fh-Wert oder ob das egal ist weiß ich nicht. Tausche es mal, wenn nichts anderes der Fehler sein kann.
bitmaster
-
Auf den ersten Blick sehe ich da keinen Fehler, vorausgesetzt, du berechnest die Position korrekt.
Hier ein Ausschnitt aus dem LOST-Code. Dieser funktioniert so:
//Hardware Cursor verschieben
word hw_cursor_pos = cursor_x + cursor_y * SCREEN_WIDTH;
outb(0x3D4, 15);
outb(0x3D5, hw_cursor_pos);
outb(0x3D4, 14);
outb(0x3D5, hw_cursor_pos >> 8);
-
Nein, m_nCursor enthält die bereits berechnete Position, also eigentlich nur das Offset (m_nOffset wäre ein besserer Name, geb ich zu...) Somit muss die Berechnung ja nicht erfolgen. Um eins weiter zu gehen, inkrementiere ich diese Variable nur, ist einfacher als immer mit einem X- und einem Y-Wert zu rechnen und geht auch schneller.
In C hatte ich das schon einmal so gemacht, und es hat funktioniert. Geht es einfach nicht, weil ich C++ verwende, oder was?
Add: Hab jetzt mit X- und Y-Werten probiert, immer noch nicht...
-
Eventuell Stack/Memory Corruption oder Probleme mit Paging, Interrupts oder Segmenten, die verhindern, dass der Code ausgeführt wird?
-
m_nCursor klingt so nach Membervariable. Könnte es sein, dass es eine globale Klasse ist, welche du nicht initialisierst?
-
http://www.osdev.org/wiki/Text_Mode_Cursor
hat fast genau den gleichen code, es werden nur noch Typumwandlungen gemacht.
Ist deine outport-function korrekt? ist die vieleicht nicht für bytes sondern words? was anderes fällt mir sonst nicht ein.
PS:
OSDev.org sagt auch:
Keep in mind that in/out to VGA Hardware is a slow operation. So using the hardware registers to remember of the current character location (row, col) is bad practice
-
Standardmäßig sahe sie so aus:
[GLOBAL outport]
outport:
push ebp
mov ebp, esp
mov edx, [ebp+8]
mov eax, [ebp+12]
out dx, al
leave
ret
[GLOBAL inport]
inport:
push ebp
mov ebp, esp
mov edx, [ebp+8]
in al, dx
leave
ret
So hab ich sie immer genutzt... Als das auf einmal im C++ Kernel nicht funktioniert hat, hab ich versucht, das so zu machen:
unsigned char inport(unsigned short port)
{
unsigned char value;
__asm__ __volatile__ ("inb %1, %0" : "=a"(value) : "d"(port));
return value;
}
void outport(unsigned short port,unsigned char value)
{
__asm__ __volatile__ ("outb %b0,%w1" : : "a"(value), "d"(port));
}(Gefunden in dem OSD Kernel Paket auf Bona Fide)
Edit: Vorher hab ich immer die ASM-Funktionen genutzt... Hat auch immer funktioniert. Nebenbei, der outport bei
outport(0x03d4,0x0f);
m_nCursor = inport(0x03d5);
outport(0x03d4,0x0e);
m_nCursor |= inport(0x03d5) << 8;muss ja funktionieren, da der Cursor richtig ausgelesen wird. Nur nicht richtig gesetzt... Der steht im Konstruktor (weil statische Klasseninstanz), also wird die Variable initialisiert.
Der Code
outport(0x03d4,0x0e);
outport(0x03d5,0x00);
outport(0x03d4,0x0f);
outport(0x03d5,0x00);
geht ja auch nicht...
Nebenbei... von inline assembler von gcc hab ich keine ahnung... Versteht den überhaupt jemand? Der ist so kryptisch...
-
Nebenbei... von inline assembler von gcc hab ich keine ahnung... Versteht den überhaupt jemand? Der ist so kryptisch...
http://lowlevel.brainsware.org/wiki/index.php/Inline-Assembler_mit_GCC
-
ich hab mit dem inline assembler etwas gemacht... und dann einfach, weil's mir so langsam reicht, alles komplett mit assembler gemacht, also due cursor-funktion:
[GLOBAL cursor]
cursor:
push ebp
mov ebp, esp
mov ebx, [ebp + 8]
mov al, 0x0e
mov dx, 0x03d4
out dx, al
mov al, bl
mov dx, 0x03d5
out dx, al
mov al, 0x0f
mov dx, 0x03d4
out dx, al
mov al, bh
mov dx, 0x03d5
out dx, al
leave
ret
ABER: ES GEHT IMMER NOCH NICHT!!!
Ich raste bald aus, es ist doch DER SELBE CODE den ALLE ANDEREN und auch ich selbst benutzen, und der immer funktioniert... NUR HIER NICHT...
WARUM NUR??
-
Entweder deine Routine ist zu schnell---> Dann würde ich irgendwelche NOPs mal reinflicken zur verlangsamung.
Oder es liegt an etwas ganz anderem an deinem OS! Was hast du denn schon alles implementiert? Multitasking?, welches?, Paging, PM, hast du irgendwelche Ports vielleicht gesperrt, IOPL-Flag in den Eflags, oder TSS?, Flaches oder anderes Speichermodell...
Erzähl mal was über dein OS!!
Gruss
Noooooooooooos
-
Entweder deine Routine ist zu schnell---> Dann würde ich irgendwelche NOPs mal reinflicken zur verlangsamung.
Was für ein Schwachsinn!!!
bitmaster
-
Bochs erwartet nicht, dass du wartest bis die Bytes korrekt verarbeitet wurden. Bochs braucht kein exaktes Timing soweit ich weiß (beim den Controllern für Floppy oder Harddisk sowie beim APIC und anderen Geräten auch nicht.)
-
Warum Schwachsinn?? 1. steht ja sowas in Osdev.org... und 2. hat es mehr Sinn einfach mal zur kontrolle 3 nops reinzuflicken, als zu erklären, wie man einen Pixel berechnet, was gar nix mit dem Problem zu tun hat....
Gruss
Noooooooooos
PS: übrigens steht glaub ich nirgends was über bochs...
-
Zuerst dachte ich, es wäre ein neuer Bug von Bochs.
ejtz hört ma auf euch hier so zu dissen das bringt auch kein ergebnis...
obwohl ich verlangsamung auch für überflüssig (http://www.stupidedia.org/stupi/%C3%9Cberfl%C3%BCssig) halte
MfG
PS: einfach mal auf überflüssig klicken und outchilln
-
was gar nix mit dem Problem zu tun hat....
Was wir bis dahin ja noch gar nbicht wussten. Und deine NOPs bringen da auch nichts, weil es mit dem Code gar nichts zu tun hat. Dieser wird nämlich nicht oder nicht richtig aufgerufen. Der Code an sich ist richtig. Also liegt das Problem ganz wo anders.
bitmaster
-
Das ist mir ja auch klar dass das warscheinlich nix bringt...Aber ganz sicher war ich mir halt nicht, weshalb ich ihm sagte er solls einfach mal probieren...Sowieso handelte der grösste Teil meines Posts nachher über andere Möglichkeiten welchen den Fehler zur Folge haben könnten.
Darum back-to-topic:Entweder deine Routine ist zu schnell---> Dann würde ich irgendwelche NOPs mal reinflicken zur verlangsamung.
Oder es liegt an etwas ganz anderem an deinem OS! Was hast du denn schon alles implementiert? Multitasking?, welches?, Paging, PM, hast du irgendwelche Ports vielleicht gesperrt, IOPL-Flag in den Eflags, oder TSS?, Flaches oder anderes Speichermodell...
Erzähl mal was über dein OS!!
Und dann eben schau nochmals mittels einer Testausgabe oder sowas ob der Code ausgeführt wird. Du kannst z.B. ein Zeichen dort ausgeben, wo der Cursor hinsollte.
Gruss Nooooooooooos
-
hi,
an der Stelle, wohin der Cursor hin soll, was steht da denn für ein Farbwert/Attributewert/"ka wie man das nennt"-Wert ?
Es sollte zumindest kein Schwarz auf Schwarz dastehen (0x00) :)
mfg,
Stefan
-
Die Zeichenausgabe ist wunderschön, so funktioniert alles.
Hier die Ganze story: Der Kernel ist der neueste rewrite des Scén-Kernels. Hier wollte ich möglichst viel Objektorientiert arbeiten. Bisher hab ich es geschafft (siehe Topic), den Kernel an die Adresse 0xc0000000 zu mappen.
Die Klasse CVideo soll überall gleichermaßen zu benutzen sein. Um dies zu erreichen, wird eine statische Variable als Instanz definiert. Da allerdings ein statisches Objekt bei jedem Aufruf neu erzeugt wird (weshalb die Bezeichnung 'static' eher Schwachsinn ist), wird im Konstruktor der Hardware-Cursor ausgelesen. Somit ist es natürlich wichtig, dass der immer korrekt gesetzt ist.
Es passiert folgendes: Bochs setzt den Cursor irgendwo in die mitte des Bildschirms. Dann, bei jedem Aufruf, also
CVideo::getInstance() << "String";Wird das objekt erzeugt, der String wird dargestellt, aber der Cursor nicht gesetzt. Beim nächsten Aufruf startet er also wieder an der Adresse des Hardware-Cursors, der noch von Bochs stammt.
Die schreib-routine ist die selbe wie immer, gefunden im BKerndev und anderen Tuts bei Bona Fide. Hab's auch 3000mal kontrolliert.
Das schärfste: Hab auch disassmebliert und mit dem alten C-Kernel verglichen, wo es funktionierte. Exakt das selbe.
Was bisher implementiert ist: Paging, PSE (die einzige Neuerung zu vorher), Exceptions (also die ersten 32 interrupts), und die IRQs, aber nur definiert, noch nichts weiter.
also der einzige unterschied sind die Zeilen
mov eax, cr4
or eax, 0x11
mov cr4, eaxFür die 4MB-Pages, aber das isses nicht oder?
-
Um dies zu erreichen, wird eine statische Variable als Instanz definiert. Da allerdings ein statisches Objekt bei jedem Aufruf neu erzeugt wird (weshalb die Bezeichnung 'static' eher Schwachsinn ist), wird im Konstruktor der Hardware-Cursor ausgelesen.
Dann machst du irgendwas falsch. Das stimmt nämlich so nicht. Für statische und globale Objekte musst du aber selbst für die Konstruktion und Destruktion sagen, siehe wiki (http://lowlevel.brainsware.org/wiki/index.php/C_PlusPlus#globale.2Fstatische_Objekte). Zeig am besten mal deine CVideo implementation, die scheint mir dann kein richtiges Singleton zu sein.
-
Ja na gut... die Sache mit dem Singleton ist ja aus dem Game-Bereich übernommen, als ich noch so was gemacht hab... da hat es Größtenteils geklappt.
Hier die video.h (der relevante Teil jedenfalls)
#ifndef __VIDEO_H__
#define __VIDEO_H__
class CVideo
{
protected:
void putc(char c);
void putnum(int num);
void scroll();
void update_cursor();
CVideo();
unsigned short *m_pVideoMem;
unsigned char m_nColour;
unsigned short m_nCursor;
static CVideo m_Instance;
public:
static CVideo getInstance();
CVideo &operator << (const char c);
CVideo &operator << (const char *str);
CVideo &operator << (const int num);
void setColour(unsigned char colour);
void cls();
};
#endif
Und die Implementation, video.cpp (diesmal fast alles):
#include <system.h>
#include <video.h>
extern "C" void cursor(unsigned short crs);
const int COLS = 80;
const int ROWS = 25;
CVideo CVideo::m_Instance = CVideo();
CVideo::CVideo()
{
m_pVideoMem = (unsigned short*)(0xb8000);
m_nColour = 0x07;
outport(0x03d4,0x0f);
m_nCursor = inport(0x03d5);
outport(0x03d4,0x0e);
m_nCursor |= inport(0x03d5) << 8;
}
CVideo CVideo::getInstance()
{
return m_Instance;
}
void CVideo::putc(char c)
{
if(c == '\n')
{
m_nCursor = (m_nCursor + COLS) & ~(COLS - 1);
}
else if(c == '\b')
{
if(m_nCursor > 0) m_nCursor--;
}
else if(c == '\t')
{
m_nCursor = (m_nCursor + 8) & ~(8-1);
}
else if(c >= 0x20)
{
m_pVideoMem[m_nCursor] = c | m_nColour << 8;
m_nCursor++;
}
scroll();
update_cursor();
}
void CVideo::putnum(int num)
{
char tmp[8];
int i = 0;
if (num == 0) putc('0');
else
{
while (num > 0)
{
int j = num % 0x10;
if(j < 10) tmp[i++] = '0' + j;
else
{
j -= 10;
tmp[i++] = 'A' + j;
}
num /= 0x10;
}
while (i-- > 0)
{
putc(tmp[i]);
}
}
}
void CVideo::scroll()
{
if(m_nCursor >= (COLS * ROWS))
{
memcpy(m_pVideoMem,&m_pVideoMem[COLS],COLS * (ROWS-1));
memsetw(&m_pVideoMem[COLS * (ROWS-1)],0,COLS);
m_nCursor = COLS * (ROWS-1);
}
}
void CVideo::update_cursor()
{
outport(0x03d4,0x0f);
outport(0x03d5,m_nCursor & 0xff);
outport(0x03d4,0x0e);
outport(0x03d5,m_nCursor >> 8);
}
void CVideo::cls()
{
memsetw(m_pVideoMem,0,COLS*ROWS);
outport(0x03d4,0x0f);
outport(0x03d5,0x00);
outport(0x03d4,0x0e);
outport(0x03d5,0x00);
}
void CVideo::setColour(unsigned char colour)
{
m_nColour = colour;
}
CVideo &CVideo::operator <<(const char c)
{
putc(c);
return *this;
}
CVideo &CVideo::operator <<(const char *str)
{
while(*str != '\0') putc(*str++);
return *this;
}
CVideo &CVideo::operator <<(const int num)
{
putnum(num);
return *this;
}
Dazu noch der Assemblerteil für die Konstruktoren:
extern __ctors_start__, __ctors_end__, __dtors_start__, __dtors_end__
; call the constructors
static_ctors_loop:
mov ebx, __ctors_start__
jmp .test
.body:
call [ebx]
add ebx,4
.test:
cmp ebx, __ctors_end__
jb .body
sti
; call kernel proper
mov eax, [multiboot]
push eax
call main
add esp, 4
; call the destructors
static_dtors_loop:
mov ebx, __dtors_start__
jmp .test
.body:
call [ebx]
add ebx,4
.test:
cmp ebx, __dtors_end__
jb .body
cli
hlt
Das war's so weit...
-
Ich hab jetzt mal ganz am anfang, noch vor dem mappen und alles sonst, etwas code zum nullen des Cursors hinzugefügt:
mov dx, 0x03d4
mov al, 0x0e
out dx, al
mov dx, 0x03d5
mov al, 0x00
out dx, al
mov dx, 0x03d4
mov al, 0x0f
out dx, al
mov dx, 0x03d5
mov al, 0x00
out dx, al
Und siehe da... es geht. Dann noch weiter an verschiedenen Stellen des Assemblerstarts. Der Punkt, ab dem es nicht mehr geht, ist gleich nach dem die Konstruktoren aufgerufen wurden. Der einzige Konstruktor ist der vom Singleton.
Ich vermute daher sehr sehr stark dass das auslesen des Cursors im Konstruktor einen Schreibzugriff irgendwie nicht mehr zulässt. Daher muss jetzt also entweder wissen warum nicht mehr, oder herausfinden wie ich ein immer wiederholendes Initialisieren des Singleton verhindern kann.
3. Möglichkeit: Ich schreib alles wieder in C.
-
Ich kenn mich nicht besonders mit C++ aus, aber
CVideo CVideo::m_Instance = CVideo();Kann imho nicht richtig sein. Du deklarierst das Feld m_Instance der Klasse CViedeo als CVideo und setzt es auf CVideo() ? Schwachsinn imho. Sollte es nicht CVideo::m_Instance = CVideo() sein? (Lässt sich der Konstruktor nicht auch ohne Zuweisungsoperator aufrufen?)
-
@Korona: Das ist schon richtig so
@FalShen: deine getInstance Methode sollte entweder eine Referenz oder einen Zeiger auf das statische Objekt zurückgeben und nicht eine Kopie. Das macht doch das Singleton Pattern aus: Nur (maximal) eine Instanz zu jeder Zeit.
edit: Bevor ichs vergesse: Der copy-constructor und der destructor sollten ebenfalls private oder protected sein. Es ist in dem Fall wichtig zumindest alle zu deklarieren, dann kann man von außen schon nicht zugreifen und alles andere gibt dann ein nicht aufgelöstes Symbol beim Linken.
edit2: :-D Fast hätte ich den operator = vergessen denn du auch nur deklarieren solltest.
-
Ja... das & hab ich vergessen, mann war ich blöde... Dank an bluecode :roll:
Den copy-constructor hab ich auch überschrieben, für den fall der Fälle... nur wenn ich einen destruktor deklariere, will der eine __cxa_atexit und den ganzen rest haben... obwohl ich eine dtors section haben will...
Der Cursor wird immer noch nicht richtig gesetzt... aber wenigstens kann ich erstmal weiterarbeiten, da er ja nicht mehr alles in eine Zeile schreiben will
Add: Tja... ich dachte an den inport liegt es dass der das Schreiben in die VGA-Ports nicht mehr zulässt, aber offenbar nicht... hab das gelöscht, der cursor wird immer nocht nicht gesetzt. Der Code ist aber zu 100% korrekt und wird auch aufgerufen, da bin ich mir sicher.
-
Den copy-constructor hab ich auch überschrieben, für den fall der Fälle... nur wenn ich einen destruktor deklariere, will der eine __cxa_atexit und den ganzen rest haben... obwohl ich eine dtors section haben will...
Du musst die richten configure-flags bzw. commandline flags angeben um das zu so hinzukriegen. Ich hoffe, dass da das was ich ins wiki eingetragen hab stimmt, aber ich bin zuversichtlich :)
-
Nee stimmt irgendwie nicht...
Egal, hab mich jetzt einfach kurzerhand vom OO-Design verabschiedet und in C gewechselt, wobei der Cursor immer noch nicht richtig gesetzt wird, ist es nicht lustig?
-
Also ich hab jetzt keine Ahnung von C-Aufrufen usw...
Aber bist du sicher, dass du nicht irgendwie ein IOPL-Flag ausversehen gesetzt hast? Ich würds mal mit dem Debugger überprüfen...
Gruss
Nooooooooooos
-
Auch auf die Gefahr hin, jetzt doof darzustehen... was'n ein IOFL flag?
-
I/O Privilege Level Field (IOPL) Field. Bits 1312. The IOPL field specifies the privilege level required to execute I/O address-space instructions (i.e., instructions that address the I/O space rather than memory-mapped I/O, such as IN, OUT, INS, OUTS, etc.). For software to execute these instructions, the current privilege-level (CPL) must be equal to or higher than (lower numerical value than) the privilege specified by IOPL (CPL <= IOPL). If the CPL is lower than (higher numerical value than) that specified by the IOPL (CPL > IOPL), the processor causes a general-protection exception (#GP) when software attempts to execute an I/O instruction. See Protected-Mode I/O in Volume 1 for information on how IOPL controls access to address-space I/O. Virtual-8086 mode uses IOPL to control virtual interrupts and the IF bit when virtual-8086 mode extensions are enabled (CR4.VME=1). The Protected-mode virtual-interrupt mechanism (PVI) also uses IOPL to control Virtual interrupts and the IF bit when PVI is enabled (CR4.PVI=1). See Virtual Interrupts on page 241 for information on how IOPL is used by the virtual interrupt mechanism.
-
Bochs sagt, das IOPL ist dann am Ende gleich 0. Soll das so sein?
Kann das auch was mit dem VME-Flag zu tun haben, in cr4? Die Infos die ich zu den Pentium-Registern finde sind eher dürftig.
Ich weiß auch immer nicht ob das OS nun CPL = 0 oder CPL = 3 ist... Mann bin ich blöd ^^
-
Dann solltest du dir erstmal die Grundlagen der x86 CPU vertraut machen sowie die Grundlagen oder am besten erweiterte Kentnisse von C/C++ anschaffen. Denn ich sehe das Problem weder an der Cursor-Funktion, noch im IOPL-Flag sondern eher an mangelnde Kentnisse. Wenn du nicht weißt ob dein OS in CPL0 oder CPL3 läuft ist das mehr als schlecht.
bitmaster
-
Ja da hast du vollkommen recht.