OSDev.org

Posted: **Mon Oct 06, 2008 6:52 am**

lataak wrote:My plan is to replace all ASCII characters with my own font. What I need now urgently is how to do it. How can I create bitmap font of my own and make the OS/VGA card use that font? That is my question. Can you give any idea on that or any link which teaches about this? Thanks.

Load font bitmap into video memory plane 2 in the sequential accessing address mode (some graphics and sequencer registers need to reprogram) taking into account that each character's bitmap occupies 32 bytes (i.e. load 16 bytes and pass over 16 bytes for font 9x16 to get next position for loading).

Posted: **Mon Oct 06, 2008 7:12 am**

Yes, I am really serious about language support. I have downloaded the Unicode code of Amharic and I will use it when I create the OS. If you want to see the characters it is found here http://www.unicode.org/charts/PDF/U1200.pdf. I am checking the link you gave me. Thank a lot Jal.

Posted: **Mon Oct 06, 2008 8:26 am**

May be I have to read first about VGA. I don't have any idea about how it works. The concept of plane is new for me.

. I will search on Google for it and try what you told me.

Posted: **Mon Oct 06, 2008 10:15 am**

VGA Hardware </shameless plug>

Posted: **Tue Oct 07, 2008 6:19 am**

I looked at my sources and now I can refine my post. There're some register values that determine the mode mentioned above.

Font loading:
graph[0x05] = 0x00 (bit 4 = 0)
graph[0x06] = 0x0C (bit 1 = 0)
seq[0x02] = 0x04 (0100b)
seq[0x04] = 0x06/0x07 (bit 2 = 1)

Characters and attributes writing (normal mode):
graph[0x05] = 0x10 (bit 4 = 1)
graph[0x06] = 0x0E (bit 1 = 1)
seq[0x02] = 0x03 (0011b)
seq[0x04] = 0x02/0x03 (bit 2 = 0)

Posted: **Tue Oct 07, 2008 10:35 am**

humm,...,new font

i think BIOS font via int 0x10 useless in your case,...,no problem
i have the same project but in arabic language the size of char. is not my problem,i have some complex things like some right/ left direction with mixed languages english/arabic together in the same text and latter shape different it text position
anyway,...,you need to implement your font in graphic mode as tiles

the new problem is:
i have my own language and you have your own,...,how can we develop a method to addopt any language in our OS's just like windoz

Posted: **Tue Oct 07, 2008 3:04 pm**

Will the people watch out with providing false information.

Arabic fonts are written in such a fashion that they are practically impossible to fit into the width of a character cell. The font in discussion is more compressed in the other direction and from what I saw, could well be fitted into 8 pixels wide. Hence in your case graphics mode has much more preference than in his case, where it is already established that it is doable.

And you are the second person here that suggests requiring English of other people's OSes.

Posted: **Wed Oct 08, 2008 3:16 am**

AhmadTayseerDajani wrote: i have my own language and you have your own,...,how can we develop a method to addopt any language in our OS's just like windoz

I bet Windows doesn't really. What Windows does is generic enough Unicode handling, that it can deal with the nasty stuff like composites and right-to-left. You can't do half of Unicode in text-mode though, so I'd start with ASCII-only until you're up to graphics mode, with variable-width font-rendering working. It's easy to go for Unicode at that point, at least if you're happy with UTF-8 (which I'd say is the sane way anyway, but I know people disagree).

Posted: **Wed Oct 08, 2008 7:47 am**

I accept the idea that we have to be able to devise a mechanism by which allow the OS to work in different languages. For the time being that is too complex for me to handle it. After finishing my own language support, I will work on any language support. To make the OS universal, it is must that the OS is based on Unicode. That is what I should do for the time being.

egos wrote:i think BIOS font via int 0x10 useless in your case,...,no problem

I don't understand why you say that. Since the number of characters is smaller than 256, I can do it in text mode if I enable 512 support leaving ASCII characters are they are (in case English is needed).

Posted: **Wed Oct 08, 2008 4:45 pm**

Hi,

lataak wrote:I accept the idea that we have to be able to devise a mechanism by which allow the OS to work in different languages. For the time being that is too complex for me to handle it. After finishing my own language support, I will work on any language support. To make the OS universal, it is must that the OS is based on Unicode. That is what I should do for the time being.
egos wrote:i think BIOS font via int 0x10 useless in your case,...,no problem
I don't understand why you say that. Since the number of characters is smaller than 256, I can do it in text mode if I enable 512 support leaving ASCII characters are they are (in case English is needed).

The Unicode Ethiopic range of code points is from 0x1200 to 0x137F, which is 384 code points. 28 of these are unused, leaving 356 that are used. This means you'd need to enable 512 character support anyway. If you enable 512 character support it'd make things easier if you use 384 characters for Ethiopic (including the 28 unused characters) so that you can do "character = Unicode - 0x1200" instead of "character = lookupTable[Unicode - 0x1200]". In this case you'd still have 128 characters left over for ASCII.

However, text mode fonts are 8 pixels wide (and 8, 14 or 16 pixels high). Take a look at Unicode code points 0x1328 to 0x132F - they're too wide and too similar, and I seriously doubt that you'll be able to draw them adequately with an 8 pixel wide grid (which is actually a 7 pixel wide grid because the last column of pixels is typically white-space that separates characters).

Here's my attempt at the 3 Unicode code points 0x1328, 0x1329 and 0x132A:

Code: Select all

.#####...#####...#####..
##.#.##.##.#.##.##.#.##.
#..#..#.#..#..#.#..#..#.
#..#..#.#..#..#.#..#..#.
#######.#######.#######.
#.#.#.#.#.#.#.#.#.#.#.#.
#######.#######.#######.
........................

Even if you can make them look a little better people won't be able to tell them apart and they'll still look like crap.

It might be possible to use wider characters in text mode on some video cards, but this is non-standard. I should point out that I've been having problems with standard BIOS functions that aren't implemented correctly on some video cards. [I've got code that attempts to detect if the video card is VGA or not using standard VGA functions "int 0x10, ax = 0x1C01" (save video state) and "int 0x10, ax = 0x1C02" (restore video state) that worked on all computers I owned when I wrote it and tested it (about 17 different computers at the time). Then I bought some more computers including 2 that use VIA's CPUs/motherboards (with onboard "chrome" video) and found that these standard VGA functions don't work.]

Basically what I'm saying is that you've got 3 choices:

Use standard 8 * 8, 8 * 14 or 8 * 16 characters in text mode with "less standard" 512 character mode and take a small chance that it won't work on a variety of different computers, and have crappy looking characters.
Use non-standard (extra-wide) characters in text mode with "less standard" 512 character mode and take a large chance that it won't work on a variety of different computers, and have better looking characters.
Use graphics mode, with an extremely good chance that it'll work on all computers and have (potentially) extremely good looking characters (including variable width fonts, different size fonts, italics, bold, antialiasing, support for all languages at the same time, etc).

IMHO this like choosing between "stab yourself in the eye", "stab yourself in the eye" and "OMG that looks good!" - it's not a hard decision *if* you're willing to do the work.

Cheers,

Brendan

Posted: **Wed Oct 08, 2008 6:06 pm**

If you are really determined to support non-ascii (and non-latin) text without a full GUI, I'd still go into graphics mode (in the VGA sense), and then do "software-text-console" which then let's you draw your characters as big or small, wide or narrow as you want. If you're happy with bitmap fonts of fixed width, all you really need to do is get the adapter in graphics mode, and then BitBLT your characters to the frame buffer. Variable width fonts can complicate matters somewhat (length of a line varies) but you could limit the impact by limiting fonts to some multiple of "monotype ascii width" (say normal and double-wide characters, with double-wide characters further constrained to columns that are multiples of 2 or something).

Posted: **Thu Oct 09, 2008 1:18 am**

That is a very good point by Brendan. The things you mentioned are very clear. I thought I could do in text mode but in that case some of the characters may look crap, you are right. Well, I am not insisting on text mode, I can use graphics mode if that is better. I am just accepting suggestions about both modes and may choose one at the end. Thank you very much.

Posted: **Thu Oct 09, 2008 2:24 am**

Another question-In graphics mode, am I going to draw each character using the likes of int10 interrupt call that prints one pixel or what? If it is so, that would be very very tedious task to do. In addition, BIOS calls are not accessible from Protected mode(as to my knowledge). How can we rely on things like that being in protected mode? Is there any other mechanism?

Posted: **Thu Oct 09, 2008 3:24 am**

Combuster wrote: Will the people watch out with providing false information.

And you are the second person here that suggests requiring English of other people's OSes.

WHAT DID YOU MEAN Combuster

Posted: **Thu Oct 09, 2008 4:43 am**

Hi,

lataak wrote:Another question-In graphics mode, am I going to draw each character using the likes of int10 interrupt call that prints one pixel or what?

Using the BIOS for anything is a bad idea (unless there's no other practical way). If you call a BIOS function 307200 times (once per pixel for 640 * 480 graphics mode) the overhead would be insane.

Mostly you want to work on several pixels at once. For example, with 32768 or 65536 (15 bpp or 16 bpp) graphics modes you'd want to use 128-bit SSE instructions if you can, and do 8 pixels per SSE register (with several SSE registers) at the same time.

lataak wrote:Is there any other mechanism?

Sure. Make sure that you can access all of the pixel data directly (when you're choosing a video mode to use), and just write your pixel data directly into video display memory.

I'm guessing you'll need to look into VBE (Video BIOS Extensions). Start with this wiki page, and download the VBE 3.0 specification from here. The easiest way to use VBE is to setup a video mode during boot (while you're still in real mode still) - otherwise you need to mess around with "thunking" or virtual80x86 mode.

Cheers,

Brendan

OSDev.org

New fonts

Re: New fonts

Re: New fonts

Re: New fonts

Re: New fonts

Re: New fonts

Re: New fonts

Re: New fonts

Re: New fonts

Re: New fonts

Re: New fonts

Re: New fonts

Re: New fonts

Re: New fonts

Re: New fonts

Re: New fonts