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.
- 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 into UMB on an XT
- Thread starter Anonymous Coward
- Start date
Trixter
Veteran Member
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.
maxtherabbit
Veteran Member
Whoa whoa so you're telling me that with a genuine AST memory board on my 286 I can map memory into UMBs??? I use a VGA so the A region is out, but I could use half of B and some of C as well
eeguru
Veteran Member
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?
The PCjr is a pretty niche use case. The top of available DOS memory is already fixed-up to 736KB (start of the CGA window). But most of the first 128K is reserved by JRCONFIG.SYS due to speed. So the effective conventional memory is 608-630 KB depending on how you add-up the BDA, the vector table, and other reservations that don't count against it. JR-IDE fills in the C segment not occupied with option BIOS code (up to 48K) with upper RAM. And if you replace a decode-ROM and run a couple jumper wires over from the cartridge slots, you can gain another 128K total in the D and E segments when cartridges are not actively inserted. +172 KB of UMB would be very useful. Even the 48K gained without having a hardware change would be nice.
The PCjr is a pretty niche use case. The top of available DOS memory is already fixed-up to 736KB (start of the CGA window). But most of the first 128K is reserved by JRCONFIG.SYS due to speed. So the effective conventional memory is 608-630 KB depending on how you add-up the BDA, the vector table, and other reservations that don't count against it. JR-IDE fills in the C segment not occupied with option BIOS code (up to 48K) with upper RAM. And if you replace a decode-ROM and run a couple jumper wires over from the cartridge slots, you can gain another 128K total in the D and E segments when cartridges are not actively inserted. +172 KB of UMB would be very useful. Even the 48K gained without having a hardware change would be nice.
Eudimorphodon
Veteran Member
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.
eeguru
Veteran Member
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).
Eudimorphodon
Veteran Member
The boards I've been making can have RAM anywhere from C400 up to EFFFF, depending on what they're plugged into and if you've configured them to leave space for other option ROMs. (But only 128k in total because they use a single 512k chip and dedicate 384k of it for under-640k backfill.) With one possible exception a simple loop that looks for RAM anywhere in that space and assumes it can use whatever it finds should do the job.
Any machine that has a flashable XT-IDE card to append the driver to and has something like the lo-tech RAM board (or a hacked 5160 1Meg motherboard) could benefit from this!