BASE address changing on jmp

[Thunder]

Hello
When I plot pixel (with VESA LFB) in asm and when I do jmp $, everything is ok, but when I'm trying to jmp "label" screen just clears.

Maybe it is something with GDT selector, maybe on jmp or call segments change?

I plotted a pixel and made jmp codese:0x10000
there I loaded new gdt values and plotted pixel, then it was ok, but another jmp every destoys. :-\

Thanks for help

[Pype.Clicker]

err ... the only thing is that jmp <segment>:<offset> reloads the CS content (selector and shadow registers for base & limit) with the GDT content. It should in no way affect other segments registers, and even if it did, this should not affect your VRAM content unless you write something else at the given pixel.

my opinion is that either you jumped to some code that cleared the previous pixel or you're doing some kind of nasty ASM bug :-@

[Thunder]

Maybe, I will try to load my kernel at 1MB, and then watch.

Thanks Pype

[Pype.Clicker]

btw, are you sure the CPU isn't simply resetting because of a Triple Fault ? when CPU reboots, the graphic card usually clears the screen...

thus if your new GDT is not correct, trying to plot a second pixel could lead you to break a segment limit and raise a (maybe unhandled) exception ... If you could provide an OSID page (where you are, what is done and tested) and a code extract of the faulty function i could give more precise advices ...

[Thunder]

No, just how you said, that kernel overwrites screen LFB, I loaded kernel at 0x10000, but when I loaded kernel at 0x100000 (1MB), now everything is working ;D.

Thanks

[Pype.Clicker]

i'm just curious ... how large is your kernel and where is your linear framebuffer located ?

[Thunder]

Whole image is 17.2 KB, kernel is at 0x100000 and LFB depends on resolution and video card.

[Pype.Clicker]

woow. pretty weird ... a 17.2Kb overwriting LFB (probably located at 0xA0000 for your current mode ... or am i wrong?) If it's not during your kernel loading, i would suggest you to keep the kernel under 1Mb and continue until you find how and why it goes into the LFB ... because it's likely to occur again with something else...

Well, it's your bug, so it's you to chose, but 'til now, i found that when one resolves a bug without understanding why, the bug isn't really resolved - just postponed.