OmniBook 300/425 - Freeing up conventional memory

[Dave Britten]

I was always bummed that I could never get OBMAX working on my OB 300, as I thought I'd be stuck with ~420 KB conventional memory forever, but while digging around the OmniBook archives to kill time, I found a document from HP explaining how to disable the DoubleSpace and Flash File System drivers manually and get pretty much the same effect.

http://omnibooks.info/archive/ob300-530/...i01072.htm

This specifically states that it applies to the 425, but I just did it on my 300 running a cloned 1.1 ROM, and it worked perfectly. The key is the OBBOOT.COM utility that controls which of the two drivers will be loaded at startup. They can be toggled independently, so if you want to play it safe, or simply don't want to use extra space on C: copying all the files from the D: ROM partition, you can disable only Double Space, for example (assuming you aren't using it on your C: drive). I'm assuming the selected boot option gets stored somewhere in NVRAM (along with the clock and such), but I'm not 100% certain what the recovery procedure is if you mess up and leave the system non-bootable. Pull the batteries and clear the NVRAM, maybe?

All the execute-in-place stuff - e.g. Windows, Excel, Word - still lives in the memory-mapped portion of ROM and continues working as it did before, it's just the stuff that was on the ROM-based D: filesystem that gets copied. So, you won't be sacrificing any extended memory in Windows.

This kinda makes moot the main reason I just ordered a 2.0 card from a 430, but what the hell, I'm sure I can still come up with plenty of interesting experiments for that.

[matthiaspaul]

(12-29-2016 04:24 AM)Dave Britten Wrote:  I was always bummed that I could never get OBMAX working on my OB 300, as I thought I'd be stuck with ~420 KB conventional memory forever, but while digging around the OmniBook archives to kill time, I found a document from HP explaining how to disable the DoubleSpace and Flash File System drivers manually and get pretty much the same effect.

If disk compression is important, you could try using Stacker 3.xx instead of DoubleSpace. Stacker can utilize DPMS (DOS Protected Mode Services), so it can relocate and run most of its resident code in extended memory, so there should be more free conventional and upper memory for other applications to work with.
Stacker 3.12 and DPMS could be lifted from DR-DOS 7.02/7.03.

Greetings,

Matthias

[Dave Britten]

(12-29-2016 07:52 PM)matthiaspaul Wrote:  If disk compression is important, you could try using Stacker 3.xx instead of DoubleSpace. Stacker can utilize DPMS (DOS Protected Mode Services), so it can relocate and run most of its resident code in extended memory, so there should be more free conventional and upper memory for other applications to work with.
Stacker 3.12 could be lifted from DR-DOS 7.02/7.03.

Greetings,

Matthias

In the OmniBook's days of 10 MB flash cards costing hundreds of dollars, compression was no doubt pretty important. Thankfully, you can find 256 MB compact flash cards in the sofa cushions at this point, so give me back that RAM and I/O performance!

I've had my 300 running with both DoubleSpace and Flash File System disabled since last night, and it's been working great. I threw DOSSHELL 5.0 on it and enabled the task swapper, which appears to use some combination of XMS and/or 386 virtual mode, so it'll run plenty of DOS programs simultaneously without needing to get Windows running in 386-enhanced mode.

[Dave Britten]

Small update: I can confirm that yanking the batteries and doing a completely cold boot seems to reset the option set by OBBOOT.COM, so you can recover from making your system non-bootable. Likewise, don't forget to reset the boot mode if you pull power for other reasons (like experimenting with CF cards to use as the C: drive, as I was doing).

Also, if you un-rem EMM386 in config.sys, you'll get an extra 60 KB UMB to devicehigh/loadhigh stuff into, but Windows won't run in standard mode with EMM386 active. Handy if you're not using Windows, or if you've installed everything needed to run it in 386-enhanced mode, though.

[matthiaspaul]

(12-29-2016 08:17 PM)Dave Britten Wrote:  so give me back that RAM and I/O performance!

That's right in general, but it depends on several factors like the speed of your storage device, the processor speed and the type of files. Compressing data and transferring only the remainder can sometimes be faster than just writing through the uncompressed data. This may not apply to your setup at all, but I found that some old (disk-based) systems actually became faster by installing Stacker.

Quote:I threw DOSSHELL 5.0 on it and enabled the task swapper, which appears to use some combination of XMS and/or 386 virtual mode

Does it really swap to XMS? AFAIR, DOSSHELL only swaps to disk, not XMS or EMS. What makes you think it is using 386 virtualization features? (AFAIK, it does not.)

Greetings,

Matthias

[Dave Britten]

(12-30-2016 09:53 PM)matthiaspaul Wrote:  That's right in general, but it depends on several factors like the speed of your storage device, the processor speed and the type of files. Compressing data and transferring only the remainder can sometimes be faster than just writing through the uncompressed data. This may not apply to your setup at all, but I found that some old (disk-based) systems actually became faster by installing Stacker.

Very true. SQL Server, for example, will almost always give you faster backups if you enable backup compression, thanks to the massive size reduction it often affords (particularly with our ERP system's fixed-width columns and tons of repeated values). I doubt the wee little 386 in the OmniBook would offer much of a boost, though, especially when it's already using a nice quick CF card. The 425's 486 might be another matter. And anyway, leaving the disk uncompressed makes it easier to yank it out and mount it on another system in case of problems.

(12-30-2016 09:53 PM)matthiaspaul Wrote:  Does it really swap to XMS? AFAIR, DOSSHELL only swaps to disk, not XMS or EMS. What makes you think it is using 386 virtualization features? (AFAIK, it does not.)

Greetings,

Matthias

It may be doing something like that. I tried finding documentation explaining what the task swapper actually does under the hood, but couldn't find anything. It does let you adjust how much conventional memory and XMS a program gets, however, which made me think it's at least doing some kind of protected and/or virtual mode tricks. I'll have to keep an eye on the OB's disk activity indicators to see if it looks like it's swapping to disk, and if I can find the swap files laying around somewhere. And perhaps it has a couple different modes of operation depending on what sort of CPU you have; I'll have to see what it does on my 200 LX.

[matthiaspaul]

(12-30-2016 10:24 PM)Dave Britten Wrote:  It does let you adjust how much conventional memory and XMS a program gets, however, which made me think it's at least doing some kind of protected and/or virtual mode tricks.

I see, but this just requires hooking the corresponding API calls and placing a filter onto them.

Quote:I'll have to keep an eye on the OB's disk activity indicators to see if it looks like it's swapping to disk, and if I can find the swap files laying around somewhere.

The .SWP swap files should be either in the %TEMP% directory or in the directory specified in the %DOSSHELL%\DOSSHELL.INI file ([savestate] swapdisk=filepath). Probably hidden.

The diagnostic tool MFT (from QEMM) had a nice feature of showing handles in use - this could be used to see if DOSSHELL allocates handles for XMS or EMS swapping (instead of dealing only with handles opened by the applications). Not sure, if MSD provides something similar.

Quote:And perhaps it has a couple different modes of operation depending on what sort of CPU you have; I'll have to see what it does on my 200 LX.

DOSSHELL has no CPU-specific modes, there should be no significant differences.

Greetings,

Matthias

[Dave Britten]

Okay, found where it hides the temp file, so it's definitely doing disk swapping. Makes me wonder why you can configure the memory requirements for program entries if they get all the RAM anyway. I'll bet RAMDRIVE.SYS would be an easy way to make it use XMS.

I do see behavior differences between my 200LX and OB300, though. On the 200LX, I can't alt-tab away from EDIT for some reason, and whenever I switch back to DOSSHELL, it redoes its disk inventory as though it's been freshly launched. All settings are the same as far as I can tell.

Related question: do you know of any guides to getting everything in place to run Windows in 368 mode? Or any other good DOS-based operating environments that offer 386 task-switching?

[striegel]

(12-31-2016 12:58 PM)Dave Britten Wrote:  ... Or any other good DOS-based operating environments that offer 386 task-switching?

Have you ever used Software Carousel? That's what I've used for a long time on the 200LX but I know it exists for other DOS machines. Where can you buy it today if you don't already own a copy? I have no idea.

Alan

[matthiaspaul]

(12-31-2016 12:58 PM)Dave Britten Wrote:  I do see behavior differences between my 200LX and OB300, though. On the 200LX, I can't alt-tab away from EDIT for some reason

Obviously, I can only guess without having a deeper look, but if this happens also with other programs of the "QBASIC family" like QBASIC or HELP and not with other programs, it might have to do with the non-standard way these programs interact with the keyboard. (EDIT.COM and HELP.COM are sort of "dummies" which internally call QBASIC.EXE with undocumented special parameters /EDCOM and /QHELP, respectively.) I remember that when I was developing an advanced DOS keyboard driver it took a lot of effort to make some of its special features work under QBASIC as well and keep it from temporarily loading its own embedded keyboard driver (INT 16h/AH=55h). However, this would not directly explain differences in the behaviour on the 200LX and the OB300, but could be the result of loaded drivers.

Quote:whenever I switch back to DOSSHELL, it redoes its disk inventory as though it's been freshly launched. All settings are the same as far as I can tell.

This might be an artifact of either the amount of available DOS memory or which pieces of memory got overwritten during swapping (IIRC DOSSHELL had two disk login modes selected depending on memory, recursively reading in the whole drive or only the current directory).

Greetings,

Matthias

[matthiaspaul]

(12-31-2016 12:58 PM)Dave Britten Wrote:  Or any other good DOS-based operating environments that offer 386 task-switching?

There are several DOS task switchers. Alan has already mentioned Software Carousel. It had a very good reputation. Another program I remember was Back&Forth. IIRC, Central Point had a task switcher named CPTASK as part of their PC Tools suite.

DR DOS 6.0 and higher came with TaskMAX, a task switcher with less overhead and more flexibility (swapping to XMS, EMS or disk) than DOSSHELL. It did not come with a file manager by itself, though - but if a user really needed a graphical file manager, s/he could use ViewMAX (a derivative of GEM).
TaskMAX came with a text mode interface by default, but it provided an API allowing other software to register as alternative interfaces. For example, if ViewMAX/2 (or 3) is loaded, it takes over the task switcher interface. Using the same API, PC/GEOS (and Windows) can do so as well. Technically, TaskMAX would also run on MS-DOS, but unfortunately this is prevented by a DOS version check, hence it could be used by you only if your Omnibook can be set up to boot alternative operating systems (or if you load a TSR to fake DOS versions).

If so, you might benefit more from switching to DR-DOS 7.03. The task manager is now called TASKMGR. If KRNL386, the 32-bit core of the operating system, is loaded (by EMM386 /MULTI), DR-DOS can provide not only task switching but multithreading as well as preemptive multitasking of applications in virtual DOS machines, so that applications can continue to run in the background, and switching the foreground task works in an instant, instead of taking up to several seconds as for a task switcher swapping to disk. This works for standard DOS as well as DPMI extended DOS applications. Other extended DOS applications will be suspended in background, the same happens with applications in unsupported graphics modes. In this mode TASKMGR no longer works as a stand-alone switcher application (unless option /S is provided) but as a frontend module to the underlying multitasking OS, so the look-and-feel remains similar.
ViewMAX and PC/GEOS can still be used as alternative graphical frontends. Under the multitasker, Windows 3.x only works in Standard mode, while it also works in 386 Enhanced mode under the task switcher. Tasks started before Windows show up seamlessly in the task list under Windows as well.

Another highly capable multitasking environment for DOS is DESQview. It even has text mode windowing capabilities.

Greetings,

Matthias

[Bill (Smithville NJ)]

(01-01-2017 11:58 PM)matthiaspaul Wrote:  Another highly capable multitasking environment for DOS is DESQview. It even has text mode windowing capabilities.

Greetings,

Matthias

I used DESQview back in the late 80's to run TCP/IP Net and a email program with ham radio. It worked very well and I even used it on a IBM PC Jr floppy disk only system.

I remember doing a test one time by opening up several dos windows and then doing a directory listing in each. You could watch the directory listing scroll by in each of the screens. With a little bit of stutter every now and then. Really quite amazing.

Bill
Smithville, NJ

[Bill (Smithville NJ)]

Dave,

What maximum memory available did you achieve. Which memory manager did you use? And could you make the config.sys and autoexec files available.

I've only been able to achieve 589kb - that's using the msdos 6.22 emm386 and himem. This is for a dos based OB-430 system - no windows loaded.

I tried using QEMM but always ran into problems using the Optimize tool - it would never complete without some warning errors.

Thanks,

Bill
Smithville, NJ

(12-29-2016 04:24 AM)Dave Britten Wrote:  I was always bummed that I could never get OBMAX working on my OB 300, as I thought I'd be stuck with ~420 KB conventional memory forever, but while digging around the OmniBook archives to kill time, I found a document from HP explaining how to disable the DoubleSpace and Flash File System drivers manually and get pretty much the same effect.

http://omnibooks.info/archive/ob300-530/...i01072.htm

This specifically states that it applies to the 425, but I just did it on my 300 running a cloned 1.1 ROM, and it worked perfectly. The key is the OBBOOT.COM utility that controls which of the two drivers will be loaded at startup. They can be toggled independently, so if you want to play it safe, or simply don't want to use extra space on C: copying all the files from the D: ROM partition, you can disable only Double Space, for example (assuming you aren't using it on your C: drive). I'm assuming the selected boot option gets stored somewhere in NVRAM (along with the clock and such), but I'm not 100% certain what the recovery procedure is if you mess up and leave the system non-bootable. Pull the batteries and clear the NVRAM, maybe?

All the execute-in-place stuff - e.g. Windows, Excel, Word - still lives in the memory-mapped portion of ROM and continues working as it did before, it's just the stuff that was on the ROM-based D: filesystem that gets copied. So, you won't be sacrificing any extended memory in Windows.

This kinda makes moot the main reason I just ordered a 2.0 card from a 430, but what the hell, I'm sure I can still come up with plenty of interesting experiments for that.

[Dave Britten]

(01-01-2017 11:58 PM)matthiaspaul Wrote:  There are several DOS task switchers. Alan has already mentioned Software Carousel. It had a very good reputation. Another program I remember was Back&Forth. IIRC, Central Point had a task switcher named CPTASK as part of their PC Tools suite.

DR DOS 6.0 and higher came with TaskMAX, a task switcher with less overhead and more flexibility (swapping to XMS, EMS or disk) than DOSSHELL. It did not come with a file manager by itself, though - but if a user really needed a graphical file manager, s/he could use ViewMAX (a derivative of GEM).
TaskMAX came with a text mode interface by default, but it provided an API allowing other software to register as alternative interfaces. For example, if ViewMAX/2 (or 3) is loaded, it takes over the task switcher interface. Using the same API, PC/GEOS (and Windows) can do so as well. Technically, TaskMAX would also run on MS-DOS, but unfortunately this is prevented by a DOS version check, hence it could be used by you only if your Omnibook can be set up to boot alternative operating systems (or if you load a TSR to fake DOS versions).

If so, you might benefit more from switching to DR-DOS 7.03. The task manager is now called TASKMGR. If KRNL386, the 32-bit core of the operating system, is loaded (by EMM386 /MULTI), DR-DOS can provide not only task switching but multithreading as well as preemptive multitasking of applications in virtual DOS machines, so that applications can continue to run in the background, and switching the foreground task works in an instant, instead of taking up to several seconds as for a task switcher swapping to disk. This works for standard DOS as well as DPMI extended DOS applications. Other extended DOS applications will be suspended in background, the same happens with applications in unsupported graphics modes. In this mode TASKMGR no longer works as a stand-alone switcher application (unless option /S is provided) but as a frontend module to the underlying multitasking OS, so the look-and-feel remains similar.
ViewMAX and PC/GEOS can still be used as alternative graphical frontends. Under the multitasker, Windows 3.x only works in Standard mode, while it also works in 386 Enhanced mode under the task switcher. Tasks started before Windows show up seamlessly in the task list under Windows as well.

Another highly capable multitasking environment for DOS is DESQview. It even has text mode windowing capabilities.

Greetings,

Matthias

Thanks, I'll check some of those out. Sounds like DESQView would be easy enough to get running on an OB 300. Once I've got a 2.0 card to experiment with, I might try some of the other DOS alternatives too.

(01-02-2017 01:58 AM)Bill (Smithville NJ) Wrote:  Dave,

What maximum memory available did you achieve. Which memory manager did you use? And could you make the config.sys and autoexec files available.

I've only been able to achieve 589kb - that's using the msdos 6.22 emm386 and himem. This is for a dos based OB-430 system - no windows loaded.

I tried using QEMM but always ran into problems using the Optimize tool - it would never complete without some warning errors.

Thanks,

Bill
Smithville, NJ

I've attached my current startup files. With these (and running OBBOOT 3 to disable DoubleSpace and Flash File System), I get this from mem immediately after boot:

636,928 bytes available to MS-DOS
592,144 largest executable program size
7,274,496 bytes available XMS memory

If you un-rem EMM386.EXE, you get a 60 KB UMB to work with, at the expense of ~3 KB conventional memory (and Windows will no longer run in standard mode with EMM386 loaded).


  OB300Startup.zip (Size: 2.02 KB / Downloads: 16)