OSDev.org

Hi, I have spent 3 days trying to figure out why my operating system works fine in a virtual machine but as soon as I run it on the real thing it has some problems. Please also note I have been using virtual floppy drives on the virtual machine and changing the drive number before putting it on USB to try on the real thing.

These are some things I tried

1. I changed it to write mode and set the drive number to 0x81 the next thing I knew I overwritten sector 2 of main hard disk! by accident this proves that my processor and bios has no problem reading my IO instructions

2. I tried drive 0x82 and my operating system bounces with a message Failed to read sector

3. I tried drive 0x80 and I had no error message but it did not successfully output A which is what the program on sector 2 was written to do

4. Apparently the Bios sets the DL register to the correct drive number after it jumps to 0x7c00 so I then didn't bother setting the DL register and again I had no error message but it failed to show me the letter A

Here is my code:
and the kernel
If anyone could help with this problem I would appreciate it

Thanks!

Oh my, where do I start?

computertrick wrote:Hi, I have spent 3 days trying to figure out why my operating system works fine in a virtual machine but as soon as I run it on the real thing it has some problems. Please also note I have been using virtual floppy drives on the virtual machine and changing the drive number before putting it on USB to try on the real thing.

Three things here - many older bioses either don't or don't fully support usb booting.
Second, Try changing only one variable. EG, run on external floppy on real machine. Or boot from hard disk in VM.
Third, int 0x13, ah = 0x42 shouldn't work on floppies. ah = 0x2 may or may not work on a usb flash drive, dependant on manufacturer and size.

1. I changed it to write mode and set the drive number to 0x81 the next thing I knew I overwritten sector 2 of main hard disk! by accident this proves that my processor and bios has no problem reading my IO instructions

Teaches you to take the hdd out when testing on real hardware...

2. I tried drive 0x82 and my operating system bounces with a message Failed to read sector

I'm not surprised. That would be the third hard drive in your system.

3. I tried drive 0x80 and I had no error message but it did not successfully output A which is what the program on sector 2 was written to do

Two questions - is it successfully burnt to the sector? and, why do you automatically assume that your program is written correctly?

4. Apparently the Bios sets the DL register to the correct drive number after it jumps to 0x7c00

True, except it's set before the jump.

so I then didn't bother setting the DL register and again I had no error message but it failed to show me the letter A

Sorry, out o f time, I'll go through the rest later.

Hmm, thanks for your reply. I don't assume its written correctly I was just stating everything that happened so theirs more of a chance of this problem being resolved.

The BIOS see's usb stick as HDD doesn't it? I have written the kernel starting at the 513th byte of the USB stick I'm thinking do HDD's not use 512 byte size sectors? Is it bigger this could be my issue if that's the case

I just modified the Microsoft virtual pc's hard disk and wrote the data and the kernel at the sector in sector sizes of 512 bytes and it loaded it fine :/ I am pretty lost right now with why this works fine on VM and not the physical system

Two things:

• 1. Your code does not initialize SS, so you have no idea where in memory your stack is, or what it's overwriting. You should probably fix that.

• 2. If your BIOS is treating your USB stick like a hard drive, then it's quite likely laid out like one, with an MBR in sector 0, and one partition which starts some unknown number of sectors later and is formatted as the logical drive you see in Windows. It's a common mistake to to write to sectors 0, 1, etc of the logical drive thinking that those are sectors 0, 1, etc of the physical device, which they wouldn't be in this scenario. If you have a sector editor that lets you open the physical device, not just the logical drive, then use it to open the physical device and confirm what sectors your code was actually written to.

I used linux to write and read to the usb stick and I read the first 512 bytes of the usb stick and then read the sector after that which was the kernel it appears to be in order. Here is a hex dump of the data

I don't see anything wrong with your code. To verify that it is reading correctly, try reading the sector to 0xb800:0.
You should see:
´°Íë
or something like that* in the top left corner of the screen.
The background colors should be black, dark red, dark blue, and white.
The foreground colors should be bright yellow, dark blue, black, and bright yellow.

*The characters may vary. Colors won't.

computertrick wrote:I used linux to write and read to the usb stick and I read the first 512 bytes of the usb stick and then read the sector after that which was the kernel it appears to be in order.

What was the actual device name you used?

m12 wrote:I don't see anything wrong with your code. To verify that it is reading correctly, try reading the sector to 0xb800:0.
You should see:
´°Íë
or something like that* in the top left corner of the screen.
The background colors should be black, dark red, dark blue, and white.
The foreground colors should be bright yellow, dark blue, black, and bright yellow.

*The characters may vary. Colors won't.

I read the sector into the address you specified and I think the video mode was reset because the screen now contains no text

computertrick wrote:

m12 wrote:I don't see anything wrong with your code. To verify that it is reading correctly, try reading the sector to 0xb800:0.
You should see:
´°Íë
or something like that* in the top left corner of the screen.
The background colors should be black, dark red, dark blue, and white.
The foreground colors should be bright yellow, dark blue, black, and bright yellow.

*The characters may vary. Colors won't.

I read the sector into the address you specified and I think the video mode was reset because the screen now contains no text

0xb8000 is the memory address of the screen. If there is now nothing, it means that you read at least 4000 zeros. Your flash drive might be/is probably using 4096 byte sectors. Put your kernel at offset 4096, and see if it loads.

m12 wrote:If there is now nothing, it means that you read at least 4000 zeros. Your flash drive might be/is probably using 4096 byte sectors. Put your kernel at offset 4096, and see if it loads.

No, it means that enough zeroes were read to wipe out the amount of text that was on the screen at that time. Considering that the first stage only prints one line if the read succeeds, reading in an empty standard-size sector very well could have cleared it if it wasn't preceded by too much other stuff.

@OP -- if you replace the jump to 0x07e00 in your original code with a jmp $ so things hang at that point, how much text do you have on the screen? Less than three lines, or more?

I still advise looking at the raw physical device with the tool of your choice and verifying the actual location of your code, rather than just assuming / guessing at its location. Or if you feel like getting a little assembly practice in, try rewriting your code to load the sector at LBA 0 (or cylinder 0, head 0, sector 1 if you prefer CHS) to 0x07e00, then print out the 512 bytes from 0x07e00 to 0x07fff in hex and see what you get. I think there's a very good chance that it won't be what you expect.

m12 wrote:

computertrick wrote:

m12 wrote:I don't see anything wrong with your code. To verify that it is reading correctly, try reading the sector to 0xb800:0.
You should see:
´°Íë
or something like that* in the top left corner of the screen.
The background colors should be black, dark red, dark blue, and white.
The foreground colors should be bright yellow, dark blue, black, and bright yellow.

*The characters may vary. Colors won't.

I read the sector into the address you specified and I think the video mode was reset because the screen now contains no text

0xb8000 is the memory address of the screen. If there is now nothing, it means that you read at least 4000 zeros. Your flash drive might be/is probably using 4096 byte sectors. Put your kernel at offset 4096, and see if it loads.

Changed the kernels offset to 4096 and it still isn't displaying A to the screen maybe its a different offset?

Also in windows when I format the usb drive it says allocation size 4096 bytes and I can change it. Once I physically transfer the files to my virtual machine through the usb stick I format it again in linux. What I'm trying to say is could it be possible that my bios is looking for headers in the usb drive and because I don't give those headers it doesn't know where to go

How about putting some extra code right at the start to print something to the screen - you need to find out if any of your code is being run at all. Like Minoto, I suspect you are writing your code to the start of a partition instead of to the first sector on the drive. Did you ever look at the first sector on it before you started? There's probably an MBR in the real sector 0 with a partition table in it (which you might want to keep a copy of so that you can restore it once you've worked out how to set the MBR to boot your OS from a partition).

DavidCooper wrote:How about putting some extra code right at the start to print something to the screen - you need to find out if any of your code is being run at all. Like Minoto, I suspect you are writing your code to the start of a partition instead of to the first sector on the drive. Did you ever look at the first sector on it before you started? There's probably an MBR in the real sector 0 with a partition table in it (which you might want to keep a copy of so that you can restore it once you've worked out how to set the MBR to boot your OS from a partition).

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

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.