maxtherabbit
Veteran Member
didn't I say that
- 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
PC-DOS 3.2 for 5150
- Thread starter maxtherabbit
- Start date
didn't I say that
Trixter
Veteran Member
Sorry, I thought you were implying the creation of a board that used one mechanism to backfill and another mechanism to provide UMBs and EMS.
Eudimorphodon
Veteran Member
If someone wants to write the driver for it I have some ideas for the hardware. The only standards doc I could find for EMS 4.0 is eye-bleedingly opaque, and huge. (And packed with weasel words about what counts as "optional", which is why technically the LTEMS board "counts" as an EMS 4.0 card; if the driver has a stub for 4.0-specific routines that can either fake it in software or returns "Sorry, Dave, I can't do that." then it's an EMS 4.0 board even if the hardware is just 3.2, or even one of those useless software emulators that ran on 286s without mapping hardware.)
Using a 2k*16b dual-port SRAM like a Renesas 7133 as a mapping register would theoretically handle 65,536 physical pages (which at 16k each would mean 1GB of memory, which I'm pretty sure is more than the standard supports by a whopping margin; that leaves some bits to shave off the top to use to indicate "unmapped", "read only", or whatever.); dividing 1024k into 16k chunks means you need 64 registers to cover the entirety of conventional memory, which means the 2K capacity of the chip would support 32 completely independent alternate register sets, and the chip is available in speeds as fast as 20ns, hopefully fast enough to be able to do chip select based on a "is this page mapped or belongs to something else?" bits shaved out of the 16 output bits.
(Using a dual-ported SRAM would vastly simplify reading and writing the paging registers; the LTEMS's registers are write-only.)
Of course, I suppose I would actually want to lay my hands on a machine that could actually use a LIM 4.0 card that has mapping registers. My only ISA (like) computers at the moment are the Tandys and a PC Convertible which still needs a bunch of repairs and is its own stack of weirdness...
Eudimorphodon
Veteran Member
Separate mechanisms to do backfill and UMBs and another for an EMS pageframe is a lot easier than an EMS 4.0 board for the cited "what about a driver?" reason.
(Well, that and the hardware is still a lot simpler and probably cheaper. Maybe there's a 5v CPLD that has enough internal register space that could do the 4.0 mapper job cheaper than the dual-port RAM and supporting hardware I suggested previously, but it's still going to be substantially more complicated. I was able to fit backfill and a slew of switch-selected UMB and ROM decoding options into a GAL 20v8 and still had room to implement the supporting logic for an LTEMS-compatible EMS 3.2 frame. Just needed to add a pair of 74LS670s as the 4 page registers. Moving to even the dumbest CPLDs would probably let me ditch the external page registers since I only need 4x8 bits of storage.)
I still don't get why the Lo-Tech card doesn't work for you. What happens if you stick a VGA card into that machine and run one of those programs that uses VGA memory to bring the total up to 704k?
Last edited:
Eudimorphodon
Veteran Member
... FWIW, I was poking around to see if I could find one of those VGA-to-memory programs to experiment with, and Google mentioned this thread that has a post in it where you say the Lo-Tech card actually works fine with "704k.com" and DOSes other than DR-DOS and PC-DOS 2000?
EDIT: I'm just going to toss this dumb comment out there since I tracked down ADDMEM.EXE to test on my Tandy 1000(*) and it mentions a possible issue in its documentation. If you have an XTIDE card in this 5160, is it configured for "Full Operating Mode"? That mode grabs 1K under the top of RAM to do its thing, which I imagine would make it fundamentally incompatible with moving the top of memory. ADDMEM came with a device driver to relocate that if needed (apparently IBM PS/2s do that, among other things), although I suspect it won't stack well with 704k.com.
(* I don't think I'll ever run addmem again because, ho boy, its Shareware nag may be the most intrusive thing I have ever seen, but it did work to give me a positively ridonkulous amount of conventional memory, 721K out of 736K, text only of course, under PC-DOS 2000.)
Last edited:
kdr
Experienced Member
Since this thread has kind of derailed into a generic UMB discussion, here's what I am playing with on my XT:
I have an SMC8003EP (aka WD8003EP) 8-bit Ethernet card in my XT, and whilst perusing the datasheet for the card's WD83C584 bus controller, noticed that it had a configuration register described as "indicates that a 32K RAM is installed in the ROM socket". And indeed, installing a CY62256 32K SRAM in the card's boot ROM socket and enabling that configuration bit works like a charm -- 32K of RAM appears at the configured boot ROM address!
I have an SMC8003EP (aka WD8003EP) 8-bit Ethernet card in my XT, and whilst perusing the datasheet for the card's WD83C584 bus controller, noticed that it had a configuration register described as "indicates that a 32K RAM is installed in the ROM socket". And indeed, installing a CY62256 32K SRAM in the card's boot ROM socket and enabling that configuration bit works like a charm -- 32K of RAM appears at the configured boot ROM address!
Eudimorphodon
Veteran Member
... Blawblawjabberjabber to myself, but... an observation about this:
If the problem *is* because the XTIDE is creating an extended BIOS area at the 639k mark then that would explain why QRAM might work anyway because QRAM has explicit support for moving an XBA if it finds one. (It's in the docs and enabled by default; for laughs I installed it to see what it does, had never touched it before.)
I spent just a few minutes poking at QRAM, but unless there's something I'm missing about it it has an *extremely* unfortunate limitation: it apparently knows about and can use the "shadow ram" functionality of some 286 chipsets to fill in upper memory instead of/in addition to using LIM 4.0 hardware, but there doesn't seem to be any way to instruct it to use RAM that's statically already there. (IE, it can't substitute for USE!UMB.SYS or the like.) That's a genuine bummer/oversight, considering memory cards for PCs that could give you bonus memory above the 640k mark (like the Lo-Tech card) were a thing that existed back then. (IE, why 704k.com exists.) It was actually kind of a shock that Manifest didn't seem to have any idea how to look for unused memory in the upper memory map like, say, Check-it!, can. I vaguely remember the ads making it sound like Manifest was this amazing uber-tool that could ferret out what was lurking in every little nook and cranny...
On the bright side its vidram.com TSR works under PC-DOS's memory management just fine on the VGA 1000 and gives me even more memory than Addmem did. 725K conventional!!!
Last edited:
Eudimorphodon
Veteran Member
NICE!
I just took a look at the datasheet for the RealTek 8019AS in my machine and it looks like the same trick might be possible. The bit in question refers to "Flash Memory", but all it does is gate whether the MEMW pin is enabled on the socket so I can't think of a reason why it wouldn't take an SRAM.
... EDIT: On second thought, later in the manual it looks like "write enable" register might not have its state loaded from reading the EEPROM, enabling writes is something you'd have to do after power-on. So maybe if you wanted an SRAM in that socket you'd need to make a little device driver stub to throw the write enable at it before loading USE!UMB.SYS, which would sure be a pain. Not 100% sure, though...
Last edited:
maxtherabbit
Veteran Member
kdr
Experienced Member
The 83C584 has separate bits for 'flash' and 'RAM', but I'm not sure what the exact difference might be...
I intend to write a tiny little device driver that will twiddle the bits, because it appears that the RAM bit is in a register that isn't automatically loaded from the EEPROM at power on. I was stoked to discover that all I needed to get a bit of UMB was a $4 SRAM chip! I found this mostly by accident, because I was using the adapter's boot ROM socket to dump some video BIOS chips and needed to configure the correct ROM size...
maxtherabbit
Veteran Member
kdr
Experienced Member
Yes, the boot ROM can be configured to reside at any address in the upper 512K of memory!
I am now on the hunt for additional WD8003EP cards.
I am now on the hunt for additional WD8003EP cards.
Eudimorphodon
Veteran Member
If you just need to stuff a value in a register maybe the code framework I used for my EMS2UMB enabler shim would interest you. Lets you make an .EXE that you can run either from a command prompt or a device statement in config.sys. (In the latter case it just runs and exits, leaving nothing resident, and it works to run it before something like USE!UMBS.SYS.)
maxtherabbit
Veteran Member
What's the resident memory footprint of that useumb driver vs qram?
Trixter
Veteran Member
Ah, found the problem. Those are the only DOSes I prefer to run. Maybe I'll try MS-DOS 6.22 as a test.
VIDRAM from QRAM would work if I had a VGA card in the system. I can put RAM at A000 but no VGA card (my system must remain CGA). Maybe I can patch VGARAM.COM and see if it falls over.
Last edited:
Eudimorphodon
Veteran Member
I’m still wondering about the “full operating mode” thing. If that is actually the problem I wonder if the DOSes that “work” might crash if you overwrite that area.
Trixter
Veteran Member
Not a problem since I'm not running XUB on the system in question.
Eudimorphodon
Veteran Member
Interesting. So, yeah, I guess those DOSes just hate 704k.com.
PC-DOS 2000 does work with VIDRAM.COM and friends, which apparently do "something else" to move the top of memory instead of that soft reboot thing. (They don't reboot, at least.) I wonder if the source code for one of them is floating around...
Actually, I think the source for a Tandy 1000 widget to move the top-of-memory pointer to compensate for graphics mode usage is, maybe modifying that would work.
Eudimorphodon
Veteran Member
USE!UMB.SYS takes 192 bytes of conventional RAM, according to "mem /c", although I think you also need DOSMAX stacked on top to enable the LOADHIGH/DEVICEHIGH commands? "mem /c" pegs the usage for that as 240 bytes conventional and 240 bytes upper. (I was able to verify this by booting a super-stripped config.) So a little less than half a K conventional.
Since I still have QRAM on my system (even though it's sort of useless to me) I did a quick basic setup where it's using the EMS' 64k frame as upper memory. (Since it lamentably can't make use of all the static upper memory I have) QRAM seems to "cloak" its actual memory usage by hiding in the upper memory it creates, but running "LOADHI" indicates it's taking 1.4k of the UMB, and the LTEMM driver is taking 6k of conventional.
So, yeah, from a strict memory consumption angle USE!UMB seems to handily beat QRAM if static UMBs are an option. But this is kind of an apples to oranges comparison; if you had a full EMS 4.0 card and software to make good use of it (like DESQView or whatever) the additional memory overhead would probably be worth it.
Trixter
Veteran Member
Some poking around VIDRAM.COM shows it going to the List of Lists and then walking the MCBs. Without digging further, I think all it's doing is just modifying the last MCB from Z to M and then making a new one (and maybe changing the value in the BDA). If that's all there is to it, I can write a tiny util that can do the same thing without requiring a reboot. If 704k + MS-DOS 6.22 doesn't work on my system with a lotech card providing 64K at A000, I'll work on that.