VOGONS


Dos 6 conventional memory tricks

Topic actions

Reply 180 of 298, by Baoran

User metadata
Rank l33t
Rank
l33t
elianda wrote:

You already wrote this. Since you noticed that Floppy does not support DMA any more when E000 is included then DMA when attributed as page frame won't work as well.

Usually DMA stops working if the UMB is generated by Shadow RAM when the mainboard does not support DMA from Shadow RAM or if UMB is generated from XMS regions where no DMA is possible. For ISA DMA generally there is a 16 MB limit. I don't know how HIMEMX provides XMS to EMM386 to generate UMBs, but the /MAX=65536 indicated that you enable more than 16 MB. Now if the XMS that is provided by HIMEMX to be mapped at E000 for virtual EMS is from an area beyond 16 MB physical it could be the source of non working DMA.

Changing himemx to normal himem.sys didn't change anything. Changing the limit to 8Mb with himemx didn't change anything either.
I have been going through the memory with umbinfo and it seems that only free space for umb seems to be B000-B7FF and D300-DFFF and that is why emm386 can't find any 64Kb empty block for the frame. Umbinfo won't even show what is in E000-EFFF and it just skips over that, so I can't tell what has exactly reserved that.

Not sure what kind of problems Frame=none would cause with emm386.

Reply 181 of 298, by retardware

User metadata
Rank Oldbie
Rank
Oldbie

Haven't read through the whole thread.

But what is absolutely amazing to me is that nobody dared to use the dead ROM space, but instead opt to include the MDA/MGA area of B000-B7FF. The latter I never considered safe back then, as there exist[ed] some software which probed for MDA by writing into that range, and iirc also overlaps with some graphics modes.

The dead ROM is usually the last 4k of the VGA BIOS which contains the alternate font (a feature I found never be used) and the lower (about half) portion of the system BIOS.
Without looking at the actual ROM contents using debug and then d xx00:0 I found it usually causes no problems in a typical system at which CheckIt says video BIOS is from C000-C5FF and system BIOS from F000-FFFF, if I include the following options in the EMM386 line, as I do not care for the BIOS Setup code be accessible from DOS:

devicehigh=EMM386.EXE I=C500-C5FF I=F000-F7FF ... ... ... 

I honestly do not understand why you Vogons do not use that dead ROM space.

Reply 182 of 298, by dr_st

User metadata
Rank l33t
Rank
l33t

Apparently, it is not as 'dead' as you think. I just tried I=F000-F7FF on my Thinkpad A21m and got a hard lockup during boot. Tried I=C500-C5FF, and got a blank screen and eventual lockup. It may work on some systems but not all of them. Whereas I=B000-B7FF should work on every system unless you use software that specifically needs that range (which is rare).

https://cloakedthargoid.wordpress.com/ - Random content on hardware, software, games and toys

Reply 183 of 298, by retardware

User metadata
Rank Oldbie
Rank
Oldbie
FeedingDragon wrote:

There is only 1 way, with a standard PC, that I know of to get conventional memory over 640k (usually maxes at 620k-630k even with 3rd party memory managers.) That is to reclaim the hi-res color graphics RAM from A000-AFFF. Can't run anything with advanced graphics, but provides a large amount of conventional memory. I've seen people using this to run memory intensive programs that are limited to ANSI or text based graphics. Such as a BBS some DOS based servers, etc...

In the 1980s with my MDA/HGC PC I had built a RAM card which filled A000 segment. Just joined that into the free memory space - which at that time only consisted of one list.
Then there came HIMEM.SYS which toggled the A20 bit, introducing another small MCB list for the HMA.
Popular at that time there was the AMS HiCard (ISA RAM expansion card), which joined/linked its memory in the area from A000 to EFFF..

With EMM386, actually with its now forgotten predecessors 386MAX, QEMM, etc, there was a third memory chain established, the UMA.

You could simply reserve the UMA memory and add it to the chain of free conventional MCBs to obtain more than 640K conventionally accessible memory.
Easily doable by small TSR.

Reply 184 of 298, by retardware

User metadata
Rank Oldbie
Rank
Oldbie
dr_st wrote:

Apparently, it is not as 'dead' as you think. I just tried I=F000-F7FF on my Thinkpad ...

I should have mentioned that this only works on standard bios (ami, newer award and phoenix).
You can examine and disassemble these.
From some time on I had the impression that they were so thoughtful to put the setup at the first, so a big part of the space can be reused.
But if you bought nonstandard hardware, you were bitten 😀

Reply 185 of 298, by GigAHerZ

User metadata
Rank Oldbie
Rank
Oldbie
retardware wrote:

You could simply reserve the UMA memory and add it to the chain of free conventional MCBs to obtain more than 640K conventionally accessible memory.
Easily doable by small TSR.

Is there such a TSR somewhere already made?

"640K ought to be enough for anybody." - And i intend to get every last bit out of it even after loading every damn driver!

Reply 186 of 298, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

I wrote a tool to add memory to the dos mcb chain. I can post info on it tonight when I get home. It was written for my Tandy 1000sx dos 3.3 to add extra memory blocks in UMB space to the memory chain, which dos 3.3 does not directly support. worked fine for me.

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 187 of 298, by retardware

User metadata
Rank Oldbie
Rank
Oldbie

It is not fully unproblematic to join other memory areas to conventional memory.
Not all programs work well with non-contiguous memory, creating a nightmare for support people.
This is known since the Hicard times.
But for most programs (at least the well-written ones) the extra memory was welcome.
So it would be great if @BloodyCactus finds his nice tool again and shares it with us!

As @FeedingDragon wrote, it is only possible to extend the contiguous conventional memory by usurping the A000 segment, usually done either by RAM card or using the chipsets remapping features. There were user-written/modded BIOSes around in the 1980s that automatically added the A000 segment if no color graphics were detected and memory was present there.

But as the common BIOSes did not check memory above 640k, I back then used a small program (in the autoexec.bat) that just merged that RAM into the conventional RAM (by adding the 64k to the last and biggest free MCB). I have recently found it on a 20-yo backup CD, file is dated Aug 3, 1988. Known to work at least until Compaq DOS 3.31 and MS-DOS 5. I hope I still have the source. But it is very simple, looking at it using debug will be sufficient to understand what it does.

Attachments

  • Filename
    mem704.tar
    File size
    10 KiB
    Downloads
    119 downloads
    File comment
    "Expands" memory by including RAM in the A000 segment
    File license
    Fair use/fair dealing exception

Reply 188 of 298, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

its in this zip

https://kråketær.com/stuff.zip

mcbexp for mcb expander. I dont know if its latest version, I'll check when I get home tonight.

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 189 of 298, by dr_st

User metadata
Rank l33t
Rank
l33t
retardware wrote:

I should have mentioned that this only works on standard bios (ami, newer award and phoenix).
You can examine and disassemble these.

Well, I tried it on my K6XV3+, and it does work there. 😏

Interestingly, CD-MAN, the only game I have which uses the monochrome video area (thus conflicting with B000-B7FF, forcing me to use B400-B7FF instead) also appears to be the only game that uses the alternate font; moreover, it switches the entire system to this font and does not switch back, so if I use C500-C5FF, and load CD-MAN, not only I can't read the in-game menus, but I get no visible text when I exit the game. In my case, this region was free UMBs; I imagine that I would get more serious if I actually loaded something in that area.

https://cloakedthargoid.wordpress.com/ - Random content on hardware, software, games and toys

Reply 190 of 298, by Disruptor

User metadata
Rank Oldbie
Rank
Oldbie
retardware wrote:
The dead ROM is usually the last 4k of the VGA BIOS which contains the alternate font (a feature I found never be used) and the […]
Show full quote

The dead ROM is usually the last 4k of the VGA BIOS which contains the alternate font (a feature I found never be used) and the lower (about half) portion of the system BIOS.
Without looking at the actual ROM contents using debug and then d xx00:0 I found it usually causes no problems in a typical system at which CheckIt says video BIOS is from C000-C5FF and system BIOS from F000-FFFF, if I include the following options in the EMM386 line, as I do not care for the BIOS Setup code be accessible from DOS:

devicehigh=EMM386.EXE I=C500-C5FF I=F000-F7FF ... ... ... 

I honestly do not understand why you Vogons do not use that dead ROM space.

Try to switch from graphics mode to text mode.
Perhaps one of the following commands may draw corrupted characters on your screen, depending on your video BIOS.
mode co80
mode co40
mode con lines=50

Reply 191 of 298, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

Ive also used that font in some demo/intro/cheat scrollers back in the day. Its not "dead rom" space to me.

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 192 of 298, by matze79

User metadata
Rank l33t
Rank
l33t
286.jpg
Filename
286.jpg
File size
49.25 KiB
Views
2422 views
File license
Fair use/fair dealing exception

My 286 Luggable with 5Mb RAM 😀

DOS 3.31 with QRAM, has CGA.
Therefore i can fill up everything to CGA Frame beginning.

I have Upper Memory, but MEM won`t show it as its ripped from other DOS Version.

https://www.retrokits.de - blog, retro projects, hdd clicker, diy soundcards etc
https://www.retroianer.de - german retro computer board

Reply 193 of 298, by elianda

User metadata
Rank l33t
Rank
l33t
retardware wrote:

I honestly do not understand why you Vogons do not use that dead ROM space.

I think that QEMM386s ROM Stealthing feature is superior to that approach.

Retronn.de - Vintage Hardware Gallery, Drivers, Guides, Videos. Now with file search
Youtube Channel
FTP Server - Driver Archive and more
DVI2PCIe alignment and 2D image quality measurement tool

Reply 194 of 298, by retardware

User metadata
Rank Oldbie
Rank
Oldbie
elianda wrote:
retardware wrote:

I honestly do not understand why you Vogons do not use that dead ROM space.

I think that QEMM386s ROM Stealthing feature is superior to that approach.

In 1989 my boss put 386MAX and QEMM386 sealed boxes on my desk and told me to evaluate them.
The conclusion was, we ditched them as they didn't cooperate well with the tools we used (CV, NuMega MCV and Soft-ICE).
Later I tried them again using newer versions and again found that the issues they create are just not worth the hassle for that minimal gain.

Do there exist trouble-free versions of QEMM that can be recommended?
(Cooperating problem-free with Windows 98SE is a must)

Reply 195 of 298, by elianda

User metadata
Rank l33t
Rank
l33t

I don't know why you want to use QEMM386 in combination with Windows 98SE. I mean the last version of QEMM is 9.0 and it is from 1997 (quite a bit newer than the QEMM from 1989), so they can not have possibly tested it against Windows 98SE. This means problems are to be expected and it is a hit or miss. It is better to use HIMEM:SYS and EMM386 that comes with Windows98SE if you boot up Windows.

My configurations are typically targeted to be able to run games. The Stealthing feature allows to dynamically map between the ROMs and RAM for double use of the same memory area.
I also have used it successfully with SWAT to develop for SoftMPU.

Retronn.de - Vintage Hardware Gallery, Drivers, Guides, Videos. Now with file search
Youtube Channel
FTP Server - Driver Archive and more
DVI2PCIe alignment and 2D image quality measurement tool

Reply 196 of 298, by ssokolow

User metadata
Rank Newbie
Rank
Newbie
elianda wrote:

I don't know why you want to use QEMM386 in combination with Windows 98SE. I mean the last version of QEMM is 9.0 and it is from 1997 (quite a bit newer than the QEMM from 1989), so they can not have possibly tested it against Windows 98SE. This means problems are to be expected and it is a hit or miss. It is better to use HIMEM:SYS and EMM386 that comes with Windows98SE if you boot up Windows.

I actually have a copy of that which I've been meaning to play around with. It's officially labelled "QEMM 97" and is the only program I've ever seen which uses the same install.exe to launch separate DOS and Windows installers.

(I haven't yet looked into whether they swapped their DOS installer in as the MZ stub for the InstallShield bootstrap or just had it detect being run under Windows and launch a renamed copy of what would normally be named setup.exe.)

Wikipedia claims that it's "Compatible with Windows 98 SE and Windows 98, though designed and tested with Windows 95 OSR2."

Internet Archive: My Uploads
My Blog: Retrocomputing Resources
My Rose-Coloured-Glasses Builds

I also try to announce retro-relevant stuff on on Mastodon.

Reply 197 of 298, by retardware

User metadata
Rank Oldbie
Rank
Oldbie
ssokolow wrote:

I actually have a copy of that which I've been meaning to play around with. It's officially labelled "QEMM 97" and is the only program I've ever seen which uses the same install.exe to launch separate DOS and Windows installers.

(I haven't yet looked into whether they swapped their DOS installer in as the MZ stub for the InstallShield bootstrap or just had it detect being run under Windows and launch a renamed copy of what would normally be named setup.exe.)

Iirc link.exe has the possibility (option) to incorporate both DOS and Windows executables in an .exe file.

ssokolow wrote:

Wikipedia claims that it's "Compatible with Windows 98 SE and Windows 98, though designed and tested with Windows 95 OSR2."

Which version is that? Is it version 9.0 which @elianda mentioned?

Reply 198 of 298, by cyclone3d

User metadata
Rank l33t++
Rank
l33t++
retardware wrote:
Haven't read through the whole thread. […]
Show full quote

Haven't read through the whole thread.

But what is absolutely amazing to me is that nobody dared to use the dead ROM space, but instead opt to include the MDA/MGA area of B000-B7FF. The latter I never considered safe back then, as there exist[ed] some software which probed for MDA by writing into that range, and iirc also overlaps with some graphics modes.

The dead ROM is usually the last 4k of the VGA BIOS which contains the alternate font (a feature I found never be used) and the lower (about half) portion of the system BIOS.
Without looking at the actual ROM contents using debug and then d xx00:0 I found it usually causes no problems in a typical system at which CheckIt says video BIOS is from C000-C5FF and system BIOS from F000-FFFF, if I include the following options in the EMM386 line, as I do not care for the BIOS Setup code be accessible from DOS:

devicehigh=EMM386.EXE I=C500-C5FF I=F000-F7FF ... ... ... 

I honestly do not understand why you Vogons do not use that dead ROM space.

Back in the day I used to use those areas.. and probably more. I would go through a memory mapper and see what was actually being used and then try to add even the smallest ranges to get more UMBs. I had some crazy long EMM386 includes back then.

I also used UMBPCI for some systems since it worked better for the specific chipsets it supported.

Yamaha modified setupds and drivers
Yamaha XG repository
YMF7x4 Guide
Aopen AW744L II SB-LINK

Reply 199 of 298, by ssokolow

User metadata
Rank Newbie
Rank
Newbie
retardware wrote:
ssokolow wrote:

I actually have a copy of that which I've been meaning to play around with. It's officially labelled "QEMM 97" and is the only program I've ever seen which uses the same install.exe to launch separate DOS and Windows installers.

(I haven't yet looked into whether they swapped their DOS installer in as the MZ stub for the InstallShield bootstrap or just had it detect being run under Windows and launch a renamed copy of what would normally be named setup.exe.)

Iirc link.exe has the possibility (option) to incorporate both DOS and Windows executables in an .exe file.

Yes. As I remember, you do it by passing /STUB <path to DOS EXE file> when running link.exe on the Windows object code.

I'm saying that I haven't yet checked whether they used a 3rd-party tool to swap out the stub on the InstallShield bootstrap EXE which would normally be named setup.exe and then renamed it to install.exe or whether they renamed it to some other non-standard name and had their install.exe just launch it if it detects Windows.

retardware wrote:
ssokolow wrote:

Wikipedia claims that it's "Compatible with Windows 98 SE and Windows 98, though designed and tested with Windows 95 OSR2."

Which version is that? Is it version 9.0 which @elianda mentioned?

Yes. Here's the relevant bit of the Wikipedia QEMM page in full (emphasis mine):

https://en.wikipedia.org/wiki/QEMM wrote:
QEMM 97 (aka v9.0) (1997-5-15) […]
Show full quote

QEMM 97 (aka v9.0) (1997-5-15)

  • Added full support for Windows 95 OSR2 and Windows 95.
  • Added full support for the under-laying DOS 7.10 with improvements and enhancements to full suite of utilities.
  • Compatible with Windows 98 SE and Windows 98, though designed and tested with Windows 95 OSR2.
  • This is the final release of QEMM.
  • New utilities include MagnaRAM, Manifest for Windows 95.
  • Additional Windows 95 features include optimizing paging file.

Internet Archive: My Uploads
My Blog: Retrocomputing Resources
My Rose-Coloured-Glasses Builds

I also try to announce retro-relevant stuff on on Mastodon.