flat assembler
Message board for the users of flat assembler.

Index > OS Construction > FAT Bootsector?

Author
Thread Post new topic Reply to topic
rhyno_dagreat



Joined: 31 Jul 2006
Posts: 487
Location: Maryland, Unol Daleithiau
rhyno_dagreat 09 Apr 2007, 01:50
I am wondering, can someone please explain to me how FAT bootsectors work? I have seen plenty of FAT code and it confounds (confuses?) me.
Post 09 Apr 2007, 01:50
View user's profile Send private message Reply with quote
Fagot



Joined: 09 Apr 2007
Posts: 3
Fagot 09 Apr 2007, 18:55
It easy.
Bootsector it simple binary program.
Two last bytes be equal 0x55,0xAA.
Bootsector size must be 512 bytes.
First two bytes is empty byte (nop) and jump to main code.
Next 60 bytes is information about boot device.

Simple boot:
Code:
org 0x7C00
use16
jmp _start
nop

OEM_ID db "BOOTSECT"
times 62-($-$$) db 0

_start:
mov ax, cs
mov ds, ax
mov ss, ax

mov si, msg
mov ah, 0x0E
_print:
lodsb
test al, al
jz hang
int 0x10
jmp _print
hang:
jmp hang

msg db "Hello, world!!!",0
times 512-($-$$)-2 db 0
dw 0xAA55
    
Post 09 Apr 2007, 18:55
View user's profile Send private message ICQ Number Reply with quote
rhyno_dagreat



Joined: 31 Jul 2006
Posts: 487
Location: Maryland, Unol Daleithiau
rhyno_dagreat 09 Apr 2007, 19:58
Thanks Fagot, though it's not the bootsector itself that confuses me. It's how the FAT works in it.
Post 09 Apr 2007, 19:58
View user's profile Send private message Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias 10 Apr 2007, 09:22
Fagot wrote:
First two bytes is empty byte (nop) and jump to main code.
Two questions:
A. Do you have a reference from Intel which explains the requirement to insert "nop" in the bootsector? I suspect this notion may be a holdover from the late 1970's when state of the art was the 8080, and floppies were, well, floppy.
B. Why can you not write "start" and "print", instead of "_start" and "_print"? Are "start" and "print" reserved words in FASM?
Post 10 Apr 2007, 09:22
View user's profile Send private message Reply with quote
Hayden



Joined: 06 Oct 2005
Posts: 132
Hayden 10 Apr 2007, 10:41
Microsoft Hardware White Paper


Description: Version 1.03, December 6, 2000
Microsoft Corporation

Download
Filename: fatgen103.pdf
Filesize: 164.57 KB
Downloaded: 165 Time(s)


_________________
New User.. Hayden McKay.
Post 10 Apr 2007, 10:41
View user's profile Send private message Reply with quote
Fagot



Joined: 09 Apr 2007
Posts: 3
Fagot 13 Apr 2007, 17:37
tom tobias wrote:
Fagot wrote:
First two bytes is empty byte (nop) and jump to main code.
Two questions:
A. Do you have a reference from Intel which explains the requirement to insert "nop" in the bootsector? I suspect this notion may be a holdover from the late 1970's when state of the art was the 8080, and floppies were, well, floppy.
B. Why can you not write "start" and "print", instead of "_start" and "_print"? Are "start" and "print" reserved words in FASM?


A - all information in pdf Smile this just standard.
B - "start" and "print" not reserved words in FASN. it's my style of programming Smile

_________________
I learn English Smile
Post 13 Apr 2007, 17:37
View user's profile Send private message ICQ Number Reply with quote
Goplat



Joined: 15 Sep 2006
Posts: 181
Goplat 13 Apr 2007, 23:02
tom tobias wrote:
Fagot wrote:
First two bytes is empty byte (nop) and jump to main code.
Two questions:
A. Do you have a reference from Intel which explains the requirement to insert "nop" in the bootsector?


Intel has nothing to do with it. The FAT filesystem was first used in Microsoft Disk BASIC in 1977. I can't find much info about this but my guess is it was available for various computers, including some with a 6502 processor where unconditional jumps were always 3 bytes long. The boot sector's data has to be in the same format and in the same location no matter what kind of processor there is, so on processors where you have 2 byte jumps (like x86) you need an extra byte to make the data start at offset 3.
Post 13 Apr 2007, 23:02
View user's profile Send private message Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias 14 Apr 2007, 00:37
Fagot wrote:
"start" and "print" not reserved words in FASN. it's my style of programming
Thank you very much Fagot, I appreciate your candor. Umm, just my opinion, I am 99.44% sure that almost no one else agrees with me, but please OMIT all UNNECESSARY punctuation, if you seek to write legible programs. Of course, if you prefer obfuscation, for whatever reason, please continue to employ as much unreadable code as you wish....
Goplat wrote:
Intel has nothing to do with it. The FAT filesystem was first used in Microsoft ....
Thank you very much Goplat, of course you are correct, thanks for correcting me. Umm, I should know the answer to this, but I don't, so can you please confirm that IF ONE WERE NOT USING FAT, any FAT, then, one would not need to employ this peculiar "nop" instrucition at the outset? IN other words, WHAT WOULD AN INITIALIZATION routine look like, if one were booting up, not into MS$, but into some other, perhaps even one's own file system? I had the impression that the first several instructions were independent of M$, and based upon BIOS requirements from the motherboard.....
Thanks again for your excellent response to my previous question...
Smile
Post 14 Apr 2007, 00:37
View user's profile Send private message Reply with quote
Hayden



Joined: 06 Oct 2005
Posts: 132
Hayden 14 Apr 2007, 02:41
Yeah... the three byte jump is only specific to the microsoft FAT format.

All boot sectors only need to have the word signature AA55h at bytes 510-512 in the secotor to make the medium bootable. execution begins at the first byte of the boot sector. The first byte may be any insctruction you wish although usualy a jump to skip over some data structure.

ie: here is a simple 'name brand' boot sector

Code:
org 7C00h

jmp bootcode
    align 4                             ; make the data address static at 7C04H
    BS_MaxCylCount         dd ? ; C
    BS_HeadsPerCyl         dd ? ; H
    BS_SecsPerHead         dd ? ; S
    BS_BytesPerSec         dd 512d      ; default - 512 bytes
    BS_MediaType           db ?         ; hdd, fdd etc...
bootcode:

; code to boot the machine...

bootsign:

    rb 7C00h+512-2-$
    db 055h,0AAh                        ; expected to be l_endian

    


it always pay's to keep at least some kind of media info in the bootsector. even if your not useing the microsoft FAT format.

_________________
New User.. Hayden McKay.


Last edited by Hayden on 15 Apr 2007, 17:38; edited 2 times in total
Post 14 Apr 2007, 02:41
View user's profile Send private message Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias 14 Apr 2007, 16:14
Hayden wrote:
The first byte may be any insctruction you wish although usualy a jump to skip over some data structure....
Thankyou very much Hayden, umm, well, I suppose this will seem a peculiar question to many folks, but, while I certainly acknowledge the accuracy of your comment that the first byte (of every bootloader I have ever seen) is a JUMP skipping over data, I fail to understand WHY everyone is so eager to commence execution of the code, BEFORE declaring the data....?????
For me, this is completely the opposite of the proper way to program. So, again, is there somewhere, in some obscure journal, or white paper, or vendor's application note, or any other location, an explanation for WHY everyone commences the startup this way? To me, a logical, and proper, PROGRAM, not code, at the very outset, ought to begin with the DATA, not the code.
Hayden wrote:
it always pay's to keep at least some kind of media info in the bootsector. even if your not useing the microsoft FAT format.
And, sincerely, thanks again for your contributions to the forum. I just cannot follow your logic, sorry to be so obtuse. Maybe my nickname should be "blockhead". Umm, the problem, it seems to me, is that if one were intending to use Atapi drives there may be a considerable amount of initialization to begin with, prior to introducing the file system. I am not sure what advantage follows emplacement of this initialization routine WITHIN the boot sector. To my provincial way of thinking, i.e. not mainstream, the bootsector ought to simply fulfil whatever minimal requirements the cpu has to get started with the main program. Thus, in contrast to those (huge majority of) FASM folks who wish to cram the MOST code possible into the bootsector, I seek, on the contrary, to have ONLY the very smallest possible initialization program in the bootsector.
Smile
Post 14 Apr 2007, 16:14
View user's profile Send private message Reply with quote
bogdanontanu



Joined: 07 Jan 2004
Posts: 403
Location: Sol. Earth. Europe. Romania. Bucuresti
bogdanontanu 15 Apr 2007, 00:53
Quote:

I fail to understand WHY everyone is so eager to commence execution of the code, BEFORE declaring the data....?????


Well, mainly because the BIOS jumps you there at boot sector start.

A JMP instruction is performed by the BIOS to this location... and a JMP instruction tells the CPU to continue the execution of CODE to a certain memory location. Guess what? Location is right there at the start...

This means that the very first byte is forced to be code

It is (ironically) because the programmers want to have DATA at start that they do perform yet another JMP... this time over the initial DATA. This is the reason for this JMP: to keep data positioned at start of boot sector and perform this action with a minimum amount of code. And the minimum amount of code that can do this action is a jump over the data zone...

Quote:

To me, a logical, and proper, PROGRAM, not code, at the very outset, ought to begin with the DATA, not the code.


To me the logical physical layout is CODE first and DATA last.


However please note that because some executable formats and layouts support "sections" in one way or another... the format of the source code does not have to mirror the format of the binary layout. You can start your program with section ".data" and continue with section ."code" and still end up with them reversed in the resulting binary (most common). Usually it does not matter much.

But the boot sector is a case where the physical layout does matter for multiple reasons...some reasons are real and some are imaginations and desires.

I find it kind of funny, I find it kind of sad when people tend to get into "program" versus "code" design principles and talk about a boot sector Very Happy


One thing I notice here is the fact that you/others seem to believe or speak as if they believe that the boot sector is the first code that will setup/initialize the CPU? In fact the boot sector is the first part of loading/starting an OS or an application.

However the machine/CPU was initialized by the BIOS and countless complicated operations have been done for this...


Quote:

I seek, on the contrary, to have ONLY the very smallest possible initialization program in the bootsector.


I agree with this ... however some people do find advantages to filling up the boot sector with as much code and functionality as possible... 512bytes is pretty small for "normal" loading code and I guess that people find it funny to fit many things "in" there Very Happy

I presume that in another 50+ posts we would have had solved all the possible implications of the first 3 bytes of the boot sector... and advanced to the new frontier of the 4 and 5th bytes...

I also have "a vison" of a dilema at bytes 510: do they have to be 0x55, 0xAA ? Or could it be 0xAA, 0x55? This is the Question... The rest is silence

_________________
"Any intelligent fool can make things bigger,
more complex, and more violent.
It takes a touch of genius -- and a lot of courage --
to move in the opposite direction."
Post 15 Apr 2007, 00:53
View user's profile Send private message Visit poster's website Reply with quote
Hayden



Joined: 06 Oct 2005
Posts: 132
Hayden 15 Apr 2007, 04:25
The data at the start of a boot sector it usualy refered to as partition infomation. logicly speaking the partition comes before anything else on the disk medium.

Even though the BIOS has set up interrupt vectors ect... there may still be some stuff left to do like enableing the A20 gate, turn on FPU ect... before the o/s can be loaded.
Post 15 Apr 2007, 04:25
View user's profile Send private message Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias 15 Apr 2007, 10:06
Bogdan wrote:
It is (ironically) because the programmers want to have DATA at start that they do perform yet another JMP... this time over the initial DATA.
Thanks Bogdan for your several useful comments. Thoughtful as always. Much appreciated.
My notion, of declaring data BEFORE executing instructions, is similar to the mechanical engineer who FIRST studies a problem, makes drawings, and perhaps even assembles a scale model, BEFORE commencing with the operations needed to build the first prototype unit. It seems to me, silly to place data before instructions, if one intends to skip over the data structure anyway. The whole point of placing the data structure at the outset, is to define WHAT IT IS THAT THE SUBSEQUENT CODE WILL BE USING for operands, instead of inserting the piece of metal stock, turning on the lathe, and commence carving WITHOUT benefit of a drawing. For me, the distinction is akin to that of the artisan, compared to the engineer. An artist creates ON THE FLY. An engineer thinks first, designs, modifies, thinks some more, then finally, acts. The artisan in the meantime has produced two dozen devices, some of which are marketable, some of which may prove to be more than simple, costly ornaments, but most of which represent a waste of time and resources.
Bogdan wrote:
...dilema at bytes 510: do they have to be 0x55, 0xAA ? Or could it be 0xAA, 0x55?
Why must either value appear? What is the purpose of this "signature"? Who, or rather, WHAT is demanding to read this "signature"? Is this a cpu requirement? A motherboard demand? Does it come from the infamous BIOS? Is it part of atapi requirements? What role does this signature play?
The entire "boot" process appears to me, at least, both obscure, and obsolete. I simply wonder how many of these eccentricities are actually required, and how many are thought to be required, because of an underlying assumption about the operating system, or the storage medium, etc....
Hayden wrote:
The data at the start of a boot sector it usualy refered to as partition infomation. logicly speaking the partition comes before anything else on the disk medium.

What if the storage medium is memory itself, NOT a disk? I can envision a motherboard with a gig of flash memory....
Smile
Post 15 Apr 2007, 10:06
View user's profile Send private message Reply with quote
Hayden



Joined: 06 Oct 2005
Posts: 132
Hayden 15 Apr 2007, 17:30
BIOS scans the boot order for a medium that has the boot signature.
Flash storage devices have a partition defined for driver compatability.

The answers are in fatgen103.pdf
Post 15 Apr 2007, 17:30
View user's profile Send private message Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias 16 Apr 2007, 01:12
Hayden wrote:
The answers are in fatgen103.pdf
Google suggests that this is a M$ product, related to Fat32, but, no reference apparent at m$ web site:
http://www.microsoft.com/whdc/default.mspx
Hayden wrote:
Flash storage devices have a partition defined for driver compatability
Perhaps some do, I doubt if the manufacturer of the flash media creates such a partition, this is installed by the user, if desired. Memory is memory, we can do whatever we want to with it.....Point is, there is NO ABSOLUTE REQUIREMENT for flash or any other memory, to employ FAT32.
Hayden wrote:
BIOS scans the boot order for a medium that has the boot signature.
In other words, if I have understood correctly, the system would HANG, and not take the jump from BIOS to the "boot sector" if the "BOOT SECTOR" does not include these bytes at the end....???
That's not very clever BIOS, if so....
Post 16 Apr 2007, 01:12
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 16 Apr 2007, 01:46
The system will prompt an error or will start the ROM BASIC if present when no boot device has the signature. If the signature is present but the sector is not really executable then the result is unpredictable but in some moment it will end with an invalid opcode exception and will hang the computer.

About flash media like my pen drive writing an image of the MenuetOS works perfectly but if I write a sector which have only the signature and executable code the BIOS simply skips my pen drive and try the next device (hard disk). The reason of this is that I didn't include the BPB so the BIOS can't take parameters for floppy emulation.

And the reason for placing the structure after a JMP I think it's more for future expandability than programmers' preference. If for example you put the structure just before the signature, then there is no way to add more fields to the structure because it will overlap with the signature and will go out of the bounds of the sector. However, placing the structure just after the jump that skips it allows for future expansion. Yes, I know, you can still put the structure at the end and reserve a field that when is non-zero the meaning is the offset of the expansion having every expansion as a linked list but is a lot easier to have a single structure and pay the miserable latency the first jumps adds.
Post 16 Apr 2007, 01:46
View user's profile Send private message Reply with quote
Hayden



Joined: 06 Oct 2005
Posts: 132
Hayden 16 Apr 2007, 03:29
Nice post locoDelAssembly...

_________________
New User.. Hayden McKay.
Post 16 Apr 2007, 03:29
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2023, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.