Date: Sat, 9 Aug 1997 23:54:11 -0700 From: Jonathan Mini <j_mini@efn.org> To: "Helmut F. Wirth" <hfwirth@ping.at> Cc: Richard Foulk <richard@pegasus.com>, emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) Message-ID: <19970809235411.04335@micron.efn.org> In-Reply-To: <33EC7977.167EB0E7@ping.at>; from Helmut F. Wirth on Sat, Aug 09, 1997 at 04:06:47PM %2B0200 References: <199708090129.PAA08057@pegasus.com> <33EC7977.167EB0E7@ping.at>
next in thread | previous in thread | raw e-mail | index | archive | help
Helmut F. Wirth stands accused of saying : > Richard Foulk wrote: > > I wouldn't have to be slow. You have more horsepower on the X side > > than on the DOS side. It has the potential of being faster I think. > > > The implementation idea I have is this: > While under X11 supply a minimal VGA BIOS with callbacks to > the emulator. Keep track of the mode changes from the DOS programs. > Supply a video memory and a palette for the DOS program to change. > That is, if a call is made to Int10/Change palette, the emulator > would update its ides of the palette. The DOS program would write > directly into the supplied video memory, thinking it real. (There > are some details with bank switching). This would emulate an unique > VGA mode, for example 640x480 with 256 colors. But the Xserver could Um. Have you looked at the VGA specification? Two things : 1) 640x480x256 isn't a VGA video mode. 2) "some details of bank switching" is a little more complex than that, especially for 4 bit (16 color) modes, such as 640x480x16. I am all for VESA VBE support for doscmd, but that's a different issue entirely over VGA support. Also, remeber that simply supporting the VGA BIOS calls (int 10h "Video Services") won't be an sufficient emulation -- you need to implement emulation for a VGA card, because most programs only use the BIOS to set video modes. > use (and in fact will) an entirley other mode. I use 1152x864 with > 65536 colors (=16 bit). Therefore: As long as the application runs > in a *window* the graphics would have to be changed for the real > vodeo mode the system is using. This could be done by copying the > fake video buffer and remapping the pixels using the palette copy > supplied from the DOS program. And this would be slow. I think fast > enough to be usable, but not faster than DOS. Not really. Slow is relative -- I think it would be faster than the method that DESQview used to do the same thing. I think that if you did a few sanity check on it (like allow yourself to resize the window for the different video modes) and possibly provide pixel multipliers for various video modes (for example, when the application asks for mode 13h, (320x200x256) you automatically resize the window to 640x400 and double the pixels) it would run at an acceptable speed. (even on slower systems, I would bet) If you do do things like pixel doubling, I would like to see it aconfigurable option. > Using the XFree86 DGA extension and the ability to switch modes > via software maybe it would be possible to act like the DOS box > under MSWindows. This woulde be faster, but it would not be inside > a window. The application would takeover the XServer and the entire > screen, until ASCII mode is restored. IMO, while this is possible, it is not the best alternative. > Any better ideas ? What you're describing sounds more like VESA VBE emulation than VGA emulation, but I would like to see both. :) > -- > 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?19970809235411.04335>