OSDev.org

I have no box that isnt VGA compatible, and I have quite a few including old ones...

Tested on the older ones: S3 Trio64, Rendition V2x00, ATI 264VT, ATI Mach64,
and the newer ones: 3D Rage, 3D Rage Pro, Rage IIC, GF4 MX440, GF6200 GF6150, ATI X300
And the emu's which also emulate old cards: Cirrus Logic, S3

Basically, if you have an unsupported card your kernel probably wouldn't run anyway

Combuster wrote:I have no box that isnt VGA compatible, and I have quite a few including old ones...

It might well be a Tseng ET4000/W32p that caused me troubles, but it's 13 years ago, so I may be wrong. Another good possibility is that I just had a bug in my code, that the Trident 8900 had no problems with, but the Tseng did. O well, we'll never know (unless I build up my old systems again, but I don't see that happening anytime soon).


JAL

Not to mention the listings on the wiki: VGA Hardware, so yes you can change modes without using the bios. All it takes is a driver, and most chips support the VGA register set anyway.

Hm... I havnt actually seen that artical. Its quite a good resource as well.

Im stuck in a problem here. Vesa, although popular, is not supported on all x86 machines. vga programming can also get very complex, and the series would be incomplete if we just tell the reader to "read this nice tutorial on programming the vga", and develop a video driver without much explanation. Then again - it is an option.

...Then again, as you said - there are already alot of resources on it. Alot of these resources may be quite complex to a reader with no prior graphics programming experience, though.

At the moment, we are developing tutorials for a variety of controllers for our hardware abstraction layer.

How do you think we should proceed? We are looking for opinions here

Thanks for the feedback so far.

If you want to have priorities on tutorials, I don't think the VGA is the best option - since the DOS games were discontinued true VGA programming has been off. Besides, the combined might of FreeVGA, the ModeX tutorials, GPBB and the Wiki article don't cover all the details of the VGA in explainable language. There are things in the wiki that are the result of lots of experimentation (and are not covered elsewhere AFAIK).

Once I get my kernel rewrite up to the stage where drivers become interesting again I'll probably continue work on that page, possibly including sample code and howto's for neat tricks.

Besides most people are likely to take the easy route: do a mode change call and use the LFB afterwards. Some might indeed bump the card with a register set but will still use LFB-style addressing making the actual VGA details uninteresting. Besides, from the game industry we know that funky graphics is an excuse to overlook gameplay...

-----------------

I think something like a HD/CD driver tutorial will be more welcomed (and useful, especially for those that are indeed booting from CD rather than that crappy 1.4M medium)

Hey everyone,

I am going to bump this thread to purpose another idea that might work for the series.

Instead of focusing on all of the controller tutorials, I am thinking of this:

>1 - Hardware Abstraction Layer (HAL)

The next section covers hardware abstraction in theory, and impliments a basic HAL. To keep portability, I decided to treat this as a static library that may be linked with the Kernel. This can easily be fixed to output a dynamic library as well.

The next thing to focus on would need to be assembly language abstraction, along side processor and architecture abstraction. This would provide an interface for the Kernel, and other driver software that is linked with the HAL.

>2 - Kernel: GDT, Interrupt Handling, PIT

These things are indeed covered alot. However, alot of this will be implemented through the HAL to keep the kernel code hardware independent. I dont know of any tutorials that cover it this way.

The basic idea is: Throughout each chapter, the chapter will include sections that add onto the current HAL. So, instead of "Building a complete HAL first", we gradually build on it when we need to and cover new topics.

---

What do you think about this setup? This will also allow us more freedom and linking resources to help developers with areas that are complex, or are already explained very well in depth.

irr cant be accessed?
imr is masked before eoi? wtf, my tests prove otherwise.

a5498828 wrote:irr cant be accessed?
imr is masked before eoi? wtf, my tests prove otherwise.

What does that have to do with anything in this thread? Furthermore, did you look at the date of the last post in this thread?

a5498828 wrote:irr cant be accessed?
imr is masked before eoi? wtf, my tests prove otherwise.

Are you drunk?
Completely off topic.

a5498828 wrote:irr cant be accessed?

Tutorial wrote:This register is internal, and cannot be accessed directly

Its RO, and you might need your infamous OCW3. In other words: the "learn to read" message applies yet again.

And please cut on your verbal aggression, you already have bad karma and this is not making it better at all. Please look up "Constructive criticism"