Bootblock: 0x55AA or 0xAA55?

[Kemp]

I think the general consensus (sp?) is that 0xAA55h works for everyone. Solar : Are you sure the padding was right on your ones that didn't work? If it was off then the BIOS would have been checking the wrong value.

[Solar]

I hate to admit it but I screwed up. I am not quite sure what happened there, but I suspect my Makefile was a bit buggy. Anyways, I was unable to reproduce what back then seemed like a perfectly good result of repeated testing.

.word 0xAA55 works, and results in

Code: Select all

...
00001f0 0000 0000 0000 0000 0000 0000 0000 aa55

all right.

Must have been smoking the wrong weed. Wait, I don't smoke... no idea. :-[

[Kemp]

00001f0 0000 0000 0000 0000 0000 0000 0000 aa55

Shouldn't that be 55aa in the final dump? (The same as doing 0x55 0xAA)

[AR]

If I'm not mistaken, each 0000 is a 2byte hex meaning 0x0000 ... 0xAA55

[gaf]

Hello,
The signature must be the 510th byte in the file, so there's no need to worry about padding. If the "code" you've posted is a dump of a working bootsector, the signature must be 0x55AA in your asm-file due to the little-endianess of x86 processors. Little endian means that the "little" end of the number is stored first (http://en.wikipedia.org/wiki/Endianness).

btw:
The siganture is a magic number:
0x55 -> 01010101
0xAA -> 10101010

I could imagine that the BIOS simply ANDs the two bytes and then compares them to 0xff which woud mean that both versions (0x55AA and 0xAA55) should work. Why else should they have chosen this specific number ?

regards,
gaf

[AR]

erm, I already went through this, see my example for drawing an exclamation mark, the x86 order is basically right to left 0x12345678 > 0x78 0x56 0x34 0x12.

Why did they choose the particular signature? Probably because it's either odd, looked cool or doesn't map to any CPU instruction (so causes inv-op when executed). The thing is that IBM did not think about things very logically, the creation of IO Address space and Segmentation is a testament to that. You need to check your binary operations as well, AND would result in 0x00, OR would be 0xFF, you are right that they could use "and al, ah; jz SigValid" but it is more likely that it's a simple "cmp ax, 0xAA55; je SigValid".

Let's just put this to rest:

Code: Select all

if (bootchk == 0) {
    if (read_word(bootseg,0x1fe) != 0xaa55) {
      print_boot_failure(bootcd, bootdrv, 0, lastdrive);
      return 0x00000000;
      }
    }

(From Bochs -> ROMBIOS.C [Line 7572 v2.2])

[Solar]

Jesus (no offense intended), but you guys can shake one's confidence.

As a sidenote, I know very well about endianess. That is why I suspected foul play in the signature.

The following are all correct:

.byte 0x55
.byte 0xAA

db 0x55
db 0xAA

.word 0xAA55

dw 0xAA55

$ hexdump -C bootsector
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa

$ hexdump bootsector
000001f0 0000 0000 0000 0000 0000 0000 0000 aa55

And no matter what basic operation might have been easier on low-endian in 8 or 16bit times, it sucks. Big time. Which is probably why no other self-restpecting CPU architecture I know of has adopted low-endian as default.

::)

[df]

i remember finding many BIOS's that would just boot anything on the first sector, regardless of signature present or valid or not.

[Solar]

I am a die-hard pedantic. If there's some convention about boot sector signatures, I'm trying to adhere to it whether it matters or not.

[distantvoices]

@solar:bruce willis mighta find it pretty hard to stay on par with you concerning the die-hard stuff. *rofl*