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.

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:

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

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

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).

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.

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 😀

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?

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.

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.

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.

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.

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:

Copy code to clipboard

1devicehigh=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

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

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.

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.

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)

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.

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."

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?

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:

Copy code to clipboard

1devicehigh=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.

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.