bugg in printing message

[wilson]

hi guys! I'm a new beginner in OS dev. I wrote a little kernel (with a little boot loader which switch in protect mode and load a kernel written in C. the kernel when is loaded print a message. when I use the function print once everything is okay, but when i used 4 times, it doesn't print all the messages. I don't know where is the bugg in my function putcar or print.

this my function putcar

Code: Select all

void putcar(unsigned char c)
{
	unsigned char *vidmem = (unsigned char *) VIDEORAM;
	if (c == 10 )		/* Touche ENTREE */
	{
		X = 0;
		Y++;	
	}
	else if (c == 9)	/* Touche Tabulation */
	{
		X = X + 8 - (X % 8);
	}
	else if (c == 13)
		X = 0;
	else
	{
		vidmem = (unsigned char *) (VIDEORAM + 2 * X + 160 * Y);
		*vidmem = c;
		*(vidmem + 1) = 0x0F;
		X++;
		if (X > 79)
		{
			X = 0;
			Y ++;
		}
	}
	if (Y > 24)
		scroll(Y -24);
	move_cursor(X, Y); 
}

this my function print:

Code: Select all

void print(unsigned char *str)
{
	while (*str !=0)
	{
		putcar(*str);
		str++;
	}
}

and my main.c

Code: Select all

void main()
{		
	clrscr();
	print(" ***************   AFRIX 0.0001   ******************* \n\n\n");
	print("Bienvenue sur le noyau afrix\n");
	print("Ce noyau a ete ecrit par (nom de l'auteur *****) et il est a sa version 0.0001\n");
	print("test affichage\n");

	for (;;);
}

and the screenshot shows the bugg.

please help me !!

[wilson]

yeah in my previous screenshot I used 3 times my function print and it works, but the code still the same and when i wrote in my main.c my function print many times it doesn't work. i have been looking for the bugg, but i didn't find, i still looking for it

[os64dev]

From you post i can gather that you have written an own loader.

Does the loader read all the sections of the kernel?
if the loader reads a section short it might be the forth string.

os64dev

[wilson]

If you're talking about my bootloader, it reads only two sectors for loading my kernel, but like you say, i've modified and i put 10 sector and its works perfectly, my kernel print all the messages that i put in the main.c thanks for your help. but I have a question please, how a short reading of sectors can cause this problem?

[neon]

If the string is stored in a location not loaded in memory that should be clear on how that can cause the issue. Strings are typically stored in the data or rodata section of the binary file. The location of these sections depend on the file format and linker configuration.

I suspect you are using LD with sections aligned on a certain boundary which would result in extra padding between sections causing the issue. I am quite curious why you are hard coding the number of sectors to read however.

[Chandra]

I am quite curious why you are hard coding the number of sectors to read however.

I think that's because he doesn't have a filesystem initialized for the target disk(possibly floppy).This means that, there's not much you can do, other than hard code the number of sectors to read, along with the starting sector for kernel image on the disk.

[os64dev]

... but I have a question please, how a short reading of sectors can cause this problem?

If not all sectors of the kernel are read from the storage device you will not have all data to display.. in general the code compiles to CODE section appended with DATA section. So in your case all the CODE was loaded into memory and thus worked fine, The 3 correct display lines (DATA) were also loaded and thus also correctly displayed. The fourth string was in a DATA section that was not loaded and therefore does not exist in memory. If you are running an emulator to run your OS the memory is typically initialized with zero's and that would be string termination character. Thus the fourth string does not give an error but displays nothing..

Hope this helps in a way

[os64dev]

I think that's because he doesn't have a filesystem initialized for the target disk(possibly floppy).This means that, there's not much you can do, other than hard code the number of sectors to read, along with the starting sector for kernel image on the disk.

Well that is not true, after the kernel compilation is done you know the exact size in sectors and can patch the boatloader (if you have written your own) to read the correct amount of sectors
works for me

[Chandra]

I think that's because he doesn't have a filesystem initialized for the target disk(possibly floppy).This means that, there's not much you can do, other than hard code the number of sectors to read, along with the starting sector for kernel image on the disk.

Well that is not true, after the kernel compilation is done you know the exact size in sectors and can patch the boatloader (if you have written your own) to read the correct amount of sectors
works for me

Well, the kernel size increases as you go on adding stuffs to the kernel. I'm not sure how you can patch your bootloader to read the varying kernel since there's no hard and fast rule nor any kind of info you can dig from you booloader. To read from the unformatted disk, you need to know where you've placed the file and what size of file is there. I'm quite confused how can you automate this process without hard coding. The only way I can think of is, read maximum sectors and load them into memory so that even you kernel size increases, it wouldn't matter anyway. I am well aware that if there was a filesystem, the case would be different because then, all you need to do is parse the filesystem and rest follows. I too, would be interested to know how you applied the patch.
Thanks in advance.

[neon]

Hm, assuming the image is not a flat binary the size of the image can be obtained from the image itself which the bootloader can use to determine amount of sectors to read thus eliminating the need to hard code anything.

Any form of a standard between kernel and bootloader like this can be used to eliminate the need.

[Chandra]

Hm, assuming the image is not a flat binary the size of the image can be obtained from the image itself which the bootloader can use to determine amount of sectors to read thus eliminating the need to hard code anything.

That's it. Assuming not a flat binary..., which may not be the case with the OP. Nor we can make that assumption by just looking at the code provided. So, if you go straight back to my post, I wrote "I think...", which means that my logic may or may not apply to the third person. What I can't see is, what is not true in my logic.

At last, the argument is over.

[Chandra]

That code assumes the kenel being the only file on the disk (other than bootloader, of course). That code can break in lots of ways.
1. If any other file(drivers, image files etc.) resides after the kernel on the disk, the only way to load the other file is hard code the file location + file size. No options.
2. If the disk happen to contain any invalid/bad sector, whole process is ruined. You can never load the other file nor the kernel.