Eric Auer schrieb:
>> Recently I did expand my computer from 1 GB to 2 GB of RAM.
>> At minimal configuration, just with himem and emm386.
> Try updating to HIMEMX and JEMM386, but take care that those
> default to giving you as much RAM as possible, without trying
> to protect DOS apps from the horror of having unbelievably
> much of it ;-). You have various command line options to limit
> available RAM in various ways, when seen through various APIs.
When using this limiters... Are himemx and jemm386 better on the whole
line then himem / emm386? Or does it introduce new problems with legacy
>> FreeDOS KEYB 2.0 (pre4)
>> Critical error: cannot allocate memory.
>> DOS reported error: 8
> For DISPLAY, you would expect XMS to be used, but for KEYB?
> Did you try without EMM386 and/or without HIMEM?
- with himem and without emm386 it was working
- without himem and without emm386 it was working
- with himem and with emm386 but with noems it was working
>> DEVICE=C:\FDOS\BIN\EMM386.EXE MAX=30000 NOEMS
>> When using NOEMS the bug did not appear.
>> (But therefore still others,
>> crashing extenders and such.)
> With NOEMS, there is no page frame, and DOS can use more
> UMB for other things, so the bad area is touched later.
> You should try to find the right X=?-? option for EMM386.
The X=A000-EFFF should be the most compatible and work in any case?
It also wasn't working...
> Modern computers and BIOSes do not always mark reserved
> UMB areas in ways that are visible to EMM386. For example
> MMIO or buffers of PCI controllers could be in UMB areas.
>> The next strange thing is that I couldn't get ctmouse 1.8
>> and 1.9 to work for normally good applications...
> Let me guess, you have USB emulating PS/2 via BIOS support?
I have mouse and keyboard connected both thought real PS/2.
But this was the helping point anyway.
As I am forced to enable either USB keyboard support and/or USB mouse
support in BIOS in order to boot from USB it was enabled (for real, this
is a known bug).
When I boot from eSATA or IDE I must remember to turn off USB
keyboard/mouse in BIOS, then ctmouse/FreeEDIT and keyb are working.
When booting from USB I must have USB keyboard/mouse in BIOS enabled,
then ctmouse/FreeEDIT and keyb are working.
> Did you try CTMOUSE 2.1 already?
Made no difference.
>> shell=c:\fdos\bin\command.com /E:4096 the bug appears
>> shell=c:\fdos\bin\command.com mouse will work again.
> CTMOUSE defaults to using UMB when possible, even if you
> do not use LH, so see above. Also, older versions of the
> CTMOUSE driver even try using ancient UMB interfaces in
> HIMEM (or even without?) but crash later. You either must
> use a command line option for CTMOUSE to tell it that it
> must not use UMB or you have to load EMM386 properly.
>> I would like to prefer to continue to use /E:4096
> How on earth can you have so much in your environment?
Is this a "really" bad or just a side comment?
> Try the MEMORY command to see how much env FreeCOM uses,
> but take other the values with care, some are misleading.
Well, I've googeld myself this setting a while ago because I did run out
of space when using complex batch. It was working well for a long time
and therefore I like to keep it in case it can make no trouble.
> That most likely means that some of your UMB area is bad!
A part of the problem has been solved already.
But when booting with himem only it says "UMB unavailable". Do you think
this would disappear when I downgrade from 2 GB (2x 1 GB bank) back to 1
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
Freedos-user mailing list