Video Seven VEGA VGA driver

[parabyte]

Video Seven VEGA VGA support. This is the last driver I have to port over from xt-elks, so that is the set finished.

The console drives the card either way and nothing is drawn from the kernel. What this adds is what the standard VGA register set cannot reach: the chip version, how much display memory is fitted, the monitor class and the board straps.

/bootopts v7=1 puts the card into VGA text mode 3 before console_init(). That is the only moment it can be done, because the console reads the display width out of the BIOS data area once as it starts and never looks again, so the same mode set made later changes the picture without the console knowing. With no v7= option the driver makes no BIOS calls before the console exists.

The adapter is a compile time choice. The VEGA is offered only when the Amstrad PEGA console driver is not selected, since the two are alternatives, so a kernel compiles in one adapter and pays for one. Both adapters' option words are gated on their own config symbols now rather than sitting in bss unconditionally.

Three tools come with it. v7info reports the board and dumps the extension registers, v7mode sets any mode the card offers and drives the extensions that are actually fitted, and v7show puts an image up and can read display memory back to prove every byte arrived. Several extension indices documented for the family are simply absent on a VEGA, they read FF and swallow writes, so the tools test a register before writing it rather than reporting success having changed nothing.

I have tested this extensively on my own hardware, an Amstrad PC1640 with the VEGA fitted. Both text and graphics, 640x480 and 800x600 and 720x540 and 752x410 and 320x200, images displayed in each and verified by reading display memory back byte for byte, the boot mode set, the extension registers, and repeated reboots. It builds three ways: VEGA on, VEGA off, and with the PEGA console selected instead, which excludes the VEGA.

Written from the V7 VGA Technical Reference Manual, June 1988. The URL is in Documentation/text/videov7.txt and in the header.

[ghaerr]

What is this? Is this a console driver that can be used instead of CONFIG_CONSOLE_DIRECT or CONSOLE_AMSTRAD_IGA?

Will this run on any PC using a Video 7 VEGA card, or just Amstrad?

What exactly does it do, is it just a "direct" console running on VGA, or is it running in graphics mode? I don't really understand what this is for.

[parabyte]

actually this does not bring anything to the table that elks does not currently provide

i will just rewrite the userland tools to do the same job. parse registers, and put data into registers to change adaptors mode, have observed that existing elks infrastructure supports all this correctly.

This is generic for any Video seven vega vga 8bit video card.

[ghaerr]

rewrite the userland tools to do the same job. parse registers, and put data into registers to change adaptors mode

Good idea. But what does this actually do? Switch text video modes, run 132x43, something else?

It seems the kernel portion just prints out some messages after reprogramming. Is that its entire purpose?

I have several issues with ifdef'ing the early kernel it, and too many ifdefs in the /bootopts code (yet again). If the VEGA actually needs to be initialized prior to console_init, there is a proper way to do that: put special code in console_init, not in the kernel main init function.

Which brings me to another point: now that I understand the AMSTRAD IGA a little better, I don't like the way I approved getting it implemented - what we've done is copy almost the entire console-direct.c and have a few functions rewritten for hardware scroll. (I know, I said do it that way, I apologize). The proper way to do this is to pull the set of functions out that need to be changed into a separate .c file (e.g. ScrollUp, ScrollDown etc). Then, have two .c files, one which uses the BIOS for the functionality, the other for your IGA code that uses hardware. Compile both (see #2796) and then link in the appropriate one via an ifdef CONFIG_AMSTRAD_IGA in console-direct.c.

The way we've now implemented this means that any change to the otherwise-unmodified direct console code now has to be done in two files - bad design. So I want to redo this. I will take the first step and pull out the functions, then you can test it and get it working again. Does that sound OK?

Given that after the above, console-direct.c will always be used for Amstrad, this allows you to do special handling, like v7_init. But I think there's a far better way - let the system come up normally, then run a user land mode switch program that switches the VGA to high-res text mode, then issue a new ioctl that tells the console the new lines/columns. In this way, since the kernel is limited in space, we don't have to have a bunch of resident code and special configuration options to switch modes, just run the vidmode program. This would also allow switching back to 25x80.

There are problems though with user land calling BIOS or video BIOS functions, the program could get switched out and the stack switched in the middle of the call. For now, we can live with it as a first pass, since our current graphics programs do the same thing (see below).

If you want to add a bunch of programs for displaying info, etc, instead of elkscmd/v7, I suggest you move them all to test/video or test/vega, where they will be built and treated mostly as "test" programs and until we figure out the best way to implement new functionality properly. I don't want the standard elkscmd/ to get to close to the hardware, as it is not portable, especially to the PM kernel (until more work is done).

I mention all this because it would be nice to have a video mode switch capability, for both extended text modes but more importantly to switch modes for the PM kernel. The problem with the PM kernel is that it can't call BIOS calls, in the kernel nor user land, so this gets complicated. The current set of graphics programs, paint, doom, Nano-X, etc all call INT 10 directly to switch to graphics mode and back from the program itself. We need to design a better way.