I think 2.2 is the last one. I have not seen higher versions.
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Loading dos high on a XT
- Thread starter RuudB
- Start date
Trixter
Veteran Member
It's compatible with DOS 6.22, but typing "mem /c" doesn't show UMB usage properly, if memory serves. It's been a while since I've tried it, but I remember being frustrated by it enough that I just used QRAM instead (which works perfectly).
As far as I know, Krille's 2.2 version is the most recent.
As far as I know, Krille's 2.2 version is the most recent.
Ruud
Veteran Member
I completely forgot about DOSMAX, googled for it and found this site from Gardner. Googled for DOSMAX and Krille but nothing turned up. Do you have an URL, please? TIA!
Trixter
Veteran Member
Krille produced USE!UMB v2.2. There have been no recent updates to DOSMAX that I know of.
Ruud
Veteran Member
Vague complaints but no real bug reports. So I'll try to explain the basics;
USE!UMBS.SYS is a UMB provider and it isn't really that complicated. It hands out blocks of memory to whatever piece of software that asks for it. This is usually DOS, from when support for UMBs where added (MS-DOS 5 I believe?), but nothing prevents software from asking for memory under older DOS versions, they just have to know how.
USE!UMBS.SYS doesn't have any say in how the blocks are used or what's put in them. It also doesn't care about DOS' memory control block chain - or whether it is linked to the UMA or not.
It is possible that there are problems with how it handles calls to itself. I don't know the XMS/EMS API:s that well and didn't bother to verify the functionality of the original version (2.0). I just optimized the code and extended functionality. If there are problems in my updates that is not present in the original version then I'd like to hear about it. But it seems to me that a more likely reason for any perceived problems might just be bugs in other parts of the puzzle. Differences in how memory usage is presented may vary between utils and DOS versions. A glaring example is how FreeDOS obviously can't handle certain block sizes as reported by @wondow in post #32. Maybe there are restrictions in what sizes UMBs can have? I don't know.
In my opinion, it might need more comments in the part regarding the XMS/EMS API but that is partly why I include the original version in all my updates - the original has more comments. Also, the specifications are not that hard to find if someone wants to do actual updates of that part of the code.
The other parts of the code is sufficiently commented in my opinion.
(Don't hesitate to ask if there's something specific you want to know.)
maxtherabbit
Veteran Member
The weirdness I've observed was present before you ever messed with it
Trixter
Veteran Member
My comments weren't meant as complaints; apologies if they seemed that way. Like maxtherabbit, the behavior was present before you ever touched the source.
No need for apologies! It's just that it is frustrating when people mentions problems but can't provide details. I would like to fix any bugs in USE!UMBS.SYS but I need detailed steps on how to reproduce them. Also, I need to use some kind of emulator as I don't have any computers that can use this driver - if anyone has advice on that part I'd be grateful.
@explit; I don't think you can use the F000-F400 memory range. The Micro8088 page on github says that you can configure the board to use ranges from C0000h to EFFFFh (depending on switch settings). USE!UMBS.SYS will seem to work with that range because there's actually very little error checking/handling in the driver. This is likely the reason why DOS says there are no UMBs.
Thanks for the answer, @Krille Yes, i read that to. As i understand, memory range F000-F400 is reserved for additional BIOS ROM inside the Micro8088 BIOS Chip (Since its much bigger than the actual BIOS). Since i have no other additinal ROMs on my BIOS, there is a possibility to switch off checking for this area in the Micro8088 BIOS. CheckIt 3.0 says, this area is not used, so i could resize the UMB!SYS range till F400.
But if you say, better not to use this area, i will change the UMB!SYS Value back to D000-EFFF.
Thanks
Eudimorphodon
Veteran Member
The point was that the hardware doesn’t put any RAM there, unless you’ve modified it to do so. USE!UMBS.SYS doesn’t itself do anything to “map” memory into unoccupied address ranges in high memory even if you have hardware capable of doing that function (Like some EMS 4.0 compatible memory cards), which you don’t have. It can only enable the use of memory that’s already mapped when the driver is loaded. IE, the memory range switches are just telling it “blindly tell DOS it can use this”, if there’s no RAM actually there it’s not going to check and stop you from creating an error situation.
If you actually wanted to use that area for RAM in the Micro8088 you would need to reprogram the decode GAL to allocate it accordingly, and from a peek at the GitHub that GAL only has address lines down to A15 attached to it. So without a hardware modification you’d have to put RAM up to F8000, not F4000… which may or may not fly depending on how large the BIOS is.
Thanks for the very informative comment, @Eudimorphodon !
modem7
10k Member
On PC family computers, and clones of, it is not possible for software to say with 100% certainty that certain hardware is not in use.
For example, if I run CheckIt 3 on my IBM PC, Checkit's memory map functionality informs me that B8000-F4000 is "<nothing>".
The 5150 motherboard's ROM's start at F4000, and in the 5150's technical reference, IBM indicate that the F0000-F4000 space is "reserved".
Putting everything together, it all sounds like that on an IBM 5150, that the F0000-F4000 space is available for me to use; perhaps I will map a card's ROM into that space.
But if I look at the 5150 motherboard's circuit diagram, I discover that the motherboard actually 'uses' the F0000-F4000 space.
The 5150 motherboard decodes the space for read operations (even though there is nothing there to read).
Had I mapped a card's ROM into that area, I would have ended up with bus contention (both the card and the motherboard simultaneously driving the data bus).
So in regard to F0000-F4000:
- IBM's "reserved" is misleading (I think 'reserved' to most people implies not in use now, but may be in the future).
- CheckIt's "<nothing>" is misleading.
Other software may have informed me of the same. Maybe a later version of CheckIt is smarter, determining (via the motherboard's BIOS ROM) that it is running on an IBM PC motherboard, and therefore knowing not to show F0000-F4000 as "<nothing>".
Make that D000-F000. When DOS asks USE!UMBS.SYS for memory it receives a response with the starting segment and the size of the block. The size is calculated during initialization by subtracting the end of the range from the beginning of the range. F000h - D000h = 2000h paragraphs, a full 128 kB block whereas EFFFh - D000h = 1FFFh, 128 kB minus 16 bytes. So 16 bytes will be unused, and if you would do this under FreeDOS you would likely trigger the bug wondow reported in post #32.
More or less, when we put an @ range pointing to a ROM, the software crash when it exit. A simple RAM test may be nice to add.
Cloudschatze
Veteran Member
I'm running into this same issue (also using PC DOS, and with DOS=UMB specified in CONFIG.SYS), and while MEM correctly reflects the state of the upper memory after an initial system boot, it shows no UMB space or usage if MEM is run following most programs.
The problem is that it's not cosmetic - additional UMB allocation/usage is precluded by the erroneous state. For example, if the CTMOUSE driver is loaded after an initial boot, while UMBs are properly reported, the driver loads into upper memory. If the CTMOUSE driver is instead loaded after running another program, and while the UMBs are being misreported, it loads into conventional memory.
What modification to USE!UMBS.SYS might prevent or resolve this behavior?