Chuck(G)
25k Member
It varies. I've got a DTK Turbo board that looks as if it apes the 5160 scheme (i.e. uses a bipolar PROM), but I've seen others that use a PAL. I think the idea is the same, but the reverse-engineering differs somewhat.
Damn, that's too bad. I guess the specs for EEMS 3.2 must be different...that's probably why my AST card can do it.
12 years later, I was able to verify this last night. On my M24 with an EEMS 3.2 board, QRAM can map 96K into A000-B7FF and use it to extend DOS to 736K. But on my real Intel Aboveboard Plus which is a LIM EMS 4.0 board, QRAM is unable to do that.
I find it somewhat disappointing that the later, full LIM EMS 4.0 spec, running on an Intel board (the "I" in "LIM), can't do as much as the earlier spec.
This necro-bump brings up a curiosity I had for the preliminary JR-IDE option BIOS rewrite code I worked on. I had added an Int 2Fh hook to manage the available UMB RAM added by JR-IDE. I haven't verified it, but I'm curious if this hook already exists before DOS is even boot-strapped, could it load DOS=HIGH with no drivers?
So, would this call you've added essentially duplicate the functionality of the USE!UMBS.SYS driver? If this is something you could package as either a stand-alone BIOS ROM extension or tack onto a generic XT-IDE BIOS I'd love to try it on one of my Tandy 1000 RAM boards that adds upper memory blocks. Presumably it would either need to be hard-configured before flashing for the exact upper memory configuration or have some kind of probe/detect loop.
Yes it effectively implements USE!UMBS.SYS in an option ROM. I do a JR-IDE specific probe for regions of C, D, and E to set the free block list though. But one could hard-code that. I'm going to check it in to the public repo as soon as I get back to some testing (end of May).