print function

[jrfritz]

Why don't you try the "WORKING" putch from FritzOS? ( I didn't post it...you need to download it...it's in fstdio.h )

[Unexpected]

I found the problem! Here, in yours and others sources is:
i = curY * 160 + 2 * curX;
It must be:
i = Y * 80 *2 + X;
I don't know why in yours it works, but in mines don't

Cool my console works! ;D

Ok, I go to sleep.. because now is 5:30 AM(NIGHT!!!) and soon will be a morning Bye!

[jrfritz]

80 * 2 = 160!

[Unexpected]

2 * curX !!!

[Slasher]

hi
right formular
offset=(y*80*2)+(x*2)
or
offset=y*160+(x*2);

[pini]

On a basic 80*25 screen, you have to use this :
160*Y+2*X
Instead of :
80*Y+X
because each character on the screen takes a word in the memory : one for the ASCII value and one for the attribute.

0xB8000+160*Y+2*X gives you the address of the ASCII value and the next byte is its attribute.

Unexpected, I think you forgot the to multiply X by two in your first putch function

[pini]

It's exactly what you just wrote. I think you posted your message while I was writing mine

[pini]

I made some test today.

I found out that this kind of string declaration :
[pre]unsigned char string[]={'T','h','i','r','d','\0'};[/pre]
works perfectly, while this kind of declaration :
[pre]unsigned char*string="Third\0";[/pre]
doesn't work.

After disassembling my kernel, I found out that the first declaration produces a sequence of mov instructions, which seems correct to me. But the other declaration seems to be considered as some executable code. (there is a push sp instead of a mov byte [...],0x54 (0x54 is 'T'))

Can this be helpful to find out what is the problem with my print function ?

[Ozguxxx]

I might be wrong but disassemblers do not know what data is in your program and what is not. So they will take the binary file, turn (I think)COMPLETELY it into instructions and then output it. So what you see should not be false, disassembler simply turns the 'third' into machine instructions. (Certainly takes 'third' as a byte stream and then does this conversion.) I think your problem is somewhere else. But I must say that I had the same problem, it was the exactly same as yours, my printf worked on 166 MHz and did not work on 800 MHz. I thought it was a result of BIOS settings but it is probably not. BTW I could not solve the problem, it still exists, for some reason that I do not know the active page in video memory is not refreshed when you change directly video memory, I still do not know. (But video memory is changed I know that it is changed, but screen is not refreshed.) Also I asked people here but we could not solve it, my advice is: do not stick on the problem unless you think that you learn something more and more as you are more stuck in it. Good luck.

[Slasher]

hi,
you do not need to put "\0" in the string manually, c does that and in c its "\n" that moves to a new line.
in your printf function you have to check for '\' and then a 'n' seperately!! this is for new line. and a '0' means end of string
unsigned char *string="HELLO"; should work fine!

[pini]

unsigned char *string="HELLO"; should work fine!

Yes, should. But it dosn't. If I use explicit arrays :
[pre]unsigned char string[]={'H','E','L','L,'O','\n',0};
[/pre]
Everything is correct.

I must precise that your code AND direct call like this :
[pre]print("Hello");
[/pre]
are working correctly on some machines and with bochs 2.0, but not with some others. I've got no explanation fot this. Have you ?

[Slasher]

hi,
post full code ie all functions that you use in printf. that is the only way we can find out the problem!

[Pype.Clicker]

I made some test today.

I found out that this kind of string declaration :
[pre]unsigned char string[]={'T','h','i','r','d','\0'};[/pre]
works perfectly, while this kind of declaration :
[pre]unsigned char*string="Third\0";[/pre]
doesn't work.

What you have to know is that, for most C compilers, constant strings are stored in the .text section (COFF) or in .rodata section (ELF), while your char string[] is in the .data section.
The reason of doing so is that the .text and .rodata sections are not writable, so the 'constant' attribute of the string can be enforced by the runtime environment.
You could either put "-fwritable-strings" flag at compile time, but that would just be turning around the problem. I suggest that you perform a small OBJDUMP -X on your object file and check if it has the expected structure (i.e. don't you have a linker script that would drop the .rodata section ?)

It could happen that one of our test machine have another version of the compiler which places the string in some other place ...

After disassembling my kernel, I found out that the first declaration produces a sequence of mov instructions, which seems correct to me. But the other declaration seems to be considered as some executable code. (there is a push sp instead of a mov byte [...],0x54 (0x54 is 'T'))

Can this be helpful to find out what is the problem with my print function ?

This tends to proove that your strings are in the .text section.
Another possible problem is that you did not relocated your code properly (i.e. pointers do not take in account the fact that sections are at different base addresses).
Try an OBJDUMP -D on your object file and see if the offset that should be the address of "constant string" actually refers to an array of byte where your "constant string" bytes are stored...

[pini]

[attachment deleted by admin]

[Perica]

..