Thanks in advance,
Panos.
This could be a bug in either Bochs or QEMU, but perhaps there's
just a difference that's exposing a mistake in
your startup sequence. Can you explain in more detail about what is
happening, and what state the machine is in (IRQs, CPU mode, etc)?
Hi Jake and thanks for your quick response,
the problem is rising at the start of the boot loader just after
setting the stack space. And afterwards i am just printing
on screen a "#" character to show to the user that "something" is
happening. For printing the character i am using the
BIOS interrupt 0x10. I have observed that if i use the following
code the problem rises :
mov ax, 0x0000
mov ss, ax
mov sp, 0xFFFF
mov si, DisplayString
call DisplayString
But if i use the following code the problem just disappear :
mov ax, 0x0001
mov ss, ax
mov sp, 0xFFFF
mov si, DisplayString
call DisplayString
The only change is that i am starting the ss at 0 ! I am sure that
i am missing something here !
Thanks in advance,
Panos.
Hi Panos,
I'm afraid that I'm no expert on 16-bit code and the x86 boot process.
Hopefully others will be able to give you a more definitive answer.
However, if your bootloader is in the MBR, it is loaded at 0x7c00 as I
recall. Could it be that the stack is writing over some of your code or
data? The exact amount of stack space used in a call might depend upon the
BIOS implementation...
> Thanks in advance,
> Panos.
> For printing the character i am using the
> BIOS interrupt 0x10. I have observed that if i use the following
> code the problem rises :
>
> mov ax, 0x0000
> mov ss, ax
> mov sp, 0xFFFF
> mov si, DisplayString
> call DisplayString
>
> But if i use the following code the problem just disappear :
>
> mov ax, 0x0001
> mov ss, ax
> mov sp, 0xFFFF
> mov si, DisplayString
> call DisplayString
>
> The only change is that i am starting the ss at 0 ! I am sure that
> i am missing something here !
Hi Panos,
I don't have QEMU so I won't be able to do any tests, but if you post the
full bootloader code I might be able to make some guesses for you.
Specific questions:
1. What does the DisplayString routine do? In particular, does it
explicitly set AL before invoking the interrupt? Does it use the stack?
Which 0x10 subfunction does it use?
2. How is the DisplayString string defined?
3. You've got a routine called DisplayString and a variable called
DisplayString. Is this correct? (When it comes to assembler I'm a fumbling
amateur.)
4. Is it possible that there's a bug somewhere else that causes the string
to always be printed several times, but in one code snippet it's always
printed in the same place (cursor is not updated?) and in the other
snippet it's printed in different places? (This would be easier to
hypothesize about if the two code snippets were the other way round: SS=1
causes the problem. This would make some sense for 0x10 subfunction 0x13.)
5. What inspired you to try changing SS and come up with the second code
snippet?
6. What happens if the string is longer than one character?
7. When the string is printed multiple times, is it always the same number
of times?
8. What happens in bochs when you set SS=1?
Like I say, I may not be able to help much because I don't use QEMU, but
I'm happy to ask stupid questions that might nudge you in the right
direction.
Cheers,
Ciaran
--
Ciaran Keating
Amadan Technologies
I usually use Bochs and VMWare player. Find VMWare
a bit faster than Bochs, especially for my ATA drive code
where I need a delay of 400ns in parts of it. I use a
technique where the PIT timer is read until 2 changes
have occurred as a way of creating the short delay .
Boshs doesn't appear to update the PIT as often so feels
slightly sluggish when using that technique.
Usually things work in both without problems.
As for your problem...
> mov ax, 0x0000
> mov ss, ax
> mov sp, 0xFFFF
> mov si, DisplayString
> call DisplayString
> But if i use the following code the problem just disappear :
> mov ax, 0x0001
> mov ss, ax
> mov sp, 0xFFFF
> mov si, DisplayString
> call DisplayString
I assume DisplayString calls int 0x10, subfunction 0x13 to
Write Character String.
Do you set ah and al inside DisplayString? Maybe setting
ax to 0x0001 in your code sets al to 0x0001 which updates
the cursor position, 0x0000 doesn't. So nothing to do with
your stack, though you might want to start with the stack 2
or 4 byte aligned.
--
Marv
Hi to all and thank you very much for your prompt replies,
the snippet of source code in assembly that i am using is the
following :
START:
cli
mov ax, 0x07C0
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax
mov ax, 0x0000
mov ss, ax
mov ax, 0xFFFF
mov sp, ax
sti
mov si, msg
call DisplayMessage
the routine "" is the following :
DisplayMessage:
lodsb
or al, al
jz .end
mov ah, 0x0E
mov bh, 0x00
mov bl, 0x07
int 0x10
jmp DisplayMessage
.end:
ret
the memory variable msg is an ASCIIZ string. This problem is not a
BIG one because i can live with a much smaller
stack ! I am just wondering the "why" ? In my source code i have
omitted the BPB and the initial jmp to the "START"
label.
Thanks in advance,
Panos.
It's been a long time since I've done 16-bit asm. It looks okay,
all data segments match, ss is obviously different but shouldn't
be a problem. cs might be different, again shouldn't be a problem.
I assume you set the origin in the asm code to 0x0000.
I suppose you could try altering the start of sp to be aligned on
2 or 4 bytes, maybe 0xfffe or 0x0000 or 0xfffc. See if that
makes a difference. Or even change it further.
> the routine "" is the following :
>
> DisplayMessage:
> lodsb
> or al, al
> jz .end
> mov ah, 0x0E
> mov bh, 0x00
> mov bl, 0x07
> int 0x10
> jmp DisplayMessage
> .end:
> ret
Looks okay, should print a string a character at
a time until the null terminator. I've forgot how BIOS
calls preserve registers but I assume most registers
including SI are preserved and the only register
that is not is AX.
--
Marv
VMware is the best emulator I've ever seen (but hasn't got any
debugger :( ).
Both can emulate the serial port over the named pipe, which is enough for
Windows kernel debugger to run.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
<alfao...@gmail.com> wrote in message
news:afaee689-558a-4d21...@28g2000hsw.googlegroups.com...
> the routine "" is the following :
>
> DisplayMessage:
> lodsb
> or al, al
> jz .end
> mov ah, 0x0E
> mov bh, 0x00
> mov bl, 0x07
> int 0x10
> jmp DisplayMessage
> .end:
> ret
>
> the memory variable msg is an ASCIIZ string. This problem is not a
> BIG one because i can live with a much smaller
> stack ! I am just wondering the "why" ? In my source code i have
> omitted the BPB and the initial jmp to the "START"
> label.
>
What does this mean 'omitted', omitted from these snippets, or not
existing in your source?
> Thanks in advance,
> Panos.- Hide quoted text -
>
> - Show quoted text -
Steve