• Please review our updated Terms and Rules here

Compaq DeskPro 286 resurrection

resman said:
EMS under real-mode Windows 3.0 is of questionable value unless the application is written to use it directly.
Click to expand...

EMS support was introduced in Windows 2.0 so most real-mode software should work with it; the question I'd have is whether there's actually any real-mode compatible software that *requires* Windows 3.0. My impression is Real Mode support was only included with Windows 3.0 for backwards compatibility with ill-behaved Windows 1/2.x software that was incompatible with Standard mode, and Microsoft really never intended anyone to run it on XTs. (Thus issues with color video drivers, etc.) If you're dying to run Windows on an XT Windows 2 might be a better choice and offer about the same level of software compatibility.
 
AndyM1981 said:
Just how slow does Windows 3.1 run? Glacially, or would it have been tolerable back in the day if you had that much RAM?
Click to expand...

Depending on what you were doing and what you were used to, I'm sure it would have been tolerable. Office style applications would have been a decent match for this setup. Boring, but adequate. Solitaire runs just fine ;-)
 
Eudimorphodon said:
EMS support was introduced in Windows 2.0 so most real-mode software should work with it; the question I'd have is whether there's actually any real-mode compatible software that *requires* Windows 3.0. My impression is Real Mode support was only included with Windows 3.0 for backwards compatibility with ill-behaved Windows 1/2.x software that was incompatible with Standard mode, and Microsoft really never intended anyone to run it on XTs. (Thus issues with color video drivers, etc.) If you're dying to run Windows on an XT Windows 2 might be a better choice and offer about the same level of software compatibility.
Click to expand...

One can use EMS to enable Large Page Frame EMS under real mode Windows 3.0 just like Windows 2. That would allow one to run multiple larger applications at the same time. I think Excel was one of the few Windows applications that used EMS directly but any spreadsheet large enough to need EMS probably should be run on a machine faster than any 286 or 808x. Most of the benefit from EMS for real mode Windows will be as a disk cache.

I think there were a couple of applications that required some Windows 3.0 APIs while also running in real mode. Not too many and generally real mode Windows wasn't happy trying to load all the needed graphics. Program Manager and File Manager were a tight squeeze with Windows 3 real mode.
 
Eudimorphodon said:
EMS support was introduced in Windows 2.0 so most real-mode software should work with it; the question I'd have is whether there's actually any real-mode compatible software that *requires* Windows 3.0. My impression is Real Mode support was only included with Windows 3.0 for backwards compatibility with ill-behaved Windows 1/2.x software that was incompatible with Standard mode, and Microsoft really never intended anyone to run it on XTs. (Thus issues with color video drivers, etc.) If you're dying to run Windows on an XT Windows 2 might be a better choice and offer about the same level of software compatibility.
Click to expand...

Yeah, I can't image running Windows 3.0 on an XT was a real high priority for MS in 1990. I could see real-mode serving the < 1MB 286 crowd. Surprisingly, Compaq was still selling a DeskPro 286n with 1 MB as a base model.
 
krebizfan said:
One can use EMS to enable Large Page Frame EMS under real mode Windows 3.0 just like Windows 2. That would allow one to run multiple larger applications at the same time.
Click to expand...

I guess I didn't use Windows at all before the Standard Mode era so... wow, if this is accurate it was really kind of pointless to bother with EMS unless you could do large page frames with conventional backfill. I didn't realize it was that terrible at using it.

(I mean, yeah, it is generally speaking *awkward* to use regular EMS for large amounts of code instead of just data, but I was under the mistaken impression that Windows jumped through the hoops to do it instead of just letting you effectively use just one 64k segment per program. Guess it shows I never actually used it.) :)
 
Eudimorphodon said:
I guess I didn't use Windows at all before the Standard Mode era so... wow, if this is accurate it was really kind of pointless to bother with EMS unless you could do large page frames with conventional backfill. I didn't realize it was that terrible at using it.

(I mean, yeah, it is generally speaking *awkward* to use regular EMS for large amounts of code instead of just data, but I was under the mistaken impression that Windows jumped through the hoops to do it instead of just letting you effectively use just one 64k segment per program. Guess it shows I never actually used it.) :)
Click to expand...

That article slightly understates the use of EMS under Windows. If there are additional EMS page frames in addition to the data frame, code can be move into it. It might use a few hundred KB of EMS for code in that case but often the code stored in EMS would not needed soon and could have been just as easily discarded. The major limiting factor is multi-segment data structures which are locked in place and dominate the lower 640 k. It is difficult to have two of those at the same time. The large page frame gives each application its own address space to lock down and easily handle multiple segments as a single unit.

I was very happy that Windows 3 was released before I was required to write larger applications for Windows. Dealing with memory management under real mode Windows in ways that don't adversely impact other programs was a lot of work.
 
Eudimorphodon said:
I guess I didn't use Windows at all before the Standard Mode era so... wow, if this is accurate it was really kind of pointless to bother with EMS unless you could do large page frames with conventional backfill. I didn't realize it was that terrible at using it.

(I mean, yeah, it is generally speaking *awkward* to use regular EMS for large amounts of code instead of just data, but I was under the mistaken impression that Windows jumped through the hoops to do it instead of just letting you effectively use just one 64k segment per program. Guess it shows I never actually used it.) :)
Click to expand...

What's interesting is in my experiments with Windows/286 I've actually found that it uses a lot of EMS even though I'm operating in the small page frame model since I can't disable conventional memory on my motherboard. I have 1.5 megs installed on an Above Board and when I load up multiple applications in Windows most of it is used, far more than if each program only had access to 64K.

Now, two of the largest users are Word and Excel, with each using over 600K when you load a large file; so perhaps they are using it directly as you said.
 
AndyM1981 said:
What's interesting is in my experiments with Windows/286 I've actually found that it uses a lot of EMS even though I'm operating in the small page frame model since I can't disable conventional memory on my motherboard. I have 1.5 megs installed on an Above Board and when I load up multiple applications in Windows most of it is used, far more than if each program only had access to 64K.

Now, two of the largest users are Word and Excel, with each using over 600K when you load a large file; so perhaps they are using it directly as you said.
Click to expand...

Seems like there would be some confusion between small and large frame EMS pages and who would have to manage them. Small frame managed by applications and large frame managed by Windows? Apparently Windows/286 was in name only. It ran in real-mode and the only 286-ishness to it was the ability to use the HMA. Even back then, MS didn't expect you to run it on your XT. I only used Windows/386, and mostly as a multi-window DOS task switcher with a smattering of Excel, Ami and Micrografix Designer (that was a good program - I should install that, too).

I'm glad those days are behind us.
 
I've pretty much wrapped up setting up and configuring the maxed-out DeskPro 286. Here is my final hardware and software setup:

Hardware:
Compaq DeskPro 286 ver 2 @ 12 MHz
80287
4.1 MB Extended RAM (2.1 MB on motherboard + 2 MB Intel AboveBoard)
16 bit VGA (bog standard, nothing exciting)
COM1, COM2, LPT1, LPT2
1.44 MB floppy drive A:
SN2000 (NE2000 compatible) Ethernet card with Universal BIOS 2.00 beta3 in boot ROM socket
Compaq Enhanced keyboard
Serial port mouse on COM1
Iomega ZIP 100 on LPT1

System Software:
Compaq MS-DOS 5.0 (620624 bytes avail)
MS network client 3.0 - TCP/IP stack connecting to Samba server (399360 bytes avail with 1 drive mapped)
Windows 3.1 in Standard mode (3,390 KB free, 86% Resources free)

Application Software:
MS Office 4.2
MicroGrafx Designer 3.1
Windows Entertainment Pack

Development Software:
MS MASM 5.1
MS C 5.1
Turbo Pascal 7.0
Borland C 2.0
Borland C++ 3.1 (sort of - 16 bit Windows Apps only)

To reiterate, I hadn't used a 286 machine since Reagan was in office (and just barely his second term). Never impressed me much, but I learned a lot from this exercise.

First off, as a pure DOS machine, it wasn't a huge leap from the DeskPro 8086, especially with a NEC V30 CPU. Coming from a 4.77 MHz 8088, however, it was a pretty decent upgrade. Hard drive I/O performance was improved with the 16 bit ISA bus even with the same drive type. I moved a modern-ish 20 GB Maxtor IDE drive from the DeskPro 8086 with XT-IDE to the DeskPro 286 using the same version of the Universal BIOS but using the Compaq AT hard/floppy drive controller. Clearly faster on the 286. But DOS didn't provide much improvement over the 8086 as access to the extended memory was near impossible. Only with the Compaq version of HIMEM.EXE to enable the HMA so DOS could be loaded high was there any indication of the additional memory. Of course, the AboveBoard would need to be reconfigured as expanded memory for DOS applications to take advantage. Still no real improvement over the 8086.

The only DOS specific programs I have are development tools. Even by 1989, the 80286 was being dropped in favor of the 80386 and 32-bit DOS extenders. The last real-mode version of Microsoft C was 5.1, and Borland's C++ was 2.0. Real-mode assemblers and Turbo Pascal (even ver. 7) hung around a little while later.

Other 80286 OSes I didn't try were OS/2 and Xenix. OS/2 on a 286 was pretty pointless, hardly any 16 bit programs to run. Xenix is somewhat interesting, and would have been a solid choice if it ran the application you needed. Since I already run Xenix 86 on a DeskPro 8086, I didn't see any need to investigate this route.

The saving grace for the 80286 was Windows 3.0/3.1. Really the only way to take advantage of the extended memory and still run a large library of applications. MS Office 4.2 runs, but using the desktop publishing features of Word will test your patience. Excel seems to run pretty well, especially with a 80287. Micrografx Designer ran up to version 3.1 (later versions wanted Enhanced mode) but it isn't something you really want to run on a 286 and VGA @ 640x480. Interestingly, Borland C++ 3.1 installed and the Windows IDE ran and compiled programs. The DOS compiler was 32 bit extended though, and I had to revert to version 2.0 for command line operation. Really, anything released after 1992 seemed to require Enhanced mode. Whether they needed 32 bit instructions or extended memory access I don't know, but they didn't care to support the 80286.

So, this whole sheltering at home time gave me the opportunity to see how far I could push a maxed-out 80286 machine. It was definitely a viable platform for light office work well into the '90s. Almost a 10 year life span (if you include the original IBM AT) during a time of rapid advancements. Not bad, but I wouldn't have traded my DeskPro 386 for one.
 
I noticed there is currently a Compaq DeskPro 286 on eBay (I'm not affiliated) that appears to have the exact same issue I had - shorted tants. Power supply crowbars when turned on. It looks to be nicely outfitted with an AboveBoard, just like the one I got. Only thing missing is the hard drive. I bet someone could give them a low offer and quickly have a nicely working machine.
 
resman said:
Development Software:
...
Turbo Pascal 7.0
Borland C++ 3.1 (sort of - 16 bit Windows Apps only)

The only DOS specific programs I have are development tools. Even by 1989, the 80286 was being dropped in favor of the 80386 and 32-bit DOS extenders. The last real-mode version of Microsoft C was 5.1, and Borland's C++ was 2.0. Real-mode assemblers and Turbo Pascal (even ver. 7) hung around a little while later.

...

Interestingly, Borland C++ 3.1 installed and the Windows IDE ran and compiled programs. The DOS compiler was 32 bit extended though, and I had to revert to version 2.0 for command line operation.
Click to expand...

As a follow up to the development tools I would to run on the DeskPro 286, I found that Borland *did* support protected mode 286 with C++ 3.1 and Pascal 7.0. You had to run their DPMIINST.EXE program to presumably find the best way to return to real mode from 286 protected mode (using the keyboard controller to identify the return from reset). Once that is done, the command line C++ can be run and TPX.EXE: the protected mode version of Turbo Pascal.
 
Borland Pascal 7.0 (not the same thing as Turbo Pascal 7) has a full IDE that runs in 286 protected mode, the main advantages being that you compile/debug/trace 286 protected-mode programs, and if a program crashes badly, the IDE traps it instead of it taking down the entire system. You may want to give that a try too.
 
I believe what I see is Turbo Pascal 7.0 with a protected mode IDE as well. Is the difference the ability to build protected mode apps (don't see a compile option for TP7)?. I admit to being surprised when I realized BC++ 3.1 could run as a 16 bit protected mode DOS app.
 
You must log in or register to reply here.
Back
Top