Screen problem

[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++;
   }
}

[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 ?

[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

[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 ?

[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.

[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)

[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

[Tom]

try my printf function & putch funtion...at my website

[Pype.Clicker]

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 ...