From owner-freebsd-hackers Sun Nov 9 07:31:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA16124 for hackers-outgoing; Sun, 9 Nov 1997 07:31:50 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA16118 for ; Sun, 9 Nov 1997 07:31:46 -0800 (PST) (envelope-from chuckr@glue.umd.edu) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.8.7/8.8.5) with SMTP id JAA26813; Sun, 9 Nov 1997 09:27:51 -0500 (EST) X-Authentication-Warning: picnic.mat.net: chuckr owned process doing -bs Date: Sun, 9 Nov 1997 09:27:50 -0500 (EST) From: Chuck Robey X-Sender: chuckr@localhost To: Terry Lambert cc: Tony Overfield , mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: >64MB In-Reply-To: <199711090753.AAA17086@usr06.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, 9 Nov 1997, Terry Lambert wrote: > > I can't tell, but I think you're talking about one of these: > > > > 1. ... switching to protected mode, setting larger segment limits > > and then switching back to real mode. > > > > It's very unlikely that you have anything in your config.sys > > that uses this trick. There's no benefit to using it, and > > there are serious compatibility problems with it. > > > > 2. ... the real mode trick of using FFFF:xxxx addressing. > > > > This lets you address up to 64K-16 bytes of memory above 1M in > > real mode. Protected mode is not needed to enable or use this > > trick. It is completely inadequate for loading a kernel. In > > DOS, this is called the HMA "high memory area". It is used > > when use have DOS=HIGH in your config.sys, as one example. > > > > 3. Something else. > > If so, please state it more clearly. > > 3. Something else. > > A) Switch to protected mode. > B) Set up a TSS and call gate. > C) Set up a memory map for real mode, excluding the last 64k in > the 640k->1M window. For it, you leave it unmapped. > D) Set up a data area below the 64k that the code stores what area > of high memory you want to access. > E) "Return" to real mode by calling through the gate. > F) When you need to access a 64k chunk abouve 1M, set which one you > want in the data area, and then access it as if it were in the > 64k region. > G) Take the fault in protected mode. Examine the data region. Map Terry, I don't think that will happen this way. Are you sure you didn't mean VM86 mode, not real mode? The exception won't move you to protected mode automatically (except in VM86 mode). > the desired region in the Real mode last 64k. Return. > > This is not quite trivial, but it's not quite impossible, either. Many > memory managers (even DOS ones) do it every day. > > There are several other you can do using suspend/resume instructions and > similar tricks (documented in the Van Gilluwe book -- I assume that's > what you were referring to in #1? > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+-----------------------------------------------