From Newsgroup: comp.os.msdos.misc

Hi! I just tried to use QEMM's VidRAM to buy some memory, and the program gave me an error message stating that the top of Conventional RAM is *not* 640k. I think I know why: I'm using the mono graphics buffer for UpperRAM. I really want the extra memory. How can I gain the 64k using VidRAM or another utility?
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.os.msdos.misc

On Sat, 9 Mar 2019 08:07:27 -0800 (PST), Harry Potter wrote:

Hi! I just tried to use QEMM's VidRAM to buy some memory, and the program gave me an error message stating that the top of Conventional RAM is
*not* 640k. I think I know why: I'm using the mono graphics buffer for UpperRAM. I really want the extra memory. How can I gain the 64k using VidRAM or another utility?

What error?
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.os.msdos.misc

On Sunday, March 10, 2019 at 5:02:47 AM UTC-4, JJ wrote:

What error?

It says that the top of Conventional RAM is *not* 640k. :(
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.os.msdos.misc

Harry Potter dit dans news:f14bb471-edca-4214-b782-25fe85d1fa64 @googlegroups.com:

On Sunday, March 10, 2019 at 5:02:47 AM UTC-4, JJ wrote:

What error?

It says that the top of Conventional RAM is *not* 640k. :(

Could be "extended BIOS data area" EBDA. Normally DOS 7.x would
relocate those data lower during IO.SYS initialisation, BUT - there
is
a but - this autorelocation doesn't happen if the EBDA size is over 1 kilobytes (from memory). If your computer's BIOS creates an XBDA
larger ° than what MSDOS itself can relocate, - it is left in place,
just under the video area at segment A000, and you'd get the message
you quoted.


Solution is to write (or get) a program taking the form of a pseudo-
device driver that will relocate the EBDA down and insert a call to
that in your CONFIG.SYS.

If it's NOT the EBDA (aka XBDA) then of course it could be other
"special" drivers that you might happen to have (I seem to remember
you having a tendency to install everything AND the kitchen sink in
your systems, and THEN come crying it doesn't work... Well, you are
welcome to try things, but should remember that being adventurous
requires skills beyond calling for help on numerous news-groups and
possibly also web-sites. Just saying ;=)

Hope you sort this and other self-inflicted pains anyway...

Cheers

° Large EBDAs *used to* be unusual; however IF you are running MS-DOS
native on some (most) new HW with EFI BIOS and a compatibility module
(CSM), your EBDA will often end up being 4 K or even larger.
Sometimes twraking BIOS settings may reduce it to regular 1Kilobytes
in size. F'instance, DISABLE "SATA" and choose something might be
called "legacy IDE" or somesuch for hard disks...
°° Regarding QEMM VIDRAM, it might do great HARM if you manage to
launch it on modern HW. You have been warned (but I fear you wouldn't
heed anyway)

--
Nim'
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.os.msdos.misc

On Sunday, March 10, 2019 at 1:01:59 PM UTC-4, NimbUs wrote:

Could be "extended BIOS data area" EBDA. Normally DOS 7.x would
relocate those data lower during IO.SYS initialisation, BUT - there
is
a but - this autorelocation doesn't happen if the EBDA size is over 1 kilobytes (from memory). If your computer's BIOS creates an XBDA
larger ° than what MSDOS itself can relocate, - it is left in place,
just under the video area at segment A000, and you'd get the message
you quoted.

It couldn't be that, as MEM doesn't register anything at the top of Conventional RAM.

Hope you sort this and other self-inflicted pains anyway...

You're right. I'm sorry. :(

° Large EBDAs *used to* be unusual; however IF you are running MS-DOS native on some (most) new HW with EFI BIOS and a compatibility module
(CSM), your EBDA will often end up being 4 K or even larger.
Sometimes twraking BIOS settings may reduce it to regular 1Kilobytes
in size. F'instance, DISABLE "SATA" and choose something might be
called "legacy IDE" or somesuch for hard disks...
°° Regarding QEMM VIDRAM, it might do great HARM if you manage to
launch it on modern HW. You have been warned (but I fear you wouldn't
heed anyway)

It came with Win98, so it should be around 1998 or 1999. Does this help?
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.os.msdos.misc

Harry Potter dit dans news:8a8e4226-fb5b-480e-8066- ee8e392360aa@googlegroups.com:

On Sunday, March 10, 2019 at 1:01:59 PM UTC-4, NimbUs wrote:

Could be "extended BIOS data area" EBDA. Normally DOS 7.x would
relocate those data lower during IO.SYS initialisation, BUT -

there

is
a but - this autorelocation doesn't happen if the EBDA size is

over 1

kilobytes (from memory).[...]

It couldn't be that, as MEM doesn't register anything at the top of

Conventional RAM.

No idea then, one would need to examine the system's memory image in
detail to gain more insight. Instead of MEM.EXE, though, you'd be
better off with (or, at least, I prefer personally) : "MI" (for
"memory information", mi.com), which came from old "PCTOOLS" suites &
you probably have or can find rather easily online nowadays). If so,

mi /a - shall yield a better memoy map than DOS's own "mem".

Oh ! Also, "peeking" at memory word 0000:40Eh using "debug" or any
other program you're comfortable with would help confirm what you
think MEM told you, i.e. that either DOS itself relocated EBDA down -
or that your comp does BOT have "EBDA" (improbably for a 1998 vintage
machine)

Hope you sort this and other self-inflicted pains anyway...

You're right. I'm sorry. :(

don't be ! I was joking (sorta...)

[...]

It came with Win98, so it should be around 1998 or 1999. Does this

help?

Yep. That machine definitely could not have (u)EFI nor SATA
abilities. OTOH, is the systemp bus already PCI ? The problem
with VIDRAM "killing" motherboards I warned against happened
with certain mmachines having a PCI bus and video integrated (in the
so-called North Bridge). QEMM was an excellent product in his time
but could not foresee problems with designs that were invented AFTER
its development ended.

--
Nim'

--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.os.msdos.misc

Is there a way to get VidRAM to only give me 64k on a VGA system? I looked at the docs., and they gave no information on the matter. Or, what other utility can do the job? I have one but don't remember its name. :(
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.os.msdos.misc

Harry Potter dit dans news:23078920-3004-40b8-b6bb-b470c0b539f9 @googlegroups.com:

Is there a way to get VidRAM to only give me 64k on a VGA system?

I looked at the docs., and they gave no information on the matter.
Or, what other utility can do the job? I have one but don't remember
its name. :(

You may be thinking of the free(?)/abandon(?)ware program : HIVIDEO.
IIRW it will use memory provided by an EGA/VGA display adapter to
expand DOS base memory. This feat works even in real mode (does not
require (q)EMM-type "expanded" mem) but again, CAUTION : ensure your
system bus is NOT PCI (or later) .

Which reminds me to ask you if you REALLY REALLY want EMM (expanded
memory) - as in : some programme you need essentially needing it ? Or
are you loading QEMM mailny as a provider of "upper" memory (UMB) ?
If the latter, then please have a look at UMBPCI (if your system is
PCI; else similar in purpose utilities might apply to your whatever
"chipset", I think the UMPCI author's homepage have a list.) Real-
mode UMBs thus obtained WITHOUT necessitationg the remapping effected
in virtual-386-mode are much preffered, when possible.

--
Nim'
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.os.msdos.misc

On Monday, March 11, 2019 at 11:47:42 AM UTC-4, NimbUs wrote:

You may be thinking of the free(?)/abandon(?)ware program : HIVIDEO.
IIRW it will use memory provided by an EGA/VGA display adapter to
expand DOS base memory. This feat works even in real mode (does not
require (q)EMM-type "expanded" mem) but again, CAUTION : ensure your
system bus is NOT PCI (or later) .

Uhh...I think it is. :(

Which reminds me to ask you if you REALLY REALLY want EMM (expanded
memory) - as in : some programme you need essentially needing it ? Or
are you loading QEMM mailny as a provider of "upper" memory (UMB) ?
If the latter, then please have a look at UMBPCI (if your system is
PCI; else similar in purpose utilities might apply to your whatever "chipset", I think the UMPCI author's homepage have a list.) Real-
mode UMBs thus obtained WITHOUT necessitationg the remapping effected
in virtual-386-mode are much preffered, when possible.

I don't think I need EMS for the intended setup. I can't use QEMM on the computer. I have it installed but not under DOS. :( Will UMBPCI give more memory than plain DOS?
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.os.msdos.misc

Harry Potter dit dans news:ec77ee43-22ce-41b0-9296-de2addefab85 @googlegroups.com:

Uhh...I think it is. :(

[PCI system bus] O.K. So,

Which reminds me to ask you if you REALLY REALLY want EMM

(expanded

memory) - as in : some programme you need essentially needing it ?

Or

are you loading QEMM mailny as a provider of "upper" memory (UMB)

?

If the latter, then please have a look at UMBPCI (if your system

is

PCI; else similar in purpose utilities might apply to your

whatever

"chipset", I think the UMPCI author's homepage have a list.) Real-
mode UMBs thus obtained WITHOUT necessitationg the remapping

effected

in virtual-386-mode are much preffered, when possible.

I don't think I need EMS for the intended setup. I can't use QEMM

on the computer. I have it installed but not under DOS. :( Will
UMBPCI give more memory than plain DOS?

Right, EMM is seldom needed. And YES, if you have PCI, with most
chipsets UMBPCI will "create" upper memory for DOS to use. The amount
you get depends on the chipset brand and model, usually 64 or 96
kilobytes, more depending on motherboard and additional adapter
details. Give it a try ASAP !


--
Nim'

--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.os.msdos.misc

On Tuesday, March 12, 2019 at 6:27:46 AM UTC-4, NimbUs wrote:

Right, EMM is seldom needed. And YES, if you have PCI, with most
chipsets UMBPCI will "create" upper memory for DOS to use. The amount
you get depends on the chipset brand and model, usually 64 or 96
kilobytes, more depending on motherboard and additional adapter
details. Give it a try ASAP !

I just downloaded it. I plan to give it a try this weekend if I go to my mother's house this weekend.
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.os.msdos.misc

On Tuesday, March 12, 2019 at 7:36:15 AM UTC-4, Harry Potter wrote:

I just downloaded it. I plan to give it a try this weekend if I go to my mother's house this weekend.

Can I allocate the mono video buffer to UMBs using UMBPCI?
--- Synchronet 3.17c-Linux NewsLink 1.110

From Newsgroup: comp.os.msdos.misc

Harry Potter dit dans news:a1f6483c-bc9e-463b-b5f8-0b6f5def0236 @googlegroups.com:

On Tuesday, March 12, 2019 at 7:36:15 AM UTC-4, Harry Potter wrote:

I just downloaded it. I plan to give it a try this weekend if I go

to my mother's house this weekend.

Can I allocate the mono video buffer to UMBs using UMBPCI?

Sorry, no - you probably can't : unless your PCI chipset would allow
such readdressing to occur, which I think none does. Thus the only way
to use the mono buffer zone (B0000-B7FFF) for UMBs is with *EMM386.

--
N.
--- Synchronet 3.17c-Linux NewsLink 1.110