OSDev.org

I have this bootsector designed to run from a floppy and it won't work on Bochs. It's not actually meant to work all the way through but that's beside the point Under Virtual PC it'll attempt to load the second stage and give error 20h (Controller Failure), whereas under Bochs it panics with RIP > CS.limit before getting that far. I stepped through and as far as I can tell it panics while in the INT 13 call. As it gets past this point under Virtual PC it seems to me that this could be an actual Bochs bug. Could anyone either confirm that this happens as I think it does or that there's something else wrong with my code that just happens to work under Virtual PC?

Been doing some reading through the Bochs TODO list and came across this:

9.1 our bios is quite heavy on stack space (notably during int13 functions).

Could it possibly be overflowing my stack that I set up and killing something else? I put the stack at 9000:0000 so it'd have to be *really* heavy on stack space, but I guess it's worth looking into.

Hi,

It's not a Bochs bug...

Bochs uses a 1 KB EBDA (Extended BIOS Data Area) from 0x0009FC00 to 0x0009FFFF to keep track of CD boot emulation (El Torito), the hard drive parameters, the floppy drive parameters, etc.

Your code overwrites this with it's stack, and when it loads sectors 33 and 34. As far as I can tell your code also overwrites it's own stack when it loads sector 34 - setting SS:SP to 0x9000:0x0000 means that the first thing pushed will make it wrap around (e.g. pushing a 16 bit word would make SS:ESP = 0x9000:0xFFFE, which is fine except for the overwriting).

Most real computer also use an EBDA (the size of the EBDA varies), and there's no way to know what you'll be overwriting. Instead it'd be better to use Int 0x12 (http://www.ctyme.com/intr/rb-0598.htm) to find the highest address in conventional memory that you can safely use.

Alternatively, you could use from 0x00080000 to 0x0008FFFF instead (should be safe on all modern computers) ...


Cheers,

Brendan

Hmmm.... that stuff wasn't in the map of memory I got from somewhere, it told me the addresses I picked were safe. I'll switch to using those other addresses and see what happens.

Am I right in thinking that things pushed onto the stack go downwards in memory (towards lower addresses)? It was always mentioned like that, but it never really made sense to me. One of those things I just accepted.

Ok, that seems to have almost worked, Virtual PC's INT 13 call now gives me error 09h ("data boundary error (attempted DMA across 64K boundary or >80h sectors)") and Bochs actually gets as far as being able to tell me the second stage wasn't where it was meant to be (that part of the disk is still empty, so that's a good sign). I might actually get this working by the end of tonight.

Hi,

Kemp wrote:Am I right in thinking that things pushed onto the stack go downwards in memory (towards lower addresses)? It was always mentioned like that, but it never really made sense to me. One of those things I just accepted.

Yes - eSP is decremented by the size of whatever you're pushing, then aligned to 2 or 4 bytes (depending on default stack size). Then what-ever you're pushing is stored at SS:eSP.

For example (in real mode), if SS:SP = 0x9000:0xFFFE and you do "push ax" then SS:SP would decrease by 2 to 0x9000:0xFFFC and the contents of AX would be stored at 0x9000:0xFFFC.

If SS:SP = 0x9000:0x0000 and you do "push ax" then the CPU would try to decrease SP by 2, but because SP can't go lower than zero it'd wrap around to 0x9000:0xFFFE, and the contents of AX would be stored at 0x9000:0xFFFE.


Cheers,

Brendan

Ok, now I load the stack at 8000:FFFF and the boot sector is moved to 8000:0000. Then the second stage is loaded starting at 8020:0000 (at the end of the first stage) and jumped to. The good news : Bochs actually jumps to the right place and executes my code The bad news : Something's broken in my segment registers because the success message is corrupted. I know what that is! Writing things down *does* help

brb


Ok, maybe not as easy as I thought. Bochs is getting to my CLI, HLT pair at the end of the second stage (a whole 9 bytes of code right now) but isn't displaying the message. Bochs says my CS and DS are correct, so I can't see what the problem would be. Every other time it has done this my DS has been AWOL.

[Code links removed, dead]

Gonna get a proper site sorted out once this code works.

What... the hell... am I on about? It worked perfectly. I'm so used to it failing that I didn't see it working when it finally did ;D

OMG, I actually have a working first stage. I can't believe it ;D ;D



Edit:
And as promised I've started getting a site set up now that the first stage loader is complete:
http://kempos.iualdii.net/index.php

This does however mean that previous links in this post no longer work.

On the plus side, my first stage still has 157 bytes to play with. A total of 355 bytes isn't bad when you take the BPB into account, though admittedly this doesn't actually do much right now.