New fonts
Re: New fonts
If you choose graphics mode, then there are free unicode bitmap fonts available in various sizes:
http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html
Try downloading http://www.cl.cam.ac.uk/~mgk25/download ... nts.tar.gz and take a look at 9x18.bdf or 10x20.bdf (they both contain glyphs for your language). Some of the font files contains more glyphs than others. Some files are postfixed with O (italic) and B (bold). The BDF format is quite easy to understand; here you find the specification: http://www.x.org/docs/BDF/
If you set the goal for Unicode support, here are some text files to help you test and diagnose problems in your text renderer: http://www.cl.cam.ac.uk/~mgk25/ucs/examples/
And by the way, the 8x13.bdf font might fit the text mode BIOS fonts, but they doesn't contain any glyphs for your language. As Brendan noticed, it is difficult to draw the glyphs using only 7 pixel width.
Just my 2 cents.
EDIT: You can view the fonts using a font editor like FontForge (or another one).
http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html
Try downloading http://www.cl.cam.ac.uk/~mgk25/download ... nts.tar.gz and take a look at 9x18.bdf or 10x20.bdf (they both contain glyphs for your language). Some of the font files contains more glyphs than others. Some files are postfixed with O (italic) and B (bold). The BDF format is quite easy to understand; here you find the specification: http://www.x.org/docs/BDF/
If you set the goal for Unicode support, here are some text files to help you test and diagnose problems in your text renderer: http://www.cl.cam.ac.uk/~mgk25/ucs/examples/
And by the way, the 8x13.bdf font might fit the text mode BIOS fonts, but they doesn't contain any glyphs for your language. As Brendan noticed, it is difficult to draw the glyphs using only 7 pixel width.
Just my 2 cents.
EDIT: You can view the fonts using a font editor like FontForge (or another one).
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: New fonts
Euhm, the VGA font is 8 pixels wide. And it can be configured to add an extra empty 9th row so that you can indeed use the full 8 pixels without making the glyphs touch each other.
[edit]As mystran said, rows must be columns [/edit]
[edit]As mystran said, rows must be columns [/edit]
Re: New fonts
Maybe he would be able to use the 9x18.bdf font then. But some of the characters (fx. 0x1328) use all 9 pixel, even though most just have an empty 9th row. Maybe characters like 0x1328 are not used together with other that also use 9 pixels. That wouldn't look nice.Combuster wrote:Euhm, the VGA font is 8 pixels wide. And it can be configured to add an extra empty 9th row so that you can indeed use the full 8 pixels without making the glyphs touch each other.
Re: New fonts
There is no empty row. In fact we're confusing rows and columns here, but there isn't an empty column either. It's just that one of the columns gets duplicated in 9-pixel wide modes.Walling wrote:Maybe he would be able to use the 9x18.bdf font then. But some of the characters (fx. 0x1328) use all 9 pixel, even though most just have an empty 9th row. Maybe characters like 0x1328 are not used together with other that also use 9 pixels. That wouldn't look nice.Combuster wrote:Euhm, the VGA font is 8 pixels wide. And it can be configured to add an extra empty 9th row so that you can indeed use the full 8 pixels without making the glyphs touch each other.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Re: New fonts
I'm confused already Personally I would use the graphical mode anyway and the "software-text-console" you mentioned. It has the possibility for new features. If I want another font size, no problem.mystran wrote:There is no empty row. In fact we're confusing rows and columns here, but there isn't an empty column either. It's just that one of the columns gets duplicated in 9-pixel wide modes.
Re: New fonts
You are wrong. The duplication only happens for certain 'graphic' characters. There was a recent thread that discussed this.mystran wrote:There is no empty row. In fact we're confusing rows and columns here, but there isn't an empty column either. It's just that one of the columns gets duplicated in 9-pixel wide modes.
JAL
Re: New fonts
Ok thanks for correcting me then. Should double check before posting from memory.jal wrote:You are wrong. The duplication only happens for certain 'graphic' characters. There was a recent thread that discussed this.mystran wrote:There is no empty row. In fact we're confusing rows and columns here, but there isn't an empty column either. It's just that one of the columns gets duplicated in 9-pixel wide modes.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Re: New fonts
So yea, I was wrong, you were right.Fonts are either 8 or 9 pixels wide and can be from 1 to 32 pixels high. The width is determined by the 9/8 Dot Mode field. Characters normally have a line of blank pixels to the right and bottom of the character to separate the character from its neighbor. Normally this is included in the character's bitmap, leaving only 7 bit columns for the character. Characters such as the capital M have to be squished to fit this, and would look better if all 8 pixels in the bitmap could be used, as in 9 Dot mode where the characters have an extra ninth bit in width, which is displayed in the text background color, However, this causes the line drawing characters to be discontinuous due to the blank column. Fortunately, the Line Graphics Enable field can be set to allow character codes C0h-DFh to have their ninth column be identical to their eighth column, providing for continuity between line drawing characters. The height is determined by the Maximum Scan Line field which is set to one less than the number of scan lines in the character.
http://www.osdever.net/FreeVGA/vga/vgatext.htm
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Re: New fonts
I have been away for a while. Coming back, I found many important things in the post. I can say I have learned lots of things. But still, I want to continue the discussion. My question: Is it possible to write graphics programs in a much higher resolution than 320x200 which is allowed by mode 13? For example like 640x480 or higher than that? Is Mode X an answer to this question?
Re: New fonts
Of course it's possible.
You can make a standard VGA graphics driver that allows to set 640x480x16colors, 320x200x256colors and ModeX.
Or, you can initialize to a VESA mode such as 800x600x16MillionColors while in real mode and then use the LFB in protected mode. And later make a V86 monitor for being able to access the BIOS in Protected Mode. That would be a very good solution.
The optimal solution would maybe involve adding support for Windows and/or Linux drivers in our Kernel and then load the drivers for our graphics card, etc. That would give us access to support the largest amount of hardware without having to write the drivers ourselves while having the possibility to rewrite our own ones.
Does anybody know how to do V86-like stuff in AMD64 Long Mode? I'm SURE V86 doesn't exist in 64-bit mode.
Here's an example of VESA code, it should be ran under pure DOS, either real or emulated in Bochs, etc. It needs some cleanup from useless comments and maybe you should try changing the 0x4113 numbers present by something like 0x4101, 0x4102 or 0x4112 in case your card doesn't support VESA mode 0x4113.
It's only to get started and it doesn't make any kind of test, so if you don't support VESA 2.x, LFB modes or the selected mode in the code lines commented with "vesa", then it will fail.
Compile with:
NASM vesa.asm -o vesa.com
You can make a standard VGA graphics driver that allows to set 640x480x16colors, 320x200x256colors and ModeX.
Or, you can initialize to a VESA mode such as 800x600x16MillionColors while in real mode and then use the LFB in protected mode. And later make a V86 monitor for being able to access the BIOS in Protected Mode. That would be a very good solution.
The optimal solution would maybe involve adding support for Windows and/or Linux drivers in our Kernel and then load the drivers for our graphics card, etc. That would give us access to support the largest amount of hardware without having to write the drivers ourselves while having the possibility to rewrite our own ones.
Does anybody know how to do V86-like stuff in AMD64 Long Mode? I'm SURE V86 doesn't exist in 64-bit mode.
Here's an example of VESA code, it should be ran under pure DOS, either real or emulated in Bochs, etc. It needs some cleanup from useless comments and maybe you should try changing the 0x4113 numbers present by something like 0x4101, 0x4102 or 0x4112 in case your card doesn't support VESA mode 0x4113.
It's only to get started and it doesn't make any kind of test, so if you don't support VESA 2.x, LFB modes or the selected mode in the code lines commented with "vesa", then it will fail.
Code: Select all
org 100h
bits 16
cli
xor eax,eax
mov ax,ds
shl eax,4
push eax
pop eax
mov ebx,GDT
add eax,ebx
mov [GDT+2],eax
lgdt[GDT] ;{6}
;Set CR0's PE bit:
;Set CR0's PE bit:
mov eax,cr0 ;{3}
inc ax ;{1}
mov cr0,eax ;{3}
push ds
push es
;Set 32-bit memory:
;Set 32-bit memory:
push byte SELDat32 ;{2}
pop ds ;{1}
push ds ;{1}
pop es ;{1}
dec ax ;{1}
mov cr0,eax ;{3}
pop es
pop ds
sti
;;Set VESA mode:
;;;
mov ax,0x4F02
mov bx,0x4113 ;vesamode
int 10h
mov ax,0xA000
mov es,ax
mov di,di
mov ax,0x1234
mov cx,(65536/2)
;rep stosw
;;Get VESA mode info to get the LFB address:
;;;
;mov AX, 0x0050
mov ax,ds
mov ES, AX
;mov DI, 0x0000
mov di,ModeInfo
mov edi,ModeInfo
mov AX, 4F01h
mov CX, 0x4113 ;vesamode
int 10h
cli
a32 mov edx,dword[ds:edi+40]
a32 mov edx,dword[es:edi+40]
mov edx,dword[ds:di+40]
mov edx,dword[es:di+40]
;a32 mov edx,dword[0x500+40]
;mov ebp,0xDEADDEAD
mov ebp,edi
mov edi,edx
push edi
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;mov edi,0xF0000000
mov ecx,((800*600*2)-1024)/4
push word 0
pop ds
push ds
pop es
mov eax,0x87654321
a32 rep stosd
;mov dword[edx],eax
pop edi
sti
;;Press a key to continue:
;;;
xor ah,ah
int 0x16
;;Return to DOS:
;;;
mov ah,0x4C
int 0x21
align 16
db "Signat1"
align 16
ModeInfo times 512 db 0
align 16
db "Signat2"
align 16
;;INIT: Data/Constants definitions and Arch. Structures
;;INIT: Data/Constants definitions and Arch. Structures
;;INIT: Data/Constants definitions and Arch. Structures
;INIT: GDT
;INIT: GDT
;INIT: GDT
GDT:
SELNull equ 0 ;As you may see, we have used
GDT_size: ;the Null Selector as the GDT
dw GDTsize ;pointer to load with LGDT.
GDT_actualPtr: ;
dd GDT ;You can see that the WORD at
dw 0x0000 ;the end of these 8 bytes are
;2 padding bytes with 0x0000.
SELCod32 equ 8
dw 0FFFFh ; bits 0-15 length (Bytes 0-1)
dw 00000h ; bits 0-15 base addr (Bytes 2-3)
db 0 ; bits 16-23 base addr (Byte 4)
db 10011010b ; bits 0-3 Type, 4 DT, 5-6 DPL & 7 P (Byte 5)
db 11001111b ; bits 16-19 length into 0-3, 6 D & 7 G (Byte 6)
db 0 ; bits 24-31 base addr (Byte 7)
SELDat32 equ 16
dw 0FFFFh ; bits 0-15 length (Bytes 0-1)
dw 00000h ; bits 0-15 base addr (Bytes 2-3)
db 0 ; bits 16-23 base addr (Byte 4)
db 10010010b ; bits 0-3 Type, 4 DT, 5-6 DPL & 7 P (Byte 5)
db 11001111b ; bits 16-19 length into 0-3, 6 D & 7 G (Byte 6)
db 0 ; bits 24-31 base addr (Byte 7)
GDT_end:
GDTsize equ (GDT_end-GDT)-1
;END: GDT
;END: GDT
;END: GDT
;;END: Data/Constants definitions and Arch. Structures
;;END: Data/Constants definitions and Arch. Structures
;;END: Data/Constants definitions and Arch. Structures
Compile with:
NASM vesa.asm -o vesa.com
YouTube:
http://youtube.com/@AltComp126
My x86 emulator/kernel project and software tools/documentation:
http://master.dl.sourceforge.net/projec ... 7z?viasf=1
http://youtube.com/@AltComp126
My x86 emulator/kernel project and software tools/documentation:
http://master.dl.sourceforge.net/projec ... 7z?viasf=1
Re: New fonts
Yes, it is possible in 16 color. What about in 256 or more colors with higher resolution like 640x480? Most operating systems do that I think. For example windows support many colors with higher resolution. Is it in VGA or VESA that they do this?
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: New fonts
You can readily push the VGA to 400x300 in 256-color mode. The main limit is that the dot clock is 28MHz max, which limits the resolution to these kind of values. If you take larger resolutions (VGA 800x600x4) then the refresh rate is so low that every sane person would get headaches, if the monitor even manages to display that.
You need VESA or specific graphics drivers to select a higher clock with corresponding resolution.
You need VESA or specific graphics drivers to select a higher clock with corresponding resolution.
Re: New fonts & Graphics Mode
I program the 800x600x256 color with the processor in protected mode.
Take a look at the program "tictactoe" on my website on how to boot the computer and set the graphics and processor mode. There is also one custom bitmap font.
TomT
http://ticon.net/~tatimmer/linux.html
Take a look at the program "tictactoe" on my website on how to boot the computer and set the graphics and processor mode. There is also one custom bitmap font.
TomT
http://ticon.net/~tatimmer/linux.html
Re: New fonts
It's VESA (the easiest) or using a native driver (there are dozens of different video drivers). Using vesa you cannot only select a 640x480x16colors, but also something like 640x480x16MillionColors or 32K Colors, if your card supports it. It's better if you have PC's equipped with VESA 2.x and Linear Frame Buffer support so you don't have the need to emulate Real Mode in a V86 monitor to access VESA BIOS functions that are "banked". If you have no LFB support in you video card, then I guess it will be difficult to support it without its own native driver. This is how VisOpSys does it, and I don't know how many other people does it this way.lataak wrote:Yes, it is possible in 16 color. What about in 256 or more colors with higher resolution like 640x480? Most operating systems do that I think. For example windows support many colors with higher resolution. Is it in VGA or VESA that they do this?
For what I remember, MenuetOS can use "banked" modes and LFB modes, so it would be great to take a look at the available source code to see how it could be done. Part or all of it could reside in the file "Vesa12.inc".
TomT, could you please check or change this part of your code:
Code: Select all
;File: boot2.s
;return vga mode info function
mov ax,0x4f01
mov cx,0x103 ;800x600x8bpp
mov di, vgamodeinfoblock ;bios will write to this memory
int 10h ;call bios
It has worked right for me, so don't take my word if you know it shouldn't be done. However, this change has worked right on all of my machines and Bochs.
YouTube:
http://youtube.com/@AltComp126
My x86 emulator/kernel project and software tools/documentation:
http://master.dl.sourceforge.net/projec ... 7z?viasf=1
http://youtube.com/@AltComp126
My x86 emulator/kernel project and software tools/documentation:
http://master.dl.sourceforge.net/projec ... 7z?viasf=1
Re: New fonts
Thanks for the tip, I will check this out.So that the mov cx,0x103 reads mov cx,0x4103?
I test on 3 computers and they are a couple years older than yours.
TomT