VESA

[ASHLEY4]

If my code works in a pc emulator, then i have done some thing wrong.
I never use them, do not get me wrong, i am not calling the maker's of pc emulators they do a very good job.
It's just harder then most people think to make one 1/2 right
and 1/2 right is not good enough.
Buy some cheap old pc as test pc, you only need the Base's.

\\\\||////
(@@)
ASHLEY4.

[crc]

If my code works in a pc emulator, then i have done some thing wrong.

That's an interesting way to view things... I agree that it's difficult to write a 100% accurate emulator, but they are helpful.

Buy some cheap old pc as test pc, you only need the Base's.

A real PC can't keep detailed logs of everything done like an emulator can. Many times I've used the detailed Bochs logs to help find tricky bugs. Not only that, but the development cycle is much faster with an emulator

I still encourage testing on real hardware, but for many people that's not an option (not everyone has multiple PC's, and not everyone can afford the cost and/or space needed to purchase a second one)

[ASHLEY4]

Yes your right crc, they are helpful as a guide, but most people think that it must be there code that wrong, maybe the best thing would to have test pc's and emulators ?.

I think that a bootable emulator would be much better, then a emulator siting on top of windows or linux.

PS: in the the UK people dump any think lower that a P100 in the tip.

\\\\||////
(@@)
ASHLEY4.

[Vladaz]

I found the bug and now it works on my Real PC and on Virtual PC.
But now I can put pixel and do everything that i want just in boot.asm, boot2.asm, kernel.asm, that means i can put pixel in asm code. But in C code there is some problem.
There is my code how I get VESA LFB and video address and how I put pixel in C:

Code: Select all

unsigned long *video;
unsigned long *LFBAddr = (unsigned long *) (0x111FF+0x28);

video = (unsigned long *)(LFBAddr[0]);

video[0] = 0xFF;
video[1] = 0xFF;
video[2] = 0xFF;
video[3] = 0xFF;

It puts pixel, but that pixel is blue colour and it's width is about 2 or 3 pixel and i don't understand what is wrong :/

[ASHLEY4]

First thing you need to do is test for bits per pixel, some vendors uses 24bit and some uses 32bit, so it could be layed out as
RGB , this is for 24bit or,
XRGB, this is for 32bit ( it may be RGBX).
The X = 0x00 and is just a packer byte.
To test for bits per pixel look in the mode_info for
"ModeInfo_BitsPerPixel" here is stored the bit per pixel number, use code like this:

Code: Select all

cmp   [ModeInfo_BitsPerPixel],24
 jne   Try32bits

As you are not using my list, you will have to work out the the address( and put in the [ ] ), once found you should set a ver up.
Once you know the bits per pixel you can jump to the right routine, so have to write two routines 1 for 24bit and 1 for 32bits.
As for writing it in C ,i am not the person to answer that one.

ps: remember that filling the screen with color, is no indecion of bits per pixel, as it will just over flow, but still work.

\\\\||////
(@@)
ASHLEY4.

[Candy]

Code: Select all

unsigned long *video;
unsigned long *LFBAddr = (unsigned long *) (0x111FF+0x28);

video = (unsigned long *)(LFBAddr[0]);

video[0] = 0xFF;
video[1] = 0xFF;
video[2] = 0xFF;
video[3] = 0xFF;

It puts pixel, but that pixel is blue colour and it's width is about 2 or 3 pixel and i don't understand what is wrong :/

Try

Code: Select all

video[0] = 0xFF0000;
video[1] = 0xFF00;
video[2] = 0xFF;
video[3] = 0xFFFFFF;

Would print a red, green, blue and white pixel next to each other. Each pixel is a single long.

If you want to byte-address them, try making it a char * (or at least something byte-wide ).