Enabled A20 line.
Switched video mode to high_res_high_color_video_mode.
Get vesa version and lfb addr.
0x0200 - 0xF0000000 (4.026.531.840)
hmm...it seems that it is not possible to use lfb unless paging used.. or is it?
vesa question
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:vesa question
sure it is, as long as you enabled protected mode / unreal mode.
Just try
and it should work happily...
Just try
Code: Select all
mov [0xF0000000],0x11223344
-
pradeep
Re:vesa question
I don't want to open other thread for vesa, I have enabled paging and High resolution vesa mode also. Now how am i supposed to display the text (fonts). I heard that fonts are also pictures but i don't have any clue of creating them. I like to use the font files provided for Windows or Linux . Is it possible ? how to do it. Don't redirect to some sites. I tried most of them and i don't have a clue about how to do that. I gone through other Os'es but it is insufficient.
-
Xardfir
Re:vesa question
Hiya,
There are 2 wyas of putting text on the screen - bitmap and 'stroke' (vector).
VGA cards and the BIOS has their own bitmap text typefaces(fonts)built into them, these can be copied by you into memory before switching into graphics mode and them put into the screen. IE the letter A as ana example would look something like this (the 1's form a letter 'A')-
00011000
00100100
00111100
00100100
00100100
01000010
01000010
When you want to write an 'A' to the screen, you have to write out all 8 lines of 0''s and 1's. By altering the 1's and 0's you can make different fonts. VGA is better than CGA in this regard as VGA fonts are 9x16 grids while CGA is 8x8 grids. The problem is at larger sizes, bitmapped fonts get very blobby.
You can find basic 8x8 fonts in a BIOS listing (an old AT/XT one is at Programmer Heaven if I recall).
The second type of typeface is more complicated but can be scaled better. This is the 'stroke' or 'vector' fonts. Think Truetype or Postscript. Everything is made up of lines that tell the video driver where the next line should be drawn relative to the previous. So an "A" might be descibed as -
Specify Font Size 100 x 300.
Draw bottom left to top middle then to bottom right.
Draw horizontal line from middle third horizontal to middle 2nd third horizontal.
It's a lot more complicated than that but I hope you get the idea. Truetype and Postscript are standard these days, but you can still find old Borland ".BGI" stroke fonts floating around the internet including editors to make them.
Put simply you have to do all of the work usually done by hardware yourself. I feel it is better to get an OS running in text mode first and then writing an a GUI console layer once you know all those little unimportant things like memory, storage and task management are working......
There are 2 wyas of putting text on the screen - bitmap and 'stroke' (vector).
VGA cards and the BIOS has their own bitmap text typefaces(fonts)built into them, these can be copied by you into memory before switching into graphics mode and them put into the screen. IE the letter A as ana example would look something like this (the 1's form a letter 'A')-
00011000
00100100
00111100
00100100
00100100
01000010
01000010
When you want to write an 'A' to the screen, you have to write out all 8 lines of 0''s and 1's. By altering the 1's and 0's you can make different fonts. VGA is better than CGA in this regard as VGA fonts are 9x16 grids while CGA is 8x8 grids. The problem is at larger sizes, bitmapped fonts get very blobby.
You can find basic 8x8 fonts in a BIOS listing (an old AT/XT one is at Programmer Heaven if I recall).
The second type of typeface is more complicated but can be scaled better. This is the 'stroke' or 'vector' fonts. Think Truetype or Postscript. Everything is made up of lines that tell the video driver where the next line should be drawn relative to the previous. So an "A" might be descibed as -
Specify Font Size 100 x 300.
Draw bottom left to top middle then to bottom right.
Draw horizontal line from middle third horizontal to middle 2nd third horizontal.
It's a lot more complicated than that but I hope you get the idea. Truetype and Postscript are standard these days, but you can still find old Borland ".BGI" stroke fonts floating around the internet including editors to make them.
Put simply you have to do all of the work usually done by hardware yourself. I feel it is better to get an OS running in text mode first and then writing an a GUI console layer once you know all those little unimportant things like memory, storage and task management are working......
-
distantvoices
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:vesa question
@xardfir: isn't it rather that you scan the bitmap row by row for 1 and if you find one, you set a pixel at the corresponding location in the screen framebuffer or offscreen buffer?
@pradeep: Pls don't be gruffy about pointers to other source code or dox or web sites. I don't like this tone.
Most websites are good and the stuff is useable. Think about explaining the same thing over and over again instead of putting it at some loco for one and all time and pointing the asker to that place - it's way shorter. Feel free to ask if you don't understand something.
BTW, Xardfir 's put it straight: First concentrate on the nitty gritty: Memory management, task management, scheduling mechanisms, device management and IO stuff, fs management and parsing - then you might come along with gui stuff pretty without problems because all the things you've done before have schooled you for that.
Stay safe:-)
@pradeep: Pls don't be gruffy about pointers to other source code or dox or web sites. I don't like this tone.
Most websites are good and the stuff is useable. Think about explaining the same thing over and over again instead of putting it at some loco for one and all time and pointing the asker to that place - it's way shorter. Feel free to ask if you don't understand something.
BTW, Xardfir 's put it straight: First concentrate on the nitty gritty: Memory management, task management, scheduling mechanisms, device management and IO stuff, fs management and parsing - then you might come along with gui stuff pretty without problems because all the things you've done before have schooled you for that.
Stay safe:-)
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
-
pradeep
Re:vesa question
The info abt fonts is not available in most of the sites that i tried out , I haven't commented abt the stuff inside it. But if u don't like my tone . Srry yarBeyond Infinity : Most websites are good and the stuff is useable
Seeing text round the hours is frustrating thats why i like to have some fun like printing "Hello World" or something else
Re:vesa question
I've made a font renderer for Pype.Clicker some time ago, it works (my version at least) using Allegro subroutines, but does not use any more complicated than "change resolution", "putpixel" and "getpixel", which you can replace with an empty function, a store to a memory address and a load from a memory address.pradeep wrote: I don't want to open other thread for vesa, I have enabled paging and High resolution vesa mode also. Now how am i supposed to display the text (fonts). I heard that fonts are also pictures but i don't have any clue of creating them. I like to use the font files provided for Windows or Linux . Is it possible ? how to do it. Don't redirect to some sites. I tried most of them and i don't have a clue about how to do that. I gone through other Os'es but it is insufficient.
I seem to have completely lost it somehow, but Pype embedded it in Clicker somewhere. If you want I can mail his version to you (which uses Clicker internal functions, probably), because I seem to have lost mine...
Re:vesa question
Hi,
AFAIK most font rendering engines convert a string of characters (Unicode or whatever) into a bitmap corresponding to the font & size selected.
Typically this bitmap represents how solid or transparent each pixel should be (for e.g. IIRC on windows, the bitmap contains values from 0 to 31, and for Linux it's from 0 to 255), but doesn't provide any other information (like the colour of each pixel), and doesn't change pixel information directly - the data from the font engine is applied to the pixel data later.
This allows for anti-aliased font data to be rendered and then re-used by the client, and/or frequently used data to be cached by the font renderer.
Most font renderers will work with a range of different font data formats (some patented). Most font data formats consist of a set of rules or formulas for each character that describe how the character should look using small lines, curves, etc. The shape of a character can also depend on the size that it's being rendered. For example, often a letter like 'g' will have a proportionally larger tail (or the curvy bit hanging underneath) when drawn in a small font size, and a proportionally smaller tail when drawn in a larger font size.
Then there's usually additional complexities involving the spacing between characters, where the space between some character pairs is reduced. For example, you might have 3 pixels between most characters (like 'M' and 'N'), but only one pixel spacing between 'L' and 'T'.
The complexities of caching adds to this, especially for Unicode fonts (tens of thousands of characters per font) where multiple fonts can be in use at the same time, and you want to cache pre-rendered data and raw font data to improve performance - balancing memory requirements, disk IO and performance can be tricky.
Also, for multi-lingual support, characters may need to drawn from right to left rather than from left to right, and the direction things are drawn may change several times within the same string when different languages are mixed.
My advice here is to get a simple font renderer working for now that just renders ASCII using the 8 * 8 and/or 8 * 16 font data from the BIOS, and forget about all this (except for making it generate output in the format you intend to use later). Support for full Unicode and proper font data formats can be added later.
Cheers,
Brendan
AFAIK most font rendering engines convert a string of characters (Unicode or whatever) into a bitmap corresponding to the font & size selected.
Typically this bitmap represents how solid or transparent each pixel should be (for e.g. IIRC on windows, the bitmap contains values from 0 to 31, and for Linux it's from 0 to 255), but doesn't provide any other information (like the colour of each pixel), and doesn't change pixel information directly - the data from the font engine is applied to the pixel data later.
This allows for anti-aliased font data to be rendered and then re-used by the client, and/or frequently used data to be cached by the font renderer.
Most font renderers will work with a range of different font data formats (some patented). Most font data formats consist of a set of rules or formulas for each character that describe how the character should look using small lines, curves, etc. The shape of a character can also depend on the size that it's being rendered. For example, often a letter like 'g' will have a proportionally larger tail (or the curvy bit hanging underneath) when drawn in a small font size, and a proportionally smaller tail when drawn in a larger font size.
Then there's usually additional complexities involving the spacing between characters, where the space between some character pairs is reduced. For example, you might have 3 pixels between most characters (like 'M' and 'N'), but only one pixel spacing between 'L' and 'T'.
The complexities of caching adds to this, especially for Unicode fonts (tens of thousands of characters per font) where multiple fonts can be in use at the same time, and you want to cache pre-rendered data and raw font data to improve performance - balancing memory requirements, disk IO and performance can be tricky.
Also, for multi-lingual support, characters may need to drawn from right to left rather than from left to right, and the direction things are drawn may change several times within the same string when different languages are mixed.
My advice here is to get a simple font renderer working for now that just renders ASCII using the 8 * 8 and/or 8 * 16 font data from the BIOS, and forget about all this (except for making it generate output in the format you intend to use later). Support for full Unicode and proper font data formats can be added later.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
-
Xardfir
Re:vesa question
Hiya,
No need to scan through bit by bit. A character is formed of eight bytes, you put out one byte at a time each in a successive row. This is simplest in black and white (or a single plane of VGA/EGA).
Depending on the plane where you put the byte will set the colour of that character. So a simple 8x8 character will take minimum 8 mov's to put onscreen. For flat frame buffer an extra addition is need to put the next part of the bitmap on the next line down. Bitmapped fonts are just small 'windows' or sprites if your Commodore 64'ish. Build them, blit them just like a window. As small or as big as you need.
So in simplicity, for a basic font system - design your font's in paintshop / photoshop - make them all the same size. Save them in a flat RAW format. Then copy them as needed using a simple loop.
Add some scaling, ability to set colour, some rotation routines......Still not as visually exciting as vector font but cheap, cheerful and graphical.
AT BIOS I have lying around uses this method, but adds the complication that CGA splits it's scanlines into two seperate fields.
No need to scan through bit by bit. A character is formed of eight bytes, you put out one byte at a time each in a successive row. This is simplest in black and white (or a single plane of VGA/EGA).
Depending on the plane where you put the byte will set the colour of that character. So a simple 8x8 character will take minimum 8 mov's to put onscreen. For flat frame buffer an extra addition is need to put the next part of the bitmap on the next line down. Bitmapped fonts are just small 'windows' or sprites if your Commodore 64'ish. Build them, blit them just like a window. As small or as big as you need.
So in simplicity, for a basic font system - design your font's in paintshop / photoshop - make them all the same size. Save them in a flat RAW format. Then copy them as needed using a simple loop.
Add some scaling, ability to set colour, some rotation routines......Still not as visually exciting as vector font but cheap, cheerful and graphical.
AT BIOS I have lying around uses this method, but adds the complication that CGA splits it's scanlines into two seperate fields.
-
srg_13
Re:vesa question
Hey,
Is there an easy way to load the ROM font in protected mode? I wrote some code to print strings with a font I was writing, but I only did up to letter H, before I went searching for a better way.
If not, does anyone have any links to other fonts?
-Stephen
Is there an easy way to load the ROM font in protected mode? I wrote some code to print strings with a font I was writing, but I only did up to letter H, before I went searching for a better way.
If not, does anyone have any links to other fonts?
-Stephen
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:vesa question
- you have the option of setting graphic video in realmode, have characters drawn by the BIOS, and then capture their pixels by hand.Stephen wrote: Hey,
Is there an easy way to load the ROM font in protected mode? I wrote some code to print strings with a font I was writing, but I only did up to letter H, before I went searching for a better way.
- you may want to do the same with any fixed font. I should have a grab of the terminal font of my linux box that i submitted to candy. I also have a fun handdrawn limitted font in my CVS, together with the adapted renderer from Candy. just checkout the sylvain.* files if you want the font.
@candy: i still have your files from candy.dublet.org unmodified (afaik). I'll put them online asap.
Re:vesa question
Hi,
The IVT entry for int 0x1F actually points to the segment:offset of the BIOS's 8 * 8 font data, but it's only the first 128 characters. This means that in protected mode you can do something like:
If you can run real mode code during boot, then you can use BIOS int 0x10, AX = 0x1130 to get the address of the 8 * 8 font data (both halves), the address of the 8 * 16 font data and the address of the 9 * 16 font data. See http://www.ctyme.com/intr/rb-0158.htm.
@pype: I'm not sure if capturing the BIOS font data and including/distributing it as binary data in an OS is an option - wouldn't this be copyright infringement?
Cheers,
Brendan
An "IBM PS2" compatible BIOS stores the font data at specific locations within the BIOS ROM area. I don't use this method because I don't know how many BIOSs are still compatible.Stephen wrote:Is there an easy way to load the ROM font in protected mode? I wrote some code to print strings with a font I was writing, but I only did up to letter H, before I went searching for a better way.
The IVT entry for int 0x1F actually points to the segment:offset of the BIOS's 8 * 8 font data, but it's only the first 128 characters. This means that in protected mode you can do something like:
Code: Select all
movzx ebx,word [0x1F * 4 + 2] ;ebx = real mode segment
movzx eax,word [0x1F * 4] ;eax = real mode offset
shl ebx,4 ;ebx = real mode base address
add eax,ebx ;eax = address of BIOS's 8 * 8 character font data (first 128 characters only)@pype: I'm not sure if capturing the BIOS font data and including/distributing it as binary data in an OS is an option - wouldn't this be copyright infringement?
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:vesa question
lol. Indeed, it may. It that concerns you, just grab it at each bootBrendan wrote: @pype: I'm not sure if capturing the BIOS font data and including/distributing it as binary data in an OS is an option - wouldn't this be copyright infringement?
Using the BIOS's font on the PC where the ROM is available shouldn't enfringe anything afaik.Re:vesa question
thanks... I think they contained the most recent version of my OS, which would come in handy in continuing on it.Pype.Clicker wrote: @candy: i still have your files from candy.dublet.org unmodified (afaik). I'll put them online asap.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:vesa question
http://www.sylvain-ulg.be.tf/scene/fontcandy/fr.html
there they are ... the "sylvain" font is public domain, but it doesn't contain the whole ascii charset: only uppercase characters and a few 'special' characters.
The two other are based from snapshot of unix terminals, so they might not be as free as the previous one...
there they are ... the "sylvain" font is public domain, but it doesn't contain the whole ascii charset: only uppercase characters and a few 'special' characters.
The two other are based from snapshot of unix terminals, so they might not be as free as the previous one...