Interesting info about A20 and computers crashing.

[Shibata]

Yesterday, I got tired of coding and decided to look some sites about CPUs and other interesting things... I found the site http://www.rcollins.org/secrets/, which shows CPUs secrets and bugs, and http://www.rcollins.org/secrets/opcodes/, which shows undocumented opcodes. The site is old and isn't updated (looking http://www.rcollins.org/Errata/ErrataSeries.html, the last article is from February 1998, and there are many 404 errors on the links), but has a interesting article about A20. Here, it shows that resseting a computer with A20 disabled may jump to unknown code, which will probably stop the CPU (triple-fault again and again...). I belive this doesn't happen nowadays (my 32-bit CPU resets normally with A20 disabled), but it's a nice information to keep OS's compatible with older CPUs and avoid crashes. I didn't know that, and I was testing some CPU features (Long Mode, for example) before enabling A20. If the CPU doesn't support Long Mode, I would show a error message and triple-fault. On older computers, that would crash the computer. Other developers can be doing the same error.

Do you think it's a good info for the wiki article? If yes, could you add it (my english isn't very good)?

[Love4Boobies]

I honestly doubt that article is correct because the A20 gate was added for backwards compatibility with DOS software that expected to have an address space of 1 MiB and wraparound to occur. It is natural to expect such software to also attempt a reset and given that it was written before the A20 gate was introduced, it wouldn't know to enable it. The solution is for the BIOS not to attempt to put anything at odd MiB's, at least until it has (temporarily) enabled the A20 gate. Even though this is not what that page is talking about, the advice might make more sense in the case of other firmware, such as (U)EFI.

[Shibata]

At first, I though that didn't make much sense too, as it should be compatible. But it should be compatible with a processor which was created many years before the 80386, so most software should be enabling the A20 line by that time. Maybe BIOS manufacturers didn't notice the issue in the first few computers with more RAM and that issue could be real. I'm not sure if that information is right, but IMHO it makes some sense. But I never tested it; let's wait and hear other opinions. Maybe someone tested it on a 80386 and can tell us the truth.

[Love4Boobies]

The A20 gate was actually introduced together with 80286 boxes, not 80386. At any rate, there was an option to either enable or disable the HMA in DOS' config.sys. Do you think no one would have noticed that they can't reset when it was disabled?

[Shibata]

The A20 gate was actually introduced together with 80286 boxes, not 80386.

That's my point: it was a little older than the 80386, so maybe some BIOS manufacturer didn't notice the bug at first. Your argument makes a lot of sense, but it isn't unbelievable that someone made this mistake in some old BIOS. There is a lot of buggy or non-standard hardware around; why wouldn't someone have not noticed this error? I will enable A20 before triple-faulting, just as precaution.

[Love4Boobies]

I still don't understand why you're making a distinction about the 80386. Why would it matter whether the A20 gate was introduced with the 80286 or the 80386? At any rate, none of my machines exhibit this bug.

[linguofreak]

but it isn't unbelievable that someone made this mistake in some old BIOS.

Yes it is: post-8086 PC's boot with A20 disabled. A20 is off by default unless needed (though most modern OS's need it and turn it on very early in the boot process). If that mistake had been made in some old BIOS, it would definitely have been noticed, given that that would have been in the DOS era (affected computers would have hung, rather than rebooting, on ctrl-alt-del).

[Love4Boobies]

Fix your quotes, man. I didn't say that.

[linguofreak]

How did *that* happen?

Fixed.