Message-ID: <01FD6EC775C6D4119CDF0090273F74A4021E5E@emwatent02.meters.com.au> From: "Da Silva, Joe" To: "'opendos AT delorie DOT com'" Subject: FW: Misc. (was BASIC & EMS, nee Optimizing CONFIG.SYS...) Date: Tue, 5 Dec 2000 09:57:34 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id RAA12882 Reply-To: opendos AT delorie DOT com OK ... last attempt! For some reason, the following message kept bouncing ... :-( Joe. > -----Original Message----- > From: Da Silva, Joe > Sent: Monday, 4 December 2000 11:45 > To: 'opendos AT delorie DOT com' > Subject: RE: Misc. (was BASIC & EMS, nee Optimizing CONFIG.SYS...) > > Arkady is of course correct, re. XMS, etc. :-) > > Now, for some miscellaneous items that have "surfaced" in > this thread : > > 1. FYI : We all agree the 8088/8086 was a very stupid choice > by IBM and is the reason we now have all these issues. The > reason they chose this *very* poor performance chip, instead > of the 68000 or Z8000 (both good performers, although I think > Z8000 also uses segmented memory - yuck!!!) is that : > a) They already had an 8085 design, which they could quickly > "rehash" to use the 8088 chip. > b) They had a license agreement with Intel, to make the 8088 > or 8086 chip themselves. > > 2. What is DV (some multitasking thing mentioned ...)? > > 3. FYI : My 4x and 6x CD-ROM drives _don't_ make shrill > spinning sounds, but my 40x CD-ROM does! This tells > me that indeed, my 40x drive spins *much* faster than > my 4x or 6x drives, so this "40x" stuff is real, not a > marketing fiction for drives that just have data buffering ... > > 4. Is it really possible to split the EMS page frame into, say > two 32K chunks? This would be a very "handy" thing - for > instance, 32K could "live" on top of the VGA BIOS, using > Stealth (not Cloaking, right? ;-) techniques, and the other > 32K could "live" on top of the F000-F7FF BIOS region (MP > says this is possible for 90% of machines ...). Great stuff, > but it sounds "too good to be true", doesn't it??? > > Joe. > > -----Original Message----- > From: Arkady V.Belousov [SMTP:ark AT belous DOT munic DOT msk DOT su] > Sent: Saturday, 2 December 2000 21:02 > To: opendos AT delorie DOT com > Subject: Re: BASIC & EMS (was: Optimizing CONFIG.SYS...) > > X-Comment-To: Patrick Moran > > Hi! > > 1-δΕΛ-2000 03:57 pmoran22 AT yahoo DOT com (Patrick Moran) wrote to > : > > PM> Okay, what the hello is XMS meory? > > XMS is not a memory, but a specification, API to access extended > memory for "real mode" programs (see below). > > PM> Is it ENTEDED meory or just another stupid swap em out memory? > > XMS is not a memory, this is a specification how to exchange data > between conventional memory (for direct access) and extended memory (to > store data there). > > PM> Extended memory does not swapping you are in > PM> memory above 1MB when you use ectended memory and you are in protected > mode > PM> when using extended memory. > > Please, don't mix extended memory itself and XMS API to access this > memory. When program work in "native" 386+ mode (so called "protected > mode") > then it have full access to all physical/virtual memory and there is no > requirements to additional explicit APIs. But me talk not about "32bit" > programs (286 CPU is not 32-bit but this not change the idea), we compare > two specification to access additional memory (XMS and EMS) in "16bit" > programs which works in "real" mode (or in "V86" mode) and have "native" > access only to 1M of memory. > > This thread started when you prosecute EMS as very bad specification > in > compare with XMS. I try to show you: EMS have _only one_ contra - it cuts > frame for working from 1M addressing. This have nothing common with > Windows, > Task manager, etc which are protected mode apps and don't require XMS and > EMS to access extended memory for itself. > > ----- snip ----- >