From owner-freebsd-emulation Sun Aug 10 01:21:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA09956 for emulation-outgoing; Sun, 10 Aug 1997 01:21:57 -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 BAA09948 for ; Sun, 10 Aug 1997 01:21:50 -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 KAA00278; Sun, 10 Aug 1997 10:21:29 +0200 (MEST) Message-ID: <33ED7A09.41C67EA6@ping.at> Date: Sun, 10 Aug 1997 10:21:29 +0200 From: "Helmut F. Wirth" X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2-STABLE i386) MIME-Version: 1.0 To: "Pedro Giffuni S," CC: emulation@freebsd.org Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) References: <19970806075054.63235@ct.picker.com> <199708061320.WAA08867@genesis.atrad.adelaide.edu.au> <19970806220031.07191@ct.picker.com> <33EA058A.42B9@fps.biblos.unal.edu.co> <19970808001728.40702@right.PCS> <33EBA119.41C67EA6@ping.at> <19970808180611.34384@right.PCS> <33EC762E.41C67EA6@ping.at> <19970809111159.62802@right.PCS> <33ECEB8E.41C67EA6@ping.at> <33ED2076.58F2@fps.biblos.unal.edu.co> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Pedro Giffuni S, wrote: > > FWIW, I think I saw the XMS specs are here, > ftp://x2ftp.oulu.fi/pub/msdos/programming/specs/00index.html > but if you don't have them already, and they are not there, drop me a > line and I'll send you a copy. > > Pedro. Thank you for the hint ! I fetched it today. I am working with Ralf Browns Interrupt List and looking at the Linux implementation. It is useful to have the spec too. Thanks -- Helmut F. Wirth Email: hfwirth@ping.at From owner-freebsd-emulation Sun Aug 10 01:39:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA10632 for emulation-outgoing; Sun, 10 Aug 1997 01:39:29 -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 BAA10627 for ; Sun, 10 Aug 1997 01:39:25 -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 KAA00310; Sun, 10 Aug 1997 10:39:15 +0200 (MEST) Message-ID: <33ED7E33.167EB0E7@ping.at> Date: Sun, 10 Aug 1997 10:39:15 +0200 From: "Helmut F. Wirth" X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2-STABLE i386) MIME-Version: 1.0 To: Jonathan Mini CC: emulation@freebsd.org Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) References: <199708090129.PAA08057@pegasus.com> <33EC7977.167EB0E7@ping.at> <19970809235411.04335@micron.efn.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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 From owner-freebsd-emulation Sun Aug 10 04:29:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA17114 for emulation-outgoing; Sun, 10 Aug 1997 04:29:31 -0700 (PDT) Received: from micron.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA17101 for ; Sun, 10 Aug 1997 04:29:25 -0700 (PDT) Received: (from mini@localhost) by micron.efn.org (8.8.5/8.8.5) id EAA04069; Sun, 10 Aug 1997 04:30:01 -0700 (PDT) Message-ID: <19970810043000.13645@micron.efn.org> Date: Sun, 10 Aug 1997 04:30:00 -0700 From: Jonathan Mini To: "Helmut F. Wirth" Cc: emulation@freebsd.org Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) Reply-To: Jonathan Mini References: <199708090129.PAA08057@pegasus.com> <33EC7977.167EB0E7@ping.at> <19970809235411.04335@micron.efn.org> <33ED7E33.167EB0E7@ping.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: <33ED7E33.167EB0E7@ping.at>; from Helmut F. Wirth on Sun, Aug 10, 1997 at 10:39:15AM +0200 X-files: The Truth is Out There. Sender: owner-freebsd-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Helmut F. Wirth stands accused of saying : > Jonathan Mini wrote: > > > > 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. Well. THe thing is is that VGA emulation and something like VESA VBE implementation are completely different, since you need to actually emulate the VGA chipset for VGA implementation, whereas VESA VBE just some extension to the BIOS code. > Yes. IMHO we would need to support only a few modes for starters. Mmm. Are you talking VGA emulation here or something else? (pretending to be a Cirrus Logic 54xx? Being VESA VBE 1.2?) > > > 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. This is true, that is the reason I was asking. I'd like to see a VGA emulation in the future, but wouldn't be surprised if that was a ways down the road :) > 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. 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. -- Jonathan Mini (j_mini@efn.org) ... bleakness ... desolation ... plastic forks ... From owner-freebsd-emulation Sun Aug 10 09:15:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA27830 for emulation-outgoing; Sun, 10 Aug 1997 09:15:01 -0700 (PDT) Received: from bsd.synx.com (rt.synx.com [194.167.81.239]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA27818 for ; Sun, 10 Aug 1997 09:14:56 -0700 (PDT) Received: from s3.synx.com (s3 [192.1.1.247]) by bsd.synx.com (8.6.12/8.6.12) with SMTP id RAA10232 for ; Sun, 10 Aug 1997 17:16:56 +0100 Received: from rs1 by s3.synx.com id aa16577; 10 Aug 97 18:09 BST Date: Sun, 10 Aug 1997 17:08:14 -0100 (GMT) From: Remy NONNENMACHER To: freebsd-emulation@freebsd.org Subject: Running Oracle listener in SCO emulation. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have got the Oracle SQL*Net V2 working under SCO (ibcs2) emulation by introducing a little modification in /sys/i386/ibcs2/ibcs2_ioctl.c : (FreeBSD-2.2.2RELEASE OOB) ibcs2_ioctl(..... . . /* socksys */ case IBCS2_SIOCSOCKSYS: return ibcs2_socksys(p, (struct ibcs2_socksys_args *)uap, retval); >>>> case IBCS2_FIONREAD: /* STREAMS */ case IBCS2_I_NREAD: /* STREAMS */ SCARG(uap, cmd) = FIONREAD; return ioctl(p, (struct ioctl_args *)uap, retval); . . Do i am using a wrong version of ibcs2 emulation ? (Note : Sorry if it's a silly question, i just switched from NetBSD to FreeBSD for my workstation). ------------------------------------------------------------------------------- S Y N C H R O N I X S.A. Avn des ANDES, Bat. LE CEDRE - 91952 LES ULIS - FRANCE Tel : +33 1 64462626 - FAX : +33 1 64466976 - Internet : Synx.com Remy NONNENMACHER - APAV Dpt. (remy@synx.com) #include #include ---- "My uncle and I entered a better life" - Alphonse Allais (When his rich uncle died). From owner-freebsd-emulation Sun Aug 10 12:41:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA09534 for emulation-outgoing; Sun, 10 Aug 1997 12:41:05 -0700 (PDT) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA09529 for ; Sun, 10 Aug 1997 12:41:01 -0700 (PDT) Received: (from karpen@localhost) by ocean.campus.luth.se (8.8.5/8.8.5) id VAA16366; Sun, 10 Aug 1997 21:52:55 +0200 (CEST) From: Mikael Karpberg Message-Id: <199708101952.VAA16366@ocean.campus.luth.se> Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) In-Reply-To: <19970810043000.13645@micron.efn.org> from Jonathan Mini at "Aug 10, 97 04:30:00 am" To: j_mini@efn.org Date: Sun, 10 Aug 1997 21:52:54 +0200 (CEST) Cc: hfwirth@ping.at, emulation@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Jonathan Mini: > Helmut F. Wirth stands accused of saying : [...] > > 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. > > 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. Why? Is there anything dangerous that could happen? And even if so, I think it might be a good idea to have as an option with a big mean red label by it's side saying "WARNGING! This is dangerous!". Because, it ought to be quite a lot faster if the program is question does a lot og graphics, no? /Mikael From owner-freebsd-emulation Sun Aug 10 13:48:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA13809 for emulation-outgoing; Sun, 10 Aug 1997 13:48:40 -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 NAA13802 for ; Sun, 10 Aug 1997 13:48:33 -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 WAA00267; Sun, 10 Aug 1997 22:48:23 +0200 (MEST) Message-ID: <33EE2917.41C67EA6@ping.at> Date: Sun, 10 Aug 1997 22:48:23 +0200 From: "Helmut F. Wirth" X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2-STABLE i386) MIME-Version: 1.0 To: Jonathan Mini CC: emulation@freebsd.org Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) References: <199708090129.PAA08057@pegasus.com> <33EC7977.167EB0E7@ping.at> <19970809235411.04335@micron.efn.org> <33ED7E33.167EB0E7@ping.at> <19970810043000.13645@micron.efn.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jonathan Mini wrote: > > Mmm. Are you talking VGA emulation here or something else? (pretending to be a > Cirrus Logic 54xx? Being VESA VBE 1.2?) 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 From owner-freebsd-emulation Sun Aug 10 18:31:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA29288 for emulation-outgoing; Sun, 10 Aug 1997 18:31:40 -0700 (PDT) Received: from micron.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA29283 for ; Sun, 10 Aug 1997 18:31:33 -0700 (PDT) Received: (from mini@localhost) by micron.efn.org (8.8.5/8.8.5) id SAA04798; Sun, 10 Aug 1997 18:31:27 -0700 (PDT) Message-ID: <19970810183126.27893@micron.efn.org> Date: Sun, 10 Aug 1997 18:31:26 -0700 From: Jonathan Mini To: Mikael Karpberg Cc: hfwirth@ping.at, emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) Reply-To: Jonathan Mini References: <19970810043000.13645@micron.efn.org> <199708101952.VAA16366@ocean.campus.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: <199708101952.VAA16366@ocean.campus.luth.se>; from Mikael Karpberg on Sun, Aug 10, 1997 at 09:52:54PM +0200 X-files: The Truth is Out There. Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mikael Karpberg stands accused of saying : > According to Jonathan Mini: > > Helmut F. Wirth stands accused of saying : > [...] > > > 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. > > > > 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. > > Why? Is there anything dangerous that could happen? And even if so, I think > it might be a good idea to have as an option with a big mean red label by > it's side saying "WARNGING! This is dangerous!". Because, it ought to be > quite a lot faster if the program is question does a lot og graphics, no? Ok : 1) WE ARE TALKING ABOUT VGA HERE, which means you get these modes : a) text : 40x25 (CGA) b) text : 80x25 (CGA) c) text : 80x50 (VGA) d) graphics : 320x200x4 (CGA) e) graphics : 640x200x1 (CGA) f) graphics : 320x200x16 (EGA) g) graphics : 640x200x16 (EGA) h) graphics : 640x350x2 (EGA) i) graphics : 640x480x1 (VGA) j) graphics : 640x480x16 (VGA) h) graphics : 320x200x256 (VGA) I don't know about you, but I'd like to see some video modes there that require high video performance. Keep in mind that games are out of the running because they do a lot of other stuff that doscmd can't emulate. (yet) 2) To truely allow full access to the VGA, we'd need to support things like the "x modes" (in appropriately named, Mode X was the original application of non-planar 256 color modes in VGA, see Dr. Dobbs, #178 Jul, 1991, p. 133. Interestingly enough, on page 32 there is one of the installments on the original 386BSD port. (This one talks about the bootstrap loader) you will need to allow the DOS app to set and read all of the VGA's registers. 3) Assuming that you do allow that, how does the syscons handle switching away from video modes that are nonstandard, or possibly what it thinks is standard mode, but is not, if the dos app crashes or is killed? Basically, your answer becomes that of Linux's svgalib : You don't. You reboot your machine. Sorry, I don't accept that. You are asking more out of the syscons module than it can give you. -- Jonathan Mini (j_mini@efn.org) ... bleakness ... desolation ... plastic forks ... From owner-freebsd-emulation Sun Aug 10 18:34:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA29562 for emulation-outgoing; Sun, 10 Aug 1997 18:34:47 -0700 (PDT) Received: from micron.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA29554 for ; Sun, 10 Aug 1997 18:34:39 -0700 (PDT) Received: (from mini@localhost) by micron.efn.org (8.8.5/8.8.5) id SAA04810; Sun, 10 Aug 1997 18:35:30 -0700 (PDT) Message-ID: <19970810183529.06224@micron.efn.org> Date: Sun, 10 Aug 1997 18:35:29 -0700 From: Jonathan Mini To: "Helmut F. Wirth" Cc: emulation@freebsd.org Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) Reply-To: Jonathan Mini 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: <33EE2917.41C67EA6@ping.at>; from Helmut F. Wirth on Sun, Aug 10, 1997 at 10:48:23PM +0200 X-files: The Truth is Out There. Sender: owner-freebsd-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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 ... From owner-freebsd-emulation Sun Aug 10 23:41:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA16321 for emulation-outgoing; Sun, 10 Aug 1997 23:41:56 -0700 (PDT) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA16313 for ; Sun, 10 Aug 1997 23:41:52 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id IAA02115; Mon, 11 Aug 1997 08:41:48 +0200 (MEST) From: Søren Schmidt Message-Id: <199708110641.IAA02115@sos.freebsd.dk> Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) In-Reply-To: <19970810183126.27893@micron.efn.org> from Jonathan Mini at "Aug 10, 97 06:31:26 pm" To: j_mini@efn.org Date: Mon, 11 Aug 1997 08:41:48 +0200 (MEST) Cc: karpen@ocean.campus.luth.se, hfwirth@ping.at, emulation@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Jonathan Mini who wrote: > > > > Why? Is there anything dangerous that could happen? And even if so, I think > > it might be a good idea to have as an option with a big mean red label by > > it's side saying "WARNGING! This is dangerous!". Because, it ought to be > > quite a lot faster if the program is question does a lot og graphics, no? > > Ok : > > 1) WE ARE TALKING ABOUT VGA HERE, which means you get these modes : > a) text : 40x25 (CGA) > b) text : 80x25 (CGA) > c) text : 80x50 (VGA) > d) graphics : 320x200x4 (CGA) > e) graphics : 640x200x1 (CGA) > f) graphics : 320x200x16 (EGA) > g) graphics : 640x200x16 (EGA) > h) graphics : 640x350x2 (EGA) > i) graphics : 640x480x1 (VGA) > j) graphics : 640x480x16 (VGA) > h) graphics : 320x200x256 (VGA) > I don't know about you, but I'd like to see some video modes there > that require high video performance. Keep in mind that games are out > of the running because they do a lot of other stuff that doscmd can't > emulate. (yet) These above are easy done, via int 0x10. > 2) To truely allow full access to the VGA, we'd need to support things > like the "x modes" (in appropriately named, Mode X was the original > application of non-planar 256 color modes in VGA, see Dr. Dobbs, #178 > Jul, 1991, p. 133. Interestingly enough, on page 32 there is one of the > installments on the original 386BSD port. (This one talks about the > bootstrap loader) you will need to allow the DOS app to set and read > all of the VGA's registers. Now it gets tricky, there is no way in h... that we are going to emulate all the regs etc in the VGA hw, its simply to complex and non std. > 3) Assuming that you do allow that, how does the syscons handle > switching away from video modes that are nonstandard, or possibly what > it thinks is standard mode, but is not, if the dos app crashes or is > killed? As long as the modes "just" use std VGA regs etc syscons has no problem with that. But if you go beyond that all hell is going to break loose. > Basically, your answer becomes that of Linux's svgalib : You don't. You > reboot your machine. Sorry, I don't accept that. > > You are asking more out of the syscons module than it can give you. Well, when/if we get the ability to run realmode from the kernel, we can call the BIOS on the card. That way we can utilize the (hopefully) onboard VESA layer. That will give what we need (and what I need for syscons). Its then possible to either do a full VESA support, or mimic some SVGA chipset for the basic functions. Give me the means to run realmode code from within the kernel, and I'll teach syscons how to use it :) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-emulation Mon Aug 11 02:07:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA23024 for emulation-outgoing; Mon, 11 Aug 1997 02:07:05 -0700 (PDT) Received: from bsd.synx.com (rt.synx.com [194.167.81.239]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id CAA23018 for ; Mon, 11 Aug 1997 02:07:01 -0700 (PDT) Received: from s3.synx.com (s3 [192.1.1.247]) by bsd.synx.com (8.6.12/8.6.12) with SMTP id KAA15720 for ; Mon, 11 Aug 1997 10:08:49 +0100 Received: from rs1 by s3.synx.com id aa20021; 11 Aug 97 11:01 BST Date: Mon, 11 Aug 1997 10:00:06 -0100 (GMT) From: Remy NONNENMACHER To: emulation@freebsd.org Subject: NetBSD 1.2 binary compat. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Every binary from NetBSD (either 1.0 or 1.2) gives me a "ld.so: Bad Magic" when trying to run it under FreeBSD 2.2.2. It seems that /usr/libexec/ld.so as different magic numbers under Free and Net. Is there a simple way to obtain a /compat/netbsd lookup when running a Q/ZMAGIC swapped exec (Netbsd) ? (in order to have a /compat/netbsd/usr/libexec/ld.so loading). (Note that isn't a critical issue since src's for netbsd products are (nearly) always available, but is would be sooooooo nice to have all *BSD* binaries running OOB under FreeBSD !!) From owner-freebsd-emulation Mon Aug 11 07:29:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA06081 for emulation-outgoing; Mon, 11 Aug 1997 07:29:40 -0700 (PDT) Received: from usc.usc.unal.edu.co ([200.21.26.65]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id HAA06071 for ; Mon, 11 Aug 1997 07:29:33 -0700 (PDT) Received: from unalmodem20.usc.unal.edu.co by usc.usc.unal.edu.co (AIX 4.1/UCB 5.64/4.03) id AA02400; Mon, 11 Aug 1997 10:23:32 -0400 Message-Id: <33EF3CB0.3148@fps.biblos.unal.edu.co> Date: Mon, 11 Aug 1997 09:24:16 -0700 From: "Pedro Giffuni S," Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.01Gold [it] (Win16; I) Mime-Version: 1.0 To: Søren Schmidt Cc: emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) References: <199708110641.IAA02115@sos.freebsd.dk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Søren Schmidt wrote: > > Give me the means to run realmode code from within the kernel, and I'll > teach syscons how to use it :) > How does X11 do it? svgalib is supposed to be based on X11, but it seems like they nuked everything related with coherence and stability. BTW: the port for NetBSD's dosemu doesn't use svgalib (don't know about the linux version), maybe they don't support SVGA for the same reasons. Pedro. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > Even more code to hack -- will it ever end > .. From owner-freebsd-emulation Mon Aug 11 11:48:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA22537 for emulation-outgoing; Mon, 11 Aug 1997 11:48:38 -0700 (PDT) Received: from micron.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA22517 for ; Mon, 11 Aug 1997 11:48:30 -0700 (PDT) Received: (from mini@localhost) by micron.efn.org (8.8.5/8.8.5) id LAA05784; Mon, 11 Aug 1997 11:49:04 -0700 (PDT) Message-ID: <19970811114903.20861@micron.efn.org> Date: Mon, 11 Aug 1997 11:49:04 -0700 From: Jonathan Mini To: =?iso-8859-1?Q?S=F8ren_Schmidt?= Cc: karpen@ocean.campus.luth.se, hfwirth@ping.at, emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) Reply-To: Jonathan Mini References: <19970810183126.27893@micron.efn.org> <199708110641.IAA02115@sos.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.76e In-Reply-To: =?iso-8859-1?Q?=3C199708110641=2EIAA02115=40sos=2Efreebsd=2Edk=3E=3B_fro?= =?iso-8859-1?Q?m_S=F8ren_Schmidt_on_Mon=2C_Aug_11=2C_1997_at_08=3A41=3A4?= =?iso-8859-1?Q?8AM_+0200?= X-files: The Truth is Out There. Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Søren Schmidt stands accused of saying : > > 2) To truely allow full access to the VGA, we'd need to support things > > like the "x modes" (in appropriately named, Mode X was the original > > application of non-planar 256 color modes in VGA, see Dr. Dobbs, #178 > > Jul, 1991, p. 133. Interestingly enough, on page 32 there is one of the > > installments on the original 386BSD port. (This one talks about the > > bootstrap loader) you will need to allow the DOS app to set and read > > all of the VGA's registers. > > Now it gets tricky, there is no way in h... that we are going to emulate > all the regs etc in the VGA hw, its simply to complex and non std. Yes, my feelings exactly -- and allowing access to the real hardware is insane. > > 3) Assuming that you do allow that, how does the syscons handle > > switching away from video modes that are nonstandard, or possibly what > > it thinks is standard mode, but is not, if the dos app crashes or is > > killed? > > As long as the modes "just" use std VGA regs etc syscons has no problem > with that. But if you go beyond that all hell is going to break loose. Syscons has support for switching away-from/into the graphics modes? Last time I played with this (in VGA_320x200) syscons wouln't allow me to switch vtys. This was 2.2.1-R, so maybe I'm missing new code :) > > Basically, your answer becomes that of Linux's svgalib : You don't. You > > reboot your machine. Sorry, I don't accept that. > > > > You are asking more out of the syscons module than it can give you. > > Well, when/if we get the ability to run realmode from the kernel, we > can call the BIOS on the card. That way we can utilize the (hopefully) > onboard VESA layer. That will give what we need (and what I need for > syscons). Its then possible to either do a full VESA support, or > mimic some SVGA chipset for the basic functions. > > Give me the means to run realmode code from within the kernel, and I'll > teach syscons how to use it :) Hehe. I am working on it, however, you won't get realmode, just something similar -- a v86 thread with the mappings of real mode. It should be close enough :) (Currently, I am waiting on a motherboard that is held up in shipping due to a UPS strike -- once I get that motherboard, I'll finally have the crash box I need) > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > Even more code to hack -- will it ever end > .. -- Jonathan Mini (j_mini@efn.org) ... bleakness ... desolation ... plastic forks ... From owner-freebsd-emulation Mon Aug 11 11:52:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA22784 for emulation-outgoing; Mon, 11 Aug 1997 11:52:25 -0700 (PDT) Received: from micron.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA22775 for ; Mon, 11 Aug 1997 11:52:20 -0700 (PDT) Received: (from mini@localhost) by micron.efn.org (8.8.5/8.8.5) id LAA05795; Mon, 11 Aug 1997 11:52:32 -0700 (PDT) Message-ID: <19970811115232.19191@micron.efn.org> Date: Mon, 11 Aug 1997 11:52:32 -0700 From: Jonathan Mini To: "Pedro Giffuni S," Cc: =?iso-8859-1?Q?S=F8ren_Schmidt?= , emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) Reply-To: Jonathan Mini References: <199708110641.IAA02115@sos.freebsd.dk> <33EF3CB0.3148@fps.biblos.unal.edu.co> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.76e In-Reply-To: <33EF3CB0.3148@fps.biblos.unal.edu.co>; from Pedro Giffuni S, on Mon, Aug 11, 1997 at 09:24:16AM -0700 X-files: The Truth is Out There. Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Pedro Giffuni S, stands accused of saying : > Søren Schmidt wrote: > > > > Give me the means to run realmode code from within the kernel, and I'll > > teach syscons how to use it :) > > > How does X11 do it? svgalib is supposed to be based on X11, but it seems > like they nuked everything related with coherence and stability. XFree86 opens /dev/mem and /dev/io and other similar devices and maps the hardware access for the chipset you tell it to use. The server you run then does a probe and looks for a video card it understands. When it finds it, it does funky stuff to change the video mode, etc, etc, etc. In effect, the XFree86 server acts as if it were the BIOS, except that it does more than the BIOS ever did. :) Also, somewhere along the way, it tells syscons to butt out. > BTW: the port for NetBSD's dosemu doesn't use svgalib (don't know about > the linux version), maybe they don't support SVGA for the same reasons. > > Pedro. > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > > Even more code to hack -- will it ever end > > .. -- Jonathan Mini (j_mini@efn.org) ... bleakness ... desolation ... plastic forks ... From owner-freebsd-emulation Mon Aug 11 13:25:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA27890 for emulation-outgoing; Mon, 11 Aug 1997 13:25:39 -0700 (PDT) Received: from sos.freebsd.dk (sos.freebsd.dk [195.8.129.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA27883 for ; Mon, 11 Aug 1997 13:25:34 -0700 (PDT) Received: (from sos@localhost) by sos.freebsd.dk (8.8.7/8.7.3) id WAA03492; Mon, 11 Aug 1997 22:25:18 +0200 (MEST) From: Søren Schmidt Message-Id: <199708112025.WAA03492@sos.freebsd.dk> Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) In-Reply-To: <19970811114903.20861@micron.efn.org> from Jonathan Mini at "Aug 11, 97 11:49:04 am" To: j_mini@efn.org Date: Mon, 11 Aug 1997 22:25:18 +0200 (MEST) Cc: karpen@ocean.campus.luth.se, hfwirth@ping.at, emulation@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In reply to Jonathan Mini who wrote: > > > > 3) Assuming that you do allow that, how does the syscons handle > > > switching away from video modes that are nonstandard, or possibly what > > > it thinks is standard mode, but is not, if the dos app crashes or is > > > killed? > > > > As long as the modes "just" use std VGA regs etc syscons has no problem > > with that. But if you go beyond that all hell is going to break loose. > > Syscons has support for switching away-from/into the graphics modes? Last time > I played with this (in VGA_320x200) syscons wouln't allow me to switch vtys. > This was 2.2.1-R, so maybe I'm missing new code :) Well, switching to/from one of the graphics modes is restricted to VT_PROCESS mode, but its just me being conservative, syscons can do the switch, however I insist on the user taking care of getting the application off the screen memory (or it'l happily overwrite all the other screens), and telling the system when its ready... Watch my little graph library soon to go into current... > > > Basically, your answer becomes that of Linux's svgalib : You don't. You > > > reboot your machine. Sorry, I don't accept that. > > > > > > You are asking more out of the syscons module than it can give you. > > > > Well, when/if we get the ability to run realmode from the kernel, we > > can call the BIOS on the card. That way we can utilize the (hopefully) > > onboard VESA layer. That will give what we need (and what I need for > > syscons). Its then possible to either do a full VESA support, or > > mimic some SVGA chipset for the basic functions. > > > > Give me the means to run realmode code from within the kernel, and I'll > > teach syscons how to use it :) > > Hehe. I am working on it, however, you won't get realmode, just something > similar -- a v86 thread with the mappings of real mode. It should be close > enough :) As long as it lets me call a 16bit realmode subrutine in the (S)VGA BIOS I'll be OK :) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team Even more code to hack -- will it ever end .. From owner-freebsd-emulation Mon Aug 11 16:50:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA08755 for emulation-outgoing; Mon, 11 Aug 1997 16:50:01 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA08726 for ; Mon, 11 Aug 1997 16:49:55 -0700 (PDT) Received: from gurney.reilly.home (d13.syd2.zeta.org.au [203.26.11.13]) by godzilla.zeta.org.au (8.8.5/8.6.9) with ESMTP id JAA00155; Tue, 12 Aug 1997 09:39:53 +1000 Received: (from andrew@localhost) by gurney.reilly.home (8.8.5/8.8.5) id JAA02131; Tue, 12 Aug 1997 09:36:26 +1000 (EST) Message-ID: <19970812093626.05693@gurney.reilly.home> Date: Tue, 12 Aug 1997 09:36:26 +1000 From: & Reilly To: "Pedro Giffuni S," Cc: emulation@freebsd.org Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) References: <199708110641.IAA02115@sos.freebsd.dk> <33EF3CB0.3148@fps.biblos.unal.edu.co> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.67e In-Reply-To: <33EF3CB0.3148@fps.biblos.unal.edu.co>; from Pedro Giffuni S, on Mon, Aug 11, 1997 at 09:24:16AM -0700 Sender: owner-freebsd-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, Aug 11, 1997 at 09:24:16AM -0700, Pedro Giffuni S, wrote: > Søren Schmidt wrote: > > > > Give me the means to run realmode code from within the kernel, and I'll > > teach syscons how to use it :) > > > How does X11 do it? svgalib is supposed to be based on X11, but it seems > like they nuked everything related with coherence and stability. Maybe now that XFree has produced a working framework for accelerated graphics hardware (XAA) this could be used to design a propper intelligent frame buffer device that could be properly part of the FreeBSD kernel, and used by syscons and X alike, with X reverting to its original role of primitives on top of a frame buffer, rather than a user-mode device driver. -- Andrew "The steady state of disks is full." -- Ken Thompson From owner-freebsd-emulation Mon Aug 11 17:35:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA11748 for emulation-outgoing; Mon, 11 Aug 1997 17:35:24 -0700 (PDT) Received: from micron.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA11742 for ; Mon, 11 Aug 1997 17:35:18 -0700 (PDT) Received: (from mini@localhost) by micron.efn.org (8.8.5/8.8.5) id RAA06092; Mon, 11 Aug 1997 17:28:32 -0700 (PDT) Message-ID: <19970811172831.26510@micron.efn.org> Date: Mon, 11 Aug 1997 17:28:31 -0700 From: Jonathan Mini To: =?iso-8859-1?Q?S=F8ren_Schmidt?= Cc: karpen@ocean.campus.luth.se, hfwirth@ping.at, emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) Reply-To: Jonathan Mini References: <19970811114903.20861@micron.efn.org> <199708112025.WAA03492@sos.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.76e In-Reply-To: =?iso-8859-1?Q?=3C199708112025=2EWAA03492=40sos=2Efreebsd=2Edk=3E=3B_fro?= =?iso-8859-1?Q?m_S=F8ren_Schmidt_on_Mon=2C_Aug_11=2C_1997_at_10=3A25=3A1?= =?iso-8859-1?Q?8PM_+0200?= X-files: The Truth is Out There. Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Søren Schmidt stands accused of saying : > In reply to Jonathan Mini who wrote: > > > > > > 3) Assuming that you do allow that, how does the syscons handle > > > > switching away from video modes that are nonstandard, or possibly what > > > > it thinks is standard mode, but is not, if the dos app crashes or is > > > > killed? > > > > > > As long as the modes "just" use std VGA regs etc syscons has no problem > > > with that. But if you go beyond that all hell is going to break loose. > > > > Syscons has support for switching away-from/into the graphics modes? Last time > > I played with this (in VGA_320x200) syscons wouln't allow me to switch vtys. > > This was 2.2.1-R, so maybe I'm missing new code :) > > Well, switching to/from one of the graphics modes is restricted to > VT_PROCESS mode, but its just me being conservative, syscons can do > the switch, however I insist on the user taking care of getting the > application off the screen memory (or it'l happily overwrite all > the other screens), and telling the system when its ready... > Watch my little graph library soon to go into current... Cool. I plan on writing some graphics code for FreeBSD's kernel soon, but I plan on having it be basically a VESA VBE client. Hopefully, we can bring our two apis together for this. > > > > Basically, your answer becomes that of Linux's svgalib : You don't. You > > > > reboot your machine. Sorry, I don't accept that. > > > > > > > > You are asking more out of the syscons module than it can give you. > > > > > > Well, when/if we get the ability to run realmode from the kernel, we > > > can call the BIOS on the card. That way we can utilize the (hopefully) > > > onboard VESA layer. That will give what we need (and what I need for > > > syscons). Its then possible to either do a full VESA support, or > > > mimic some SVGA chipset for the basic functions. > > > > > > Give me the means to run realmode code from within the kernel, and I'll > > > teach syscons how to use it :) > > > > Hehe. I am working on it, however, you won't get realmode, just something > > similar -- a v86 thread with the mappings of real mode. It should be close > > enough :) > > As long as it lets me call a 16bit realmode subrutine in the (S)VGA BIOS > I'll be OK :) That's what I'm writing it for. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Søren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > Even more code to hack -- will it ever end > .. -- Jonathan Mini (j_mini@efn.org) ... bleakness ... desolation ... plastic forks ... From owner-freebsd-emulation Mon Aug 11 18:17:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA14151 for emulation-outgoing; Mon, 11 Aug 1997 18:17:41 -0700 (PDT) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA14145 for ; Mon, 11 Aug 1997 18:17:35 -0700 (PDT) Received: from nospam.hiwaay.net (max2-163.HiWAAY.net [208.147.145.163]) by fly.HiWAAY.net (8.8.6/8.8.6) with ESMTP id UAA04394 for ; Mon, 11 Aug 1997 20:15:10 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nexgen.hiwaay.net (8.8.6/8.8.4) with ESMTP id TAA08396 for ; Mon, 11 Aug 1997 19:11:35 -0500 (CDT) Message-Id: <199708120011.TAA08396@nexgen.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: emulation@FreeBSD.ORG From: dkelly@hiwaay.net Subject: Re: NetBSD 1.2 binary compat. In-reply-to: Message from Remy NONNENMACHER of "Mon, 11 Aug 1997 10:00:06 -0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Aug 1997 19:11:35 -0500 Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Remy NONNENMACHER writes: > > Every binary from NetBSD (either 1.0 or 1.2) gives me a "ld.so: Bad > Magic" when trying to run it under FreeBSD 2.2.2. Yup. Me too. I downloaded a demo of Introl's embedded C compiler from http://www.introl.com, chose the NetBSD (x86) as the closest thing to FreeBSD. Exact same fatal message as above. -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-emulation Mon Aug 11 22:09:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA29476 for emulation-outgoing; Mon, 11 Aug 1997 22:09:54 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA29469 for ; Mon, 11 Aug 1997 22:09:50 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id OAA06051; Tue, 12 Aug 1997 14:38:48 +0930 (CST) From: Michael Smith Message-Id: <199708120508.OAA06051@genesis.atrad.adelaide.edu.au> Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD)g In-Reply-To: <19970807194755.37948@ct.picker.com> from Randall Hopper at "Aug 7, 97 07:47:55 pm" To: rhh@ct.picker.com (Randall Hopper) Date: Tue, 12 Aug 1997 14:38:47 +0930 (CST) Cc: pgiffuni@fps.biblos.unal.edu.co, emulation@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Randall Hopper stands accused of saying: > > Ok. Mostly I just wanted to step through some of it to help get a faster > line on how the internals work. I figured it'd be a easier than picking > through the source and printfs. Not really. Getting gdb into a poition to talk to the doscmd kernel is fairly tough (as you will have seen). > Is there a rough architecture overview or some notes/scribbles lying around > anywhere on-line that might give someone a head start with this? Here (points at self). 8) doscmd runs in two separate modes, with slightly different sets of behaviour. In "boot" mode (the simplest), it establishes the memory footprint as the BIOS would during initialisation, reads the bootsector from the boot medium into the standard location, and then calls it in vm86 mode. In "dos" mode, it additionally establishes a pile of DOS data structures and adds interrupt handlers for the DOS "system calls", then loads the DOS executable and runs that in vm86 mode. In any case, vm86 mode is managed as follows : - Signal delivery on a separate (no-application) stack is requested. - A signal handler is established for the signal indicating a vm86 trap. - A repeating SIGALRM signal is arranged to allow for the simulation of time-related events. - vm86 mode is entered by constructing a phony stackframe for sigreturn() which sets the PSL_VM bit in the processor's status word. Execution returns to the emulator when the emulated process executes an instrution that results in a vm86 trap. See trap.c for the handler code for this, but note that some traps are handled directly in the kernel. The remainder of the guts of doscmd are simply handlers for these traps. > Randall -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-emulation Tue Aug 12 17:50:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA04994 for emulation-outgoing; Tue, 12 Aug 1997 17:50:22 -0700 (PDT) Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04987 for ; Tue, 12 Aug 1997 17:50:12 -0700 (PDT) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id UAA06577; Tue, 12 Aug 1997 20:02:34 -0500 (CDT) Received: (jlemon@localhost) by right.PCS (8.6.13/8.6.4) id TAA15833; Tue, 12 Aug 1997 19:50:35 -0500 Message-ID: <19970812195034.31150@right.PCS> Date: Tue, 12 Aug 1997 19:50:34 -0500 From: Jonathan Lemon To: =?iso-8859-1?Q?S=F8ren_Schmidt?= Cc: j_mini@efn.org, karpen@ocean.campus.luth.se, hfwirth@ping.at, emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) References: <19970811114903.20861@micron.efn.org> <199708112025.WAA03492@sos.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.61.1 In-Reply-To: =?iso-8859-1?Q?=3C199708112025=2EWAA03492=40sos=2Efreebsd=2Edk=3E=3B_fro?= =?iso-8859-1?Q?m_S=F8ren_Schmidt_on_Aug_08=2C_1997_at_10=3A25=3A18PM_+02?= =?iso-8859-1?Q?00?= Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Aug 08, 1997 at 10:25:18PM +0200, Søren Schmidt wrote: > > Hehe. I am working on it, however, you won't get realmode, just something > > similar -- a v86 thread with the mappings of real mode. It should be close > > enough :) > > As long as it lets me call a 16bit realmode subrutine in the (S)VGA BIOS > I'll be OK :) Amazingly enough, I've been working on something similar too. At this point, I think I need a little bit of feedback. How would a vm86() interface be used? I don't think that just passing in the i386 registers and an interrupt number to call would be enough; I think that some of the INT calls want to pass data back and forth via low-memory areas. If that is the case, then the address space has to exist before and after the call; probably the easiest way would be for the calling process to create the address space and then pass it to the vm86 thread. Otherwise, the thread could just attach to kernel area around 'atdevbase' Also, where would this be called from? kernel code only? user code? If both, then there should also be a parameter that specifies what I/O the process is permitted to do. This way, when when calling some arbitrary piece of BIOS code which may touch I/O space, we can fail if the call was from user mode. Side note here: the vm86 changes do permit controlled access to the full I/O space from user-mode, assuming that the process is running as root. My current thinking (for the kernel) is: - create a 'vm86daemon', which maps in the lower physical 1M into it's address space. - submit requests to this thread, which puts the caller to sleep until the request completes. Another possibility would be to create a new thread for every call, but that seems to have too much overhead. Am I on the right track here, or am I totally off base? -- Jonathan From owner-freebsd-emulation Tue Aug 12 19:41:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA11877 for emulation-outgoing; Tue, 12 Aug 1997 19:41:00 -0700 (PDT) Received: from micron.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA11858 for ; Tue, 12 Aug 1997 19:40:51 -0700 (PDT) Received: (from mini@localhost) by micron.efn.org (8.8.5/8.8.5) id TAA02131; Tue, 12 Aug 1997 19:40:57 -0700 (PDT) Message-ID: <19970812194056.12566@micron.efn.org> Date: Tue, 12 Aug 1997 19:40:56 -0700 From: Jonathan Mini To: Jonathan Lemon Cc: =?iso-8859-1?Q?S=F8ren_Schmidt?= , karpen@ocean.campus.luth.se, hfwirth@ping.at, emulation@FreeBSD.ORG Subject: Re: Fun with DOSCMD (was Re: modifying boot mgrs FROM FREEBSD) Reply-To: Jonathan Mini References: <19970811114903.20861@micron.efn.org> <199708112025.WAA03492@sos.freebsd.dk> <19970812195034.31150@right.PCS> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.76e In-Reply-To: <19970812195034.31150@right.PCS>; from Jonathan Lemon on Tue, Aug 12, 1997 at 07:50:34PM -0500 X-files: The Truth is Out There. Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jonathan Lemon stands accused of saying : > On Aug 08, 1997 at 10:25:18PM +0200, Søren Schmidt wrote: > > > Hehe. I am working on it, however, you won't get realmode, just something > > > similar -- a v86 thread with the mappings of real mode. It should be close > > > enough :) > > > > As long as it lets me call a 16bit realmode subrutine in the (S)VGA BIOS > > I'll be OK :) > > Amazingly enough, I've been working on something similar too. At this point, > I think I need a little bit of feedback. > > How would a vm86() interface be used? I don't think that just passing in > the i386 registers and an interrupt number to call would be enough; I think > that some of the INT calls want to pass data back and forth via low-memory > areas. > > If that is the case, then the address space has to exist before and after > the call; probably the easiest way would be for the calling process to create > the address space and then pass it to the vm86 thread. Otherwise, the thread > could just attach to kernel area around 'atdevbase' > Also, where would this be called from? kernel code only? user code? > If both, then there should also be a parameter that specifies what I/O the > process is permitted to do. This way, when when calling some arbitrary piece > of BIOS code which may touch I/O space, we can fail if the call was from user > mode. My opinion is that it should be callable from kernel space only. Although, it would be kinda nice to call a BIOS routine from a userland process, my mind makes large comments about security holes. > Side note here: the vm86 changes do permit controlled access to the full > I/O space from user-mode, assuming that the process is running as root. > > My current thinking (for the kernel) is: > > - create a 'vm86daemon', which maps in the lower physical 1M into > it's address space. > > - submit requests to this thread, which puts the caller to sleep > until the request completes. > > Another possibility would be to create a new thread for every call, but > that seems to have too much overhead. No! The BIOS is not re-entrant. The requests must be seriealised, no matter how inefficient it is. > Am I on the right track here, or am I totally off base? > -- > Jonathan -- Jonathan Mini (j_mini@efn.org) ... bleakness ... desolation ... plastic forks ... From owner-freebsd-emulation Thu Aug 14 12:51:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA08954 for emulation-outgoing; Thu, 14 Aug 1997 12:51:21 -0700 (PDT) Received: from post.metrolink.net (post.metrolink.net [207.31.112.16]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA08934 for ; Thu, 14 Aug 1997 12:51:14 -0700 (PDT) Received: from gumby.metrolink ([207.31.112.19]) by post.metrolink.net (Post.Office MTA v3.1 release PO203a ID# 0-39944U5500L500S0) with SMTP id AAA301 for ; Thu, 14 Aug 1997 15:51:28 -0400 Message-Id: <3.0.32.19970814154902.00ee34cc@post.metrolink.net> X-Sender: admin@post.metrolink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 14 Aug 1997 15:49:03 -0400 To: freebsd-emulation@FreeBSD.ORG From: admin@metrolink.net (admin) Subject: REMOVE jclay@metrolink.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From owner-freebsd-emulation Thu Aug 14 17:18:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA23678 for emulation-outgoing; Thu, 14 Aug 1997 17:18:55 -0700 (PDT) Received: from sumatra.americantv.com (sumatra.americantv.com [207.170.17.37]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA23662 for ; Thu, 14 Aug 1997 17:18:45 -0700 (PDT) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id TAA11175; Thu, 14 Aug 1997 19:33:04 -0500 (CDT) Received: (jlemon@localhost) by right.PCS (8.6.13/8.6.4) id TAA21232; Thu, 14 Aug 1997 19:19:47 -0500 Message-ID: <19970814191947.62382@right.PCS> Date: Thu, 14 Aug 1997 19:19:47 -0500 From: Jonathan Lemon To: Jonathan Mini , emulation@freebsd.org Subject: Calling BIOS from within FreeBSD References: <19970811114903.20861@micron.efn.org> <199708112025.WAA03492@sos.freebsd.dk> <19970812195034.31150@right.PCS> <19970812194056.12566@micron.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.61.1 In-Reply-To: <19970812194056.12566@micron.efn.org>; from Jonathan Mini on Aug 08, 1997 at 07:40:56PM -0700 Sender: owner-freebsd-emulation@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello - I have patches to -current for a "vm86 thread". Although in a very rough state, it allows you to execute random BIOS functions. For example: INT x10, AH=x10, AL=x19 (Read VGA Pel Mask register) scratch[6:50pm](0)# ./vmcall 0x10 0x10 0x19 result: 0 trapno: 9 err: 0 ax=1019 bx=00ff cx=0000 dx=0000 si=0000 di=0000 sp=8000 bp=0000 cs=0000 ss=0000 ds=0000 es=0000 ip=7c02 eflags=b0202 INT x10, AH=x4F, AL=0 (Get SVGA general information) scratch[6:50pm](0)# ./vmcall 0x10 0x4F 0 result: 0 trapno: 9 err: 0 ax=004f bx=0000 cx=0000 dx=0000 si=0000 di=0000 sp=8000 bp=0000 cs=0000 ss=0000 ds=0000 es=0000 ip=7c02 eflags=b0202 (Whups, I forgot I'm calling it with es:di == 0:0, so there goes my interrupt table. Urk. But here's the result:) int 0x00: 0x41534556 int 0x01: 0x500e0102 int 0x02: 0xc000 int 0x03: 0x502d0000 int 0x04: 0x20c000 int 0x05: 0x0 int 0x06: 0x0 int 0x07: 0x0 int 0x08: 0x0 int 0x09: 0x0 The patches are at: ftp://sumatra.americantv.com/pub/vm86-970814.tar.gz -- Jonathan From owner-freebsd-emulation Thu Aug 14 21:12:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA05265 for emulation-outgoing; Thu, 14 Aug 1997 21:12:30 -0700 (PDT) Received: from micron.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA05259 for ; Thu, 14 Aug 1997 21:12:22 -0700 (PDT) Received: (from mini@localhost) by micron.efn.org (8.8.5/8.8.5) id VAA04820; Thu, 14 Aug 1997 21:13:43 -0700 (PDT) Message-ID: <19970814211342.49849@micron.efn.org> Date: Thu, 14 Aug 1997 21:13:42 -0700 From: Jonathan Mini To: Jonathan Lemon Cc: emulation@FreeBSD.ORG Subject: Re: Calling BIOS from within FreeBSD Reply-To: Jonathan Mini References: <19970811114903.20861@micron.efn.org> <199708112025.WAA03492@sos.freebsd.dk> <19970812195034.31150@right.PCS> <19970812194056.12566@micron.efn.org> <19970814191947.62382@right.PCS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: <19970814191947.62382@right.PCS>; from Jonathan Lemon on Thu, Aug 14, 1997 at 07:19:47PM -0500 X-files: The Truth is Out There. Sender: owner-freebsd-emulation@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk *dances for joy in the isles* Jonathan Lemon stands accused of saying : > Hello - > > I have patches to -current for a "vm86 thread". Although in a very rough > state, it allows you to execute random BIOS functions. For example: > > INT x10, AH=x10, AL=x19 (Read VGA Pel Mask register) > scratch[6:50pm](0)# ./vmcall 0x10 0x10 0x19 > result: 0 > trapno: 9 err: 0 > ax=1019 bx=00ff cx=0000 dx=0000 > si=0000 di=0000 sp=8000 bp=0000 > cs=0000 ss=0000 ds=0000 es=0000 > ip=7c02 eflags=b0202 > > INT x10, AH=x4F, AL=0 (Get SVGA general information) > scratch[6:50pm](0)# ./vmcall 0x10 0x4F 0 > result: 0 > trapno: 9 err: 0 > ax=004f bx=0000 cx=0000 dx=0000 > si=0000 di=0000 sp=8000 bp=0000 > cs=0000 ss=0000 ds=0000 es=0000 > ip=7c02 eflags=b0202 > > (Whups, I forgot I'm calling it with es:di == 0:0, so there goes my > interrupt table. Urk. But here's the result:) > > int 0x00: 0x41534556 int 0x01: 0x500e0102 > int 0x02: 0xc000 int 0x03: 0x502d0000 > int 0x04: 0x20c000 int 0x05: 0x0 > int 0x06: 0x0 int 0x07: 0x0 > int 0x08: 0x0 int 0x09: 0x0 > > > The patches are at: ftp://sumatra.americantv.com/pub/vm86-970814.tar.gz > -- > Jonathan -- Jonathan Mini (j_mini@efn.org) ... bleakness ... desolation ... plastic forks ...