Page 1 of 1
Screen problem
Posted: Thu Oct 17, 2002 6:57 am
by CyberMan
Hello
i have a problem with my screen driver, my printk() fonction work fine but after 3/4 lines she don't print message.
Now, the code:
typedef struct
{
int type;
int attr;
int tattr;
int x;
int y;
int caps_lock;
int num_lock;
int scroll_lock;
int ram;
} screen_struct;
void write_screen(char buff)
{
char *video;
video=(char *)(sc_struct.ram+2*sc_struct.x+160*sc_struct.y);
switch(buff)
{
case ESC:
reset_screen();
break;
case TAB:
print_tab();
break;
case RET:
sc_struct.x=0;
sc_struct.y++;
if(sc_struct.y>24)
{
sc_struct.y=0;
sc_struct.x=0;
}
break;
default:
*video = buff;
video++;
*video = sc_struct.attr;
video++;
sc_struct.x++;
if(sc_struct.x>79)
{
sc_struct.x=0,
sc_struct.y++;
if
{
sc_struct.y>24)
{
sc_struct.x=0;
sc_struct.y=0;
}
}
break;
}
}
void printk(const char *str)
{
const char *string = str;
while(*string!='\0')
{
write_screen(*string);
string++;
}
}
Re:Screen problem
Posted: Thu Oct 17, 2002 8:18 am
by Pype.Clicker
the only thing that seems wweird to me in your code is the const char *string = str ... what's the meaning of this ?? if one can't modify a const argument, why do you copy it in another const pointer ???
btw, where does your string come from ? isn't there any buffer overflow before you call kprint ?
Re:Screen problem
Posted: Thu Oct 17, 2002 8:49 am
by CyberMan
I don't think, i call my printk() fonction:
printk("test\n"); for example.
And if I do:
printk("test\n");
printk("test\n");
printk("test\n");
printk("test\n");
printk("test\n");
My computer reboot....
Please, help me....
CyberMan
Re:Screen problem
Posted: Fri Oct 18, 2002 5:32 am
by Pype.Clicker
very very weird ... any interrupts that could occur during this code ? what do happen if you insert a "waitkey" loop (i.e. while (inp(0x60)>128); ) between each print command and disable interrupts, for instance ?
Re:Screen problem
Posted: Fri Oct 18, 2002 7:26 am
by CyberMan
I have writing my printk() fonction again and now she work fine, i don't now why. But now i write the floppy driver, and when i add a function my computer reboot. If I delete this function my kernel work fine. The interrupt is disabled.
Re:Screen problem
Posted: Fri Oct 18, 2002 7:57 am
by Pype.Clicker
sounds like you should check your compiled kernel looks like what you think it does with some binutility like objdump or maybe just an HEX editor ... i've seen plenty of beginners that just put an
Code: Select all
void starter() {
asm("jmp _start");
}
and pray for the linker to put this as the very first instruction ... this sounds risky to me: changing the link order or adding a small inline function could move your starter somewhere else ...
If you use such a trick and that it sounds too complicated to do some binary files manipulation to ensure the starter function is the first bytes of your code, just use
Code: Select all
void starter() {
asm("jmp _start; string 'Magic'");
}
and have your bootsector check your "magic" sequence is present at the right file offset (should be 5 or 2 according to the kind of jmp (long or short)

Re:Screen problem
Posted: Fri Oct 18, 2002 9:16 am
by CyberMan
My code
asm("jmp start");
void start(void)
{
init_screen();
init_floppy();
...
while(1);
}
I use gcc, objcopy and dd (I am under Linux) :
gcc -c main.c -o main.o
ld -Ttext=0x1000 -o nos main.o -e 0x0
objcopy -R .note -R .comment -S -o binary nos nos.bin
dd if=boot.bin seek=0 of=/dev/fd0
dd if=nos.bin seek=1 of=/dev/fd0
Re:Screen problem
Posted: Fri Oct 18, 2002 10:40 am
by Tom
try my printf function & putch funtion...at my website
Re:Screen problem
Posted: Mon Oct 21, 2002 12:23 am
by Pype.Clicker
CyberMan wrote:
I use gcc, objcopy and dd (I am under Linux) :
gcc -c main.c -o main.o
ld -Ttext=0x1000 -o nos main.o -e 0x0
objcopy -R .note -R .comment -S -o binary nos nos.bin
The problem of the asm("jmp start"); command is that it works only if it is output as the very first bytes of the .text section and that the .text section is the very first of your binary file. This can usually be assumed true when you have a simple building environment, but it is harder to enforce when the time pass ...
At least, you should add "-M kernel.map" to the ld command (so that you can check the object order is the one you expect

) and try a small objdump -d main.o, so that you can see if the first bytes are the one you expect ...