EMM386 Errors

[Steve Andrues]

I have a data-acquisition system running through the PC parallel port. In an attempt to fix regular system "freezes", we switched the computer from a 386SX-16 to a 486DX2-66. The problems have moved to consistently inconsistent. Tonight I got a DOS error which said "EMM386 error #12 in ap(plication)". I am assuming that the rest of the message was "application". Does anyone know what EMM386 error #12 is? It may point to my resident Poltergeist. Any help will be greatly appreciated.
Thanks.
Steve Andrues

------------------

[Mel Bishop]

It would help to know what operating system you are using. EMM386
is the extended memory manager and it may be that your app is
"leaking" to memory locations out of bounds.

I would check your EMM386 and make sure it's the one that is
supposed to be used with the appropriate O/S you are using.

Just out idle curosity, why are you using the parallel port
instead of one of serial ports? Now don't get me wrong, there's
nothing wrong with using the parallel port if it works.
------------------
Well, (few minutes later), did a Google search and check out: http://www.computerhope.com/emm386hl.htm#05
Looks you got a stack problem.



[This message has been edited by Mel Bishop (edited December 10, 2003).]

[Steve Andrues]

I am currently using DOS 6.22 for the OS. The reason for using the parallel port is easy. A very good friend of mine was watching the normal operation of my shop and announced that it "offended his sensibilities". He returned a week later with a working prototype and all that I had to do was "flesh-in" the rest of the code. At the time the idea was a good one. The data acquisition system was independent of the hardware. Any standard "Herculese" parallel port would work just fine. In the mean time there is BIOS-confifurable parallel ports and my system will not work. But that is another problem ..... I am currently using the EMM386 that comes with Dos6.22.

------------------

[Mel Bishop]

Oh. Okay.

Did you click on the link above and check your STACKS statement
in your CONFIG.SYS?


------------------

[Steve Andrues]

At the risk of revealing my DOS-ignorance; what stacks statement? What should I look for and what do you think would be optimal? The available memory for my tiny program is 15M (out of 16). It would run on the 386SX with 1M of memory.

------------------

[Mel Bishop]

Bring up CONFIG.SYS in your favorite plain text word processor
and check for a STACKS=(something) line. If it's there, change
the parameters to STACKS=16,256. If it's not there, add
STACKS=16,256. That SHOULD take care of your problem.

FYI: The stack on a computer is where the operating system
stores temporary information. Its structure is like the
magazine on a rifle, last-in, first-out. If and when the stack
fills up, your program will crash. However, unless you are into
assembly programing, you won't normally need to use it but
you do need to be aware of it.

As an added thought, run MEMMAKER and let it do it's thing.
------------------


[This message has been edited by Mel Bishop (edited December 11, 2003).]

[Steve Andrues]

The problem continues ....
After making the Stacks (and everything else in the Config.sys file) the same on our production machine the same as the "test mule" we got an insufficient memory error while trying to compile the code. No problem. 16MB later the production machine and test-mule are the same. Now the compiler reports that it cannot find some of the Linked files. The directories for the compiler are setup the same in both machines. There has been NO CHANGE in the code. Why will the code that was running on Thursday not run on Friday?!? Any ideas?

------------------

[Mel Bishop]

If you are trying to compile from within the IDE and get an
"Insufficient memory" error, your source code is probably too
big to hold both the IDE and and compile routine. To solve
this, drop to DOS (quit the IDE) and compile it with PBC.EXE.

If the program can't find its support files, there is something
in there preventing finding their location. You may have to
explicitely defind the full path of the support files in the
source code.

Not on Friday? Maybe it's taking an early weekend
------------------




[This message has been edited by Mel Bishop (edited December 15, 2003).]

[Herman Kieskamp]

Howmuch expanded memory do you reserve ?? The config line should
have something like: device=c:\dos\emm386.exe 4096
This means you give the expanded memory manager 4 Mb of RAM to claim and address.
Emm686 reserves stack-space addresses in so-called hi-mem, can't remember
if there is a way to put it in the base-addressed 640 Kb. The hi-mem gets sometimes
fragmented when loaded tsr's or device drivers leave memory that was occupied when
then program initialized. Try to use a clean as possible system. Sometimes adding little
pause's to certain fast polling procedures to see if you can stabelize the situation.
Sometimes the reason is not all obvious !!

Herman.



------------------
You gotta run, and don't loop back.

[Mike Luther]

How much memory of various kinds does your memory test utility show?
When I run 'MEM' at a command line, here is what I show:

752640 bytes total memory
752640 bytes available for DOS
671840 largest executable program size

8781824 bytes total EMS memory
8388608 bytes free EMS memory

2031616 bytes total XMS memory
2031616 bytes available XMS memory
0 bytes available contiguous extended memory
DOS resident in High Memory Area
High Memory Area in use

When you post what you see, a couple suggestions may evolve.

------------------
Mike Luther
[email protected]

[Steve Andrues]

MEM command yields the following results:

Memory Type Total = Used + Free
-------------------- ---------- --------- ----------
Conventional 640K 171K 469K
Upper 0K 0K 0K
Reserved 384K 384K 0K
Extended (XMS)* 31,744K 2,576K 29,168K
-------------------- ---------- --------- ----------
Total Memory 32,768K 3,131K 29,637K

Total Under 1MB 640K 171K 469K

Total Expanded (EMS) 32,064 (32,833,536 bytes)
Free Expanded (EMS)* 29,408 (30,113,792 bytes)

* EMM386 is using XMS memory to simulate EMS memory as needed.
Free EMS memory may change as free XMS memory changes.

Largest executable program size 469K (480,240 bytes)
Largest free upper memory block 0K ( 0 bytes)
MS-DOS is resident in the high memory.

------------------

[Mel Bishop]

Having only 469K for your biggest program size is really low.
One thing you might try:

In your CONFIG.SYS file, DEVICEHIGH all your device drivers,
i,e, "devicehigh = ANSY.SYS". Be sure to load EMM386 and the
other one FIRST.

In your AUTOEXEC.BAT, Load High (LH) your other stuff, i.e.,
"LH MSCDEX.EXE".

This will put most, of not all, of your system file in the upper
memory region and free up a hoop-lah of conventional memory.


------------------

[Lance Edmonds]

Or you could just REM out all the unnecessary drivers such as ANSI, MSCDEX (unless CDRom access is absolutely essential), etc, or modify your CONFIG.SYS fiel so that it produces boot-menu offering a choice of "minimalistic" and "load everything"... the 6.2x docs show how to do it using square brackets to name the sections, etc.

That said, there were a number of buggy HIMEM and EMM386 versions around (with the same time/date stamp as the "fixed" versions!). Therefore, a good test would be to (at least temporarily) replace the HIMEM and EMM386 files with versions from, for example, a Windows 3.1x installation, etc.

Yet another idea could be to use a QEMM memory manager instead -- it should even be able to optimize memory use for you, much like MEMMAKER does.

(QEMM tip: avoid Stealth mode if at all possible -- it seems to cause more problems than it fixes!)


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>