newline Character

[rustyoz]

was there any particular reason why 0x00A0 was chosen as the newline character instead of 0x000A as according to the ASCII and other standards?

[noxer]

Yes, my fingers typing A before 0. I think is was a typo. I think you have fixed this in you pull request. I will review the code (on tuesday) and then merge the fix.

[rustyoz]

Yes I have included it in one of my commits. Its in the pull request I made but I will try to re organise those commits to make each one for a single problem or feature just to make the commit history a bit neater and merging the code easier

[aponigricon]

0x000A IS A CHARACTER DAMMIT! For special control characters/key characters use anything higher than 0x007F.

[noxer]

0x000A IS THE CHARACTER FOR LINEFEED so why not use it for linefeed?

[aponigricon]

http://0x10cwiki.com/images/f/fc/Font.svg DCPU-16 ASCII IS DIFFERENT FROM TRUE ASCII! Seriously; read up!

[rustyoz]

of course it is different from true ascii, the point is that routines that will be using the newline control character are for text, so we might as well use standard ascii control characters. a direct screen drawing routine might be better which will ignore any control characters

[rustyoz]

and please avoid the use of caps-lock.

[aponigricon]

But what if someone wants to get a bit fancy, and make gui-like containers for text, or drawings? He won't be able to use 0x000A.

PS: I never use caps-lock :P

[rustyoz]

Ah well then we can keep 0x00A0 then since it is easy to remember.

[erisdev]

The right way to draw a gui isn't with text routines; let's stick with ASCII for the sake of compatibility with the outside world, please?

If you want to draw boxes, you should be writing directly to VRAM or (better yet) using drawing routines that will handle that for you. Back in the bad old days, the IBM PC code page 437 character set included several graphical characters in the control characters' slots as well, but that doesn't mean printf("%c%c", 0x0d, 0x0a) was rendered as ◙♪.

[aponigricon]

Sounds fine, but the porblem is that the LEM display, doesn't support direct pixel-by-pixel rendering, it's only graphics mode is text mode, so GUI's are nearly impossible. But the closest you can stick to a GUI from a text graphics mode, is TUI's.

[erisdev]

@VladVP I think you've missed my point somewhat. What I mean is that you shouldn't be calling printf or equivalent to draw boxes onscreen. You can still get those box drawing characters by writing their values directly to VRAM even if the text manipulation routines treat 0x0a as a line feed (as they should).

[rustyoz]

if you want an example of a box drawing routine that doesn't rely on not having 0xA as the line feed symbol
look at this https://github.com/bungao/AtlasOS/commit/99f2e1f60e63528ed79c106cace6a99ed42f745e

it draws a nice pretty box of your choice of colour given 2 screen coordinates

[aponigricon]

Hmm... sounds unstable, but if all routines communicate properly it should go...

[rustyoz]

unstable?