The continuing saga of Windows 3.1 in enhanced mode on OmniBook 300

[Dave Britten]

Yup, I'm still trying to get this to work, and I think I'm making a bit of progress. I don't have everything working 100% yet, but this is what I've done so far (I've only tested with a 2.0 ROM card as of yet, not with the ROM-based DOS/Windows that it came with):

1. Pop in the 2.0 ROM card, and boot to D:.
2. OBFDISK C:, and FORMAT C: /S to prep your C: card and make it bootable. Copy the CONFIG.SYS and AUTOEXEC.BAT to C:.
3. Install DOS 6.20 in VirtualBox, or another suitable virtual machine platform. Shut down the VM after you're done.
4. Mount the .VHD from the DOS 6.20 VM, attach your C: CF card to your PC, and copy the DOS directory over.
5. Put the C: card back in the OmniBook.
6. Copy the following files from D:\ to C:\DOS, and edit both AUTOEXEC.BAT and CONFIG.SYS on C: to point to the new paths where necessary: OBCRDDRV.EXE, POWER.EXE, OBMGM.EXE, OBFDISK.EXE, FORMAT.COM. You can skip PRSPF.SYS and REM it out; it's for a parallel port floppy drive, I believe.

Okay, that gets you a working DOS 6.20 installation. Now for Windows:

1. Extract all files from a set of Windows 3.11 floppy disks/images to the root of another empty CF card.
2. Pop that card into your OmniBook's A: slot, and run A:\SETUP.EXE.
3. Install Windows like normal (it'll be easier if you've got a serial mouse attached at this point). You shouldn't have to change the hardware config, as far as I can tell. You may want to shrink the virtual memory swap file to something like 8192 KB, though.
4. After installation, make sure you edit C:\WINDOWS\SYSTEM.INI and add this to the "386Enh" section: EMMExclude=d000-dfff
5. Edit AUTOEXEC.BAT, and alter the SMARTDRV line to have these arguments: "c d- /L". That will disable write caching on C: (I don't trust that with a system that can suspend/resume at any moment), and disable caching entirely on D: (you don't need it).
6. Reboot.
7. WIN /3, open up "MS-DOS Prompt", hit Alt-Enter, and... hooray!

Still working on getting the other things figured out, e.g. Windows power management, the OmniBook control panel, the OmniBook mouse driver, etc.

Note that this really only makes sense to do if your OB300 has a RAM upgrade. In my case, I've got the full 8 MB.

[Dave Britten]

Well shoot, as soon as I try to run it on battery power, Windows freezes dead in its tracks. Seems like the same old power management issue I ran into before. I wish I could get a copy of a working 430 hard drive with Windows installed and running in 386 mode... Can't figure out what the secret ingredient is here.

[Bill (Smithville NJ)]

(08-03-2017 04:01 PM)Dave Britten Wrote:  Well shoot, as soon as I try to run it on battery power, Windows freezes dead in its tracks. Seems like the same old power management issue I ran into before. I wish I could get a copy of a working 430 hard drive with Windows installed and running in 386 mode... Can't figure out what the secret ingredient is here.

Hi Dave,

I have an OB-430. I usually use it as a DOS machine.
If I get some time, I'll try to get Win3.1 installed on it. If I do I could send you an image of it.

I'll let you know how I make out.

Bill
Smithville, NJ

[Dave Britten]

(08-05-2017 12:42 AM)Bill (Smithville NJ) Wrote:  Hi Dave,

I have an OB-430. I usually use it as a DOS machine.
If I get some time, I'll try to get Win3.1 installed on it. If I do I could send you an image of it.

I'll let you know how I make out.

Bill
Smithville, NJ

Thanks, I'd mostly be interested in hearing what kind of results you get. Install DOS 6.20, Win 3.11 retail, and run Windows in 386-enhanced mode on battery power and let me know what happens. Not sure if it's just a slight difference in the 386 chip's power management vs. the 486 that's throwing something off.

And so far, I haven't figured out how to make DesqView do proper 386 multitasking. It seems like it's just swapping things in and out of XMS - or possibly swap files - rather than running multiple V86 VMs (and it gobbles up ~180 KB conventional memory, which doesn't help any).

At this point, I would settle for Win 3.1 in Standard mode but with DOS task swapping in XMS rather than swap files, and EMS enabled for Lotus Agenda.

[Bill (Smithville NJ)]

Dave,

Just realized I have Windows 3.1 NOT 3.11. And I'm having problems with getting 3.1 working. Need to spend more time on it.

May be a little while - I have a family medial issue that is taking up most of my time at present.

Bill
Smithville, NJ

[Dave Britten]

No problem, it's all just a casual experiment anyway.

It occurred to me that maybe I should try using the power management drivers from an original OB300 ROM with the software I'm running from the 2.0 card. Perhaps there's some key difference there.

[matthiaspaul]

(08-05-2017 01:09 AM)Dave Britten Wrote:  And so far, I haven't figured out how to make DesqView do proper 386 multitasking.

Which version of DESQview, and are you using QEMM or EMM386 as memory manager?

Did you try the DR-DOS multitasker already?

Greetings,

Matthias

[Dave Britten]

(08-05-2017 07:15 PM)matthiaspaul Wrote:  Which version of DESQview, and are you using QEMM or EMM386 as memory manager?

Did you try the DR-DOS multitasker already?

Greetings,

Matthias

I believe I tried DESQview 2.8, with both QEMM 8 and EMM386. QEMM was another pain, as Optimize usually ended up with awful and/or non-working configs. I also couldn't get it to put EMS in the UMA. Normally you'd put it at C000-CFFF on the OB300, but my attempts to do so were met with crashes on bootup. Couldn't find any good reference of command line arguments to try customizing it properly.

Haven't experimented with DR-DOS yet. MS-DOS 6.20 is the easiest to get installed without a floppy drive, since you can just FORMAT /S a new card, and copy over the DOS directory from 6.20 installed in a VM.

I'm sure the answer is "horribly", but has anybody seen how Win 95 runs on a 386 OmniBook with 8 MB RAM?

[matthiaspaul]

(08-06-2017 12:03 PM)Dave Britten Wrote:  QEMM was another pain, as Optimize usually ended up with awful and/or non-working configs.

I see. I always configured systems manually.

Quote:Haven't experimented with DR-DOS yet. MS-DOS 6.20 is the easiest to get installed without a floppy drive, since you can just FORMAT /S a new card, and copy over the DOS directory from 6.20 installed in a VM.

If you manage to make the DR-DOS 7.03 SYS.COM, IBMBIO.COM, IBMDOS.COM and COMMAND.COM files accessible from your MS-DOS system on the Omnibook (for example, by copying them to a C:\DRDOS\ directory on the CF drive on a PC), you could then try:

C:\DRDOS\SYS.COM C:\DRDOS C:

from the MS-DOS prompt on the OB300 to make drive C: DR-DOS-bootable using the files located in C:\DRDOS. (IIRC, the 7.03 SYS was already enabled to run under other systems (although with somewhat limited functionality possibly requiring some tweaking), however, if it doesn't, I could provide a much advanced 7.07 SYS which does for sure.)

The same method could be used running the DR-DOS SYS in the MS-DOS emulator under the Windows NT family if the target drive can be "locked" for the emulator by Windows, so that direct disk write access to that volume's boot sector from inside of the emulator becomes possible (this is typically not necessary for drive A: or B: - but I take it that you don't have these drives under Windows any more).

Or, if you'd manage to make the CF visible to a running DR-DOS VM on the PC (but not necessarily as boot drive A: or C: ), you could use the DR-DOS SYS to transfer the system to the CF. Again, you'd need to allow direct disk write access to the boot sector of the CF from the VM somehow.

Alternatively, if the C: CF drive is visible at BIOS INT 13h level on the OB300, you could also use the DR-DOS 7.03 FDISK.COM to prepare the C: drive - the DR-DOS FDISK does not only partition a disk, but can also format the freshly created volumes and initialize their boot sectors in one go, so there's no risk to accidently mess up the wrong volume and no need for FORMAT /S or SYS. Afterwards, you could just copy over the remaining DR-DOS files, including the system files. It is important to know that, in contrast to MS-DOS/PC DOS, DR-DOS has "smart" boot sectors which will actually "mount" the file-system to search for and load the system files in the root directory instead of expecting them to be placed at a certain location. Physically, the system files can be located anywhere and also can be fragmented. So, as soon as you find some way to replace the MS-DOS boot sector on the boot drive by a DR-DOS one, you've won.

If the CF drive is not visible on INT 13h level, you could use DEBUG to copy over the volume's logically first sector save the BPB (volume C: is logical drive 2 on DOS level). You'd just need a boot sector file for this, which you should be able to extract from a running DR-DOS VM on a PC using DEBUG as well. For this, the VM would need to grant read access to the VM boot drive's boot sector.

If the problem is getting the DR-DOS files off the DR-DOS distribution disk images, the normal way to use them is through the DR-DOS DISKCOPY or MAKEDISK utilities (which can also work with image files), but the images should be mountable by most third-party image mount utilities as well - they are just normal raw disk images with a short binary footer attached to them containing some extra data for DISKCOPY (which is (and should be) ignored by most other image mounters). In the worst case, this footer would have to be stripped off so that the files match the standard floppy image file sizes exactly in order to be recognized by raw image file mounters.

Quote:I'm sure the answer is "horribly", but has anybody seen how Win 95 runs on a 386 OmniBook with 8 MB RAM?

Putting memory requirements aside, Windows 4.0 does no longer support Standard mode, so if you can't get Enhanced mode to work properly with Windows 3.1x already, there's little point trying to use Windows 4.0...
Also, MS-DOS 7.0 consumes significantly more resident memory than prior versions for features offering no advantage on the OB300.

If you want a Windows 95 look-and-feel, you could try PC/GEOS (actually New Deal Office or Breadbox Ensemble), which will run fast on a 386 with 8 MB, look a lot like Windows 95 by default, and come with a set of quite powerful office applications. Optionally you could even use it as a GUI for the DR-DOS task switcher or multitasker as well.

Greetings,

Matthias

PS: I'm somewhat reluctant to go into better details, as I'm not sure this is the right forum for this topic. Wouldn't it be better to move this thread into the "Not quite HP Calculators - but related" sub-forum?

[Dave Britten]

(08-07-2017 11:05 AM)matthiaspaul Wrote:  

(08-06-2017 12:03 PM)Dave Britten Wrote:  QEMM was another pain, as Optimize usually ended up with awful and/or non-working configs.

I see. I always configured systems manually.

I'd like to try that, but haven't found a good command line argument reference for QEMM yet.

(08-07-2017 11:05 AM)matthiaspaul Wrote:  If you manage to make the DR-DOS 7.03 SYS.COM, IBMBIO.COM, IBMDOS.COM and COMMAND.COM files accessible from your MS-DOS system on the Omnibook (for example, by copying them to a C:\DRDOS\ directory on the CF drive on a PC), you could then try:

C:\DRDOS\SYS.COM C:\DRDOS C:

If DR-DOS is more lenient about what its utilities run under, then that might be doable. I know MS-DOS loves throwing "Incorrect MS-DOS Version", so you wouldn't be able to, for example, use DOS 6.22 SYS.COM or FORMAT.COM while running 6.20 in an attempt to upgrade.

(08-07-2017 11:05 AM)matthiaspaul Wrote:  PS: I'm somewhat reluctant to go into better details, as I'm not sure this is the right forum for this topic. Wouldn't it be better to move this thread into the "Not quite HP Calculators - but related" sub-forum?

Well, depends on your definition of "very old computers". But if somebody thinks this is better suited in another section, feel free to move it.

[Hans Brueggemann]

... just in case:
Windows 3.11 paraphernalia

[Bill (Smithville NJ)]

(08-06-2017 12:03 PM)Dave Britten Wrote:  I'm sure the answer is "horribly", but has anybody seen how Win 95 runs on a 386 OmniBook with 8 MB RAM?

Hi Dave,

I just did an experiment. Pulled the CF Card from my OB600 (Which runs Win95) and put it into an OB-430 with 8 mb ram. It booted up (slowllllllllllly) into Win 95 and complained about the Display drive being configured improperly. I ran a small program (File Commander) and it ran fine. When I pressed the off key, it turned off but then would not turn back on until I pressed the reset button. So the power management is not working correctly - which doesn't surprise me since it was running the OB-600 power management.

I might try copying the power management files from the OB-430 windows version and see if the works in Win95.

I really don't think you could do any productive work with it but is interesting to see that it would boot Win95.

Bill
Smithville, NJ

[matthiaspaul]

(08-07-2017 12:12 PM)Dave Britten Wrote:  I'd like to try that, but haven't found a good command line argument reference for QEMM yet.

IIRC all executables have built-in help screens giving you an overview of what's available. I'm not aware of an online reference for this, unfortunately.

(08-07-2017 12:12 PM)Dave Britten Wrote:  If DR-DOS is more lenient about what its utilities run under, then that might be doable. I know MS-DOS loves throwing "Incorrect MS-DOS Version", so you wouldn't be able to, for example, use DOS 6.22 SYS.COM or FORMAT.COM while running 6.20 in an attempt to upgrade.

Yes, this can be very frustrating. In general, DR-DOS follows the exact opposite philosophy, so that you will get this error message only if there is a technical or other serious reason not to allow this.

Unfortunately for the OB300, TASKMGR and SYS are among those exceptions. The DR-DOS 7.03 SYS 1.52 runs on other DR-DOS versions, but not on foreign DOSes - this was a safety measure to keep users from accidently invoking the "wrong" SYS tool in multi-OS scenarios (in conjunction with LOADER and the SYS /DR:ext option, DR-DOS can be installed onto the same volume in parallel to other OSes including other DR-DOS versions, MS-DOS, PC DOS, OS/2, Windows 9x, NT, etc.), and also because some assumptions made for automatic configuration are only valid on DR-DOS systems.

This does not apply to the newer SYS 1.66 tool, though, which was specially designed to work also on other systems in order to make it easier to set up a DR-DOS system. I just ran some tests and was about to copy some screenshots into an earlier version of this post, when there was a power outage causing a corrupted filesystem - and unfortunately this particular executable is now one of the files lost, so I will have to relocate it on a backup... This may take some while. #-|)

Greetings,

Matthias

[matthiaspaul]

(08-07-2017 11:05 AM)matthiaspaul Wrote:  The same method could be used running the DR-DOS SYS in the MS-DOS emulator under the Windows NT family if the target drive can be "locked" for the emulator by Windows, so that direct disk write access to that volume's boot sector from inside of the emulator becomes possible (this is typically not necessary for drive A: or B: - but I take it that you don't have these drives under Windows any more).

For illustration purposes here come some screenshots of SYS 1.66 running under NT's MS-DOS 5.50 emulator:

Z>set DRSYS=ON (optional to tell SYS you are aware of the fact that you're running it in a foreign environment and want to proceed anyway without having to individually ACK some warnings and extra info screens displayed in this scenario otherwise)
Z>sys /? /[

Code:


SYS [/Help] [drive1:][path] drive2: [/options]

SYS copies the DR-DOS system files from the source drive1:path to the target
drive2:. The target disk must be FAT formatted already. SYS also updates the
Boot Sector, so that the target disk becomes a DR-DOS bootable system disk.
In case no source drive and path is given, SYS will assume the system files to
reside on the drive containing the SYS.COM program. If this is a local drive,
it will try to locate them in the root of this drive, otherwise it will search
for them in the SYS.COM directory itself. SYS tries to use %[DR]COMSPEC% to
locate the Command Processor before searching for it at various other places.

  /A            Additionally copy [D]CONFIG.SYS and AUTOEXEC.BAT file(s).
  /B or /L      Do not modify the Boot Sector in destination (with LOADER).
  /C            Ignore %[DR]COMSPEC% variable(s) to find Command Processor.
  /CHS or /LBA  Force Boot Sector to use either CHS or LBA INT 13 Extensions.
  /DR[:ext]     Use other file extension for system files (BIN) (with LOADER).
  /E or /#      Force refresh of Serial Number or Time Stamp on target disk.
  /F:path       Alternative way to specify the drive1:path of source files.
  /G            Acoustic reminder of disk change or system transfer complete.
  /J            Additionally copy preloaded on-the-fly disk compression driver.
  /K            Keep original attributes of system files (else set to +RSH).
  /M            Make multiple system diskettes in one go.
  /N            Always preserve Command Processor name (use CONFIG.SYS SHELL).
  /O[:nnn]      Override IPL reported boot drive unit (n=0..126, 128..254).
  /P            Always prompt for insertion of diskettes (batchjob use).
  /R[:password] Password required to read, write or delete the kernel files.
  /S            Skip copying the Command Processor.
  /U            Save Boot Sector & Command Processor (OLDBOOT.BIN/COMMAND.OLD).
  /V            Always verify the integrity of the data written to disk.
  /X            Display verbose messages.            (%YESCHAR%=y, %NOCHAR%=n)
  /Y[:y[n]]     Assume YES on queries & abort on errors, or override YN chars.
  /3 or /5      Name either DRBIOS.SYS/DRBDOS.SYS or IBMBIO.COM/IBMDOS.COM.
  /6            Update GEMDOS Serial Number on target disk (Atari readability).
  /[ or /]      Mute or enforce signon message display (default: OS dependent).

Z>sys z:. a: /X /[

Code:


Reading files from the source disk...
Z:\DOS\DRDOS\DRDOS.707\IBMBIO.COM
Z:\DOS\DRDOS\DRDOS.707\IBMDOS.COM
Z:\DOS\DRDOS\DRDOS.707\COMMAND.COM
Preparing target disk...
Choosing FAT12 CHS Boot Sector (requires IPL to report boot unit).
Treating target as diskette or superfloppy medium (boot drive unit 0).
Writing new Boot Sector...
Writing files to the target disk...
A:\IBMBIO.COM
A:\IBMDOS.COM
A:\COMMAND.COM
Volume in drive A: is unlabeled, File System is FAT.
Volume Serial Number is 130A-091B.

System files copied.

SYS tries to lock the target drive for direct disk access, however, for a program run inside of the DOS emulator this isn't possible in all configurations. If it doesn't work, you'll get an error message like this (assuming X: would be the target drive here):

Code:


Drive X: not ready.
(In order to ensure File System integrity Operating Systems such as the OS/2
or NT families (including Windows 2000, XP and 2003) block direct disk access.
Your Host Operating System may provide configuration options to temporarily
lock the drive for exclusive use by SYS running in the DOS emulator, otherwise
you may need to first boot DR-DOS in order to run SYS. In many cases SYS should
still be able to access removable drives such as floppy drive A: or B: in order
to create a DR-DOS bootable disk. In case the disk has already been bootable
under a prior issue of DR-DOS and you want to update the DR-DOS files on disk,
use SYS /B to not update the Boot Sector.)

Sometimes write access to the boot sector is blocked even if a drive is locked, for example when using certain resident virus scanners. Therefore SYS will first attempt to read the boot sector and when a DR-DOS compatible boot sector is found on the target already, it will only update the kernel files and skip writing a new boot sector:

Code:


Required Boot Sector already found on target disk, no need to write new one.

As illustrated further above this method could be adapted to run the DR-DOS SYS 1.66 under MS-DOS 6.2x on the OB300. Write access to the boot sector should be possible for SYS on all logical drives, even without any need to "lock" the drive first (MS-DOS 6.x does not support this, anyway).

Greetings,

Matthias