idt migration

ninjarider · August 02, 2007, 02:20:47 AM

tried yesturday moving the idt from base address of 0 to 400h the limit of the idt is 400h. cx is 100h and looped. im starting at 0 and using lodsd and stosd. i end up getting wierd result. if i change in to were im moving it from base 0 to base 500h it functions normally.

what wrong. also all entries in the idt start at offset f000h

Tedd · August 02, 2007, 11:55:05 AM

Segment 0040h (linear: 0400h) is used by bios for storing its data - stay out of it until you switch to pmode :wink
0500h seems to be free..

ninjarider · August 02, 2007, 01:52:51 PM

well i ran the int 15h to get the smap and it sad everything under the a block was available. but it makes since that they would make the data segment right above the idt. all i really wanted was to be able to put my page table at offset 0 seg 0. which for some reason i cant get to work. not to worried about it. i got alot coming up this week signed up for an 80 work week. that'll be a nice check.

Tedd · August 03, 2007, 12:10:23 PM

smap doesn't detail every single area of memory and what is using it, it's just a list of areas that 'can' be used; they could already be used by something else - mostly bios, but once in pmode this is no problem (the memory 'can' be free and usable if nothing else is using it.)

It may be a better a idea to switch to pmode first (with interrupts and NMIs disabled - as you should anyway) and then set up your new idt at 0000h (or wherever you want it), then you can re-enable interrupts when it's ready.

Mark Jones · August 03, 2007, 08:28:31 PM

Hey Ninjarider, just curious if you were rebooting a PC every time to try these tests, or using a simulator like http://www.emu8086.com/

:-)

ninjarider · August 05, 2007, 12:17:22 PM

i dont believe in using a simulator. sometimes simulators dont have the same results as rebooting into the system.

Tedd · August 06, 2007, 12:13:59 PM

True, but they do have some value in helping to test your code. They're not prefect, and not a substitute for testing on real hardware, but they can save you a lot of time in rebooting. Also, if they have a debugger (like http://bochs.sourceforge.net) it can help so very much in finding what went wrong and why it crashed once again.

ninjarider · August 06, 2007, 05:38:13 PM

well as far as the time that it takes to reboot. i just mind. and yes it is frustrating wondering about the constant reboot or the lock ups. i know that having the tools will make it easier. but i also want to be able to do it in my head. might not be as efficient but oh well.

MichaelW · August 06, 2007, 05:59:10 PM

Having to reboot a zillion times is frustrating. What I used to do was include code that would allow me to display things on the screen, even from PM. Just having the ability to display short strings was useful, because it allowed me to determine by trial and error where the code was failing.

ninjarider · August 06, 2007, 07:44:00 PM

micheal thats pretty much what i do. theres also a lot of the code that i test from within debug. yeah for right now i havn't been able to dl that 32-bit debuger. (well not able to get it to my house/no internet at the house). when i reboot i usually have my debug.asm included in it. i take and print text at various milestones leting me know were the issue is.

and i really have to find something to make a backup of my code at each compile. i was thinking about using pkzip so i could do it from the command line and archive 30+ zips in a directory for it. i accidently added some bad code. well not bad code but put it in the wrong place and started triple faulting going into pm again. god that was a pain in the ass to fix.

News:

idt migration