section directives: beginner vs bootloader

[lord_raven]

How come in tutorials they show these section directives but then in boot loaders they are missing?? Is it because they cause extra bytes of code to be in the .asm? I noticed in my bootloader that when I have both the section .text and the section .data in file, the bytes are 560 in the sector and fail. When I use just one then its 532 in bytes and when I remove them it is at 512. Would this be an appropriate assumption?

[Frank Kotler]

Hi lord_raven,

Welcome to the forum.

The BIOS will load 512 bytes - period.

in "-f bin" output format will put "section .data" after "section .text". It shouldn't add anything. Perhaps some alignment (?). I would not use it.

We don't know what tutorials or what you've done that failed... (unless you tell us)

Best,
Frank

[lord_raven]

Hi thanks for answering. The site I was looking through was https://www.tutorialspoint.com/assembly_programming/assembly_basic_syntax.htm
I was mainly just interested in the layout of nasm coding. So it is perfectly fine not writing or just omitting section .text, section .data in every .asm
file?

[debs3759]

If all you code after assembly takes up less than one segment (65536 bytes) then you can leave out the section directives for the .bin file format (ie a boot sector, sys file or .com file). Make sure you jump over any data in your code, or put the data after all the programming code.

If you need to see a sample boot sector that is tested and works, mine is at https://forum.nasm.us/index.php?topic=2265.0 and is fully commented. The code I shared is for FAT12, so mainly targets floppy drives, but will show you the basics. It relocates itself in memory, then loads and displays a text file, which can be anywhere on the drive and can be fragmented. Loading a first stage loader and jumping to it should be much easier easier. I hope to get back into programming in the new year, and will update it to load a first stage file to set up PM etc, as well as creating FAT16 and FAT32 version, which I will share here. They should be much less complicated

I'm looking at creating a very basic OS with real mode version for 286 and earlier systems, and a protected mode for 386 and later. Just because I'm trying to fill my time (I'm housebound, and have too much time that I pass on ebay)

[lord_raven]

Thank you for replying!!! I thought so when it came to the section .data, section .text.  I figured once you were experienced enough you would know when to omit parts like that. I have seen a lot of code without the sections part so I had to ask lol. Thought i was misunderstanding something.

As far as the bootloader, I have a question on that process.

I am following the http://www.brokenthorn.com/Resources/OSDevIndex.html tutorial, using virtualbox, and ubuntu as a subsystem. The tools they use in that tutorial are outdated and I am having trouble understanding the connection between our files, the tools, and virtualbox.

The problem that I am having is the second stage isn't loading up properly. It shows in virtualbox that the first stage is loaded up but the second file isn't. So I want to get some clarification on how the process works.


I understand that in our first stage boot.asm we are limited to 512, which gets written into the first sector of a floppy image disk.img.

Code: [Select]


 bash -c "nasm -f bin boot.asm -o boot.bin"
 bash -c "dd if=boot.bin of=disk.img conv=notrunc"

I understand that because we are limited, we need to use that limited space in the first sector, to call the second stage KRNLDR.SYS.  In boot.asm we wrote the functions/routines for a fat12 file system and KRNLDR.SYS is the fat12 filename that we are trying to get or need to call.

Code: [Select]

 
  bash -c "nasm -f bin Stage2.asm -o KRNLDR.SYS"
  copy KRNLDR.SYS  A:\KRNLDR.SYS


Code: [Select]

my first question: If we mount the disk.img with imdisk.

     imdisk -a -f disk.img -s 1440K -m A:

Once we run this new drive, does it becomes our fat12 directory?
meaning that we created a drive, mounted the disk.img to it, and now
the memory that we allocated for this drive is the memory being used
for our fat12?

If so then after the drive is created, we now have our created file system that
we  can copy KRNLDR.SYS into? finally putting us in the position to get the fat12 file at runtime by stage one?

I feel like that seems right and would take care of my second stage problem.

Code: [Select]

The second question: Since we have mounted the disk.img onto the drive.
How does virtualbox also connect to that same disk.img file being used
by the drive? We can not use drives as a booting format in virtualbox,
only .img, .flp, .iso file types. So do we have to create a batch that
allows virtualbox to run the disk.img first, takes the first stage
steps, transfer ownership or connects the image to the drive some how,
so that we can finally have a file system to call the second stage from.
I feel like I am really over thinking this step.

The batch file I have so far:

Code: [Select]


    bash -c "nasm -f bin boot.asm -o boot.bin"
    bash -c "dd if=boot.bin of=disk.img conv=notrunc"

    imdisk -a -f disk.img -s 1440K -m A:

    bash -c "nasm -f bin Stage2.asm -o KRNLDR.SYS"
    copy KRNLDR.SYS  A:\KRNLDR.SYS

When I was using a single boot, it was no problem, to just use the disk.img straight from the directory that it was created  from and not mounting a drive. but now, based off if question is true, then the drive is required for a two step boot loading process to work properly. Any help would be much appreciated!!!

[debs3759]

I'm not sure whether I understand the question. Your boot sector has to be written to the boot (first) sector of the drive you are booting from (ie Track 0 Sector 0). It doesn't matter what extension your assembled file has, as only the contents of the file are written to the drive. The boot code can span more than one sector, but the BIOS will only load the first sector, so that has to include code to load the rest of your code.