OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Mar 29, 2024 3:26 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Weird int 0x13 behaviour in real environment
PostPosted: Tue Mar 05, 2019 2:01 pm 
Offline

Joined: Tue Mar 05, 2019 12:44 pm
Posts: 9
Hi, this is my first post, as I'm starting to make my own operating system. The Wiki part of this site already helped me a lot !
I'm still at the beginning of the project, stuck at the bootloader level.
This bootloader is very basic ; its final version will read sector 2 of the initial disk (a USB drive), place it in the RAM, go into 32-bit protected mode, and far jump to the memory where the 2nd sector was loaded.
The problem I'm facing only occurs on my real-life Toshiba Satellite Pro NB10-A, and I don't have any other real-life ressource to try my bootloader on.
Here is my current bootloader : It only loads sector 2 and print its first byte as an ascii character, without jumpping to it.
Code:
org 0x7c00
use16
jmp main
bootdrv:db 0
include "gdt.asm" ; global descriptor table
main:
   ; read "disk"
   ; dl already set
   mov ah, 0x02 ; Read Sector : stanislavs.org/helppc/int_13-2.html
   mov bx, 0 ; temporarily 0
   mov al, 1 ; read 1 sector
   mov ch, bl ; cylinder 0
   mov cl, 2 ; select sector 2 (reading sector 1 works correctly)
   mov dh, bl ; head 0
   mov es, bx ; buffer segment : 0
   mov bx, 0x9000 ; buffer address (es:bx) : 0*16 + 0x9000 = 0x09000
   int 0x13 ; interrupt call
   
   ; switching to 32-bit pm mode
   cli ; clear interrupts
   lgdt [gdt_descriptor] ; load gdt
   mov eax, cr0 ; real switch (setting flag)
   or eax, 0x1
   mov cr0, eax
   ; far jump (still in this 1st sector) :
   jmp CODE_SEGMENT:init_protected_mode
use32
init_protected_mode:
   mov ax, DATA_SEGMENT ; set all the segments (cs was set when far-jumping)
   mov ds, ax
   mov ss, ax
   mov es, ax
   mov fs, ax
   mov gs, ax
   
   mov edx, 0xb8000 ; set edx to the video memory (no more interrupts to print !)
   mov al, [0x9000] ; place in al the byte in 0x9000 (where the sector was loaded, should be "X")
   mov ah, 0xf0 ; character style : black on white (easily found in screen)
   mov [edx], ax ; setting the video memory (the change is seen in the top-left corner)
   
   jmp $ ; hang
times 510-($-$$) db 0 ; fill with zeros
dw 0xaa55 ; magic bytes to allow bootable drive
; second sector starts here
db "X"

Here is the source for gdt.asm (Global Descriptor Table)
Code:
gdt_start:
gdt_null_descriptor:
   dd 0, 0
gdt_code_descriptor:
   dw 0xffff, 0
   db 0, 10011010b, 11001111b, 0
gdt_data_descriptor:
   dw 0xffff, 0
   db 0, 10010010b, 11001111b, 0
gdt_end:

gdt_descriptor:
   dw gdt_end - gdt_start - 1
   dd gdt_start

CODE_SEGMENT equ gdt_code_descriptor - gdt_start
DATA_SEGMENT equ gdt_data_descriptor - gdt_start


Here is a description of the problem:
A. Loading in qemu-system-i386 :
This code works flawlessly : the "X" (black on white) is displayed in the top-left corner.
Image
B. Loading in my Toshiba :
The top-left corner shows an empty white box (null byte interpreted as ascii, shown as whitespace).
While debugging with a custom print function displaying hexadecimal, I realised that when reading sector 1, it works well (a "3" is displayed at the top left, ascii 51), but when reading sector 2, the buffer is full of zeros. The carry register indicates normal behaviour, and the number in "al", the number of sectors actually read, is 1 (correct). But, the buffer is actually full of zeros. I tried different addresses for the buffer, I checked a lot of registers, tried some solutions I found in the web. None solved the problem, but what's worse is that I don't understand where it could come from : I specified correct parameters of the interrupt 0x13,2, so why does the real environment won't let me access this sector ? Grub loads flawlessly on this device, so I'm the one missing something.
Also, This USB drive does not contain any partitionning system at this state of the project.
To compile my project :
real-life (z my USB drive) : ..\..\fasm\FASM.EXE ath_os.asm ath_os.bin && dd if=ath_os.bin of=\\.\z: bs=512 count=2
qemu : ..\..\fasm\FASM.EXE ath_os.asm ath_os.bin && "C:\Program Files (x86)\qemu\qemu-system-i386w.exe" -hda ath_os.bin
I also tried putting the .bin to my USB drive with rufus and with dd on linux.

I'm attaching the full code including disk_load, print, and debug functions.
Also I'm a beginner in assembly but I'll do my best to understand complex answers.


Attachments:
File comment: Screenshot of the "X" shown in Qemu
qemu_success.png
qemu_success.png [ 9.93 KiB | Viewed 2983 times ]
boot.zip [1.91 KiB]
Downloaded 16 times
Top
 Profile  
 
 Post subject: Re: Weird int 0x13 behaviour in real environment
PostPosted: Tue Mar 05, 2019 2:31 pm 
Offline

Joined: Tue Mar 05, 2019 12:44 pm
Posts: 9
The simplest program reproducing the error :
Code:
; reading "disk"
mov ah, 0x02
mov bx, 0
mov al, 1
mov ch, bl
mov cl, 2 ; sector
mov dh, bl
mov es, bx
mov bx, 0x9000
int 0x13

; printing the byte
mov ah, 0x0e
mov al, [0x9000]
int 0x10

jmp $ ; hang

times 510-($-$$) db 0
dw 0xaa55 ; magic bytes
; sector 2 :
db "X"

Same problem, shorter & simpler code.


Top
 Profile  
 
 Post subject: Re: Weird int 0x13 behaviour in real environment
PostPosted: Tue Mar 05, 2019 4:32 pm 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 934
Location: USA
After a quick look-over, I didn't see anything in error, however, being you are reading from a USB thumb drive using the firmware's emulation, this gives me the idea that this is the problem.

Depending on the firmware's emulation, CHS address of 2 (C = 0, H = 0, S = 2) may not be LBA 1 as you might think it is. Some BIOS' start at a given partition address range, others start at LBA 0.

Are you sure that LBA 1 (the second physical sector of the device) actually has something other than zeros in it? I am not familiar with DD so I can't tell you if your writing to the USB drive is correct.

However, I would be looking at how you are writing the second sector to the USB device to make sure it actually is the second sector.

There are many problems with BIOSes and their emulation of USB boot devices... Some will only emulate a hard drive, some will only emulate partitions on that device as hard drive(s), some will think it is a floppy and emulate as a floppy, some with think it is a hard drive even though you have specified floppy. Others will read the first sector and expect a valid (FAT) BPB and use that as the parameters.

For example, if you do not have a BPB at LBA 0, but the firmware read it as one anyway, it might have read that there is only one sector per track and has now moved to the second track of the device (i.e.: move so many sectors from LBA 0) to read that second sector. i.e.: Let's say that the read data from the first part of the first sector has the follow:
Code:
BPB:HEADS = 14
BPB:SPT = 1
even though you don't have a valid BPB there, it might have read that as so. Now, since it thinks that there are 14 heads, but only 1 sector per track, there actually isn't a CHS of address of 0/0/2, since there is only 1 sector per track. It will also think that the very next sector (LBA 1) is actually 14 sectors away, depending on whether you are the 'writer' or the 'reader'.

If you continue to use a USB device as your booting (test) device, I strongly suggest using a valid (FAT) BPB whether you have a FAT formatted device or not.

In my research, I have found that to be sure your USB device will boot on the most firmware emulation possible, have a small amount of sectors reserved at the beginning of your USB device for a valid BPB and MBR that simply loads another sector (starting at LBA 1 if you want) and jumps to it. Then place your boot code at that LBA. The BPB at LBA 0 specifies the type of disk you want emulated.

Ben
- http://www.fysnet.net/osdesign_book_series.htm


Top
 Profile  
 
 Post subject: Re: Weird int 0x13 behaviour in real environment
PostPosted: Tue Mar 05, 2019 4:42 pm 
Offline

Joined: Tue Mar 05, 2019 12:44 pm
Posts: 9
Thanks a lot for your time, I will try a valid BPB tomorrow :D


Top
 Profile  
 
 Post subject: Re: Weird int 0x13 behaviour in real environment
PostPosted: Tue Mar 05, 2019 7:16 pm 
Offline
Member
Member

Joined: Fri Aug 26, 2016 1:41 pm
Posts: 671
Ben these days, the lack of a BPB is a problem on a lot of firmware booting USB as FDD (and specifically FDD) because many BIOSes blindly write the USB's drive geometry into the BPB area (after reading the boot sector to 0x07c00) prior to transferring control to physical address 0x07c00. If you don't at least have the space reserved for the BPB you end up having these BIOSes overwrite code and data near the beginning of the bootloader. This has actually been a recurring theme in Stackoverflow questions for nearly 2 years. I even wrote about the problem in this Stackoverflow Answer (which has more or less become the canonical response on SO)


Top
 Profile  
 
 Post subject: Re: Weird int 0x13 behaviour in real environment
PostPosted: Tue Mar 05, 2019 8:47 pm 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 934
Location: USA
Without sounding rude, that's pretty much what I said, but in a different way :-)

Anyway, for the OP, it most likely is not your code, but more likely the emulated disk read service. Place a valid BPB at LBA 0 and you should be fine.

If you don't want a FAT file system, that's fine, start at LBA 1 with whatever file system you want and let LBA 0 jump to it via a standard MBR.

Ben
- http://www.fysnet.net/osdesign_book_series.htm


Top
 Profile  
 
 Post subject: Re: Weird int 0x13 behaviour in real environment
PostPosted: Tue Mar 05, 2019 8:54 pm 
Offline
Member
Member

Joined: Fri Aug 26, 2016 1:41 pm
Posts: 671
Your comment was more about drive geometry values in the BPB (for a case where none exists) and having subsequent disk reads fail. What I was suggesting can affect code whether it is related to disk reads or something else -as long as that code falls in the area that a BPB may occupy and especially where the drive geometry related fields sit. You could have your bootloader simply using BIOS routines to print a string to the display and have that fail when run as USB with FDD emulation.


Top
 Profile  
 
 Post subject: Re: Weird int 0x13 behaviour in real environment
PostPosted: Tue Mar 05, 2019 9:03 pm 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 934
Location: USA
MichaelPetch wrote:
Your comment was more about drive geometry values in the BPB (for a case where none exists) and having subsequent disk reads fail. What I was suggesting can affect code whether it is related to disk reads or something else -as long as that code falls in the area that a BPB may occupy and especially where the drive geometry related fields sit. You could have your bootloader simply using BIOS routines to print a string to the display and have that fail when run as USB with FDD emulation.

Absolutely, you are correct. I did fail to mention that.

Either way, I am guessing this will fix the problem the OP is having.

Thanks,
Ben
- http://www.fysnet.net/osdesign_book_series.htm


Top
 Profile  
 
 Post subject: Re: Weird int 0x13 behaviour in real environment
PostPosted: Wed Mar 06, 2019 6:53 am 
Offline

Joined: Tue Mar 05, 2019 12:44 pm
Posts: 9
Hello everyone,
I found various examples of BPBs online and I ended up uploading this to my USB drive:
Code:
org 0x7c00
jmp start
times 3-($-$$) db 0x90

bpbOEM                  DB "Kap.OS  "
bpbBytesPerSector:      DW 512
bpbSectorsPerCluster:   DB 1
bpbReservedSectors:     DW 1
bpbNumberOfFATs:        DB 2
bpbRootEntries:         DW 224
bpbTotalSectors:        DW 2880
bpbMedia:               DB 0xF0
bpbSectorsPerFAT:       DW 9
bpbSectorsPerTrack:     DW 18
bpbHeadsPerCylinder:    DW 2
bpbHiddenSectors:       DD 0
bpbTotalSectorsBig:     DD 0
bsDriveNumber:          DB 0
bsUnused:               DB 0
bsExtBootSignature:     DB 0x29
bsSerialNumber:         DD "srno"
bsVolumeLabel:          DB "NO NAME    "
bsFileSystem:           DB "FAT12   "

start:
   xor  ax, ax
   int  0x13
   
   mov ah, 0x02
   mov bx, 0
   mov al, 1
   mov ch, bl
   mov cl, 2 ; sector
   mov dh, bl
   mov es, bx
   mov bx, 0x9000
   int 0x13

   mov ah, 0x0e
   mov al, [0x9000]
   int 0x10

   jmp $

times 510-($-$$) db 0
dw 0xaa55
; sector 2 :
db "X"


I see no change... Before I try to put an MBR, I would like to understand, how is an MBR different from this apart from the partition table ? If the same code is executed, why does it matter ?
Also, Yes I'm sure the sector 2 is written correctly to the USB drive because I dumped it with dd and inspected it : the "X" is there as expected.
One thing I'm starting to imagine is that the drive label specified to DD might be a... partition ? even if Windows tells me that it's taking the space of the whole USB drive, it might be wrong... I'll try uploading the code on linux again, with the BPB this time.


Top
 Profile  
 
 Post subject: Re: Weird int 0x13 behaviour in real environment
PostPosted: Wed Mar 06, 2019 7:44 am 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 934
Location: USA
As for DD and Windows, again, I have not used DD so cannot be sure, but Windows usually does deal with partitions than with devices, unless you develop DD to use devices.

As for why a BPB and a MBR? In theory, you can do whatever you wish. Have your code just as you show with a "dummy" BPB and go from there. However, a MBR is the traditional first sector of a media device and you have now noticed what happens when you don't use traditional techniques, i.e.: the traditional BPB.

It is traditional to use a MBR at LBA 0 that has a single partition entry that points to either an extended partition table or a single partition at LBA 63.

However, to bypass the issues I and MichealPetch (more clearly) explained, you need to have a BPB at LBA 0 on a USB bootable device. Some file systems will allow this by simply skipping the number of bytes needed for the BPB. Some will not. For example, the Ext2 filesystem only allows a single block (usually 1024 bytes) before the super block. This 1024-byte block is valuable real estate when a bootable Ext2 is needed (not mentioning GRUB or other boot techniques).

Personally, I don't want to "have to" put the BPB in my boot code just because someone else was too lazy to create a decent emulation of the device in the first place. Therefore, I use a specific 512-byte un-traditional MBR with a BPB all pointing to LBA 1 for the start of the bootable partition. This 512-byte MBR/BPB can be exactly the same for any USB bootable device and installed file system. Simply binary write it to LBA 0 and then my boot partition to LBA 1. Period.

Just my opinion,

Ben
- http://www.fysnet.net/osdesign_book_series.htm


Top
 Profile  
 
 Post subject: Re: Weird int 0x13 behaviour in real environment
PostPosted: Wed Mar 06, 2019 8:26 am 
Offline
Member
Member

Joined: Fri Aug 26, 2016 1:41 pm
Posts: 671
On Windows your DD is likely not writing to the first sector of the drive when you use the option of=\\.\z:. This is likely writing to the first sector of the partition Z: resides on. Get the latest version of Chrysocome DD for Windows and use the od= opttion where you simply specify the drive letter for the USB (ie od=z:).You must have administrator privileges. I have written more about the issue of Windows and using DD in this Stackoverflow answer (see the second section of the answer).If using DD with administrator privileges you keep getting an access denied error you will want to clean the volume using these instructions.


Top
 Profile  
 
 Post subject: Re: Weird int 0x13 behaviour in real environment
PostPosted: Wed Mar 06, 2019 8:52 am 
Offline

Joined: Tue Mar 05, 2019 12:44 pm
Posts: 9
I just checked, and this is still not solved by uploading through Linux -> dd.
I'm using Chrysocome's DD already :D
I also tried on another laptop, an Asus EEE-PC 900A, and it produces the same behaviour...
An MBR would try to read the disk the same way, I guess just adding a partition table from byte 446 wouldn't solve the problem...
Current things tried:
- Sectors successfully uploaded to the 1st sectors of the USB drive [Done]
- Putting a BPB at the beginning (byte 3 -> ...) [Done]
- Test on another laptop [Done, same result]
- MBR [don't see why it wouldn't produce the same result]

But now that I use DD with the "od" option, my toshiba laptop seems to ignore the drive, as if it was not bootable xD


Top
 Profile  
 
 Post subject: Re: Weird int 0x13 behaviour in real environment
PostPosted: Wed Mar 06, 2019 9:05 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5103
AlfredTH wrote:
But now that I use DD with the "od" option, my toshiba laptop seems to ignore the drive, as if it was not bootable xD

One UEFI CSM (InsydeH2O?) is particularly bad and will only boot USB drives with a valid MBR and partition table. Sounds like whatever you're using now isn't valid.


Top
 Profile  
 
 Post subject: Re: Weird int 0x13 behaviour in real environment
PostPosted: Wed Mar 06, 2019 9:27 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
I try to get this out to all new members, to get everyone started on the same footing. I hope this helps. I usually send it by PM, but I try to post it to a thread periodically so that anyone who doesn't check their PMs might see it anyway.
----------------------------------

The first thing I want to say is this: if you aren't already using version control for all software projects you are working on, drop everything and start to do that now. Set up a VCS such as Git, Subversion, Mercurial, Bazaar, or what have you - which you use is less important than the fact that you need to use it. Similarly, setting up your repos on an offsite host such as Gitlab, Github, Sourceforge, CloudForge, or BitBucket should be the very first thing you do whenever you start a new project, no matter how large or small it is.

If nothing else, it makes it easy to share your code with us on the forum, as you can just post a link, rather than pasting oodles and oodles of code into a post.

Once you have that out of the way (if you didn't already), you can start to consider the OS specific issues.

If you haven't already, I would strongly advise you to read the introductory material in the wiki:


After this, go through the material on the practical aspects of
running an OS-dev project:

I strongly suggest that you read through these pages in detail, along with the appropriate ones to follow, before doing any actual development. These pages should ensure that you have at least the basic groundwork for learning about OS dev covered.

This brings you to your first big decision: which platform, or platforms, to target. Commonly options include:
  • x86 - the CPU architecture of the stock PC desktops and laptops, and the system which remains the 'default' for OS dev on this group. However, it is notoriously quirky, especially regarding Memory Segmentation, and the sharp divisions between 16-bit Real Mode, 16-bit and 32-bit Protected Modes, and 64-bit Long Mode.
  • ARM - a RISC architecture widely used on mobile devices and for 'Internet of Things' and 'Maker' equipment, including the popular Raspberry Pi and Beagleboard single board computers. While it is generally seen as easier to work with that x86, most notably in the much less severe differences in between the 32-bit and 64-bit modes and the lack of memory segmentation, the wiki and other resources don't cover it nearly as well (though this is changing over time as it becomes more commonly targeted).
  • MIPS, another RISC design which is slightly older than ARM. It is one of the first RISC design to come out, being part of the reason the idea caught on, and is even simpler than ARM in terms of programming, though a bit tedious when it comes to assembly programming. While it was widely used in workstations and game consoles in the 1990s, it has declined significantly due to mismanagement by the owners of the design, and is mostly seen in devices such as routers. There are a handful of System on Chip single-board computers that use it, such as the Creator Board and the Onion Omega2, and manufacturers in both China and Russia have licensed the ISA with the idea of breaking their dependence on Intel. Finding good information on the instruction set is easy, as it is widely used in courses on assembly language and computer architecture and there are several emulators that run MIPS code, but finding usable information on the actual hardware systems using it is often difficult at best.
  • RISC-V is an up and coming open source hardware ISA, but so far is Not Ready For Prime Time. This may change in the next few years, though.

You then need to decide which Language to use for the kernel. For most OS-Developers this means knowing and using C; while other languages can be used, it is important to know how to read C code, even if you don't use C, as most OS examples are written in it. You will also need to know at least some assembly language for the target platform, as there are always parts of the kernel and the device drivers which cannot be done in high-level languages.

You further need to choose the compiler, assembler, linker, build tool, and support utilities to use - what is called the 'toolchain' for your OS. For most platforms, there aren't many to choose from, and the obvious choice would be GCC and the Binutils toolchain due to their ubiquity. However, on the Intel x86 platform, it isn't as simple, as there are several other toolchains which are in widespread use for it, the most notable being the Microsoft one - a very familiar one to Windows programmers, but one which presents problems in OSDev. The biggest issue with Visual Studio, and with proprietary toolchains in general, is that using it rules out the possibility of your OS being "self-hosting" - that is to say, being able to develop your OS in the OS itself, something most OSdevs do want to eventually be able to do. The fact that Porting GCC to your OS is feasible, whereas porting proprietary x86 toolchains isn't, is a big factor in the use Binutils and GCC, as it their deep connection to Linux and other Unix derivatives.

Regardless of the high-level language you use for OS dev (if any), you will still need to use assembly language, which means choosing an assembler. If you are using Binutils and GCC, the obvious choice would be GAS, but for x86 especially, there are other assemblers which many OSdevs prefer, such as Netwide Assembler (NASM) and Flat Assembler (FASM).

The important thing here is that assembly language syntax varies more among the x86 assemblers than it does for most other platforms, with the biggest difference being that between the Intel syntax used in the majority of x86 assemblers, and the AT&T syntax used in GAS. You can see an overview of the differences on the somewhat misnamed wiki page Opcode syntax. While it is possible to coax GAS to use the Intel syntax using the .intel_syntax noprefix directive, the opposite is generally not true for Intel-based assemblers such as NASM, and even with that directive, GAS is still quite different from other x86 assemblers in other regards.

It is still important to understand that the various Intel syntax assemblers - NASM, FASM, and YASM among others - have differences in how they handle indexing, in the directives they use, and in their support for features such as macros and defining data structures. While most of these follow the general syntax of Microsoft Assembler (MASM), they all diverge from it in various ways.

Once you know which platform you are targeting, and the toolchain you want to use, you need to understand them. You should read up on the core technologies for the platform. Assuming that you are targeting the PC architecture, this would include:

This leads to the next big decision: which Bootloader to use. There are a number of different standard bootloaders for x86, with the most prominent being GRUB. We strong recommend against Rolling Your Own Bootloader, but it is an option as well.

You need to consider what kind of File System to use. Common ones used when starting out in OS dev include:

We generally don't recommend designing your own, but as with boot loaders, it is a possibility as well.

While this is a lot of reading, it simply reflects the due diligence that any OS-devver needs to go through in order to get anywhere. OS development, even as a simple project, is not amenable to the Stack Overflow cut-and-paste model of software development; you really need to understand a fair amount of the concepts and principles before writing any code, and the examples given in tutorials and forum posts generally are exactly that. Copying an existing code snippet without at least a basic idea of what it is doing simply won't do. While learning itself is an iterative process - you learn one thing, try it out, see what worked and what didn't, read some more, etc. - in this case a basic foundation is needed at the start. Without a solid understanding of at least some of the core ideas before starting, you simply can't get very far in OS dev.

Hopefully, this won't scare you off; it isn't nearly as bad as it sounds. It just takes a lot of patience and a bit of effort, a little at a time.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Weird int 0x13 behaviour in real environment
PostPosted: Wed Mar 06, 2019 9:38 am 
Offline
Member
Member

Joined: Fri Aug 26, 2016 1:41 pm
Posts: 671
It all depends on how your BIOS is booting USB media.If it is using HDD emulation then you'd almost certainly need a partition table. I'd be curious what happens if you take this exact file and assemble it and use DD with the od=z: to write it to the first sector. This is a simple bootloader with a partition table but the active partition is one that starts at the first sector of the drive (LBA=0, CHS=0,0,1). I'm curious if prints 'Hello,world!' or not?
Code:
bits 16
org 0x7c00

boot_start:
    xor ax, ax                  ; DS=0 since we use ORG 0x7c00. 0x0000<<4+0x7c00=0x7c00
    mov ds, ax
    mov es, ax

    ; If you will be reading data into memory outside of 0x7c00 to 0x7dff
    ; then you want to set the stack SS:SP - uncomment these lines
    ; mov ss, ax                ; Stack at 0x0000:0x7c00
    ; mov sp, 0x7c00            ;     Just below bootloader

    cld                         ; Forward movement of string instructions
                                ;     (MOVSB, SCASB, etc)

    mov si, HelloWorldMsg       ; Print hello world
    call print_string

end_loop:                       ; Loop forever to terminate
    hlt
    jmp end_loop

; Function: print_string
;           Display a string to the console on display page 0
;
; Inputs:   SI = Offset of address to print
; Clobbers: AX, BX, SI

print_string:
    mov ah, 0x0e                ; BIOS tty Print
    xor bx, bx                  ; Set display page to 0 (BL)
    jmp .getch
.repeat:
    int 0x10                    ; print character
.getch:
    lodsb                       ; Get character from string
    test al,al                  ; Have we reached end of string?
    jnz .repeat                 ;     if not process next character
.end:
    ret

HelloWorldMsg:   db "Hello, world!", 0x0d, 0x0a, 0

times 446-($-$$) db 0   ; Pad with 0s up until first partition entry
part1_entry:
db 0x80                 ; 0x80 = Active boot partition, 0x00=inactive
db 0x00, 0x01, 0x00     ; CHS of first absolute sector (MBR) of hard drive
                        ;     Head=0, Sector=1, Cylinder=0
db 0x0c                 ; Partition type (has to be non-zero)
                        ;     0x0c = Win 95 FAT32 (LBA)
db 0x00, 0x01, 0x00     ; CHS of last absolute sector (MBR) of hard drive
                        ;     Head=0, Sector=1, Cylinder=0
                        ;     We are effectively saying Size of partition is 1 sector
dd 0x0                  ; LBA of first absolute sector (0=MBR)
dd 0x1                  ; Number of sectors in partition. We set it to 1 but if you
                        ;     wish you could set it to the number of sectors on the disk

times 510-($-$$) db 0   ; Pad remainder of boot sector up to boot signature. This zeroes
                        ;     partition entries 2,3,4 effectively making them inactive

dw 0xAA55               ; The standard PC boot signature after partition table


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], Google [Bot], Majestic-12 [Bot] and 153 guests


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 post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group