0

I have a very simple program that I've written using FASM that attempts to simply print out a string from inside the boot sector of an emulated x86 chip via qemu. I am attempting to print out a basic startup string. I can get the emulator to boot from the virtual hard disk and print out individual characters if I specify them by hand by moving a specific ascii value into the al register, but it will not execute passed a db or dw command. Here is the current code I have:

mov ah,0x0e ;int 10/ah = 0eh -> scrolling teletype BIOS routine

prepare db "Preparing to Launch..."

lea ebx,[prepare]

print1:
mov al, [ebx]
int 0x10
inc cl

cmp cl, 22
jle print1

times 510 -( $ - $$ ) db 0 ;Pad the boot sector out with zeros
dw 0xaa55

The code appears to be compiling perfectly fine, as when I look at the hex values of the harddisk, it places the 0xaa55 in the proper location. Furthermore, if I place a simple interrupt statement around the db command, so that it looks like this:

mov al, 76
int 0x10

prepare db "Preparing to Launch..."

mov al, 76
int 0x10 

the second interrupt will never be executed. I have tried moving the prepare db "Preparing to Launch..." line throughout the code, in which case it will compile without fail, but will print a series of 19 capital S's as opposed to the actual string.

To simplify, the output I'm getting if prepare db "Preparing..." is near the top of my code looks like this:

Booting from Hard Disk...

If that line of code is at the bottom, then it looks like this:

Booting from Hard Disk...
SSSSSSSSSSSSSSSSSSSSSS

But I want it to look like this:

Booting from Hard Disk...
Preparing to Launch...
Off Beat
  • 25
  • 5
  • 1
    If the `db` string is in the path of execution then it will be interpreted as instructions and executed, and they will surely not do what you want. The CPU just sees bytes, it doesn't know that you didn't mean them as instructions. Put the string somewhere else, or jump over it. – Nate Eldredge Jan 21 '21 at 17:09
  • Do you know why it would be outputting exclusively S's rather than the supplied string in the case that I have the `db` at the very bottom of the code? Am I perhaps not referring to the proper value when loading the value into `ebx` or something along those lines? – Off Beat Jan 21 '21 at 17:25
  • 1
    You'd have to show us the actual code that has that behavior. If it's literally at the very bottom then the string is past the first 512 bytes and so is not getting loaded into memory. – Nate Eldredge Jan 21 '21 at 17:25
  • Also, you're not incrementing `ebx` in your loop, so in any case you will print the same character 22 times. – Nate Eldredge Jan 21 '21 at 17:33
  • Single-step your code in a debugger (e.g. the one built-in to BOCHS). That will let you see exactly what's happening when your ASCII bytes get decoded as machine code. – Peter Cordes Jan 21 '21 at 18:09
  • Also also, you seem to be assuming that `cl` will be zero when your code starts, but that is not guaranteed. You need to initialize `bh` and `bl` for the `int 0x10` call as well, see http://www.ctyme.com/intr/rb-0106.htm. – Nate Eldredge Jan 21 '21 at 18:14
  • And your code seems to be missing an ORG, so the assembler won't know the correct address where it is to be loaded, which means the `lea ebx, [prepare]` won't get the correct address. Anyway, the boot sector runs in 16-bit mode so using 32-bit addresses is rather pointless. Basically there seem to be many different problems with this code. – Nate Eldredge Jan 21 '21 at 18:21
  • I believe the misplacement of the `db` directive was the cause for my original issue. I'm now facing an issue with it not printing out the characters located at the specified address (0x1b in the case of the `P` of "Preparing"), and instead printing out a seemingly unrelated value, but ultimately this seems like a different question entirely. Thank you. – Off Beat Jan 21 '21 at 23:52

0 Answers0