Can anyone see any problems with this C++ code?

[BMW]

For my kernel I made a print string function:

Code: Select all

#define VIDMEM 0x000B8000
#define SCREEN_COLS 80
#define SCREEN_ROWS 25

unsigned int _CurX = 0, _CurY = 0;
unsigned char colour = 0x07;

void PrintChar32(char* c)
{
	unsigned char* p = (unsigned char*)VIDMEM;
	p += _CurY * SCREEN_COLS * 2;
	p += _CurX * 2;
	p[0] = *c;
	p[1] = colour;
	if(++_CurX == SCREEN_COLS)
	{
		_CurX = 0;
		if(++_CurY == SCREEN_ROWS)
		{
			//TODO: Make it scroll instead of overwriting
			_CurY = 0;
		}
	}
}

void PrintString32(char* s)
{
	unsigned int c = 0;
	while(s[c] != 0)
	{
		PrintChar32(s+c);
		c++;
	}
}

However, when i do this PrintString32("Test"); it prints a whole load of 0x00s...

[iansjack]

I'm not quite sure why you use a pointer with PrintChar rather than just having a char parameter. It's an extra complication which makes it difficult for my poor brain to follow at this time of the morning.

But this has got to be a trivial bug to trap with a debugger. Just single-step through the code in a debugger - either at source-code level or assembler level if necessary - and the answer will surely be obvious. You are going to face far more difficult bugs than this when programming an OS so you might as well practise your debugging skills on this simple problem.

[BMW]

How do I step through the code when its running in an emulator???? (QEMU)

[Combuster]

RTFM, perhaps?

Also, please fix your signature, it breaks forum rules.

[iansjack]

Well, for starters you read the qemu documentation: http://qemu.weilnetz.de/qemu-doc.html#gdb_005fusage

Alternatively you can use an emulator with debugging built in (SimNow from AMD is my favourite - http://developer.amd.com/tools/cpu-deve ... simulator/ ). Whatever you decide on, I would advise you take a little time off from coding and learn how to use a debugging environment. You are going to need it.

[BMW]

RTFM, perhaps?

lol

[BMW]

WTF.

This is what I do:

Code: Select all

void __stdcall kernel_main()
{
	
	_asm
	{
		mov ax, 0x10
		mov ds, ax
		mov es, ax
		mov fs, ax
		mov gs, ax
		mov ss, ax
		mov esp, 0x90000
	}
	
	PrintChar32('d');
	
	return;
}

That should print a "d" in the top left of the screen. Instead, it fills the screen with "d"s.


EDIT:
LMFAO I am thick.

I changed ESP at the start of my kernel.... resulting in the kernel returning to the wrong location and repeating my code.

[BMW]

WTFWTFWTFWTFWTF.

Code: Select all

void PrintString32(char* s)
{
	unsigned int count = 0;
	while(s[count] != '\0')
	{
		PrintChar32(s[count]);
		count++;
	}
	
	return;
}

When I do this: PrintString32("Test");
it prints one 0x00 in the top left.
C++ has gone mental

[iansjack]

so what does the debugging tell you?

[BMW]

so what does the debugging tell you?

Haven't done it yet... I will do it soon

[iansjack]

It might be best to do so before posting further iterations of your problem just in case people start to get irritated.

[BMW]

Is it possible to use GDB to debug a kernel made in VC++? Or do I have to compile it with gcc?

[iansjack]

Not as far as I know. One of the many reasons why I don't use Visual C++ as my development environment for OS programming. It's a brilliant tool, but I don't find it suitable for OS work. Same goes (IMO) for XCode on OS X. I use a Linux development environment as I find it far more suited to this sort of work. (I know some people use the native tools of Windows or OS X, but it just seems like too much hard work to me when so much documentation is built around the GNU toolset.)

If Visual C++ is your choice then I'm afraid that you're going to have to find your own way of debugging with qemu. But if you want to get serious about OS development then you're going to need debugging at some stage (and you seem to have reached that stage). You could always debug at an assembler level using SimNow. Alternatively, just look at the code generated by your functions, work through it manually and you should be able to spot the error. The problem with that approach is that you have to be intimately familiar with what each instruction does and what effect it has on registers and flags. It's very easy to make false assumptions and miss simple errors.

Basically what I'm getting at here is that you have a very simple problem. (I'm not saying I know what the error is because I don't have the time or the inclination to debug other people's code.) It's up to you to learn how to track down the bug. If you can't do that then reconsider whether OS development is your thing. You are going to run in to lots of little problems like this and people will very quickly lose patience with you if you post each and every one on this forum. I don't mean to sound harsh, though I realize it may come across that way, but that's just the way it is. These forums aren't really set up to act as tutorials or to provide hand-holding tuition.

[BMW]

Not as far as I know. One of the many reasons why I don't use Visual C++ as my development environment for OS programming. It's a brilliant tool, but I don't find it suitable for OS work. Same goes (IMO) for XCode on OS X. I use a Linux development environment as I find it far more suited to this sort of work. (I know some people use the native tools of Windows or OS X, but it just seems like too much hard work to me when so much documentation is built around the GNU toolset.)

If Visual C++ is your choice then I'm afraid that you're going to have to find your own way of debugging with qemu. But if you want to get serious about OS development then you're going to need debugging at some stage (and you seem to have reached that stage). You could always debug at an assembler level using SimNow. Alternatively, just look at the code generated by your functions, work through it manually and you should be able to spot the error. The problem with that approach is that you have to be intimately familiar with what each instruction does and what effect it has on registers and flags. It's very easy to make false assumptions and miss simple errors.

Basically what I'm getting at here is that you have a very simple problem. (I'm not saying I know what the error is because I don't have the time or the inclination to debug other people's code.) It's up to you to learn how to track down the bug. If you can't do that then reconsider whether OS development is your thing. You are going to run in to lots of little problems like this and people will very quickly lose patience with you if you post each and every one on this forum. I don't mean to sound harsh, though I realize it may come across that way, but that's just the way it is. These forums aren't really set up to act as tutorials or to provide hand-holding tuition.

Thank you so much for your time, brilliant answer thanks!

Ok, I will probably switch to the GNU compilers.

I couldn't seem to find a download link for SimNow for Windows????????

[Nessphoro]

That code works for me.
The problem is in your makefile/linker script/boot loader/format.