OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 7:06 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 33 posts ]  Go to page 1, 2, 3  Next
Author Message
 Post subject: drawing with VGA
PostPosted: Fri Oct 05, 2018 12:19 pm 
Offline
Member
Member

Joined: Wed Aug 29, 2018 4:42 pm
Posts: 122
hi,
i'm trying to write to screen with VGA.i can switch to some text and graphical modes, so that isn't the problem.but, i can't draw to screen. the idea is to write directly to video ram, and not using the bios.when i draw, it just draws something buggy, and also i can't set the color.how can i do it?. in my github repo, there is the way that i use to draw, but as i said, it's buggy.

Thanks!


Top
 Profile  
 
 Post subject: Re: drawing with VGA
PostPosted: Fri Oct 05, 2018 3:19 pm 
Offline
Member
Member
User avatar

Joined: Sun Sep 19, 2010 10:05 pm
Posts: 1074
First, be sure you have called the BIOS function to enable the A20 address line. Without that, you will only have access to half of the video memory.

Next, call BIOS function INT 10h with AL = 13h and AH = 0h to switch to Mode 13h.

Then write 0x01 to address 0xA0000 (or address 0x00 with the DS register set to 0xA000), and the next 64,000 bytes. This should set the entire screen to blue.

Let us know if it doesn't work, and we'll try to help you track down the issue.

Thanks.

_________________
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott


Top
 Profile  
 
 Post subject: Re: drawing with VGA
PostPosted: Fri Oct 05, 2018 5:53 pm 
Offline
Member
Member

Joined: Wed Aug 29, 2018 4:42 pm
Posts: 122
the A20 line is enabled, see in "Bootloader.asm" before calling the kernel.as i said, i wont use BIOS interrupts, the VGA driver is for computers that cannot use VM8086.so let me rewrite the question;i want to draw with VGA graphical modes without BIOS.

Thanks!


Top
 Profile  
 
 Post subject: Re: drawing with VGA
PostPosted: Fri Oct 05, 2018 7:36 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

alberinfo wrote:
i'm trying to write to screen with VGA.i can switch to some text and graphical modes, so that isn't the problem.but, i can't draw to screen. the idea is to write directly to video ram, and not using the bios.when i draw, it just draws something buggy, and also i can't set the color.how can i do it?. in my github repo, there is the way that i use to draw, but as i said, it's buggy.


I have no idea what your code is trying to do. It looks like it tries to use direct IO port writes to set a "640*480 with 16 colours" VGA mode (which is a horribly bad idea on its own - far too many things can go wrong); but then the code to draw pixels looks like it's designed for a "640*480 with 65536 colours" mode (that is not a VGA mode and can't be set using standard VGA IO ports).

Note that for "640*480 with 16 colours" VGA mode, video memory is split into 4 planes, where each plane contains one bit for each pixel and each pixel is spread across all 4 planes (a little bit like there's 4 separate 1-bit bitmaps). Normally you can't set a pixel with a single write (e.g. you need to change one bit in the first plane, then switch to the second plane, then change one bit in the second plane, then...); however there's various "write modes" (and masks and other logic) that (in theory) can be used to modify how the hardware processes a write and what it effects.

Please note that:
  • The only reliable way to switch video modes without using firmware is to write a native video driver for the specific card
  • A native video driver for the specific card is not a video driver for a "generic VGA" unless the video card actually is a genuine IBM VGA card from 1987
  • For systems with multiple monitors/multiple video cards; both can't be using the obsolete/legacy VGA IO ports at the same time. For this reason all modern video cards support memory mapped IO registers (e.g. likely found using PCI BARs) and these are what a native video driver should use (so that the driver actually works properly, even when there's multiple video cards).
  • The obsolete/legacy VGA IO ports may not exist on UEFI machines for multiple reasons (mostly so UEFI can support multiple video cards properly, but also because there's no reason for the chipset in an "UEFI only" system to support the crusty old junk involved in making VGA pretend to work - e.g. special "legacy IO port ranges" and "VGA pallete snoop" in PCI bridges, etc). Don't forget that what is currently the foreseeable future will be actually be "the foreseeable past" by the time your OS is finished/released (and even if it's just "learning" with no plan to release anything you don't want to fill your head with worthless/obsolete trivia by learning the wrong thing).
  • VGA modes are extremely ugly and nobody ever wants to look at them. People mostly only ever want to see their monitor's preferred resolution (e.g. maybe 1920*1600 with millions of colours), partly because it's the only resolution the monitor actually supports, and partly because it avoids (typically "cheap and nasty") scaling done in the monitor to convert a "wrong resolution" into what the monitor actually supports. You can find out what the only right resolution is by asking the monitor for its EDID and parsing it.
  • Code that generates graphics should use an abstraction that provides resolution independence (e.g. use millimeters and not pixels as its unit of measurement, so when the caller asks for a font that's 16 millimetres tall it can calculate out how many pixels that actually is and scale the font to suit) to avoid horrible design failures from the 1990s (e.g. tiny text on small screens, icon grids that get broken and ruin your desktop when the resolution changes, etc). Unfortunately (due to a combination of backward compatibility and stupidity - e.g. the original design of GDI) most old operating systems (Windows, Linux, ...) still struggle to do this properly; but you don't have backward compatibility to worry about so you have no excuse for doing it wrong.
  • Because the only resolution that should ever be used is the monitor's preferred resolution (or whatever is closest to that) and because you will/should have resolution independence (so applications never need to know or care what the resolution actually is, even when an application is spread across 2 or more monitors with completely different resolutions); if the best possible video mode is configured during boot (e.g. by boot loader using firmware without hideous error prone hackery) there are only 2 reasons to ever want to change video modes after boot:
    • The user replaced their monitor with a different monitor (with a different preferred resolution); which happens so rarely that (if you don't have a native video driver for the specific video card that's able to detect that the monitor was changed and obtain the EDID for the new monitor) it's not unreasonable to expect the user to reboot in this case.
    • You weren't able to use the best possible video mode for the monitor during boot (e.g. due to limitations in the firmware/video card's ROM) but started a native video driver designed for the specific video card that is able to set the best possible video mode for the monitor. In this case it's reasonable for the native video driver to change video modes once as part of the device driver's initialisation; but that's no problem because you have native video driver for this to happen in the first place.

In other words; you seem to be doing a lot of unnecessary work (virtual8086 mode, native VGA driver) to get everything wrong for no sane reason (because you've assumed that the OS should be able to change video modes after boot when it mostly should not).


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.


Top
 Profile  
 
 Post subject: Re: drawing with VGA
PostPosted: Sat Oct 06, 2018 8:50 am 
Offline
Member
Member

Joined: Wed Aug 29, 2018 4:42 pm
Posts: 122
hi,
thanks for your reply.but the idea for the operating system is to revive old computers, that doesn't work with new OS like windows or linux, like x86 computers, but also to be able to run in new computers.so VGA isn't the way, ok, but then, how to set a graphical mode and write to the screen without bios, and that it's capable to run in any graphics card, like a univesal method?

Thanks!


Top
 Profile  
 
 Post subject: Re: drawing with VGA
PostPosted: Sat Oct 06, 2018 11:16 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

alberinfo wrote:
thanks for your reply.but the idea for the operating system is to revive old computers, that doesn't work with new OS like windows or linux, like x86 computers, but also to be able to run in new computers.


How old (e.g. so old that you need to worry about EGA too)? Don't forget that 64-bit 80x86 was released in 2003 (15 years ago), and for computers "old" mostly means "about 10 years old", which (for the low-end) translates to "dual core 64-bit CPU with 2 GiB or more RAM and a video card & monitor capable of 1366*768 or better".

alberinfo wrote:
so VGA isn't the way, ok, but then, how to set a graphical mode and write to the screen without bios, and that it's capable to run in any graphics card, like a univesal method?


There is none.

The only universal option is to use the firmware (including VBE on BIOS, and GOP and UGA on UEFI); and for UEFI systems you can't use GOP or UGA after boot (and can only continue using the video mode and framebuffer that was setup during boot).


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.


Top
 Profile  
 
 Post subject: Re: drawing with VGA
PostPosted: Sat Oct 06, 2018 11:30 am 
Offline
Member
Member

Joined: Wed Aug 29, 2018 4:42 pm
Posts: 122
so, what about setting up a framebuffer in the 'kernelloader'?i think it could solve this problem


Top
 Profile  
 
 Post subject: Re: drawing with VGA
PostPosted: Sat Oct 06, 2018 11:49 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

alberinfo wrote:
so, what about setting up a framebuffer in the 'kernelloader'?i think it could solve this problem


I'm not sure what your "kernel loader" actually does; but if it has access to firmware's functions (or can get access to them) then it will work (and is the only option I'd recommend).

Note that for multi-boot (e.g. GRUB) it's not so simple - if you boot from UEFI then the boot loader calls "exitBootServices()" before starting any of your code so none of your code can use the UEFI functions for video. In this case the only sane (easy, reliable-ish and future proof) option is to let the boot loader setup a video mode before starting your code (e.g. before starting your "kernel loader"?) and let the boot loader tell your code the details for the video mode it set up for you (framebuffer address, resolution, pixel format, pitch, etc).


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.


Top
 Profile  
 
 Post subject: Re: drawing with VGA
PostPosted: Sat Oct 06, 2018 12:38 pm 
Offline
Member
Member
User avatar

Joined: Sat Nov 22, 2014 6:33 pm
Posts: 934
Location: USA
alberinfo,

I totally agree with Brendan's statement:
Brendan wrote:
...the only sane (easy, reliable-ish and future proof) option is to let the boot loader setup a video mode before starting your code (e.g. before starting your "kernel loader"?) and let the boot loader tell your code the details for the video mode it set up for you (framebuffer address, resolution, pixel format, pitch, etc).

This is the best way to do it and then once your kernel takes over, it can (if it so desires) search for and enumerate the video card, load a driver for it, then using that driver, change to a different/better video mode. Only this way is the best and most reliable way to do this.

The enumeration of the video card can be early in the loading stage, where there is a flicker of the screen from the mode the firmware set to the new mode of the newly loaded driver, or it can be later in the stage where you have loaded/started your GUI and there let the driver change the mode.

There is no easy way around it. You can't get to the best screen mode without a bit of work first. Sorry.

Ben


Top
 Profile  
 
 Post subject: Re: drawing with VGA
PostPosted: Sun Oct 07, 2018 8:55 am 
Offline
Member
Member

Joined: Wed Aug 29, 2018 4:42 pm
Posts: 122
ok.the bootloader is grub, the "kernelloader" is in my repo as "bootloader.asm".so in bootloader.asm i'm in protected mode, so the only way aviable for setting up a framebuffer is in grub?


Top
 Profile  
 
 Post subject: Re: drawing with VGA
PostPosted: Sun Oct 07, 2018 9:14 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
Short of writing drivers for a number of different possible hardware configurations, yes. Note that to use modes not supported by the boot loader (whether GRUB or the UEFI loader), or most 2D or 3D acceleration features, you would need to write device-specific drivers eventually, anyway.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: drawing with VGA
PostPosted: Mon Oct 08, 2018 5:08 pm 
Offline
Member
Member

Joined: Wed Aug 29, 2018 4:42 pm
Posts: 122
i've made a way to draw through VGA set by the io ports(Yes, I know your recommendations for not setting a video mode through io ports, but I think I'm still at a very early stage of development to start writing specific drivers)which works fine.the max resolution that i can get is 640x480x16, which is not the best, but it's fine.i've seen that theres a horizontal table and a vertical table for the video modes, so i was thinking, can i write another table(in the repo ar tbl_hor(or ver for vertical res)_gra(or txt for text modes)and then the number of pixels), so i can use 800x600x16?


Top
 Profile  
 
 Post subject: Re: drawing with VGA
PostPosted: Mon Oct 08, 2018 8:03 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

alberinfo wrote:
i've made a way to draw through VGA set by the io ports(Yes, I know your recommendations for not setting a video mode through io ports, but I think I'm still at a very early stage of development to start writing specific drivers)which works fine.the max resolution that i can get is 640x480x16, which is not the best, but it's fine.i've seen that theres a horizontal table and a vertical table for the video modes, so i was thinking, can i write another table(in the repo ar tbl_hor(or ver for vertical res)_gra(or txt for text modes)and then the number of pixels), so i can use 800x600x16?


In theory you can misconfigure a VGA controller to get a 800x600x16 video mode. The problem is that pixel clock isn't fast enough to match any standard/established video timing (it'd be something like "800x600x16 at 47 frames per second") so most monitors won't support it because they won't recognise the video timing.

Note that the slowest standard/established video timing would be "800x600 at 56 Hz (non-interlaced)"; and this video timing needs a 36 MHz pixel clock (VGA only has 28.322 MHz). You'd also need to get the horizontal and vertical sync pulse polarities right (both positive not both negative like you'd use for 640*480) and make sure all the other timing (front porch width, sync pulse width, back porch width; for both horizontal and vertical timing) is correct.

To set up a faster pixel clock (to get an 800x600 video mode timing the monitor is more likely to recognise) you need to use "non-standard, non-VGA", and that means you'd need a native driver for each specific video card.

You should also understand that there's "safe mode timings" that all monitors are supposed to support (which includes the "640*480 at 60 Hz" timing that VGA provides); and everything else is optional and may not be supported by the monitor. For this reason, if you're not using a safe mode timing, then you should ask the monitor what it supports (by obtaining and parsing its EDID) before attempting to set a (potentially unsupported) video mode.


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.


Top
 Profile  
 
 Post subject: Re: drawing with VGA
PostPosted: Wed Oct 10, 2018 6:11 am 
Offline
Member
Member

Joined: Wed Aug 29, 2018 4:42 pm
Posts: 122
thanks, but i wont write a specific driver just for a 800x600 resolution, also note that(as far as i understand) the 800x600 standard is established by SVGA and not by VGA.

Thanks!


Top
 Profile  
 
 Post subject: Re: drawing with VGA
PostPosted: Wed Oct 10, 2018 6:43 am 
Offline
Member
Member

Joined: Tue May 13, 2014 3:02 am
Posts: 280
Location: Private, UK
alberinfo wrote:
the 800x600 standard is established by SVGA and not by VGA.


That depends on what you mean by "standard"... An 800x600 16-colour mode is possible on a standard VGA card, but won't be compatible with a standard VGA monitor (most later SVGA multisync monitors will accept it though). The "standard" VGA video modes with BIOS assigned numbers are a reletively small subset of what the hardware is actually capable of.

Also, SVGA was never really a "standard"; until VBE was established in the mid-late 1990s any software wanting to use "better than VGA" graphics capabilites needed hardware-specific drivers (or run under an OS with such drivers). That's one reason that that 800x600 16-colour mode was actually used occasionally (Windows 9x even included a driver for it); it could be used on most "SVGA" hardware and didn't require the developer to know exactly what variant of "SVGA" the user had.

Anyway, unless you're programming impressive graphics demos for late-1980s to early-1990s hardware, it's probably best to stick to "standard" graphics modes (although the 320x240 "mode-X" mode is highly compatible and offers the advantage of sqaure pixels over the standard 320x200 mode, so might be worth some consideration).

_________________
Image


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 33 posts ]  Go to page 1, 2, 3  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot] and 78 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group