Author Topic: keyboard input and assembler  (Read 1766 times)

Offline Daniellebishop

  • Jr. Member
  • *
  • Posts: 6
keyboard input and assembler
« on: January 31, 2023, 06:36:26 AM »
Hi, I am Daniellebishop and i have one question. I am no from English speaking country and I am making my own OS in C and assembler but when I came to printing text on screen and I want to use my characters ( that I use in my country ) I don't know how to use them because C compiler doesn't compiled it very well for my OS so it didn't work. Later i change text encoding ( to ISO 8859-2 ) it worked better but not enough - some characters it did compiled correctly and some not, and I don't know know how to fix it, I decide best way will be make own charset but I don't know how to do it. Also I need help with keyboard in C - i know that I can read input from it using port 0x60 and 0x64 but i need also recognize characters and here is my problem - using scan odes i don't know if some key on keyboard has special scan code or if special letter has own and unique scan code if first it will be easy to make function to read for example Slovak, English, American or any keyboard because special key has own scan code and doesn't depends on letters written on it but if second it will be harder because i can'f find Slovak keyboard scan codes so please help me, it is confusing me ( very very confusing )  - sorry for mistakes, because ( as I mentioned before  ) I am not from English speaking country. My Insite Employee Login
« Last Edit: February 01, 2023, 03:59:57 AM by Daniellebishop »

Offline fredericopissarra

  • Full Member
  • **
  • Posts: 368
  • Country: br
Re: keyboard input and assembler
« Reply #1 on: January 31, 2023, 10:59:29 AM »
Your english is very good! And, hey, I'm not from an english speaking country as well (Brazil).

Your OS is one of those where you jump to graphics mode? Is so it can be "easy" to implement UNICODE. In theory, you could have 2M characters in a "font". But I suggest you don't try to implement surrogates and composition just yet. This can give you almost 64K chars (a little bit less due to surrogates codepoints range -- you'll see).

If you want to implement your own single byte charset, you could create an array mapping a byte to a group of them, like this:
Code: [Select]
unsigned char font[256][16] = {
 { /* ASCII: 54 */
    0x00, /* ········ */
    0x00, /* ········ */
    0x38, /* ··***··· */
    0x60, /* ·**····· */
    0xc0, /* **······ */
    0xc0, /* **······ */
    0xfc, /* ******·· */
    0xc6, /* **···**· */
    0xc6, /* **···**· */
    0xc6, /* **···**· */
    0xc6, /* **···**· */
    0x7c, /* ·*****·· */
    0x00, /* ········ */
    0x00, /* ········ */
    0x00, /* ········ */
    0x00  /* ········ */
The all you need to do is draw this small "box" on screen in the appropriate video memory location.

In VGA hardware you can reconstruct the default "font" setup by the ROM-BIOS. To do this I recommend this article from OSdev. Just know that this is limited to 256 chars and their width and height depends on the text mode you are using. See Ralf Brown's Interrupt List abour service 0, interrupt 0x10, there's a list of modes and char "sizes" there.

But I would stick with graphics mode (emulating a text mode) because you can create a bigger array with bigger and better well drawn glyphs. I think the important thing is to obey some charset like UNICODE. And, of course, you'll have to make some code to decode a "fonts" file, if you want flexibility. This is another venue of research: There are (I believe) 3 types of fonts: bitmaped, vectorial and those which uses Bèzier curves (truetype, opentype etc...). The last one is a little bit complicated (but you can find the specification for those as well). For now, bitmaped fonts should be enough.