Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
computertrick wrote:Its on a USB stick and after I wrote to the USB with linux using dd command I then read from it again and the first sector is boot loader and second sector is kernel and the boot loader runs fine
Are you now saying that you've solved the problem? If not, you need to find out if your code is running at all when you attempt to boot it on real hardware. Once you've established that it is, it's then worth going to the trouble of writing more code to try to debug the problem, such as checking to see if the second sector is already there before you load it (which could happen if the sector size is bigger than 512 bytes), and then you could write a byte to the location where the second sector is to be loaded and then check it again after loading that sector to see if anything has been loaded on top of it, etc. There are all sorts of things you can do to debug your problem (assuming that you haven't already fixed it), but you should follow the easiest path to do so, and that means doing it in the right order so that you aren't wasting hours trying to fix a problem further down the track from an unrecognised earlier problem which may be rendering all your other experiments pointless.
Yes the boot loader runs fine and works fine on real hardware I also get no error when it loads the second sector how ever the code on the sector sector
mov ah, 0x0e
mov al, 65
int 10h
jmp $
Unfortunately does not run I think its all to do with offsets maybe I'm jumping to the wrong place
You've never actually said that you see your message "Grape loading" being printed to the screen. If you are seeing that, then it looks as if the rest of your code should work - I've gone through the machine code to check. So, the next step should be to avoid jumping to the code loaded in from the next sector and to check instead to see if it is actually being loaded in, whether it's being loaded in in the right place, and whether something else is being loaded in instead. That's why you need to write something to the location where it's to be loaded in before loading it in, then load the second sector in, then read the first byte of memory where it's supposed to be loaded in and see if it has changed and if it's been changed to the correct value. If it hasn't been changed, that will tell you a lot. If it's changed to the wrong value, that will tell you a lot more.
Pick an unlikely value like 63 (decimal - it's a "?"). Write that to 7E00 before loading the second sector, and then after attempting to load that sector, read back the byte at 7E00 and write it to the screen by setting ES to B800 and setting DI to 0 before using STOSW (with the byte in question being in AL and a colour value such as C for red in AH).
[By the way, the machine code for your far jump to 7E00 is correct.]
Last edited by DavidCooper on Fri May 31, 2013 2:50 pm, edited 1 time in total.
DavidCooper wrote:You've never actually said that you see your message "Grape loading" being printed to the screen. If you are seeing that, then it looks as if the rest of your code should work - I've gone through the machine code to check. So, the next step should be to avoid jumping to the code loaded in from the next sector and to check instead to see if it is actually being loaded in, whether it's being loaded in in the right place, and whether something else is being loaded in instead. That's why you need to write something to the location where it's to be loaded in before loading it in, then load the second sector in, then read the first byte of memory where it's supposed to be loaded in and see if it has changed and if it's been changed to the correct value. If it hasn't been changed, that will tell you a lot. If it's changed to the wrong value, that will tell you a lot more.
Pick an unlikely value like 63 (decimal - it's a "?"). Write that to 7E00 before loading the second sector, and then after attempting to load that sector, read back the byte at 7E00 and write it to the screen by setting ES to B800 and setting DI to 0 before using STOSW (with the byte in question being in AL and a colour value such as C for red in AH).
That's a good idea I will try that
Would it be possible to just use this to output the data in 0x7e00?
Maybe - I just don't know how the BIOS print routine handles strange values that are out of the normal range, so I'd rather hear a description of what gets poked directly to the screen.
