Date: Sun, 10 Aug 1997 10:39:15 +0200 From: "Helmut F. Wirth" <hfwirth@ping.at> To: Jonathan Mini <j_mini@efn.org> Cc: emulation@freebsd.org Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) Message-ID: <33ED7E33.167EB0E7@ping.at> References: <199708090129.PAA08057@pegasus.com> <33EC7977.167EB0E7@ping.at> <19970809235411.04335@micron.efn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jonathan Mini wrote: > > 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. True. I was sloppy to call it that. But todays VGAs are nearly all SVGAs. > 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. Yes. IMHO we would need to support only a few modes for starters. > > 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. :) I was thinking of a sort of VESA emulation. But a full VGA emulation including a VESA BIOS emulation is much work. We would need to monitor in/out commands to many VGA registers. I thought a little about doscmd in console mode too, that is when no Xserver is running. Here it should be possible to do real hardware access for hardware not sensitive for the kernel and security. For doscmd in non X11 environments I think we could simply map the VGA/VESA original BIOS of the card and use it under VM86. We would need an advisory call (ioctl) to the screen drivers (syscons, ...) to save and restore the environment and for screen switching. -- Helmut F. Wirth Email: hfwirth@ping.at
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33ED7E33.167EB0E7>