The Place to Start for Operating System Developers
http://f.osdev.org/
I tested it in on Bochs, worked fine.kiznit wrote:It is very common for things to work on qemu and not on real hardware.
I would suggest trying bochs next. It does more validation / is less permissible then qemu.
Can you be more specific? What are the current symptoms with the latest code? Still printing halfway and then hanging? Or not printing at all now?eisdt wrote:It does work on QEMU flawlessly indeed. It does not, though, work as well on real hardware for some hidden reason.intx13 wrote:eisdt, what is the current status on your real hardware? Your code works on both Bochs and QEMU for me.
The latest code and behavior thereof can be found here.intx13 wrote:Can you be more specific? What are the current symptoms with the latest code? Still printing halfway and then hanging? Or not printing at all now?
Colors are only meaningful in graphic mode, which I'm not currently using (code runs in text mode initially). The BIOS does seem to care about the page number, though. Yes, the separator is printed after 0xDEAD; thereafter, nothing. Not even the terminating '.' .Stamerlan wrote:I don't see any mistakes now, but tomorrow on my work I'll have modified version of qemu and I'll show u which registers values are passed to int 0x10. I'm relocating now and I don't have any flash to try to boot from real hw.
May be it will help: if u already tried beep and calling printRegister twice, try to use colour 0x07 (instead 0x03), as far as I remember there was bug in colours on vm (I don't remember which one, but colours different from 0x07 where shown incorrectly) may be ur bios has same issue (it's very unlikely, but more research I can do only tomorrow)
P.S. on real hw do u see a separator ('_')?
Happy hacking!
Code: Select all
stub handle_10:1148:
a=00000e35 b=0000030a c=00000005 d=00000035 ds=0000 es=0000 ss=eef1
si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30 f=0046
stub handle_10:1148:
a=00000e37 b=0000030a c=00000004 d=00000037 ds=0000 es=0000 ss=eef1
si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30 f=0002
stub handle_10:1148:
a=00000e30 b=0000030a c=00000003 d=00000030 ds=0000 es=0000 ss=eef1
si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30 f=0006
stub handle_10:1148:
a=00000e30 b=0000030a c=00000002 d=00000030 ds=0000 es=0000 ss=eef1
si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30 f=0002
stub handle_10:1148:
a=00000e35 b=0000030a c=00000001 d=00000035 ds=0000 es=0000 ss=eef1
si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30 f=0002
stub handle_10:1148:
a=00000e5f b=0000030a c=00000000 d=00000035 ds=0000 es=0000 ss=eef1
si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30 f=0046
stub handle_10:1148:
a=00000e33 b=0000030a c=00000005 d=00000033 ds=0000 es=0000 ss=eef1
si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30 f=0046
stub handle_10:1148:
a=00000e31 b=0000030a c=00000004 d=00000031 ds=0000 es=0000 ss=eef1
si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30 f=0002
stub handle_10:1148:
a=00000e38 b=0000030a c=00000003 d=00000038 ds=0000 es=0000 ss=eef1
si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30 f=0006
stub handle_10:1148:
a=00000e34 b=0000030a c=00000002 d=00000034 ds=0000 es=0000 ss=eef1
si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30 f=0002
stub handle_10:1148:
a=00000e38 b=0000030a c=00000001 d=00000038 ds=0000 es=0000 ss=eef1
si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30 f=0002
stub handle_10:1148:
a=00000e2e b=0000030a c=00000000 d=00000038 ds=0000 es=0000 ss=eef1
si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30 f=0046
Really?ss=eef1
Assemblers don't perform optimizations as they can't see the logic of the code, unlike compilers for higher level languages (e.g. C); or you were perhaps referring to something else?Roflo wrote:Maybe compiler optimization? Disassemble the binary and compare.
Thanks for trying the code on RHW. (lucky you!) You see 0xDEAD_$MSG_ADDRESS., right?Stamerlan wrote: 2eisdt I run ur code on my hw (American Megatrends A06), only change I've done is mov $0x3, %bh -> mov $0x3, %bx in printChar function. All works fine for me. May be u have a problem when u r writing to flash, or if it's a hd check if u r writing to correct disk (which u r booting from) may be u boot from old version of ur bootloader?
If they were a problem the code wouldn't start at all, would it? Thing is that the code works at someone's will: I thought there was something wrong with the constants in general, so I placed aStamerlan wrote:Did u disable secure boot and enable legacy boot mode?
Code: Select all
val:
.dw 0xFFFF
57005 is 0xDEAD and 31848 (0x7C68) is the address of the string. I get the same results on QEMU.intx13 wrote:FYI the output I'm seeing in Bochs and QEMU is "57005_31848." It should be "DEAD_<whatever>." right?
Yep, I saw dead, separator, msg addr and point at the end. But I fixed misprint in printChar. Now I'll try to do it with misprint (I guess I shouldn't see anything)Thanks for trying the code on RHW. (lucky you!) You see 0xDEAD_$MSG_ADDRESS., right?
I don't use bootloaders -- it's just a USB 2.0 drive I write the code to. I then enter the BIOS, F8, boot it and hope to see what I programmed the CPU to do.
Maybe on some bios this function uses additional registers (such as cx, dx), which aren't documented?I tested on two laptops and was able to reproduce what you're seeing on one of them. The other one worked fine. This is interesting!