OSDev.org

ATXcs1372 wrote:How did you come across this? I'm writing a VBE driver and it seems I'm fighting Bochs more than my own code with a very similar issue to your screenshot.

I've had the same issue,

What I found is that this behavior would come up if I used the wrong Resolution:Color Depth.

Just make sure that if your code expects, say 1024x768:32, you are not initializing VBE to 1024:768:24.

Nessphoro wrote:

ATXcs1372 wrote:How did you come across this? I'm writing a VBE driver and it seems I'm fighting Bochs more than my own code with a very similar issue to your screenshot.

I've had the same issue,

What I found is that this behavior would come up if I used the wrong Resolution:Color Depth.

Just make sure that if your code expects, say 1024x768:32, you are not initializing VBE to 1024:768:24.

I'll look into it when I get home, but hopefully that isn't part of the issue.
Part of my boot code is to actually poll the available modes (ax=0x4F00, int 0x10) and check if it's available to the current hardware.
Once that's done it uses the get info (ax=0x4F01) and I just look for the closest mode available and my kernel adapts by reading the VBEModeInfoBlock variables...
As long as Bochs is reporting things correctly it should work.
Are you using any BGA (Bochs Graphics Adapter) specific code or just VBE?

Just VBE.

My mouse coordinates are messed up... They just travel sideways in a sort of half-random waveish pattern... still to be fixed.



You reckon I could sell this as an art-piece?

Now it has been fixed =)

Good news, my crash handler works.
Bad news, woot! Look in the second to last line of text, I have NO idea where that came form.

Griwes wrote:I think I will laugh off of myself after fixing this, but this is result of first attempt to VBE mode string printing:

http://i.imgur.com/NdB9G.png (1600x1200, not going to embed it here...)

Not sure where I did something wrong, though.

Edit: my code was lacking one "return;" in function handling single characters, but rest was because of bug (I guess, I don't think that bug could hide somewhere in my code, checked it several times) in bochs' VBE code... it was giving me pitch for 1280x1024 in 1600x1200 mode.

I was completely wrong in my last sentence. The issue was just plainly stupid; after checking every possible mode, I wasn't filling VBE structure with chosen mode's information, so I was basically using last mode's details instead of chosen mode's ones. :facepalm:

This is the "blue screen of death" of RDOS (image taken with a camera, as it was run on real hardware):



So, here something bad happened on core 5 of the processor, and the dump shows core's control-registers, GDT/IDT, pending interrupts, general registers, segment registers (including base, limits and descriptor types). In the lower part is an area where any address can be inspected, by typing a selector & offset in the "US" field. It is also possible to switch processor core to display another core's crash-state. The interactive function is only available with a PS/2 keyboard.

This is a real crash in that core 5 attempt to reference the thread control block when it doesn't have an active thread. The whole scenario actually looks power-manangement related as the core also have no TR or LDT loaded, and thus seems to have just rebooted.

LOL when testing out my single ISR on my 16bit operating system this happend. I have no idea how it just repeats forever

Funny, I figured out what I did wrong. This operating system code is quickly turning to spaghetti.

By the way you can turn on file compression on c.img, it'll make it like 1mb compared to 200.

I see a screen full of bad omens. You'd probably call them "warnings"

Yeah I might just do that for c.img. All that is on that drive is DOS used for debug to write the boot loader to the floppy, something that I hope I am done with and can just work on the kernel now. Ohh the warnings over there that you see are just warnings about sti and cli and cld and some of the labels that I have setup. I am not using the nasm option to suppress them.

when doing osdev, I recommend -Werror, turn on all possible warnings, fix all warning, and do not suppress anything.
warnings are there for some reasons.

bluemoon wrote:when doing osdev, I recommend -Werror, turn on all possible warnings, fix all warning, and do not suppress anything.
warnings are there for some reasons.

I disagree on using -Werror. I started off using it, but during tests I would regularly comment some lines out or somehow test a not fully written function. It would quite often give me warning such as "Unused variable xxx", which I completely didn't care about during testing. However, I didn't want to turn off those warnings because they are useful from time to time - just not during testing.
But -Werror doesn't really help that much anyway imho. Just keep an eye on all warnings and ALWAYS fix them (unless you are aware of one, know why it is, and you're certain you'll fix it later). Why would you need to be *forced* to do so anyway?

Though in general I agree: fix ALL warnings, even if they are purely legal code. It'll save you @$$ more than once.