The B000-B7FF include is known as the 'monochrome display adapter memory area'.

It's a chunk of memory where black and white monochrome display cards' video memory is exposed to the computer, so that programs can write on it directly.

It should have nothing mapped there with a VGA card. (They use memory in a different location).

Generally speaking, 'RAM=' is the same as 'I=', but uncommon/depreciated.

From the line you are reporting, the dos memory map should look like this:

640k dos memory |VGA adapter area| monochrome display buffer (as UMB) | VGA BIOS| UMB at C800-CFFF| some memory mapped device at D000-D0FF| UMB memory at D1000-D7FF| another memory mapped device at D800-D9FF| UMB at DD00-DFFF| EMS Pageframe at Eooo-EFFF| System BIOS at F000-FFFF

The thing I find suspect is the inclusion at C800.

Almost no modern VGA bios is small enough to end there. If you switched out that ET4000 for something else, this is probably your culprit.

What I would suggest:

Remove the 'RAM=C800-CFFF' directive, back up the existing config.sys and autoexec.bat, then run memmaker, and tell it YES, KEEP INCLUDES AND EXCLUDES.

The way your memory map is broken up means it will be very crabby about how/where device drivers get loaded into memory, since some of the free regions are quite small. Memmaker can more intelligently decide which regions to use for what drivers.

The include at C800 is *very likely* clobbering the bottom half of the VGA display adapter's BIOS code, which gets called when the card is instructed to do things. (Like change display mode). In my experience, only very very old cards without VESA function sneak in small enough to end at C7FF. Most end at CBFF, or even gobble up the whole C000 segment, and end at CFFF.

It's not possible for me to predict where your VGA bios ends.

You can find out by holding F5 while booting, so that config.sys and autoexec.bat are skipped, then running MSD, looking on the (M)emory page, and seeing for yourself where it ends.

(An image of this screen would go a LONG way toward helping you.)

Thanks for the info, I will try another VGA ISA card tomorrow.

I will also try running memmaker and MSD (I didn't know the program MSD, looks handy!) I'll post screenshots.

Regarding the B000-B7FF block, could it be related to (Most powerful / Most popular ISA SVGA Cards?):

mkarcher wrote on 2022-11-03, 08:17:

ET4000 cards were quite popular those days. Some of them can be switched in CGA/EGA emulation modes where they are (mostly) register-level compatible to those cards. If there is a chip labeled "SYNC ROM", this is definitely the case - that ROM contains translation table from CGA or EGA values to VGA values for CRTC programming. ...

The card I have, has the "Sync rom" (I didn't dump it yet)

If it does register level cga, then the b000-b7ff region might actually be in use, yes.

To be clear: when the PC boots, it hangs on the EMM386 line in config.sys but I still see a blinking cursor.

I've tried 3 other ISA graphic cards (original config.sys), all hang.
I've tried removing RAM=C800-CFFF, computer still hangs after boot, if I try to run memmaker without loading config.sys (even including original ranges), it removes all directives.
I've took some screenshots using MSD.

Some extra info, on top of the config.sys is following comment (translated from german):
rem Allocate areas for rack mapping, 9.8.96, #7
rem Adapted to new address distribution, 31.10.96, #7
rem FILES entry added, 18.11.96, #7
rem Exclude hardware areas, 22.08.97, #7

The videocard that was installed at the time these images were taken ends at C9FF. (There's a bit of 'maybe free' just before that, but I personally wouldnt risk it.)

B000-B7FF should be treated like there is actual RAM there. We cannot use that region with this videocard because it does register level compatibility with MDA and CGA.

Try this emm line

RAM X=B000-B7FF I=CA00-CFFF X=D000-D0FF I=D100-D7FF X=D800-D9FF I=DD00-DFFF FRAME=E000

Note:

I dont know if your CNC controller cards are memory-mapped or not. I *suspect* they are, with those strange and small excludes.. but MSD sees nothing there at those locations.

If this were a 'normal' system, I would try to move the pageframe, and treat the E000 region as suspicious.

(Based on MSD's memory viewer, with this config-- again, this is if it was a normal system that did not have cnc cards in it!)

RAM X=B000-B7FF I=CA00-D9FF X=DA00-DBFF I=DC00-E5FF X=E600-EFFF FRAME=CA00

Since there is a 64k block that could be the pageframe between CA00-D9FF. Emm wants this to align on segment boundaries, but it does not have to. Upper memory would be 'tidier' this way, and avoid any of the suspicious 'maybe free' areas.

debnie wrote on 2026-02-02, 19:40:

When I boot the computer the computer hangs on this line in config.sys: "DEVICE=C:\DOS\EMM386.EXE FRAME=E000 RAM=B000-BFFF RAM= […]
Show full quote

When I boot the computer the computer hangs on this line in config.sys:
"DEVICE=C:\DOS\EMM386.EXE FRAME=E000 RAM=B000-BFFF RAM=D100-D7FF X=D000-D0FF X=D800-D9FF RAM=C800-CFFF RAM=DD00-DFFF"

The CNC program uses the FRAME=E000 (referenced inside config files).

EMM386 create EMS frame at E000, most software uses INT/BIOS call to determinate where EMS frame is, no need to force it at config files.
CNC really need EMS memory ? Or may it look for I/O card at E000 ?

Incorrect.

Emm386 will create the pageframe where it *thinks* makes the most sense, but it does not always know best. The FRAME= statement *tells* Emm386 *where* to place the pageframe, declaratively.

Msdosdrv.txt has this to say about the FRAME= statement

FRAME=address

Specifies the page-frame segment base directly. To specify a specific segment-base address for the page frame, use the FRAME switch, and specify the address you want. Valid values for address are in the ranges 8000h through 9000h and C000h through E000h, in increments of 400h. To provide expanded memory and disable the page frame, you can specify FRAME=NONE; however, this may cause some programs that require expanded memory to work improperly.

Programs wishing to use EMS should do the query, to learn where the pageframe is.
It's possible the cnc software wants to take shortcuts, and instead of doing things *right*, (by calling the emm's software interrupt and issuing the query, like a good program), it instead just accepts a user defined variable where the frame starts, then just runs roughshod shooting page operation requests.

As far as emm386 is concerned though, ANY block of address that meets the above requirements, and is 64kb in size, may be used as the pageframe location.

wierd_w wrote on Yesterday, 11:23:

Incorrect.

1) "no need to force it at config files" = CNC config files, not config.sys
2) "EMM386 create EMS frame at E000" = because it forced at config.sys at E000, of cource adress can be different if not forced and E000 claimed by optional ROM/RAM

Yeah, i saw what you meant after the fact.

It's important to remember that 'industrial' software often takes .. 'liberties'.. since the computer is assumed to have a fixed role, and will not be 'sharing' with other software or tasks.

Time is money, programmer time was costly, yadda yada.

As such, 'a proper, standards conforming program that uses ems' should query the emm provider where the pageframe is, ask how many pages there are, ask to allocate a number of pages, switch to the first of it's allocated pages, THEN write on the address where the emm SAID it is.

Industrial software very rarely does things in a standards conforming way. If the programmer could get away with not talking to the emm this way, and instead just being a bossy bitch, that's how it would get written; it presumes that it wont be sharing with other programs, so why *bother* allocating pages? Just tell the emm to bring up page 0, and act like a tyrant.

I tried: RAM X=B000-B7FF I=CA00-CFFF X=D000-D0FF I=D100-D7FF X=D800-D9FF I=DD00-DFFF FRAME=E000
Got a warning: Option ROM or RAM detected within page frame.
When I run the software, I get the colorful ASCII screen (see image), tested with two graphic cards.

I tried: RAM X=B000-B7FF I=CA00-D9FF X=DA00-DBFF I=DC00-E5FF X=E600-EFFF FRAME=CA00
Got an error: Unable to set page frame base address--EMS unavailable. Invalid parameter specified.

The frame address references I found in the program are hardcoded, in the software folder is a symbol table with the address:

1Intel 8086 LOCATER
2
3SYMBOL TABLE
4BASE    OFFSET TYPE SYMBOL
5E000H   1212H  PUB  ASODBUFFER
6E000H   0000H  PUB  DATASEG@
7E000H   D0A2H  PUB  ABBAU
8E000H   8683H  PUB  ABBRUCHCOMPLET
9E000H   1AC6H  PUB  ABBRUCHMERKER
10...

wierd_w wrote on Yesterday, 11:53:

It's important to remember that 'industrial' software often takes .. 'liberties'.. since the computer is assumed to have a fixed role, and will not be 'sharing' with other software or tasks.

This I can concur 😉

Ok. Outright tell the emm to include the address range we will use as the pageframe, to shut it up, and force the frame there.

RAM X=B000-B7FF I=CA00-CFFF X=D000-D0FF I=D100-D7FF X=D800-D9FF I=DD00-DFFF I=E000-EFFF FRAME=E000

If it still baulks, it's because part of the e000 range has 'something suspicious' in it, and some of it does not. It may need multiple explicit includes, like this, to shut it up:

RAM X=B000-B7FF I=CA00-CFFF X=D000-D0FF I=D100-D7FF X=D800-D9FF I=DD00-DFFF I=E000-E3FF I=E400-E7FF I=E800-EBFF I=EC00-EFFF FRAME=E000

wierd_w wrote on Yesterday, 12:09:

RAM X=B000-B7FF I=CA00-CFFF X=D000-D0FF I=D100-D7FF X=D800-D9FF I=DD00-DFFF I=E000-EFFF FRAME=E000

No need X= and I= (umb crap), only FRAME= is enough. If emm386 hangs, need to disable umb totally X=A000-DFFF X=F000-FFFF

Mov AX, 0xDEAD wrote on Yesterday, 12:44:

wierd_w wrote on Yesterday, 12:09:

RAM X=B000-B7FF I=CA00-CFFF X=D000-D0FF I=D100-D7FF X=D800-D9FF I=DD00-DFFF I=E000-EFFF FRAME=E000

No need X= and I= (umb crap), only RAM and FRAME= is enough

This is *not* a normal computer.

This is an industrial SBC with ISA backplane, that has 2 bespoke ISA cards, that control an industrial robot.

These excludes come from the 'previously known working' configuration.

Agreed, you dont make excludes like this if there is not a good reason. I am assuming there is, even if I dont know what it is. (why exclude 256 BYTES at D000-D00FF? Hell if I know!)

Based on what has happened, I presume this chain of events:

An electrical malfunction smoked the original SBC, and video card.

OP replaced the SBC and video card, with an identical SBC, and a Tseng Labs ET4000, respectively.

The original memory configuration included the monochrome display buffer area (b000-b7ff), which is not permissable with the ET4000. This was causing a hang. Fixed.

The original memory configuration thought the vga bios ended at C7FF. The new videocard's video bios ends at CBFF. The bottom part of the vbios was getting clobbered by the include. This was causing rainbow colored ascii garbage and a hang. Fixed.

EMM386 is detecting 'something' on the tail end of the E000 segment, where the pageframe *must* go, to satisfy the badly written robot control software. There is 'undocumented' behavior with emm386 that lets you get around this with explicit includes. Now Testing.

wierd_w wrote on Yesterday, 12:53:

These excludes come from the 'previously known working' configuration.

I think need to disable all UMB ranges and leave only E000-EFFF for EMS, even if cnc requires mouse driver and originaly loaded to umb

Mov AX, 0xDEAD wrote on Yesterday, 13:04:

wierd_w wrote on Yesterday, 12:53:

These excludes come from the 'previously known working' configuration.

I think need to disable all UMB ranges and leave only E000-EFFF for EMS, even if cnc requires mouse driver and originaly loaded to umb

If it comes down to it as a diagnostic step, sure.

Right now, i'd suspect emm386 finding extended bios configuration data in the e000 segment, and being a primadonna about it.

This SBC is too old to have an AHCI controller living there, so i'm not too worried about the forced include.

Just a clarification, the SBC was replaced, but the graphic card is still original (Tseng Labs ET4000)
There are no drivers (mouse, cdrom,...) and normally only the program is started from autoexec.bat

Complete config.sys:
DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE FRAME=E000 RAM=B000-BFFF RAM=D100-D7FF X=D000-D0FF X=D800-D9FF RAM=C800-CFFF RAM=DD00-DFFF
STACKS=0,0
DOS=HIGH
FILES=20

I tried RAM X=B000-B7FF I=CA00-CFFF X=D000-D0FF I=D100-D7FF X=D800-D9FF I=DD00-DFFF I=E000-EFFF FRAME=E000, but after starting the program still ASCII rainbow mess.
Could it be that the program directly writes to the graphics card?
(Also no changes when the IO cards are placed or not).