OSDev.org

Hi,

Haghiri75 wrote:Thank you very much! But I have another question, does "printString_atCoords" routine, changes cursor place? I tried it but it didn't work.

For the code I posted (and the code you posted) there's no support for:

• Any ASCII control characters (line feed, tab, etc)
• Anything that is not 7-bit ASCII (e.g. mapping Unicode to "VGA glyphs" in the ranges 0 to 31 and 127 to 255 where possible)
• Scrolling when you hit the bottom of the screen
• Wrapping properly when you hit the right edge of the screen
• A cursor location
• A visible cursor (that can be enabled when you're waiting for user input, and disabled when you're not)
• Printing anything that is not a string (single characters, decimal values, etc)
• Anything that is not "standard" 80 * 25 text mode

Cheers,

Brendan

Brendan wrote: There is also no calling convention, and you decide where each routine's entry point expects to find input parameters and leaves output parameters. People that don't understand these differences end up writing bad code (code restricted by limitations that exist for compiler generated code but don't exist in assembly).

To clarify: a calling convention is, from the perspective of assembly language, exactly that: a protocol that is used to make communication between procedures easier. While they are often needed in assembly code that is to be called from high-level languages, for straightforward assembly code that does not present an outside interface, they aren't necessary.

This does not mean they aren't useful at all in assembly; if you stick to a calling convention - of which there are often several for a given CPU type - then using your code as a library is easier. However, that's simply a matter of convenience to the user of an API, and even then there is some wiggle room as long as all the calling code is in assembly. The key here is not to blindly follow a set rulebook, but to document the interfaces in detail. A calling convention saves you the trouble of doing this, but as Brendan said, it can come at a cost of inefficiencies in the code. You have to weigh the tradeoffs.

Brendan wrote:For the code I posted (and the code you posted) there's no support for:

Again, to clarify: the example code Brendan gave (as I understand it) does only one thing, namely, it copies a series of bytes to alternating bytes at a specific point in the video text buffer. The features he lists are all things you will need to implement yourself, which in turn will mean understanding how the video text buffer works. The wiki has a number of relevant pages on the subject:

• VESA Video Modes
• Text UI
• Double Buffering (mainly a graphical programming issue, but still relevant in understanding the use of multiple text buffers)

At the very least, implementing a cursor will require a pointer variable holding the current writing position in the text buffer. However, the text buffers themselves are just sets of linear glyph-attribute pairs; there are no inherent concepts of 'row', 'column', 'newline', 'advancing', 'scrolling', and so forth. All of these things are features you will need to implement in code and in data structures of your own choosing.