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'm making a small real mode OS, just to enhance my assembly knowledge a little... I was just wondering how I can access the extended memory while still in real mode, like for example MS-DOS does using HIMEM.SYS? What is HIMEM.SYS' "trick" to access the extended memory? Some kind of unreal mode, or what?
i believe this is in the faq but anyway
What happens is you enable A20 gate and then you switch to protected mode, make a generic "full address" set of selectors and then load the gdt using lgdt; load the new selectors into the appropriate segment registers. then you switch back to real mode and voila you got access to everything. You will have to make a pokeb32() in asm(don't have time to go into detail) because no C compiler i know of supports both 16 and 32 bit instructions
First of all, I'm writing the OS in assembly only (since it's a small real mode OS).
Are you sure that's what HIMEM.SYS does in MS-DOS? It use the unreal mode trick? For some reason, that seems strange to me, but I don't know... Enabling the A20 gate alone will just give me access to the first 64KB of the extended memory, right?
If I set up unreal mode, I still won't be able to for example read from disk using int 13h, and stright into EBX, right? I will have to read into a buffer in the conventional memory, and transfer the data into a final location in the extended memory afterwards?
I see little point in what you are doing, if it's a small realmode OS, you should not need the extended memory.
Much better to implement a function for going to and from realmode, this way you can have the best of both worlds, that what i do in my OS, if i need to use realmode function for vesa or mode switching.
Here's a demo i made to do that, with asm code may help http://www.dex4u.com/images/DemoVesa.zip
Note: needs vesa2.
I know it's not important in such a small OS, but remember, I do this to learn more assembly, etc. From what I've read until now, the best thing to do is probably going into unreal mode, but I've read that it's much slower than protected mode and real mode, and I can't use the 32-bit offset values with any BIOS interrupt, so maybe unreal mode aint the best choice anyway (are there any other?)
Still, I wonder how MS-DOS does this?
EDIT: I found out how HIMEM.SYS does it; it does as people mentioned before. I sets up a GDT entry that covers the whole memory, load it, enable PE-bit, far jump, and then it goes back to real mode. So it's some kind of unreal mode trick.
Ah, of course. So no far jump is needed, I suppose. However, I tried to write some small piece of code that copies a string into 100000h, and then printing it from that location. This didn't work; it hanged while in the loop that copies the string at DS:ESI to DS:EDI (not using any MOVSx instruction) where ESI points at the start of the string within the program, and EDI points to 100000h... Why doesn't this work?
No, it copies a string from its location in the program space and into offset 100000h of the flat memory, and then it tries to print the string starting at 100000h, but that doesn't work. Nothing get's printed on the screen. It seems that it's something with the loop that copies the string to 100000h.
And yes, I have tested the print routine. It works if ESI points to the string in the program (msg_test).