FAT12文件起始地址存疑：0x4200还是0x4400？

1. 磁盘偏移 vs 内存地址的核心混淆 #

你提到的资料中“FAT12文件起始于0x4200”，这里的0x4200是磁盘镜像的字节偏移，对应第33个扇区（1扇区=512字节，33×512=16896=0x4200）。而引导加载器里的JMP 0xc400是内存地址，对应磁盘上的0x4400（第34扇区，34×512=17408=0x4400），两者的对应关系由引导加载器的加载逻辑决定：

• 引导加载器从磁盘第2个扇区（LBA1，偏移0x200）开始加载，每扇区对应内存中0x8200 + n×512的位置（n为加载的扇区序号，从0开始）
• 磁盘第33扇区（偏移0x4200）→ 内存地址：0x8200 + (33-1)×512 = 0xc200
• 磁盘第34扇区（偏移0x4400）→ 内存地址：0x8200 + (34-1)×512 = 0xc400

2. 文件出现在0x4400的原因 #

你的镜像创建流程只写入了引导扇区，其余部分用零填充，并未初始化FAT表和根目录结构。执行mount -o fat=12挂载时，系统会自动生成FAT12文件系统，但未严格遵循你在引导扇区BPB中定义的参数：

• 标准1.44MB软盘的FAT12结构是：引导扇区（1扇区）→ 2个FAT表（各9扇区，共18扇区）→ 根目录（14扇区）→ 数据区（从第33扇区开始）
• 但由于镜像初始无有效FAT结构，挂载系统可能自动调整了根目录的占用扇区数，导致数据区起始位置后移到第34扇区（偏移0x4400），因此os.bin被写入到了这里。

3. 跳转0xc200仍能运行的可能原因 #

引导加载器加载了10个柱面的扇区（共360扇区），覆盖了从第2扇区到第361扇区的所有磁盘区域，包括第33和34扇区：

• 若你修改跳转地址后重新执行了copy步骤，挂载系统可能调整了os.bin的存储位置，使其落到第33扇区（对应内存0xc200）；
• 若你查看的是旧镜像的磁盘数据，实际新镜像中第33扇区已被os.bin覆盖；
• 极少数情况：内存中0xc200的内容被后续加载的扇区意外覆盖，但根据你提供的磁盘数据，这种情况概率极低，建议重新验证镜像内容。

验证方法 #

用以下命令提取磁盘第33、34扇区的内容，确认os.bin的实际位置：

dd if=myos.img of=sector33.bin skip=33 count=1 bs=512
dd if=myos.img of=sector34.bin skip=34 count=1 bs=512

也可通过QEMU调试：

qemu-system-i386 -drive file=myos.img,if=floppy -s -S

然后用GDB连接，查看内存0xc200和0xc400处的内容，对比磁盘数据。

内容的提问来源于stack exchange，提问作者lewis