home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.ibm.pc.misc:10923 comp.sys.ibm.pc.hardware:20491
- Path: sparky!uunet!noc.near.net!mars.caps.maine.edu!maine.maine.edu!ree700a
- Organization: University of Maine System
- Date: Tuesday, 28 Jul 1992 11:17:17 EDT
- From: <REE700A@MAINE.MAINE.EDU>
- Message-ID: <92210.111717REE700A@MAINE.MAINE.EDU>
- Newsgroups: comp.sys.ibm.pc.misc,comp.sys.ibm.pc.hardware
- Subject: 32 bit BIOS, etc. (was RE: 486/50'2 vs Sun 2's
- Lines: 76
-
- Somehow, the previous thread degenerated from a comparison to a speculation a
- bout 32-bit software, an over-hyped thing, given that it's all based on a real-
- mode bios!
-
- +>perhaps this would have more to do with the key-repeat rate on the 486 ??
- +>also: a 486 running 32bit OS/2 2.0 programs is about 4 time faster on
- +>integer code ( let alone floating point ) than the same machine under dos.
- +>(ie: think about what you are actually measuring !!!)
-
- Maybe OS/2 avoids the DOS-bios (hence it's large size) but, 32-bit pointers
- don't inherently buy you anything except simpler segmentation (not to understat
- e the advantages to the developer there). Otherwise, there is little or no sav
- ings between 32-bit protected mode pointers and 16-bit protected mode pointers.
- For that matter, given the BIOS problem, 16-bit real mode is probable faster wi
- thin it's MB area than either protected mode. Alas, what runs in 1MB anymore?
-
- +I can't see how this is possible. I can see how recompiling stuff for
-
-
- +32-bit *might* make it up to twice as fast, but not 4 times as fast. Please
- +justify this. I, myself, have ported DFLAT (the text mode user
- +interface lib from Dr. Dobb's Journal) and it's sample application,
- +to 32-bit extended dos and have noticed no speed increase at all.
- +And this code is full of far pointers. I have seen some small, tight
- +programs (gif decoder code) that does not benefit at all from
- +32-bit. The pointers are all near and the words used are all 16bit, and
- +there is no reason to make them 32-bit. From my experience, the
-
- True, but even a 16-bit operating system can move 32-bit double-words
-
- +advantages of having 32 bits are more in the form of having a large
- +flat address space, and much less in the form of more speed.
-
- And some advantage that is... try manipulating a 1MB data set...
-
- First, could someone please write a definitive post to the effect that
- 32 bit data values are available in both 16 bit and 32 bit operating
- systems?! Recompiling something for 32 bit will, in all likelihood
- accomplish nothing, since the same segmentation, data manipulation
- and (MOST important) BIOS calls which require a drop from protected mode
- and back will be involved (OK a good compiler _may_ improve the segment-
- ation).
- In order for 32-bit operating systems to be anything special (or
- for that matter, 16-bit protected mode operating systems), we need
- a revolution in BIOS itself. Perhaps new BIOS chips should have an
- option, whereby you press some key combination for protected mode & a
- second ROM chip (in ultra-extended memory) takes over. Real mode
- programs could be emulated, and even this would be faster than an XT!
- Then again, the BIOS-controlled dual boot could allow a 16-bit real
- mode boot for DOS, etc. which would set up the normal IRQ table _OR_
- a more useful, truely protected mode, 32-bit, Screw-DOS operating system.
- The only real catch is getting 32-bit protected mode BIOS extensions
- for all of those DOS-compatible cards. But then again, in a system which
- can flatmode 4 GB, there's plenty of room for memory resident drivers.
-
- While I've got your attention - Here's my $0.02 worth on Video...
- with 4GB of real memory space, why not set aside, oh about 128 MB as
- reserved space for memory mapped terminals? Rather than dealing with
- this bullshit about planes of memory and VGA registers, why not just
- allocate about 4MB for direct mapped Video, Mouse & Keyboard space and
- plan on allowing up to 32 users (OK, so I'm way ahead of it on this).
-
- I seriously think that a 32-bit BIOS, direct mapped, true-color
- (accelerated or co-processed) video and Fast-clocked (50 MHz) EISA
- will be sufficient to blow the lid off of desktop performance. When I
- think about the wasted clock cycles incurred by DOS, Windows, OS/2 and
- even Unix in dealing with archaic hardware standards, like segmented
- real mode memory, Multi-plane mapped video and slow-clocked I/O busses,
- I wonder how everyone stands for it.
-
- Jeffrey C. Andle
- U. Maine - Dept. of ELE & Surface Science Lab.
- Orono, ME
- " I wish my ideas were your own, then I wouldn't have to convince you "
- They are, alas, mine, not my employers', or anyone's who will do anything
- with them. If you want them, take them...
-