Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I have a clear screen function that used to work fine. I then changed my code to be linked at 3GB and load at 1Mb using the GDT trick. Now my clear screen function won't work and just sits there clearing the first character on the screen Any Ideas? Here is the code im using
Have you changed the base address on the selector? If so your pointer to video memory will be translated from logical->physical by adding that base address to the pointer, and end up pointing to the wrong place.
Just something I thought of when I read the message, could be completely wrong of course ;D.
Sorry, I ment to post that completly slipped my mind.
I have a base of 0x40000000 and a limit of 0xFFFF (4Gb as granuality bit is high) for my code and data segment. Then i have a selector of 0x0 and a limit of 0xFF for my Stack.
The C00 is to make it so that it translates to 0xB8000 when added to teh selector. This seems to work as i can write to the screen but i can't get a loop to go through and access each byte one after the other. I am wondering if this is a problem between with the way an index for an array is added to the base to calculae the address and the GDT?
the GDT content is only used when the segment is loaded. The translation is applied only once the effective address has been computed (so it's independent from the actual addressing mode: based, indexed, indirect, direct, whatever ...)
Is there anyway to get ndisasmw.exe to output to a file. I don't really fancy typing it out. Also how do you know how much is data of the COFF files that are output and how much is code?
You should definitely get a disassembly, and a register dump from Bochs -- it would be useful to find the value of ESP, and all the segment base addresses, limits and flags.
If you're disassembling COFF or other files, objdump is better, as long as you don't mind reading AT&T syntax. ndisasm gets confused by the file headers.
You - now that you put it that way, I had the same problem when I did array indexing for the video memory. As in your case, this also worked fine:
char *vidmem = (char *)0XB8000;
for ( i=0; i <= 25*80*2; i++ )
{
*vidmem++= somechar;
*vidmem++= someattr;
}
Just like you, when indexing by array vidmem, yeilded unpredictable results. But just incrementing the pointer worked fine. Until now, I never gave a second thought about it. This was quite awhile ago when I was still getting used to realmode addressing, and I chalked my error up as a "realmode addressing quirk" I did not understand. Now looking back, I guess I understand realmode addressing pretty well, but I still do not understand why the array indexing did not work.
Tim is right, the asm results should yield some answers, but I do not have time to look right now. If noone else comes up with the answer I'll try and look this weekend.
short vs. char does not explain the issue here. A short would just index you through the array in character+attribute pairs instead of indexing each one indavidually (char, attr, char, attr...etc.). They are each 8 bit values.
Now that I re-read the post, I think my problem was different. My problem had to be real-mode addressing related. That does not explain anything about the problem this post is about. Sorry for screwing up the conversation flow there.
I finally figured out how to get it to output to a file. I knew there was a way to redirect output i just couldn't remeber how to do it but sorted that now.