Eudimorphodon
Veteran Member
Recently I designed and built a simple Plus-bus RAM card for my Tandy 1000 EX that came with only the built-in 256k. This card includes the ability to map the remaining 128k of the 512k SRAM chip used to backfill the lower 640k into the empty D0000h and E0000h pages in the memory map.
The reason I included this feature is I'd stumbled across several threads on this forum of people successfully using Upper Memory Blocks to load device drivers and DOS on XT-class machines. (First machine I ever owned with support for UMBs back in the day was a 486.) However, in researching this I wasn't able to find solid accounts of this working on XT-class Tandy 1000s with add-on memory boards; to the contrary, it seemed like there were several accounts of this specifically not working, or at least being unstable somehow. Now that I have my card working with the XT-IDE CF daughtercard I designed for it and have a "hard disk" I've started fiddling with actually using the UMBs on my card for something other than a simple RAM disk. I'm curious if anyone has experiences they're willing to share about using UMBs on their Tandy 1000s and what software configurations work best. (Or don't work.)
Here's the result of my first attempt. Out of many apparent possibilities I chose USE!UMBS.SYS for the upper memory manager and DOSMAX version 2.1 to actually force DOS high. The operating system I used is plain MS-DOS 5.0. Here is what conventional RAM looks like without upper memory enabled:
This is the configuration I arrived at for config.sys:
(biosptch.sys is a driver to allow access to oddball giant floppy images on my Flashfloppy-equipped Gotek)
With this configuration this is what "mem /c" reports:
Nearly 44k freed and almost 610k conventional DOS memory on a machine that effectively has only has 624k instead of 640k. Not bad?
Here's a couple screenshots of Check-It 3 reporting on conventional and upper RAM usage.
I can't say I've tested it extensively, but I have run a fair amount of things, including programs using Tandy Graphics/Sound modes, and I haven't seen any crashes. However, I did run into an anomaly that I'm not sure is just a cosmetic problem or not. I can reliably reproduce that after running a program that allocates more than the default 16k off the top of memory the "mem /c" command will no longer output information about upper memory. Screenshot:
It is consistent that the "Size in Decimal" reported by mem /c for "MSDOS" in conventional memory changes slightly, from 9312 to 9296. There don't seem to be any ill-effects, Check-It still shows the upper memory map identically and the system doesn't seem to crash, but it's... interesting. Presumably some top-of-memory structure is getting updated in a way that confuses mem /c (I can reproduce this easily just using a BASIC program that clears 32k of video memory for Tandy video modes 5 or 6.)
Anyway, I'm curious about other people's experiences with trying this on Tandy 1000s, especially the 8088/8086-equipped models that can't take the "768k" expansion that prevents the machine from sharing video RAM with conventional memory. I haven't tried alternate software yet (it looks like Quarterdeck's QRAM might be a possibility?) or other DOS versions, if someone's using that I'd love to hear about it.
The reason I included this feature is I'd stumbled across several threads on this forum of people successfully using Upper Memory Blocks to load device drivers and DOS on XT-class machines. (First machine I ever owned with support for UMBs back in the day was a 486.) However, in researching this I wasn't able to find solid accounts of this working on XT-class Tandy 1000s with add-on memory boards; to the contrary, it seemed like there were several accounts of this specifically not working, or at least being unstable somehow. Now that I have my card working with the XT-IDE CF daughtercard I designed for it and have a "hard disk" I've started fiddling with actually using the UMBs on my card for something other than a simple RAM disk. I'm curious if anyone has experiences they're willing to share about using UMBs on their Tandy 1000s and what software configurations work best. (Or don't work.)
Here's the result of my first attempt. Out of many apparent possibilities I chose USE!UMBS.SYS for the upper memory manager and DOSMAX version 2.1 to actually force DOS high. The operating system I used is plain MS-DOS 5.0. Here is what conventional RAM looks like without upper memory enabled:
Code:
Conventional Memory :
Name Size in Decimal Size in Hex
------------- --------------------- -------------
MSDOS 53744 ( 52.5K) D1F0
BIOSPTCH 128 ( 0.1K) 80
COMMAND 4704 ( 4.6K) 1260
FREE 64 ( 0.1K) 40
FREE 580176 (566.6K) 8DA50
Total FREE : 580240 (566.6K)
Total bytes available to programs : 580240 (566.6K)
Largest executable program size : 580064 (566.5K)This is the configuration I arrived at for config.sys:
Code:
DOS=high,umb
files=30
buffers=10
device=c:\tandy\use!umbs.sys D000-EFFF
device=c:\tandy\dosmax.exe /P:-
devicehigh=c:\tandy\biosptch.sys(biosptch.sys is a driver to allow access to oddball giant floppy images on my Flashfloppy-equipped Gotek)
With this configuration this is what "mem /c" reports:
Code:
Conventional Memory :
Name Size in Decimal Size in Hex
------------- --------------------- -------------
MSDOS 9312 ( 9.1K) 2460
USE!UMBS 192 ( 0.2K) C0
COMMAND 4704 ( 4.6K) 1260
FREE 64 ( 0.1K) 40
FREE 624592 (610.0K) 987D0
Total FREE : 624656 (610.0K)
Upper Memory :
Name Size in Decimal Size in Hex
------------- --------------------- -------------
SYSTEM 249904 (244.0K) 3D030
DOSMAX 224 ( 0.2K) E0
BIOSPTCH 128 ( 0.1K) 80
FILES 1488 ( 1.5K) 5D0
FCBS 256 ( 0.3K) 100
5328 ( 5.2K) 14D0
LASTDRIV 448 ( 0.4K) 1C0
INSTALL 128 ( 0.1K) 80
FREE 85968 ( 84.0K) 14FD0
Total FREE : 85968 ( 84.0K)
Total bytes available to programs (Conventional+Upper) : 710624 (694.0K)
Largest executable program size : 624480 (609.8K)
Largest available upper memory block : 85968 ( 84.0K)Nearly 44k freed and almost 610k conventional DOS memory on a machine that effectively has only has 624k instead of 640k. Not bad?
Here's a couple screenshots of Check-It 3 reporting on conventional and upper RAM usage.
I can't say I've tested it extensively, but I have run a fair amount of things, including programs using Tandy Graphics/Sound modes, and I haven't seen any crashes. However, I did run into an anomaly that I'm not sure is just a cosmetic problem or not. I can reliably reproduce that after running a program that allocates more than the default 16k off the top of memory the "mem /c" command will no longer output information about upper memory. Screenshot:
It is consistent that the "Size in Decimal" reported by mem /c for "MSDOS" in conventional memory changes slightly, from 9312 to 9296. There don't seem to be any ill-effects, Check-It still shows the upper memory map identically and the system doesn't seem to crash, but it's... interesting. Presumably some top-of-memory structure is getting updated in a way that confuses mem /c (I can reproduce this easily just using a BASIC program that clears 32k of video memory for Tandy video modes 5 or 6.)
Anyway, I'm curious about other people's experiences with trying this on Tandy 1000s, especially the 8088/8086-equipped models that can't take the "768k" expansion that prevents the machine from sharing video RAM with conventional memory. I haven't tried alternate software yet (it looks like Quarterdeck's QRAM might be a possibility?) or other DOS versions, if someone's using that I'd love to hear about it.
