OSDev.org

When I use printf, and if I want to end the line with "\ n", then it does not end and some character appears

Without any code I can't be sure what is happening but it looks like you didn't implement anything to handle the newline character.
Remember that with OSDev there is nothing unless you build it.

Looks like you wrote or borrow someone's printf code that writes directly to the screen. If that is the case it appears the printf you are using doesn't translate \n (and likely \r and other special characters. The values for their characters are being literally written to the screen and you see the ASCII representation. printf and the underlying code/functions for screen output would have to be amended to handle such cases.

MichaelPetch wrote:Looks like you wrote or borrow someone's printf code that writes directly to the screen. If that is the case it appears the printf you are using doesn't translate \n (and likely \r and other special characters. The values for their characters are being literally written to the screen and you see the ASCII representation. printf and the underlying code/functions for screen output would have to be amended to handle such cases.

I took the printf code from here: https://wiki.osdev.org/Meaty_Skeleton#l ... 2Fprintf.c

Can you see anywhere in that code where "\n" is handled?

iansjack wrote:Can you see anywhere in that code where "\n" is handled?

I do not see . But how to handle \n, I don't know

Well, what do you think should happen?

It's a big mistake to just copy code without understanding what it does or what you want it to do.

Gebet94 wrote:
I do not see . But how to handle \n, I don't know

I think *you* know how to handle it, you just don't know how to write code that will tell the computer how to handle it. Actually, I suspect you know how to tell the computer how to handle it, but that you don't know that you know.

So:

Question 1: In English (not C), what needs to happen when there is a newline in a string?

Once you have an answer for that, I'll have a few more questions for you.

Let me provide some additional hints for Lingofreak's question.

It will help to bear in mind that the text buffer is a contiguous block of memory, which is mapped to the logical character cells on the screen. While some of the old BIOS and MS-DOS routines have screen output which behaves like a teletype (usually abbreviated TTY in this context), the actual character/attribute pairs in memory map one-to-one the displayed character cells, including those you aren't currently using.

Or to put it another way, a blank space on the screen isn't a cell where there is no character written to it, it's cell whose value is a space character (0x20 in the character part of the char/attrib pair). If you look at the function terminal_initialize() in the code you mentioned, you'll even see where it is filling the text buffer with spaces before starting.

It may help to think of it as a grid, and maybe even draw it out a few times on sheets of graph paper, putting some placeholder mark in all of the squares to represent the space character and then erasing them and putting the output characters in them as you go.

Writing an ASCII carriage return (0x0D) and/or line feed (0x0A) to memory means exactly that - it puts those values into the cell your cursor is currently on - so actually writing those characters to the buffer isn't what you want to do. You need to think of what actions those control codes indicate should be performed, instead.

Also, from the program's point of view, a 'cursor' is just a place in the text buffer where you happen to be writing a character to; it doesn't automatically advance to some other character cell unless you make it do so. The code you yoinked from Meaty Skeleton does this as a matter of course (specifically in the terminal_putchar() function), moving the writing area to the cell in memory following the one it just wrote to, but that's just a particular design choice meant to make it behave like a TTY. You don't necessarily need to have it work that way in your code, even if it is usually useful to have it do so. Your functions can move their logical 'cursor' to anywhere in the text buffer at will, but you need to know where in the text buffer you want it to go - and there's even a function in that code, terminal_putentryat(), for writing anywhere on the terminal that you want without actually changing the cursor at all.

But the question of what a newline does is only relevant if you are emulating a TTY, with its linear, line at a time model of how the screen is used which is designed primarily to imitate a scroll of paper on a printer. The console itself has no concept of a 'newline' unless you give it one.

You probably want to keep track of where the cursor is (or at least, where it last was) while you move it around, though. Since you are probably treating the video display as a square, rather than a stream, you will want to decide if you'd rather have a single memory address to hold that location, or if a pair of (x,y) coordinates would be more useful. If you look at the file tty.c, you will see that this is in fact what that code does (with the variables terminal_row and terminal_column) silently behind the scenes.

So, think to yourself: if you are writing to the middle of one line, and your goal is to stop writing there and begin writing at the start of the next line, where is the start of the next line as it is represented in the text buffer, and what do you need to do to move your cursor?

One last couple of hints: when you make your changes, you'll want to make them to the function terminal_putchar(), which is the one which sets where in to the text buffer you are writing to. The one which does the actual writing is terminal_putentryat(), but it doesn't use the cursor coordinates the way terminal_putchar() does. Also, looking ahead a bit, you might want to consider what scrolling will entail when your cursor has reached the bottom of the screen and you want to write another line past where you are now in your virtual TTY.

Yeah, yeah, I know, I keep editing things even after people have read them, my bad...

Gebet94: if you haven't noticed by now, this question has come up here many, many times, and a lot of people here are a bit tired of answering it, especially since you would have easily found the solution if you'd done a search in the forum with a query such as "print newline to screen". I know it must seem rude to you to answer this way, but just think of how rude it seems to us that you didn't look first.

I should add that this exact question, about this exact code (with some failed modifications), was answered in detail here, though you may want to try to work out the solution yourself before reading that. A related problem and solution can be seen here for contrast. This post also has a detailed explanation of the way the text buffer maps to the screen.

linguofreak wrote:Question 1: In English (not C), what needs to happen when there is a newline in a string?

The cursor moves to a new line?.. How else to say, I don't know

Gebet94 wrote:

linguofreak wrote:Question 1: In English (not C), what needs to happen when there is a newline in a string?

The cursor moves to a new line?.. How else to say, I don't know

Simply put, you need to keep track of your cursor's location. You can have two variables, let's say cursor_row and cursor_col which contain the current location of the cursor. Let them be initialized with 0.

Whenever you print a character to screen, you read cursor_row and cursor_col and write the character (and the associated attributes) to the location specified by cursor_row and cursor_col, then update cursor_row and cursor_col to move the cursor to the next cell.

If you want to print a newline ('\n'), then the code would simply update cursor_row and cursor_col to move the cursor to next line.

Now since cursor_row and cursor_col refer to the first cell of a new line, the next character to be printed will be put at this specified location (the beginning of the new line), then the code will update cursor_row and cursor_col as usual.

Does this make sense? I think the main issue here is copying the code without having a vision for the design of your software program. You need to design the thing from scratch and then ask yourself how to implement it.

iocoder wrote:Question 1: In English (not C), what needs to happen when there is a newline in a string?
The cursor moves to a new line?.. How else to say, I don't know

Simply put, you need to keep track of your cursor's location. You can have two variables, let's say cursor_row and cursor_col which contain the current location of the cursor. Let them be initialized with 0.

Whenever you print a character to screen, you read cursor_row and cursor_col and write the character (and the associated attributes) to the location specified by cursor_row and cursor_col, then update cursor_row and cursor_col to move the cursor to the next cell.

If you want to print a newline ('\n'), then the code would simply update cursor_row and cursor_col to move the cursor to next line.

Now since cursor_row and cursor_col refer to the first cell of a new line, the next character to be printed will be put at this specified location (the beginning of the new line), then the code will update cursor_row and cursor_col as usual.

Does this make sense? I think the main issue here is copying the code without having a vision for the design of your software program. You need to design the thing from scratch and then ask yourself how to implement it.

Thank you, and thank you all too. I will consider all my mistakes

Gebet94 wrote:

linguofreak wrote:Question 1: In English (not C), what needs to happen when there is a newline in a string?

The cursor moves to a new line?..

Pretty much exactly the answer we're looking for, though we should probably state it as "The cursor moves to the beginning of a new line". If we just move the cursor down a line every time we get a newline:
So we have to make sure that we're also resetting the cursor to the beginning of the line.

How else to say, I don't know

Don't overthink it. I'm generally looking for fairly simple answers here.