From owner-freebsd-emulation Sat Aug 9 15:20:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA17675 for emulation-outgoing; Sat, 9 Aug 1997 15:20:54 -0700 (PDT) Received: from atlantis.ping.at (a013.static.Vienna.AT.EU.net [193.154.186.13]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA17669 for ; Sat, 9 Aug 1997 15:20:44 -0700 (PDT) Received: from atlantis (localhost.ping.at [127.0.0.1]) by atlantis.ping.at (8.8.6/8.6.12) with SMTP id QAA00342; Sat, 9 Aug 1997 16:06:47 +0200 (MEST) Message-ID: <33EC7977.167EB0E7@ping.at> Date: Sat, 09 Aug 1997 16:06:47 +0200 From: "Helmut F. Wirth" X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2-STABLE i386) MIME-Version: 1.0 To: Richard Foulk CC: emulation@freebsd.org Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) References: <199708090129.PAA08057@pegasus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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 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. 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. Any better ideas ? -- Helmut F. Wirth Email: hfwirth@ping.at