Posted: Fri Apr 18, 2008 8:23 am
Heisenberg?AJ wrote:Why stop there? What about encoding on quarks and leptons?
The Place to Start for Operating System Developers
http://f.osdev.org/
Heisenberg?AJ wrote:Why stop there? What about encoding on quarks and leptons?
Code: Select all
lidt [0x0000]
sti
Or maybe even on the quarks and leptons of super-cooled, ultra-dense, hydrogen atoms? Takes up less space than carbon and has more adjectives.AJ wrote: Why stop there? What about encoding on quarks and leptons?
Read again the intel manuals especially the part where it explains what isStevo14 wrote:Well, it works now, sort of... I followed everyones advice (including reading the relevant sections of the Intel manuals and setting up a stack) and I am proud to say that I can now successfully enter real mode (yay!). The problem now is that interrupts don't work, despite loading the real mode IVT using:Again, I'm probably missing something very fundamental.Code: Select all
lidt [0x0000] sti
Or maybe even on the quarks and leptons of super-cooled, ultra-dense, hydrogen atoms? Takes up less space than carbon and has more adjectives.AJ wrote: Why stop there? What about encoding on quarks and leptons?
Slightly off topic, but did Yahoo give you permission to hot link their emoticons? I believe they're copyrighted...zaleschiemilgabriel wrote:What do leptons and quarks have to do with switching to real mode?
A common misconception when it comes to "stuff that's on the internet".zaleschiemilgabriel wrote:And thirdly, I assume that if those emoticons are there for everyone to see, they are also there for everyone to use.
Ready4Dis wrote:Well, firstly, you need to make sure that the EIP you are at is a valid 16-bit EIP. You also must first drop down to 16-bit pmode before making the switch, then you also have to make sure you are at a legitemate physical address (paging not available in real-mode). So, to recap:
Must be <1mb (well, below 0x100FEFF), in 16-bit pmode, and at a valid physical page (not virtual). If all these are met, you now have to make sure the function knows where it's located, and it must support 16 and 32-bit relocations (well, unless you drop into 16-bit pmode on entry, then it must only support 16-bit relocations). The easiest method would be like this:
Memory map bottom 1mb (or however much you need, probably 4k is plenty), setup a 16-bit code and data segment, then reserve a block of memory below 1mb for your program (binary is nice, because elf, coff, etc don't support 16-bit relocations, and it'll have to be written in ASM). So, now we write the entry code similar to this:
This code was written in this window, I may have missed a step or so, but should get you pointed in the right direction. Be careful enabling ints, you probably want to disable your PIC or APIC before entering real-mode so you don't have unhandled interrupts firing. You can go back into p-mode after this, just remember to reset the IDT, re-enable everything (paging, pmode bit), do a retf (far return, so it pops the Code segment back off as well, and when you call this you need to do a far call (callf CODESEL16:0x1000) to the function. So, basically it's not difficult, just have to remember that real-mode and p-mode are very different (16-bit, no virtual memory, IVT instead of IDT, cannot access > 1mb, etc, etc). If you run into more problems, let us know, that should get you started pretty nicely though. The other option (not sure how APM works exactly, so this may or may not be viable) is v86 mode.Code: Select all
[bits 16] [org 0x1000] ;Whatever you want here, 16-bit reserved location Entry16: cli ;Disable interrupts mov eax, DATASEL16 ;16 bit data selector mov ds, eax mov es, eax mov fs, eax mov gs, eax ;Disable paging, works because it's a 1:1 mapping! mov eax, cr0 and eax, 0x7FFFFFFe ;Disable paging bit & enable 16-bit pmode mov cr0, eax jump 0x0000:GoRMode ;Perform Far jump to setup CS :) GoRMode: mov ax, 0x0000 ;Reset data selectors to 0x0000 mov ds, ax mov es, ax mov fs, ax mov gs, ax lidt 0x000 ;Real move IVT is @ 0x0000 sti ;Restore interrupts, be careful, unhandled int's will kill it ;And finally we are ready to play in real mode!
Multiple typosis?bobjohnson2121 wrote:does anyone know why Ready4Dis mentions 0x100FEFF in his post?
Yes. IDTR contains not IDT address, but special pointer structure. Use Ready4Dis's code.Stevo14 wrote: Again, I'm probably missing something very fundamental.
Then this is completely unrelated.bobjohnson2121 wrote:Ooooh man I hope not typos!
Here is why I am asking: I have an ambient pressure (altitude) sensor that is malfunctioning from time to time. I communicate with the sensor from a Freescale Microcontroller (MCF52223) using SPI, well Motorolla/Freescale/Google's version of SPI - QSPI. There are two 16 bit integers I read to create a 32 bit integer which I then run through an equation to calculate ambient pressure. Generally the data comes in fine, but once in a blue moon the two integers I read in are 0x100 and 0xFEFF which turns into 0x100FEFF, and is not the correct data.
So I punched 0x100FEFF into google hoping to find some sort of computer science clue, and this forum is all that came up.