I am new to x86 assembly but been a programmer for nearly 34 years. I am writing a 16 bit OS and everything is working ok to a degree. The program is split into a Bootloader and Kernel Binaries which then joined into a single image file. When running the program through QEMU the Bootloader runs and loads at 0x7c00 fine and displays messages on the screen and successfully loads the Kernel into 0x7e00 and successfully starts the process which clears the screen and sets the cursor in the top left of the screen. However when it then goes to display messages to the screen it fails. When objdumping the Kernel Binary I can see that the binary is set to load the first byte into the SI register at the correct address however nothing happens. Adjusting the address it turns out that the address is being offset by 230-255 bytes after the correct position. I have set all of the segment registers to zero and still makes no difference. Does anyone have any ideas on the cause and fix and if there is anyway of debugging a raw binary file through QEMU. Every link i have looked at only shows how to debug an ELF file through GDB linking into QEMU via a TCP Port.
Asked
Active
Viewed 391 times
1
-
Can you show us the code for your kernel and how you link the kernel to a binary? For debugging I'd recommend BOCHS since it has a proper 16-bit real mode debugger. Debugging 16-bit real mode code is actually very difficult since GDB doesn't understand real mode segment:offset addressing – Michael Petch Oct 20 '20 at 17:16
-
The code is too big to upload so i have disassembled the Binary and extracted out the lines where it fails. Im not sure what you mean by linking the Kernal to the Binary 7e26: be c5 7e mov si,0x7ec5 mov si,Heading1 Heading1 7ec5: 20 62 61 and BYTE PTR [bp+si+0x61],ah – Lee Bardoe Oct 20 '20 at 23:56
-
https://pastebin.com/Az7W2VVW – Lee Bardoe Oct 21 '20 at 11:37
-
I have uploaded my code for the kernal. As i said it works right up until the call println and it prints a load of A's rather than the text in the Heading1 memory location which on the disassembled code says its at address 7ec2. – Lee Bardoe Oct 21 '20 at 11:39
-
I took your kernel file and assembled it. I have a [bootloader on Stackoverflow](https://stackoverflow.com/a/54894586/3857942) that I used to load it to 0x7e00 in memory. The program works properly and I don't see anything wrong in the code you put in pastebin which suggests to me that maybe in your bootloader you haven't loaded the kernel to the right ES:BX location in memory or you jumped to your kernel incorrectly. Can you pastebin your bootloader as well? – Michael Petch Oct 21 '20 at 12:03
-
I will send that over later. On a side note though if it was being loaded to the wrong ES:BX location woukd it not have completely failed. It clears the screen and sets the cursor pisition ok which woukd state that the bootloader has called the correct location. Sorry if thats comes across as a bit of a dumb statement but i am new to asm so still learning. Thanks – Lee Bardoe Oct 21 '20 at 13:40
-
https://pastebin.com/UqPbmM3Y Added the boot loader code – Lee Bardoe Oct 21 '20 at 15:19
-
I will look at the bootloader in the next half hour. As for the loading with Int 13h - if you specify the wrong ES:BX and it happens to be later in memory than it should be - the empty space not written to contains 0x00 in all the bytes. That will translate into a valid instructions that won't crash the CPU in real mode but doesn't do anything particularly useful. It will execute the 0x00 bytes until it encounters the real code. – Michael Petch Oct 21 '20 at 15:56
-
I didn't run the bootloader but I think I see the problem. You define `kernel_start` as `kernal_start dw 0x7e00` and you do `mov bx, kernal_start` to do the diskread. The problem is that `mov bx, kernal_start` moves the address where the 0x7e00 is stored in memory (not what is at that address)! And then you do `jmp kernal_start` which jumps to the memory address where 0x7e00 is stored. To fix all this I think you meant to do `kernal_start equ 0x7e00` instead of `kernel_start dw 0x7e00` – Michael Petch Oct 21 '20 at 16:04
-
Thanks i wil givt a try and let you know. – Lee Bardoe Oct 21 '20 at 16:54
-
1Hi Michael just wanted to say i made the change and it did indeed fix the issue. Thanks very much – Lee Bardoe Oct 22 '20 at 05:43