> Granted, one could add drivers for specific hardware, and have the
> kernel routine detect and use it in preference to the BIOS driver if
> the relevant driver is present, but I wouldnae see such as a first
> choice for getting a working video subsystem...
Yes, get it working first, optimize later...
>
> Whilst we're on the subject, let's enumerate the various different
> video subsystems we may need to handle, assuming a genuine XT clone of
> some sort:
>
> 1. IBM MDA.
> 2. Hercules MDA.
> 3. CGA.
> 4. EGA.
** 640x350 16 color 4 plane
> 5. MCGA.
> 6. XGA.
> 7. VGA.
** 640x480 16 color 4 plane
> 8. Assorted SVGA modes - how many are there now?
TSENG LANGS 800x600 16 color
> 9. Tandy 1000 range.
> 10. Tandy 2000 range.
> 11. DEC Rainbow range.
> 12. Olivetti computers ???
>
I have written a driver for nanoX over the weekend (it doesn't quite work yet,
we had two NBA playoff games to win) that implements native (that's right, no
bios required!) execution on the above ** hardware. The driver is compiled
for one of the three modes. I do call the bios to get the native graphics rom
character
set address right now once, but that will go away when loadable fonts are implemented.
I am interested if there's anyone on this list who has native mode code for
other screens for the above...
Greg
> Others, anybody?
>
> Best wishes from Riley.
>
> +----------------------------------------------------------------------+
> | There is something frustrating about the quality and speed of Linux |
> | development, ie., the quality is too high and the speed is too high, |
> | in other words, I can implement this XXXX feature, but I bet someone |
> | else has already done so and is just about to release their patch. |
> +----------------------------------------------------------------------+
> * ftp://ftp.MemAlpha.cx/pub/rhw/Linux
> * http://www.MemAlpha.cx/kernel.versions.html
>
