🚀 go-pugleaf

  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...