Image Map Image Map
Page 7 of 7 FirstFirst ... 34567
Results 61 to 67 of 67

Thread: Loading dos into UMB on an XT

  1. #61
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    34,384
    Blog Entries
    18

    Default

    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.

  2. #62
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    6,546
    Blog Entries
    1

    Default

    Quote Originally Posted by Anonymous Coward View Post
    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.
    Offering a bounty for:
    - A working Sanyo MBC-775, Olivetti M24, or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  3. #63

    Default

    Quote Originally Posted by Trixter View Post
    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.
    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

  4. #64
    Join Date
    Mar 2011
    Location
    Atlanta, GA, USA
    Posts
    1,593

    Default

    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.
    "Good engineers keep thick authoritative books on their shelf. Not for their own reference, but to throw at people who ask stupid questions; hoping a small fragment of knowledge will osmotically transfer with each cranial impact." - Me

  5. #65
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    2,402

    Default

    Quote Originally Posted by eeguru View Post
    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.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  6. #66
    Join Date
    Mar 2011
    Location
    Atlanta, GA, USA
    Posts
    1,593

    Default

    Quote Originally Posted by Eudimorphodon View Post
    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).
    "Good engineers keep thick authoritative books on their shelf. Not for their own reference, but to throw at people who ask stupid questions; hoping a small fragment of knowledge will osmotically transfer with each cranial impact." - Me

  7. #67
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    2,402

    Default

    Quote Originally Posted by eeguru View Post
    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).
    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!
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •