OSDev.org

Hello,

I was reading :
http://wiki.osdev.org/A20_Line

And those lines are intriguing me : I don't understand why we touch ds:si because it is not directly used in the cmp.
We could only push es:di I think.

I know I miss something.

Could you please tell me ?

Thanks

Hi,

JulienDarc wrote:I don't understand why we touch ds:si because it is not directly used in the cmp.

If modifying the data at 0x00000500 (or 0x0000:0x0500 in real mode) causes the data at address 0x00100500 (or 0xFFFF:0x0510 in real mode) to change, then A20 is disabled.


Cheers,

Brendan

Hello Brendan.

Brendan wrote:Hi,

JulienDarc wrote:I don't understand why we touch ds:si because it is not directly used in the cmp.

If modifying the data at 0x00000500 (or 0x0000:0x0500 in real mode) causes the data at address 0x00100500 (or 0xFFFF:0x0510 in real mode) to change, then A20 is disabled.

Cheers,

Brendan

But it responded not truly the question why there is no compare instruction for the content of DS:SI.

Dirk

freecrac wrote:Hello Brendan.

Brendan wrote:Hi,

JulienDarc wrote:I don't understand why we touch ds:si because it is not directly used in the cmp.

If modifying the data at 0x00000500 (or 0x0000:0x0500 in real mode) causes the data at address 0x00100500 (or 0xFFFF:0x0510 in real mode) to change, then A20 is disabled.

Cheers,

Brendan

But it responded not truly the question why there is no compare instruction for the content of DS:SI.

Dirk

Read up on what A20 does - if A20 is off, writing to 0x100500 will actually write to 0x500, and reading 0x100500 will read from 0x500. That means, if you write to 0x100500, then write to 0x500, and then read 0x100500 it should give you the first value (that you wrote to 0x100500). If that works, A20 is enabled. If it does not, all writes got sent to 0x500 instead and you can now detect it.

Candy wrote:Read up on what A20 does - if A20 is off, writing to 0x100500 will actually write to 0x500, and reading 0x100500 will read from 0x500. That means, if you write to 0x100500, then write to 0x500, and then read 0x100500 it should give you the first value (that you wrote to 0x100500). If that works, A20 is enabled. If it does not, all writes got sent to 0x500 instead and you can now detect it.

Thanks, this is a good answer. I like it.

Dirk

Yes,

what is wrong with that :
?

My readings "tell" me that there is a wrap around when a20 is disabled.
So the byte located at 0x0000:0x0500 should be written with the value 0xff when a20 is disabled and 0x00 when a20 is enabled (and 0xffff:0x0510 has its byte 0xff written).

The code above seems to do just that, too. Am I wrong ?

that code is basically identical to the original except:
your code doesn't save/restore the previous contents of those memory locations, if whatever was in them was important, it is now lost...

also:
your code has a serious bug in that it disables but does not restore interrupts...
if the wraparound happens, interrupts are left disabled (bug)
if wraparound does not happen interrupts are enabled even if they were disabled before the code ran (very very dangerous bug that can cause instant triple-fault or random/unexpected code execution)

Doesn't popf restore the int flag?

ooooooops !!!
That is right !

Ok now i get the whole thing and will store/load what was in memory at those addresses.

I will let my code above as is for future readers.

Thanks a lot !

Julien

Roflo wrote:Doesn't popf restore the int flag?

oops... your right, i didn't see that there at the end, just the (pointless) sti earlier (saw the STI and assumed there wasn't a popf since sti is unnecessary otherwise)

Yes the sti is wrong here. I messed up "a bit" -> 90% chance triple fault