OSDev.org

Posted: **Sat May 07, 2016 7:14 pm**

i went out and inspected and eliminated last few bugs. I was copying 200h sectors instead of 1 sector that messed up. After that, the section of the code that prints out the first few bytes at 8000h (jump address) were printing correctly. That means sector 1 copied right. The initial code there will also spit out few bytes (because I virtually copied and pasted it from boot.asm) but it is not printing. That means jump has gone astray.

I went out and tried qemu on my workstation but the linux resolution is horrible at 320x200. Tried with centos and fedora they all suck. The display and screen module utilities: xorg, xrandr and cvt all failed to work, I hate them and had bad memory in the past too. Must be written by real incompetent smart*sses. User forum has lot of hit and miss Q&A mostly on guesswork nothing sound. Classic problem with the open-source where any one chip-in and do whatever they want. Anyways I decided not to go that route dealing with something that never works for hours.

I am gonna have to find something else.

And done for today too, next big thing is to get the jump thing working and will have a largely working bootloader.

Posted: **Sat May 07, 2016 7:20 pm**

SpyderTL wrote:You might want to try booting from a floppy image, first. The only real structure that you absolutely need is to set the last two bytes of the first sector to 0x55 and 0xaa.

Then, once you have that working, move on to a HDD image.

i decided to do with HDD since eventually it will not fit into FDD. I did not want to do that transition later. Well, on last update, at least HDD works with Vbox now.

Posted: **Sat May 07, 2016 11:48 pm**

ok, big update, it turns out vbox has very nice full-fledged debug support including single step, register dump/mod:
just start as:
virtualbox --start vm <vmname> --debug and console is available in the vm entry.
In short it turns out it was not jumping to 8000h address, instead it jumped 20:200. Looks like label was interpreted not as an absolute address rather it is relative from the code segment:

Following is a unassembly output from oracle vbox:

Code: Select all

: 0000:00007cc3 66 ea 00 02 00 00 20 00 jmp far 00020h:000000200h
0000:00007ccb 00 00                   add byte [bx+si], al
0000:00007ccd 00 00                   add byte [bx+si], al
0000:00007ccf 00 00                   add byte [bx+si], al
0000:00007cd1 00 00                   add byte [bx+si], al
0000:00007cd3 00 00                   add byte [bx+si], al
0000:00007cd5 00 00                   add byte [bx+si], al
0000:00007cd7 00 00                   add byte [bx+si], al
0000:00007cd9 00 00                   add byte [bx+si], al
0000:00007cdb 00 00                   add byte [bx+si], al
VBoxDbg> t
VBoxDbg> 
dbgf event: Single step! (rem)
eax=00000e45 ebx=00000080 ecx=00000000 edx=00000080 esi=00008010 edi=000000e0
eip=00000200 esp=00000020 ebp=00000000 iopl=0 nv up ei ng nz ac pe nc
cs=0020 ds=0000 es=b800 fs=0000 gs=0000 ss=001c               eflags=00000292
0020:00000200 00 00                   add byte [bx+si], al
VBoxDbg>

Since the compiler was having me jump through a lot of red-tape regarding jump instruction what not and what can be compiled, i just did following to do a absolute jump to 8000h

Code: Select all

    db      0eah, 00h, 80h, 00h, 00h

OSDev.org

bootloader does not seem to work

Re: bootloader does not seem to work

Re: bootloader does not seem to work

Re: bootloader does not seem to work