Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #651 > unrolled thread

Loading DOS high on a XT

Back to article view | Back to comp.os.msdos.programmer

Contents

  Loading DOS high on a XT Ruud <Ruud.Baltissen@apg.nl> - 2012-07-15 23:16 -0700
    Re: Loading DOS high on a XT Ross Ridge <rridge@csclub.uwaterloo.ca> - 2012-07-16 02:58 -0400
    Re: Loading DOS high on a XT "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-16 05:10 -0400
      Re: Loading DOS high on a XT Ruud <Ruud.Baltissen@apg.nl> - 2012-07-17 01:37 -0700
        Re: Loading DOS high on a XT Jim Leonard <mobygamer@gmail.com> - 2012-07-17 14:11 -0700
          Re: Loading DOS high on a XT Ruud <Ruud.Baltissen@apg.nl> - 2012-07-17 22:36 -0700
    Re: Loading DOS high on a XT T. Ment <t.ment@protocol.invalid> - 2019-03-30 04:58 +0000
      Re: Loading DOS high on a XT "R.Wieser" <address@not.available> - 2019-03-30 08:04 +0100
        Re: Loading DOS high on a XT src153 <src153@protocol.invalid> - 2019-03-30 15:17 +0000
          Re: Loading DOS high on a XT "R.Wieser" <address@not.available> - 2019-03-30 19:30 +0100
            Re: Loading DOS high on a XT src153 <src153@protocol.invalid> - 2019-03-30 18:56 +0000
              Re: Loading DOS high on a XT "R.Wieser" <address@not.available> - 2019-03-30 21:18 +0100
                Re: Loading DOS high on a XT src153 <src153@protocol.invalid> - 2019-03-30 21:22 +0000
                  Re: Loading DOS high on a XT src153 <src153@protocol.invalid> - 2019-03-30 23:09 +0000
                    Re: Loading DOS high on a XT src153 <src153@protocol.invalid> - 2019-03-30 23:34 +0000
                  Re: Loading DOS high on a XT "R.Wieser" <address@not.available> - 2019-03-31 10:25 +0200
          Re: Loading DOS high on a XT Rod Pemberton <invalid@lkntrgzxc.com> - 2019-04-02 18:05 -0400

#651 — Loading DOS high on a XT

Hallo allemaal,

I still like to tinker with old XTs. At the moment I have one equiped
with a 10 MHz V20, 8087, 6.4 GB HDD, 640 KB normal RAM and a selfbuilt
module with 128 KB UMB RAM. I use this UMB to store my drivers so I'm
able to free as much RAM under the 640 KB barrier as possible.

DOS itself can be loaded high as well and AFAIk this is done by
HIMEM.SYS. But that program won't work on a XT so the obvious
question: how can I persuade DOS to load itself in the UMB area
instead below the 640 KB barrier?
Thank you very much for any information!

Groetjes, Ruud Baltissen
www.Baltissen.org

[toc] | [next] | [standalone]

#652

Ruud  <Ruud.Baltissen@apg.nl> wrote:
>DOS itself can be loaded high as well and AFAIk this is done by
>HIMEM.SYS. But that program won't work on a XT so the obvious
>question: how can I persuade DOS to load itself in the UMB area
>instead below the 640 KB barrier?

MS-DOS loads itself "high" (ie. DOS=HIGH in CONFIG.SYS) by loading part
of itself into the HMA (High Memory Area).  That's the (almost) 64K
area above the 20-bit addressing limit of the original 8086 CPU which
can be accessed from real mode on CPUs with more than 20-bit addressing
('286 or later).

Since the HMA doesn't exist on PC XTs you won't be able to convince
MS-DOS to load there.  If I can recall correctly, MS-DOS can also load
some code into UMBs, but I think that's limited to internal drivers and
parts of COMMAND.COM.  I assume you've already created an XMS driver
with UMB extensions to get your drivers loaded there.  If that doesn't
also convince MS-DOS to load what it can into UMBs, then I'm not sure
anything else will.

					Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  

[toc] | [prev] | [next] | [standalone]

#653

"Ruud" <Ruud.Baltissen@apg.nl> wrote in message
news:ca26ced2-1f41-40ee-bacc-5cead74a400b@n33g2000vbi.googlegroups.com...
>
> I still like to tinker with old XTs. At the moment I have one equiped
> with a 10 MHz V20, 8087, 6.4 GB HDD, 640 KB normal RAM and a selfbuilt
> module with 128 KB UMB RAM. I use this UMB to store my drivers so I'm
> able to free as much RAM under the 640 KB barrier as possible.
>
> DOS itself can be loaded high as well and AFAIk this is done by
> HIMEM.SYS. But that program won't work on a XT so the obvious
> question: how can I persuade DOS to load itself in the UMB area
> instead below the 640 KB barrier?
> Thank you very much for any information!
>

You've already tried "DOS=UMB"?

What make of DOS and which version?

Have you tried an alternate XMS and/or EMS manager?  E.g., Japheth's JEMM or
HIMEMX?  Jack Ellis' XMGR?  Uwe Sieber's UMBPCI?
http://www.japheth.de/Jemm.html
http://johnson.tmfc.net/dos/driver.html
http://www.uwe-sieber.de/umbpci_e.html

These may be of interest:
http://support.microsoft.com/kb/95555
http://support.microsoft.com/kb/91088


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#654

Hallo Ross and Rob,


I thank you both for you replies!

I visited all links but couldn't get off the impression that these
programs were meant only for 383 machines or higher, maybe 286. But at
least it sparked an idea:
It seems DOS uses INT 15h to see whether it should load his portion
high or not. But a XT doesn't serve this interrupt. But what if I
could emulate them? But then there is still one question to solve: how
can we persuade DOS to load its part in UMB instead of the HMA area?


Groetjes, Ruud Baltissen
www.Baltissen.org

[toc] | [prev] | [next] | [standalone]

#657

On Jul 17, 3:37 am, Ruud <Ruud.Baltis...@apg.nl> wrote:
> can we persuade DOS to load its part in UMB instead of the HMA area?

The only way I've gotten DOS to be able to load parts of itself in UMB
is by the following procedure:

1. Install a hardware EMS board (so that there are actual UMBs
present!  You need actual RAM where you intend to put things :-)
2. Install and run Quarterdeck QRAM, which makes UMBs available (there
might be non-commercial equivalents but I don't know what they are)
3. Run a later version of DOS such as IBM PC DOS 2000 (IBM PC DOS 7.0)
which can load parts of itself into UMBs

I've tested this successfully with an Intel Aboveboard in an IBM
5160.  I only get a single 64K segment using this technique, but it's
enough for DOS to load 35K of buffers and stuff there, and there's
enough space left over to load a few TSRs like nnansi (ansi.sys
replacement), ctmouse (mouse.com replacement), and a packet driver.
My total free DOS RAM is about 612KB free.

[toc] | [prev] | [next] | [standalone]

#659

Hallo Jim,


> 1. Install a hardware EMS board (so that there are actual UMBs present!

I have 128 KB SRAM in the D- and E-area.


> 2. Install and run Quarterdeck QRAM, which makes UMBs available

Should have that as well. Otherwise I have a group of computer friends
that can supply it.


> 3. Run a later version of DOS such as ... (IBM PC DOS 7.0)

I aquired an old IBM laptop two weeks ago with.... IBM PC DOS 7.0.

So it seems I have the ingredients, now or in the future. I let you
know of the results.
Thank you very much!


Groetjes, Ruud Baltissen
www.Baltissen.org

[toc] | [prev] | [next] | [standalone]

#3200

An interesting old post ...

On Sun, 15 Jul 2012 23:16:33 -0700 (PDT), Ruud wrote:

>I still like to tinker with old XTs. At the moment I have one equiped
>with a 10 MHz V20, 8087, 6.4 GB HDD, 640 KB normal RAM and a selfbuilt
>module with 128 KB UMB RAM.

I thought BIOS sets up RAM addressing. How do you integrate a selfbuilt
module?

[toc] | [prev] | [next] | [standalone]

#3201

T,

> I thought BIOS sets up RAM addressing. How do you integrate a
> selfbuilt module?

The same way the other "extension cards" (like video, ethernet and others) 
do it for their extension ROMs (and RAM): pick a spot (above the 640K 
border) where no other card claimed/got its and go sit there.

Its also possible that the 128KByte was not available as a contiguous range, 
but instead in smaller blocks that had to be selected ("bank switching". 
like, if I'm not mistaken, EMM did it).

The "self build" might be about having designed the circuitry and soldered 
the chips himself.   The actual access to such memory ranges has been 
build-into the motherboard from the start.

And by the way, in that XP timeframe the addressing is "set up" by the 
processor and other hardware on the motherboard.   The "BIOS" is nothing 
more than a collection of on-board and extension-card ROMs, exposing a set 
of basic APIs and initialisation routines (in short: software).   Nothing in 
there can dictate how the addressing happens (other than to "pretty please" 
the available hardware).

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#3202

On Sat, 30 Mar 2019 08:04:59 +0100, "R.Wieser" wrote:

>And by the way, in that XP timeframe the addressing is "set up" by the 
>processor and other hardware on the motherboard.   The "BIOS" is nothing 
>more than a collection of on-board and extension-card ROMs, exposing a set 
>of basic APIs and initialisation routines (in short: software).   Nothing in 
>there can dictate how the addressing happens (other than to "pretty please" 
>the available hardware).

With 286+ and MMU, physical RAM is mapped in two pieces, 0-640k, and
1M+. The virtual address space between 640k to 1M is partially taken by
ROMs, the rest unused.

286+ can map physical RAM into UMB space, call it shadow RAM and copy
ROM into it. But other UMB space is empty and unmapped, typically D000
and E000 space.

The BIOS sets up shadow RAM. UMBPCI is like an extension of BIOS, it
uses knowledge of a motherboard chipset to map physical RAM into UMB
space.

But,

> The 286 was ... the first commercially available microprocessor with
> on-chip MMU

https://en.wikipedia.org/wiki/Intel_80286

So the question of UMB mapping on XT remains.

[toc] | [prev] | [next] | [standalone]

#3203

src153,

> With 286+ and ....
....
> So the question of UMB mapping on XT remains.

I don't get it: what has UMB to do with anything in regard to that extension 
card ?   Are you sure you responded to the right guy ?

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#3204

On Sat, 30 Mar 2019 19:30:32 +0100, R.Wieser wrote:

> I don't get it: what has UMB to do with anything in regard to that extension 
> card ?   Are you sure you responded to the right guy ?

Rudd's post from 2012 has another sentence:


> I use this UMB to store my drivers so I'm able to free as much RAM
> under the 640 KB barrier as possible. 

Claiming his self built card memory can be mapped into UMB space, so
that he can load drivers there. It takes BIOS, UMBPCI, or EMM386 to map
physical memory into UMB space, so how did he make it work on an XT?

Did he modify the XT BIOS? Add a BIOS extension? I think only he can
answer that, if he's still around. It was 7 years ago, so maybe not.

[toc] | [prev] | [next] | [standalone]

#3205

src153,

> It takes BIOS, UMBPCI, or EMM386 to map physical
> memory into UMB space, so how did he make it work on
> an XT?

Because it doesn't need any of that.

All you need is a latch that will remember the bits you send to it, and feed
its outputs to the address lines "above" the ones that are available for
that extension card (going to the RAM on that card).   Change the latches
contents (normally by writing to a specific address in the cards address
space) and you look at another block of physical memory.

Ofcourse, a small driver will be needed.  Which is normally loaded (or 
available in ROM) in the lower range of the extension card (leaving one or 
more adresses at its top free to write to the above mentioned latch - or in 
the case of ROM, overlapping), leaving the upper range free for the RAM 
block switching

And by the way: EMM does not "map physical memory into UMB space", it simply
/copies/ a block from beyond the 1M border into UMB space - and back again
when another block is requested.   If you ask it nicely it will as easily
copy in/out of convential memory.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#3206

On Sat, 30 Mar 2019 21:18:34 +0100, R.Wieser wrote:

>Ofcourse, a small driver will be needed.  Which is normally loaded (or 
>available in ROM) in the lower range of the extension card (leaving one or 
>more adresses at its top free to write to the above mentioned latch - or in 
>the case of ROM, overlapping), leaving the upper range free for the RAM 
>block switching

There is no RAM block switching with UMBs. If you've not done what Ruud
did, why climb out on a limb of speculation. I don't think you know what
you're talking about.


>And by the way: EMM does not "map physical memory into UMB space", it simply
>/copies/ a block from beyond the 1M border into UMB space - and back again
>when another block is requested.   If you ask it nicely it will as easily
>copy in/out of convential memory.

That's only true of the EMS page frame, and then, only if you want one.
You can configure EMM386 for NOEMS, and there is no page frame, only
UMBs. Physical memory is mapped for UMBs and kept that way. Otherwise, a
TSR or device driver loaded high could not hook an interrupt and stay in
memory to catch it.

There are books that explain all this for 286+ MMU systems, but I've
seen none that explain UMBs for XT. Thanks for trying, but I'll wait for
someone who's actually done it.

[toc] | [prev] | [next] | [standalone]

#3207

On Sat, 30 Mar 2019 21:22:54 +0000, src153 wrote:

> There are books that explain all this for 286+ MMU systems, but I've
> seen none that explain UMBs for XT.

Found the answer.

> It's all about the GAL in u44. It defines which blocks of memory are
> addressable

http://www.vcfed.org/forum/showthread.php?29677-UMB-on-an-8088-without-a-V-20

Gets deep.

[toc] | [prev] | [next] | [standalone]

#3208

On Sat, 30 Mar 2019 23:09:39 +0000, src153 wrote:

>> It's all about the GAL in u44. It defines which blocks of memory are
>> addressable

>http://www.vcfed.org/forum/showthread.php?29677-UMB-on-an-8088-without-a-V-20

>Gets deep.

Those were the days. When adding 128k was a big deal. And people posted
to Usenet. Now I'm just blogging to myself.

[toc] | [prev] | [next] | [standalone]

#3209

src153,

> There is no RAM block switching with UMBs.

And I never said there was (prove me wrong).

EMM (allowing access to the memory above the 1M border) however does.   So, 
why did you name EMM when all you wanted to talk about whas UMB ?   Which is 
regular memory, just located in the 640K ... 1M area.   Nothing special 
about it -- other than that the OS doesn't load programs there that is.

And for the record: I was responding to that extension card, and how it 
could used/function.    I've /suggested/ that it could be using 
block-swapping, though thats not even certain.  It could just one directly 
adressable continuous block.  You know, for XT motherboards which physically 
"filled out" with 640KByte of RAM sticks.

> I don't think you know what you're talking about.

You're right, that must be it.

FYI: My first "real" 'puter was a 286, which I used to program Assembly on. 
You know, directly accessing memory and I/O.  It was a nice time, everything 
was up for grabs.

Goodbye.
Rudy Wieser.

[toc] | [prev] | [next] | [standalone]

#3227

On Sat, 30 Mar 2019 15:17:37 +0000
src153 <src153@protocol.invalid> wrote:

> On Sat, 30 Mar 2019 08:04:59 +0100, "R.Wieser" wrote:

> >And by the way, in that XP timeframe the addressing is "set up" by
> >the processor and other hardware on the motherboard.   The "BIOS" is
> >nothing more than a collection of on-board and extension-card ROMs,
> >exposing a set of basic APIs and initialisation routines (in short:
> >software).   Nothing in there can dictate how the addressing happens
> >(other than to "pretty please" the available hardware).  
> 
> With 286+ and MMU, physical RAM is mapped in two pieces, 0-640k, and
> 1M+. The virtual address space between 640k to 1M is partially taken
> by ROMs, the rest unused.
> 
> 286+ can map physical RAM into UMB space, call it shadow RAM and copy
> ROM into it. But other UMB space is empty and unmapped, typically D000
> and E000 space.
> 
> The BIOS sets up shadow RAM. UMBPCI is like an extension of BIOS, it
> uses knowledge of a motherboard chipset to map physical RAM into UMB
> space.
> 

About the only things I still remember about my XT was that the MFM
drives kept failing, and it had a memory expansion card with many DIP
RAM chips.  So, I don't recall if you could load DOS high or not.

See "IBM 64KB Memory Expansion Option" and "IBM 64/256KB Memory
Expansion Option" and "IBM 256KB Memory Expansion Option" sections
here:
http://www.minuszerodegrees.net/5150_5160/cards/5150_5160_cards.htm

One of the card descriptions above links to a page of manuals in pdf
format, one of which is supposed to have a schematic of the expansion
card.

The descriptions above say the memory can be installed as long as it
doesn't create an address conflict.  From what I remember of the IBM
schematic, i.e., not that much anymore ..., that seems to be correct.

However, one of those manuals, probably the Technical Reference, should
have the full schematic of the XT (or PC or AT respectively), as I
once possessed copies of the PC schematic many decades ago.

So, you'll likely see two things on the schematic 1) some high address
lines not connected to the main motherboard memory but going to decoder
circuitry to select the memory chips, and 2) a full set of address
lines connected to the expansion connector to allow for RAM/ROM on
expansion cards.

Sorry, I didn't download and check this to confirm.  That exercise will
be left for the reader, today.


Rod Pemberton
-- 
The lesson for Boeing.  You push the nose of a plane down, and planes
go down.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.msdos.programmer

csiph-web