Video memory - 0xA0000 or 0xB8000?

[Fergo]

Hello every one, how are you?

I've saw a lot of codes that uses "conventional" video memory, but some codes point to 0xA0000 as the starting address and other codes point to 0xB8000. Until now I only used interruptions to print chars and symbols to the screen, so I actually didn't had to care about the memory address. But now, looking at C and C++ code which directly writes to video memory, I've seen pointers to 0xA0000 and 0xB8000. What is the difference between each block?

Sorry if it's a dumb question, but I tried looking for some definitions and I only got more confused. Sorry for my english too. Thanks in advance!

Regards,
Fergi

[t0xic]

0xB8000 is for text mode
0xA0000 is for mode 13h (and other VGA modes?)

[codemastersnake]

0xA0000 is the pointer address to the Graphical Mode and 0xB8000 is the pointer address to the Color Text Mode and 0xB0000 is the pointer to the Monochrome text Mode.

Therefor those OSDEVERs who are using GUI writes to 0xA0000 and those who are still stuck in the text mode write to 0xB80000.

Now YOu have said that they use C/C++ and write directly to the address. This is because these are Memory Mapped I/O. If you can write directly to them you save a lot of CPU cycles that fasten up your OS.

Hope thats helpful.

[Fergo]

Thanks a lot t0xic and Snake! Everything is clear now
Have a nice day!

Regards,
Fergo

[codemastersnake]

any time dude!

Happy OS Development!

[Fergo]

Sorry to bump this thready, but I entered in vacation now and I start messing with osdev again. Is it possible to write directly to 0xB8000 in real mode using C?
I'm doing just like a tutorial in OsDever, but it's definately not working. Here is the code I found:

Code: Select all

void k_clear_screen() // clear the entire text screen
{
	char *vidmem = (char *) 0xb8000;
	unsigned int i=0;
	while(i < (80*25*2))
	{
		vidmem[i]=' ';
		i++;
		vidmem[i]=WHITE_TXT;
		i++;
	};
};

Here is my code (I'm just trying to fill the screen with a brown G):

Code: Select all

void test() {
	char *vidmem = (char *) 0xB8000;
	unsigned int i=0;
	while(i < (80*25*2))
	{
		vidmem[i]='G';
		i++;
		vidmem[i]=0x06;
		i++;
	};
}

What is wrong with this code?

Have a nice weekend,
Fergo.

[Combuster]

In real mode, you normally need a far pointer. (ES=0xB800, mov [ES:offset], ... ) GCC has no far pointers
In unreal mode you can indeed use a linear address, but you'll have to deduce the segment base from it if it isn't 0 - so if your code is located at 0x1000:0000, then video memory will be at 0xb8000 - segment base = 0xb8000 - 0x1000 << 4 = 0xa8000.

Both under assumption that you can get the compiler to output 16 bit code.

[Owen]

Real mode pointers are 16-bits. If you want to write to video memory in real mode, you need a far pointer, which is 32-bits but only has 20-bits of addressing range.

What compiler are you using?

[Fergo]

I'm using TurboC++ 3 because it's easy to create plain binary files with it, use intel syntax with inline assembly and generate a good 16bit code.
I don't know if TC++3 has far pointers. I'm loading my kernel to 09C0:1000. So it´s not possible to write directly to video mem using real mode? Or I understood it wrong?

Thanks a lot for your replies and sorry for my english too.

Regards,
Fergo

[JamesM]

I'm using TurboC++ 3 because it's easy to create plain binary files with it, use intel syntax with inline assembly and generate a good 16bit code.
I don't know if TC++3 has far pointers. I'm loading my kernel to 09C0:1000. So it´s not possible to write directly to video mem using real mode? Or I understood it wrong?

Thanks a lot for your replies and sorry for my english too.

Regards,
Fergo

It is possible to write to video memory in real mode. However, you're using C, and C doesn't have in built support for far pointers or any of the real mode cruft you're likely to find.

If the code compiles, look at the generated assembly and see what it is doing.

[Fergo]

Hum, that make sense. I've disassembled the kernel in IDA and yeah, the value is truncated to 0x8000:

Code: Select all

mov     [bp+var_2], 8000

So I can't do this in C because the compiler use 16 bit addressing, not the 20 bit addressing that can be achieved with SEG:OFF in ASM (where I could write to B800:0000, which converts to 8B000), right ? Basically there is no way to do this kind of thing using 16bit C code?

I really appreciate your time, thanks a lot.
Fergo

[Combuster]

TC3 has far pointer support.

IIRC you should be able to pull off this (you need to find the MK_FP macro, its in some header)

Code: Select all

char far *vram = MK_FP(0xB800, 0);
vram[0] = '!';
vram[1] = 15;

[ChazZeromus]

I thought that 0xA0000 was an address in video memory that can only be used in real mode when a special procedure is perform changing the video mode. Is this true?
i never really looked into graphics yet in my OS, I'm handling memory and solid kernel stuff but does that mean that 0xA0000 is only useful in real mode?

[suthers]

0xA0000 is used as graphics memory in vga mode...
Though without drivers you can't access any form of graphics mode in protected mode, it is possible to set them in real, unreal or V86 mode using interrupts...
So it is in fact very useful in protected mode, because without, there wouldn't any possibility of a GUI without drivers...
Jules

[Fergo]

Until now I always used interruptions (teletype, in most cases) for printing text on screen, but I was missing some colors, so I decided to write directly into the VGA memory. Another good thing writing directly to the VGA is that it's a lot faster (not that I need speed now, but it's good to practice )

Combuster, I found the MK_FP in DOS.H:

Code: Select all

#define MK_FP( seg,ofs )( (void _seg * )( seg ) +( void near * )( ofs ))

As it's just a define, I just copied it to my kernel and worked like a charm! Thanks a lot man! Sorry for this dumb (I guess?) questions.

A nice weekend to everyone,
Fergo