[SOLVED] Partially written string literals

[Stamerlan]

Hi, eisdt,

Try to set BL register to 0x07 (or any value different from 0) and BH(page number) to 0. BL - contains color (0 - black color).
Another advice: Try to put pusha before calling interrupt and popa after calling - if all things will be fine - your bios changes some registers.

P.S. May you print what bios prints?

Good luck!

[eisdt]

There's something interesting going on here. I thought about trying to see what's actually in SI, so I wrote a atoi function to find out.
I programmed that a specific format should be printed so that I can compare the output on QEMU (expected) and on real HW; it's

Code: Select all

$VALUE_$MSG_ADDRESS.

where:
VALUE = is just a number (0xDEAD specifically) to check the function's working;
_ = separator
$MSG_ADDRESS = What I put into %SI after mov $msg, %SI
. = stop

On QEMU, I get 57005_31846. . Fine. On RHW, 57005_ and nothing else (no terminating '.'). No idea why, I hope you can. It's as if something trapped.

I tried @Stamerlan's suggestion and surrounded every int with a pusha/popa pair and, before the int, a xor %bh, %bh and mov $0x7, %bl (yes it could be done in a single mov, but I prefer readability in this case). After the '_', a 'z' appears; if I remove the pusha/popa pairs but keep the setup for bx, a 'r' is rather printed. I don't know where they come from or who printed them.

[Octocontrabass]

Can you upload a complete binary of your code?

Have you compared what you wrote to the disk and what you are able to read from the disk?

[eisdt]

Can you upload a complete binary of your code?

Have you compared what you wrote to the disk and what you are able to read from the disk?

Yes I have, by zeroing out something the first 20MB, writing the binary and reading back the first 512 bytes: The hash sum matched.
What were you thinking about? Actually, I thought I could have been writing past the MBR, though that wouldn't make the device bootable.

I'll post the full code later, possibly making a NASM equivalent as well.

[iansjack]

How long is the binary? Are you sure that you are writing all of it to the disk? How do you write it to the disk?

[Stamerlan]

Hi, eisdt,

Try to check is direction flag cleared (or try to add cld at the beginning of your code). Can you paste all your code (AT&T syntax is well)?

Have a nice day!

[eisdt]

How long is the binary? Are you sure that you are writing all of it to the disk? How do you write it to the disk?

I write the image to disk with:

Code: Select all

sudo dd if=main.img of=/dev/sdb

The image is compiled with:

Code: Select all

as test.S -o test.o && ld test.o --oformat binary -Ttext 0x7C00 -o main.img

The image is 512 bytes long, as expected.

Hi, eisdt,
Try to check is direction flag cleared (or try to add cld at the beginning of your code). Can you paste all your code (AT&T syntax is well)?
Have a nice day!

Yes, someone else pointed out about that previously; anyway, I'm now trying to print the address of the message which doesn't required a direction (one issue off then).

The latest code can be found here, as it's getting lengthy and there seem to be no spoilers to embrace it. Hope it's still fine. I've also attached it to the post. Thanks for paying attention!

Behavior: the value of 0xDEAD is printed along with the separator; then nothing. Printing or whatever halts.

[Stamerlan]

Hi, eisdt,

Currently I have no time to read all carefully, but I found smth which can be an issue: on qemu u got 57005_31846 (0xDEAD_7C66) but your message address is 0x7C68 (when I compiled your code).
In the evening I'll check it more carefully.

P.S. try to beep (print BEL char(0x07) using int 0x10) to check if function returned from the 2nd printRegister call

Have a nice day!

[eisdt]

Currently I have no time to read all carefully, but I found smth which can be an issue: on qemu u got 57005_31846 (0xDEAD_7C66) but your message address is 0x7C68 (when I compiled your code).
In the evening I'll check it more carefully.
P.S. try to beep (print BEL char(0x07) using int 0x10) to check if function returned from the 2nd printRegister call

No hurry. About the first issue, I think it's because the code changed while testing. I don't think the 2nd printRegister call returns at all because, otherwise, a '.' would be printed as you could see on QEMU.

[Stamerlan]

Hi, eisdt,

Or maybe smth changes video page/text color/smth else and u just don't see if smth printed. You may try to invoke printRegister with predefined value twice to check if this function has side effects or not.

P.S. Which BIOS version do u have?

Have a nice day!

[eisdt]

P.S. Which BIOS version do u have?

American Megatrends, revision 4.6.

[sebihepp]

I probably found one mistake: printChar sets register bh to 3. This is writing to Page 3 (try 0) and the color is undefined in this case.

Edit: Forget my solution. I was answering to quick. In Bochs it works as well. Now I have to test it on my hardware.

Edit2: On my real Hardware it even doesn't print anything...

[eisdt]

I probably found one mistake: printChar sets register bh to 3. This is writing to Page 3 (try 0) and the color is undefined in this case.

Edit: Forget my solution. I was answering to quick. In Bochs it works as well. Now I have to test it on my hardware.

Edit2: On my real Hardware it even doesn't print anything...

Yep, good catch, I made a typo (%bh -> %bx). That's comforting to hear because it means there's concretely something wrong going on! If you make some progress or find a solution, please, let us know, I'm looking forward to reading it.

[intx13]

eisdt, what is the current status on your real hardware? Your code works on both Bochs and QEMU for me.

[eisdt]

eisdt, what is the current status on your real hardware? Your code works on both Bochs and QEMU for me.

It does work on QEMU flawlessly indeed. It does not, though, work as well on real hardware for some hidden reason.