OSDev.org

I am just trying to understand how to test if I am correctly enabling the A20 line. My understanding is that prior to enabling the A20 line only zero to 1M is addressable 0x00000000 - 0x000FFFFF to check this I do the following
I write to the dword just below the 2M limit, and if the A20 line is NOT enabled then I would expect the written value to appear
just below the 1M limit due to the address bits 31-20, being ignored. So I would expect the test above to fail when I uncomment teh A20 enable code (the two first lines) but in BOCHS it doesn't, hence the question is my understanding correct and is this a reasonable method to test if the enabling has been successful?

It is, but only assuming you're already in protected mode. In real mode you can't access anything above 0xFFFF due to segment limits.

If you are in protected mode, this is not going to help as you can't fix that problem from protected mode.

The A20 Line page on the wiki has sample code that sets the two addresses to two different values, then checks to see if they are equal. Then it sets them back to their original value.

hubris wrote:0x000FFFFC

I don't think your test will work very well when you aren't using RAM. Other than that, it sounds like you've got the right idea. (Enabling A20 in the first place is usually the hardest part.)

Candy wrote:It is, but only assuming you're already in protected mode. In real mode you can't access anything above 0xFFFF due to segment limits.

That's the kind of situation where unreal mode is useful.

Candy wrote:If you are in protected mode, this is not going to help as you can't fix that problem from protected mode.

Are you sure about that?

Hi,

Octocontrabass wrote:

Candy wrote:It is, but only assuming you're already in protected mode. In real mode you can't access anything above 0xFFFF due to segment limits.

That's the kind of situation where unreal mode is useful.

One of the quirks of real mode is that you can access slightly more than 1 MiB of memory. Real mode addresses 0xFFFF:0x0010 to 0xFFFF:0xFFFF become physical addresses 0x00100000 to 0x0010FFEF; so you can actually access "not quite 64 KiB" more than 1 MiB.

Of course this is the reason A20 exists in the first place. On ancient CPUs (that only had a 20-bit physical address bus) these accesses would wrap around (e.g. 0xFFFF:0xFFFF becomes 0x0010FFEF which is truncated to 0x0000FFEF) and someone wrote software that depended on the wrap around and their software broke when newer CPUs came along, so the entire industry had to be cursed with A20 (to work around the problem) for 30+ years.


Cheers,

Brendan

Brendan wrote:someone wrote software that depended on the wrap around and their software broke when newer CPUs came along

I have been wondering what that software might be. On traditional PCs, the only one I can think of would be the BIOS routines. For example, an IRQ handler modifying (cs = 0xF800, ip = ????) the bios data area found at 0x0040:0x0000 without loading other segment registers but using a cs override prefix if accessing data. That brings me to another point: would it be safe to enable the A20 line and still keep the BIOS in control? Of course, this just theoretical and applies only on really old rare PC hardware.

Hi,

Antti wrote:

Brendan wrote:someone wrote software that depended on the wrap around and their software broke when newer CPUs came along

I have been wondering what that software might be. On traditional PCs, the only one I can think would be the BIOS routines.

I don't know. Ages ago I tried to find out, but I failed to find anything specific online.

I don't think it would've been BIOS, as BIOS is "motherboard specific" anyway and could've been changed so that newer BIOSs for newer motherboards don't depend on the wrap around. On the other hand, I can't think of a sane reason for a real mode OS (CP/M, MS-DOS) or applications to rely on the wrap around either (but programmers do seem to do insane things at times).

Antti wrote:That brings me to another point: would it be safe to enable the A20 line and still keep the BIOS in control? Of course, this just theoretical and applies only on really old rare PC hardware.

It's safe to enable A20 and keep BIOS in control - even MS-DOS does that (back in the "himem.sys" days).


Cheers,

Brendan

This is a little bit strange. There are differences between an 8086 and newer that could be far more significant than this wrap-around feature. But still this specific issue had to be made backward compatible at any cost. There must have been an important application that used this wrap-around hack.

Brendan wrote:Hi,

Antti wrote:

Brendan wrote:someone wrote software that depended on the wrap around and their software broke when newer CPUs came along

I have been wondering what that software might be. On traditional PCs, the only one I can think would be the BIOS routines.

I don't know. Ages ago I tried to find out, but I failed to find anything specific online.

. . .

OS/2 Museum wrote:There is precious little information on that topic. But as it turns out, all versions of DOS, including the OS/2 DOS box and NTVDM in Windows NT, implement a CP/M-like system call interface which cannot work without address wrap-around being emulated one way or another. In other words, any DOS application may in fact need the wrap-around, without necessarily being even aware of the fact.

Thank you Mike! I think the link you sent clarifies this matter to a great extent. A very good history lesson. The puzzle is solved.

hubris wrote:I write to the dword just below the 2M limit, and if the A20 line is NOT enabled then I would expect the written value to appear
just below the 1M limit due to the address bits 31-20, being ignored. So I would expect the test above to fail when I uncomment teh A20 enable code (the two first lines) but in BOCHS it doesn't, hence the question is my understanding correct and is this a reasonable method to test if the enabling has been successful?

Summarized:

1) Bochs has A20 enabled by default and depending on the configuration it might not even support having it disabled. Therefore a default Bochs install makes a bad testcase. This is something you'll really want to test on real hardware.
2) You're using a BIOS ROM address for aliasing, expecting read-only memory to change.
3) You're only testing for a magic number rather than the effect itself. If you put that number there once it'll be there for longer (including after a warm reboot) and mess up your detection.

Thank all for your discussion and additional information. I had posted this questions to try and understand what could be happening with the issue I had raised in
[url]http://forum.osdev.org/viewtopic.php?f=1&t=29340&sid=3d2d3d59e2b42849700201d761d67431
[/url].
As it turned out the solution was buried deep inside the code to load sectors from the disk, I had swapped the sector number and sector count values inside the loading code so everything worked until the number of sectors became greater than the sector number and then strangeness began to happen. I discovered this while doing my 47th triple check of the code I had written only to discover the previous 46 checks had not picked up the error.
Yeah for BOCHS as the debugging capability is invaluable, as indeed is this community.