Date: Sun, 10 Aug 1997 18:35:29 -0700 From: Jonathan Mini <j_mini@efn.org> To: "Helmut F. Wirth" <hfwirth@ping.at> Cc: emulation@freebsd.org Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) Message-ID: <19970810183529.06224@micron.efn.org> In-Reply-To: <33EE2917.41C67EA6@ping.at>; from Helmut F. Wirth on Sun, Aug 10, 1997 at 10:48:23PM %2B0200 References: <199708090129.PAA08057@pegasus.com> <33EC7977.167EB0E7@ping.at> <19970809235411.04335@micron.efn.org> <33ED7E33.167EB0E7@ping.at> <19970810043000.13645@micron.efn.org> <33EE2917.41C67EA6@ping.at>
next in thread | previous in thread | raw e-mail | index | archive | help
To be honest : Have you ever written a video driver for such cards? It's not as simple as you are making it sound. Win95 has a "generic SVGA" dirver, which is really a VESA VBE driver. You are wrong on a few details, which will prove to be fatal. It would be best to emulate the VGA good enough to provide the proper access for the 16 color modes, and perhaps some stuff to allow the app to put the card into the non-planar 256 color modes. Those modes use the same hardware as the 16 color modes, so you don't really need to write any new code :) (just the ones to detect a 320x240 mode set, or some such) IMO, thought a driver good enough to handle the standard BIOS VGA modes is good enough for our surrent purposes. Helmut F. Wirth stands accused of saying : > I think we would need VGA emulation only for the true (old) VGA modes, > that is the > modes with 16 colors, dealing with planes. The 256 color modes and the > HiColor and > TrueColor modes are pretty simple: The card has to be brought into the > mode and then > most things take place via a direct write to the frame buffer. The only > register accesses in this state are the bank switching, in case of 256 > colors the video palette > access and for games probably the change to different video buffers, if > video memory > is big enough and the mode allows it. A program that uses the hardware > acceleration > capabilities of for example a S3 card would not work this way, and I > think under X11 > it would not be worth the trouble. If somebody needs use such a program, > s/he could > use it in console mode without X11. Some sort of VESA emulation could be > neccessary, > but only the part of it a program needs to inform itself about the cards > capabilities. > Windows 95 has a SVGA generic driver which works with a lot of cards, > including my > S3 Virge/VX. This is because as long as you don't try to use the > hardware specialities > of your S3/Cirrus/Matrox/... most cards are compatible in some basic > things. So the > emulator would report an ordinary SVGA for all cards under X11 and > proceed to emulate > the simple capabilities of such a card. > > > > Not for anything but a few video modes. (i.e. text modes and like > > 320x200x256) Also, I am leery of letting my DOS app change the state of my > > system console's hardware. > > I don't think this would be a problem: If the original card BIOS is > enabled, doscmd > could sneak in a call to the BIOS before it terminates and such use the > BIOS to restore > the cards hardware to the initial (ASCII) state, this is the same state > as after a > reboot, so the BSD console driver can handle it. XFree also messes with > your console > and even without BIOS support manages to restore all. The state has to > be saved before > any DOS application starts and must be restored, when doscmd ends. All > things in between > are under control of the BIOS, and this is the best 16-bit program one > can get for > the display hardware. The reason it is not used with XFree is only the > problems with > the different OSes XFree86 runs on and the problem to bring a VM86 > emulation for > every of this OSes, solely for the VGA BIOS. > -- > Helmut F. Wirth > Email: hfwirth@ping.at -- Jonathan Mini (j_mini@efn.org) ... bleakness ... desolation ... plastic forks ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970810183529.06224>