running 16-bit code in xms

[GorillaCoder]

Is it possible to run x86 16-bit code at ffff:0010?
This would be 0100000h in protected mode, at the start of xms memory.

[carbonBased]

erm... 0xffff * 16 + 0x10 != 0x100000

In any event, assuming there's nothing of value at that memory location (which there probably is... I'm pretty sure the BIOS uses that segment) then you could definitly run x86 code at that location (you can run code at any location... !  I don't get the question...?)

Jeff

[GorillaCoder]

Sorry, fff0:0010
I want to have the bios load in boot code, which would in turn load in a binary at fff0:0010, switch to protected mode, and continue running in 32-bit mode.
I thought that would create a problem because it would be executing past the 1mb boundry?  Also, I keep hereing about the a20 line, what does this do?

[Brill]

The a20 line is the 21'st address bus line. Because older machines didn't have the a20 address line they couldn't use it. and to keep backwards compatability with older software it's disabled when your machine starts, you must enable it to use it, and when you enable it you get the full address space your machine has.

Brill.

[carbonBased]

You can execute past the 1MB boundary in real mode, if the A20 is set (for the reasons Brill has stated).  In fact, you can access the entire 32-bit address space from real mode with some tricks (ie, "unreal" mode, etc).

The only problem I'm seeing here is that, the address you're trying to load to, may be reserved.  I don't have a memory map on me, but I'm pretty sure the BIOS reserves segment 0xF000... depending on how much space it alloctes, FFF0:0010 may still be in use by the BIOS, and so you shouldn't try and put any code there.

Jeff

[VoidLogic]

(I'm in real mode)
ohhohh this is good, does that mean if i enable A20 my OS gain use memory directly in the same manner is uses conventional memory, rather then HIMEM.SYS?
How would I enable this?

[GorillaCoder]

I think I was right the first time: ffff:0010h = ffff0h+10h = 100000h(flat 32-bit)
Yes, I believe unreal mode would be good for loading in an large os binary images past the 1mb boundary
but then I would want to exit flat mode and enter real mode again (temporarily) to setup and use 32-bit protected mode and minimal dpmi properly
which is why I was asking if there was a way to exectute 16-bit code in the ffff:0010h area, and what the a20 line had to do with this, if anything.
I am still not quite sure what the a20 line actually does to the system, does it allow access to that last 64kb segment in 16-bit mode?

[carbonBased]

Okay, hopefully this'll put the A20 line into perspective.

Early computers had a 20-bit wide bus.  Therefore, the largest ammount of memory accessable = 2^20 = 1048576 totally addressable bytes.

Programs written for these computers, however, utilitized a "feature"/quirk of this system call wrap around.  The 21st address bit was ignored (it didn't exist!).  Essentially, it equated to 0, no matter what.  Therefore anything over 1MB (ie, 1048576) wrapped around back to 0.

Do the math yourself, and it'll make more sense:
Try 1048577 (ie, 1 byte past the 1MB mark)
Convert it to binary, and notice the 21st bit is set.  However, since the 21st bit is hard coded to 0 in these old systems, that number simply equates to 1.
Hope that makes sense... I can't explain it too well.

Now, note that newer systems, for compatibility reasons, still hard code the 21st address bit to 0.  Of course, these new systems have 32-bit address busses.  32 address bits, however, aren't too useful if the 21st one is always 0.

So, to access and use the fully 32-bit addressable address space of these new systems you must turn off that "wrap around" compatibility, and enable recognition of the 21st address line.

Cheers,
Jeff

[GorillaCoder]

Ok, it starting to make sense now, so you would have to set this bit for all systems with a 386 or better, even a PentiumIV?
Matt

[carbonBased]

Yep.

Jeff