PC-DOS 3.2 for 5150

[maxtherabbit]

FWIW, "The Last Byte" does work on DOS 3.3 with static upper memory blocks. Running the "chipset" auto-detect program automatically sniffed out the 96k of memory type PHYSICAL in the right place, and I've confirmed I can load ANSI.SYS, CTMOUSE, and LTEMM.EXE (among others) high.

If you have enough upper memory to load DOS high this is still a loser compared to that, I have *way* more free memory under PC-DOS 7. But if you have 3.x and only a small amount of upper memory, like 32k on a network card, this may fill a niche. I am also very curious if the extend-base-memory function works properly if you have hardwired memory in A000.

The 30 second-then-hit-a-key shareware wait is pretty obnoxious, so unless you can register it that's a thing.

Can PC-DOS 7 actually load the DOS kernel into UMB (the first megabyte), or does it just utilize the 64kB HMA segment? I know it has that DOSDATA=UMB thing (that essentially just does the same thing as DOSMAX) but that's not moving the whole kernel

 

[Eudimorphodon]

Can PC-DOS 7 actually load the DOS kernel into UMB (the first megabyte), or does it just utilize the 64kB HMA segment? I know it has that DOSDATA=UMB thing (that essentially just does the same thing as DOSMAX) but that's not moving the whole kernel

With DOSMAX's help you can load MS-DOS 5 through PC-DOS 7's kernels into a UMB and free up the equivalent amount of space as you get from loading them into the HMA. Essentially DOSMAX fakes out the calls that would move the kernel to the HMA with himem.sys and retargets them to a UMB instead. You configure these DOSes just exactly like you would for HIMEM.SYS, with the "DOS=HIGH,UMB" syntax in config.sys.

(I also have the DOSDATA=UMB parameter set, but I think it may technically be redundant since DOSMAX can also move DOS data high on 5-6.22 itself. DOS 7 also has the native ability to load the resident part of command.com high, I have that set and therefore don't require the SHELLMAX helper to eek out the extra memory from doing that. But if you do have everything set up correctly with SHELLMAX on 6.22 the total free mem is very close between the two.)

End result is I have a whopping 631K conventional free on my standard boot config+packet driver on the VGA Tandy. (Subtract 16k for the TGA one.) And that's real "K", not decimal thousands.

Modules using memory below 1Mb:

  Name           Total       =   Conventional   +   Upper Memory
  --------  ----------------   ----------------   ----------------
  SYSTEM      27,632   (27K)      9,328    (9K)     18,304   (18K)
  BIOSPTCH       128    (0K)        128    (0K)          0    (0K)
  USE!UMBS       192    (0K)        192    (0K)          0    (0K)
  DOSMAX         240    (0K)          0    (0K)        240    (0K)
  SETVER         816    (1K)          0    (0K)        816    (1K)
  ANSI         3,600    (4K)          0    (0K)      3,600    (4K)
  LTEMM        6,320    (6K)          0    (0K)      6,320    (6K)
  INSTALL        160    (0K)          0    (0K)        160    (0K)
  COMMAND      5,056    (5K)          0    (0K)      5,056    (5K)
  CTMOUSE      3,104    (3K)          0    (0K)      3,104    (3K)
  XPRT           544    (1K)          0    (0K)        544    (1K)
  DOSKEY       3,952    (4K)          0    (0K)      3,952    (4K)
  PNPPD        4,672    (5K)          0    (0K)      4,672    (5K)
  FREE       660,240  (645K)    645,696  (631K)     14,544   (14K)

Memory summary:

  Type of Memory       Total    =     Used    +     Free
  ----------------  -----------   -----------   -----------
  Conventional          655,360         9,664       645,696
  Upper                  61,312        46,768        14,544
  Reserved              331,904       331,904             0
  Extended (XMS)              0             0             0
  ----------------  -----------   -----------   -----------
  Total memory        1,048,576       388,336       660,240

  Total under 1Mb       716,672        56,432       660,240

  Total Expanded (EMS)                  1,048,576   (1,024K)
  Free Expanded (EMS)                   1,048,576   (1,024K)

  Largest executable program size         645,680     (631K)
  Largest free upper memory block          14,256      (14K)

 

[Trixter]

I've been reviewing the docs of TLB. It appears to also support appending memory in the A000 segment to conventional through the use of a program in its optional advanced utilities pack called HIGHAPND

Cool! Now I have something new to try.

Can PC-DOS 7 actually load the DOS kernel into UMB (the first megabyte), or does it just utilize the 64kB HMA segment? I know it has that DOSDATA=UMB thing (that essentially just does the same thing as DOSMAX) but that's not moving the whole kernel

PC DOS 7 only loads DOS memory structures high, but not the kernel. DR DOS 6 *does* load the kernel high, although ironically I had trouble getting DOS structures like HIGHBUFFERS to load high. All things being equal, with an EMS card that could map 64K memory into E000 (D000 was the page frame) to create 64K of UMBs, I had 593K free in PC-DOS 7 and 612K free in DR-DOS 6. Neither extended DOS into A000, so I'm hoping The Last Byte will allow this *and* provide UMBs so that I can get the best of both worlds. My current "hammer" solution (extend DOS into a RAM card's A000, and no UMBs), gives me 639KB free.

As for the shareware nag, I have the name and contact details of the person who wrote it, and I'll see if they can accommodate a registration if it works for me. But if they can't, I have other means of removing the nag.

 

[Trixter]

With DOSMAX's help you can load MS-DOS 5 through PC-DOS 7's kernels into a UMB and free up the equivalent amount of space as you get from loading them into the HMA.

Now that's interesting, that did not work for me at all. Are we talking DOSMAX21? If not, what version are you using? Also, could you post your CONFIG.SYS?

 

[Eudimorphodon]

Now that's interesting, that did not work for me at all. Are we talking DOSMAX21? If not, what version are you using? Also, could you post your CONFIG.SYS?

Yeah, DOSMAX 2.1. Here's a copy of my config file. (Slightly cleaned up, I removed some commented-out things like a redundant SHELLMAX command.) Almost the same config works on 5 and 6.22. (With the aforementioned difference in the SHELL command.) System in question has hard-wired upper memory from C800-DFFF and the Lo-Tech EMS pageframe at E000. (Thus the difference between "HIGH" and "HUGE".)

EDIT: Possibly worth noting: I think you need a *smidge* more than 64K of upper memory to load DOS 7 with all the data and command.com high. With only 64K contiguous UMB it might bail, I'm trying to remember exactly. (I think that may have been the issue that inspired me to go crazy with haxxoring the HX's upper memory to free it of all the useless ROM cluttering it up.)

EDIT the Second: Realized it's easy enough to check. And, yes, with only 64k it'll say it doesn't have enough free space for SYSTEM and not put the kernel high. It *will* put at least some of it high if I comment out DOSDATA=UMB; the end result is 615k conventional free with most of the drivers in that config.sys still able to go high, leaving only 2K UMB unused.

This is why I'm kind of wondering if there might be a market for something that can provide UMBs like the Lo-Tech 1MB but has finer-than-64K resolution for the addressing. The card in my Tandy can go down to a 16k blocksize, or 8k if I wired up the last unusued input on the GAL.

 

[Trixter]

Thanks very much, this was helpful.

While The Last Byte was unable to do what I wanted -- it doesn't allow you to mix and match methods, so I couldn't do "adapter RAM" + "EMS4" -- I was able to get DOSMAX to load the DOS kernel high, finally. The specific combination/order was:

DOS=HIGH,UMB
DEVICE=c:\utils\memory\dosmax21\stopmax.sys
DEVICE=c:\DRV\EMM.SYS PC 258 ND RD
DEVICE=c:\qram\qram.sys
DEVICE=c:\utils\memory\dosmax21\dosmax.exe

I had neglected to use STOPMAX previously. This was required in order to get DOSMAX to move the kernel. With this combination, coupled with 4DOS loading into upper memory, I'm able to get 630K free, which is astonishing, and a new record for me.

I can *further* increase it to 694KB free by running my MCB hammer posted earlier, but this corrupts DOS's knowledge of UMBs: I can no longer view UMB contents, and neither can MANIFEST. But is the MCB chain broken? Well, the MEM command doesn't see anything wrong with the chain (believe me, it complains when it does) and reports the total amount of free memory correctly even though it can't see UMBs any more. My understanding of the MCB chain and how it interacts with UMBs must be incomplete, so I'm going to do more research on that front.

 

[Eudimorphodon]

If you can figure out what the deal is with the UMB linkage breaking that’d be awesome. I suspect strongly that the same fix that lets you move the top of memory up would also allow patching the ADJMEM utility for Tandy 1000s so the issue of it getting severed when you run a program that uses Tandy video modes could be worked around.

 

[Trixter]

Turns out the UMB MCB chain is a complete second chain that the MCB hammer will need to address; it isn't relocating it, so that's why it gets stomped. The first UMB can be located through a pointer in the disk buffer information structure, which can be obtained from the List of Lists. I have more work to do.

 

[davide78]

End result is I have a whopping 631K conventional free on my standard boot config+packet driver on the VGA Tandy. (Subtract 16k for the TGA one.) And that's real "K", not decimal thousands.

Is the mem listing from PC DOS 7 ? How do you manage to have only 27K for SYSTEM? In my case it takes more than 50K, even with a clean boot and by decreasing FILES and BUFFERS.

 

[maxtherabbit]

I had neglected to use STOPMAX previously. This was required in order to get DOSMAX to move the kernel. With this combination, coupled with 4DOS loading into upper memory, I'm able to get 630K free, which is astonishing, and a new record for me.

Is this on a system with more than 1MB of linear memory?

 

[Eudimorphodon]

I’m still kind of puzzled why STOPMAX was needed on an 8088, but I’m guessing that’s a specific interaction from stacking with QRAM.

 

[maxtherabbit]

Likewise, thus the question in my previous post. If you don't have a 64k HMA at 10000 stopmax shouldn't have anything useful to do

 

[Eudimorphodon]

Likewise, thus the question in my previous post. If you don't have a 64k HMA at 10000 stopmax shouldn't have anything useful to do

If I had to hazard a guess what's going on it's if you run DOSMAX directly on USE!UMB.SYS there's nothing that looks like an HMA provider to confuse DOSMAX into thinking it should step back and let the HMA handler put DOS "high". I'm pretty sure QRAM.SYS is also an HMA provider, so with it loaded DOSMAX assumes it should let it handle the "DOS=HIGH" request unless told otherwise. (Obviously QRAM can't actually provide an HMA on a sub-286, but it might still be offering the hook?)

 

[Trixter]

I removed STOPMAX from config.sys and rebooted, and... it still worked. So STOPMAX must have been a vestigial line during my testing.

Some research shows that while the DOS low RAM MCB chain is very well documented (for being "undocumented"), the start of the UMB MCB chain is very difficult to find information on. I'm going to write an MCB walker so that I can test some ideas before jamming bytes into DOS internals.

 

[Eudimorphodon]

I removed STOPMAX from config.sys and rebooted, and... it still worked. So STOPMAX must have been a vestigial line during my testing.

Heh.

And ugh. I was worried that the UMB chain thing might lead to a pit of dark magic.

This is a really out-there suggestion, and it almost certainly won't work, but I'm kind of curious if you were to load USE!UMBS.SYS configured to enable A000-AFFF as a UMB before loading your EMS card driver if magically that segment would get added to the list of pages that QRAM has to work with and thus let it extend DOS into it.

My guess is it'll do nothing, QRAM will either object to there being another UMB handler installed when it loads, or it'll just ignore it an use its own pool derived from the capabilities of the EMS driver, but, eh?

 

[Trixter]

Already tried; QRAM fails to load, as there is another UMB provider present.

Another thing I'm going to try is writing a device driver to extend DOS to 704k, to be run before the XMS/UMB provider loads.

 

[Jove]

I've been following along and have my own 8088 about as efficient as it's ever been thanks to this thread!

The issue I'm running into is that 704k isn't working, it reports no memory at A000. test!umb reports the same thing ...

except when the VGA card is in any kind of graphics mode, then A000 is visible to both programs.

Anyone know of a workaround to get an Oak 077 chipset to always have the ram be visible to the system?

Thanks

 

[Trixter]

So, I solved my problem, DOS extends into A000, and I now get 680+ KB free without any UMB issues. But I don't think many people are going to like my solution...

I tried adjusting the BDA to 704k with a device driver, but by then DOS had already loaded, and oddness ensued. So there are two ways to fix the BDA before DOS boots: Rewrite the ROM BIOS so that it keeps testing beyond 640K, or by running code before DOS loads. I chose the latter, and patched the DOS boot sector such that it forced 40h:13h to 280h (704), then continued booting. Works like a charm.

 

[Eudimorphodon]

If all it takes is literally just overwriting the value at 40h:13h with the new size I wonder how hard it would be to patch that into an XTIDE BIOS image. (On machines so equipped.) I could test *lowering* it 16k to see if it solved the borked UMB issue on Tandy 1000s....

 

[Trixter]

Here's the program and source code I wrote that can patch floppy and hard disk MBRs for this: ftp://ftp.oldskool.org/pub/misc/Software/Patches/patch704.zip

Final results are 694KB free after patching:

Modules using memory below 1Mb:

  Name           Total       =   Conventional   +   Upper Memory
  --------  ----------------   ----------------   ----------------
  SYSTEM       9,072    (9K)      9,040    (9K)         32    (0K)
  EMM            176    (0K)        176    (0K)          0    (0K)
  NDOS         3,952    (4K)        800    (1K)      3,152    (3K)
  DOSMAX         272    (0K)          0    (0K)        272    (0K)
  SETVER         768    (1K)          0    (0K)        768    (1K)
  FILES        1,504    (1K)          0    (0K)      1,504    (1K)
  FCBS           272    (0K)          0    (0K)        272    (0K)
  BUFFERS      8,528    (8K)          0    (0K)      8,528    (8K)
  LASTDRIV       720    (1K)          0    (0K)        720    (1K)
  INSTALL        160    (0K)          0    (0K)        160    (0K)
  EXP8         3,504    (3K)          0    (0K)      3,504    (3K)
  FREE       719,040  (702K)    710,864  (694K)      8,176    (8K)

Memory summary:

  Type of Memory       Total    =     Used    +     Free
  ----------------  -----------   -----------   -----------
  Conventional          720,896        10,032       710,864
  Upper                  27,088        18,912         8,176
  Reserved              300,592       300,592             0
  Extended (XMS)              0             0             0
  ----------------  -----------   -----------   -----------
  Total memory        1,048,576       329,536       719,040

  Total under 1Mb       747,984        28,944       719,040

  Total Expanded (EMS)                  2,080,768   (2,032K)
  Free Expanded (EMS)                   1,916,928   (1,872K)

  Largest executable program size         710,848     (694K)
  Largest free upper memory block           7,776       (8K)

This is 100KB more free than when I started this a week ago :-D This will make coding/debugging large projects on the bare metal 5160 much easier.