Which comes first? A20 line or PM switch?

[MSDOSDudeNot]

Alright, so the wiki seems scattered. On this Wiki article: https://wiki.osdev.org/Protected_Mode - it says that you must enable the A20 line before switching to Protected Mode. But then, in this Wiki article: https://wiki.osdev.org/Rolling_Your_Own_Bootloader - it mentions the enablement of the A20 line after the "You have long way to continue..." section. So I'm very confused at the order. There's another article on the wiki with the same thing as this, but I cannot remember where it is. Anyway, my question is which comes first? Does it matter like the wiki says? Or am I somehow missing the time line of events here?

Thanks.

[BenLunt]

There is a simple answer, though it comes in two parts:

1) You must enable the A20 line before you use any odd numbered Megabyte of memory.
2) You must enable pmode before you execute any pmode code.

Period. Nothing more, nothing less.

The A20 line has nothing to do with pmode as well as pmode has nothing to do with the A20 line.

1) If you wish to use all of memory, not just the even Megabytes, you must enable the A20 line.
2) If you wish to execute and take advantage of pmode code and the things that come along with it, you must enable pmode.

One does not need to be done before the other.

Ben

[Sik]

Yeah, the two are not technically related.

That said, if you're switching to protected mode then you'll probably want to use all of RAM immediately, so it's probably wise to enable A20 first. Having it enabled early never harms unless you're running old DOS programs from the '80s (you aren't) :​P

[MSDOSDudeNot]

Yeah, the two are not technically related.

That said, if you're switching to protected mode then you'll probably want to use all of RAM immediately, so it's probably wise to enable A20 first. Having it enabled early never harms unless you're running old DOS programs from the '80s (you aren't) :​P

Actually, I plan to support .COM files and to have a Real Mode back-end in the system, along with Virtual x86. So these DOS things actually are important to me with regards to my project. In fact, that's one of, if not the, big motivation for me asking this question. I'm genuinely confused at this.

[Sik]

Oh. You can probably still fake the effects using paging anyway, so it shouldn't be a big deal. The problem is when you leave A20 enabled without paging (i.e. in actual real mode).

For the record, the usual culprit blamed for the need of A20 line is the CALL 5 mechanism (added for compatibility with CP/M) where jumping to 0005h would then invoke a jump to an address that wraps around, but when we looked for test programs for DOSBox-X nobody knew about any such program except for a test program made just for the purpose. On the other hand, a significant bunch of programs seem to rely on it due to using signed arithmetic instead of unsigned during compression and accidentally relying on the wraparound to make it work.


(also not gonna lie, surprised Intel even let the CPU access over 1MB in real mode i.e. they didn't mask out all the upper address bits altogether - biggest CPU whammy ever there)

[Octocontrabass]

According to Intel (in various CPU manuals dating all the way back to the 486), you must enable the A20 line before you switch to protected mode, and you must not disable the A20 line while in protected mode. Disobeying these requirements results in undefined behavior.

I suppose nowadays most users of DOS programs and DOSBox are only interested in games, but if you're looking for real software that relies on CALL 5, look no further than Microsoft Word.

[MichaelPetch]

[quote="Octocontrabass"]According to Intel (in various CPU manuals dating all the way back to the 486), you must enable the A20 line before you switch to protected mode, and you must not disable the A20 line while in protected mode. Disobeying these requirements results in undefined behavior.

Care to quote some?I'm very curious. The behavior of the A20 line (when it is enabled or disabled) and its effects on addressing are very well defined and the same effect in real or protected mode - when A20 is disabled physical addresses in odd number megabyte region map to the even number megabyte boundary preceding it. If you write code that doesn't require data/code in an odd megabyte region your code should work as expected.

[Octocontrabass]

Care to quote some?I'm very curious.

486 manual, order 240486: "A20M# is active LOW and must be asserted only when the processor is in real mode. The A20M# is not defined in Protected Mode."
Pentium manual, order 241428: "The effect of A20M# is undefined in protected mode. A20M# must be asserted only when the processor is in real mode."
Pentium Pro manual, order 242690: "A20M# must only be asserted when the processor is in real mode."
Pentium II manual, order 243502: "A20M# must only be asserted when the processor is in real mode."

...I can go on, but I think you get the idea.

The behavior of the A20 line (when it is enabled or disabled) and its effects on addressing are very well defined and the same effect in real or protected mode - when A20 is disabled physical addresses in odd number megabyte region map to the even number megabyte boundary preceding it.

What you've described is the simplest implementation of the A20 gate, but not the only one. For example, at least some of Compaq's Deskpro series used a system where only the second megabyte would be mapped to the first megabyte, and the remainder of the address space is unaffected.

If you write code that doesn't require data/code in an odd megabyte region your code should work as expected.

Most likely yes, but it's a bad idea to rely on undefined behavior.

[Antti]

That is interesting information. We should not play any tricks on A20M# but understand the interface, i.e. the second megabyte is relevant and not the whole address space. By the way, is it actually guaranteed that triple faults are safe if A20M# is disabled (or vice versa)?

[Octocontrabass]

Triple faults aren't guaranteed to reset the CPU. (Check the comments.)

Resetting the CPU with the A20 line enabled (A20M# disabled) will simply begin executing the BIOS ROM from the beginning, like usual. Resetting the CPU with the A20 line disabled (A20M# enabled) is not specified in any of the manuals I've looked at, and might differ between CPUs or chipsets. I suspect a common result will be an immediate fault on the invalid opcode FF /7 at 0xFFEFFFF0.

[Sik]

Huh, I thought the reboot was caused by the CPU resetting on its own, not by the CPU halting and whatever is on the motherboard deciding to reboot it. But I don't know that much about x86, I just know that a lot of docs out there say to triple fault to reboot :​/ But they're unofficial docs (also just looked up, and yup 68000 also does the same when it double faults, it halts and requires external hardware to explicitly reset it, so it's not just x86 doing this)

I guess the "obvious" behavior of A20 line enable comes from the original implementation essentially being a discrete AND gate slapped on the relevant address line. I suppose that stopped being relevant when the task was given to the CPU once it became the memory controller as well (do modern implementations even support masking away A20 anymore?).


EDIT: oh hey how convenient
http://www.os2museum.com/wp/the-a20-gate-fallout/

1) Every OEM had its own interpretation of what an A20 gate should be
2) A20 gate interferes with the cache which is why 486 onwards has to be aware of the current state

The latter also probably explains why leaving A20 gated out is undefined behavior: the CPU probably assumes it's always enabled in protected mode (for its cache) but the motherboard may still be messing with it, and leaving A20 always working is the only way to ensure both are in sync.

I wonder how much of a mess would have been avoided if the CPU itself had disabled the extra address lines in real mode :​/ (I guess it never occured to Intel's engineers that software may be relying on wraparound... this is why when you want to do backwards compatibility you need to recreate even the obscure details that supposedly shouldn't matter)

[BenLunt]

the CPU probably assumes it's always enabled in protected mode

I think the big word there is "assumes". I hate that word. That word makes an @$$ out of you and me. (@$$-u-me)

Ben
- http://www.fysnet.net/osdesign_book_series.htm

[Octocontrabass]

I guess the "obvious" behavior of A20 line enable comes from the original implementation essentially being a discrete AND gate slapped on the relevant address line. I suppose that stopped being relevant when the task was given to the CPU once it became the memory controller as well (do modern implementations even support masking away A20 anymore?).

The A20 gate has been the CPU's job since the 486. The memory controller can't mask A20 without risking cache coherence problems. (Cyrix did some amazing things to get their 486DLC to work in a 386DX motherboard.)

The latter also probably explains why leaving A20 gated out is undefined behavior: the CPU probably assumes it's always enabled in protected mode (for its cache) but the motherboard may still be messing with it, and leaving A20 always working is the only way to ensure both are in sync.

Due to the aforementioned coherency problems, there's no safe way for the motherboard to mask A20 outside of the CPU. It's more likely that Intel decided it would be easier to optimize their CPUs if they didn't have to worry about someone trying to mask A20 while in protected mode. (For example, they might place the A20 gate between the core address generation and the prefetch logic, so prefetched code across a 1MB boundary might come from a physical address with A20 set even while A20 is masked.)

[tom9876543]

Another example of an Intel f#$k up.
Intel should have predicted there would be some dubious coders relying on the 8086's address wrap around.
Intel should have included a "8086 address wrap around" flag in the 286's Machine Status Word.
IBM et al had to implement the dodgy A20 solution due to Intel's failure.

[nullplan]

Another example of an Intel f#$k up.
Intel should have predicted there would be some dubious coders relying on the 8086's address wrap around.
Intel should have included a "8086 address wrap around" flag in the 286's Machine Status Word.
IBM et al had to implement the dodgy A20 solution due to Intel's failure.

I disagree. Whether or not programming the 8086 with wrap-around is dubious is anyone's guess (is software faulty that fails in an environment for which is wasn't written?). The status word idea couldn't have worked since the 21st address line was actually introduced on the 186, which didn't have a MSW. So by the time the 286 rolled around there was 8086 software that depended on address wrap-around and 186 software that depended on its absence. Nothing Intel could do, really. Besides, at the time the CPU was talking directly to the memory and main board, it was simply not the CPUs place to decide anything about how the system bus was to be used. At the time, IBM was making the system, Intel only provided a component in it. Backward compat was IBM's goal, not necessarily Intel's.

It is trivially easy to use the benefit of hindsight to appear smarter than the people of the time. No-one could have reasonably predicted the PC would take off the way it did. No-one could have predicted the CPU market to become so monolithic. No-one could have predicted that OSes would have to disable the A20 gate three decades after its inception.

Also, no-one was stopping IBM from integrating another simple flip-flop on the board of the PC/AT, instead of abusing the keyboard controller.