DOS ain't dead

an update of Jemm is available. However, if the current version works for you, there is no need to upgrade.

http://www.japheth.de/Download/jemm565b.zip

More details

It has turned out that the reboot strategies ("standard" and "altboot") of Jemm + FD Emm386 are totally different from what MS Emm386 does. What's worse, the Jemm + FD Emm386 "standard" method doesn't work on many machines.

With this update Jemm's "standard" method is fully MS Emm386 compatible.

related link: http://support.microsoft.com/kb/93366

---
MS-DOS forever!

> an update of Jemm is available.
>
> It has turned out that the reboot strategies ("standard" and "altboot") of
> Jemm + FD Emm386 are totally different from what MS Emm386 does. What's
> worse, the Jemm + FD Emm386 "standard" method doesn't work on many
> machines.
>
> With this update Jemm's "standard" method is fully MS Emm386 compatible.
>
> related link: http://support.microsoft.com/kb/93366

Yeah, my old 486 doesn't hang / beep nine times, wait, beep, etc. anymore by default (previously had to use ALTBOOT for Ctrl-Alt-Del to not exhibit such strange behavior).

---
Know your limits.h

one day after Jemm v5.65 has been released, a severe bug in Jemm v5.6x concerning Phar Lab TNT DOS extender applications has been reported. The symptoms are easy to identify: a quick reboot if such an application is launched.

http://www.japheth.de/Download/jemm566b.zip fixes this bug.

---
MS-DOS forever!

> one day after Jemm v5.65 has been released, a severe bug in Jemm v5.6x
> concerning Phar Lab TNT DOS extender applications has been reported. The
> symptoms are easy to identify: a quick reboot if such an application is
> launched.
>
> http://www.japheth.de/Download/jemm566b.zip fixes this bug.

(What uses that freak-o extender, old MASM?? Norton Ghost??? Whatever it is, it's something I don't have, heh.)

Anyways, I've been testing my own mini two-floppy FreeDOS distro (development version, soon to be uploaded) with JEMM, but I have had some problems lately running it (version 5.65 and later 5.66 too). Basically, it would hang (with floppy light "lit up" for endless amounts of time) after loading JEMM, but Devore's old HIMEM + EMM386 worked fine. Obviously, that ain't good.

At first stumble, I turned on VERBOSE ("EPROM at C000", "EPROM at Ce80"), and I can only assume the problems are because of the Ultra IDE BIOS extension for the extra HDs in this P4 computer (since none of my others had problems). I'm fairly certain it's not the DOS kernel (tested two different ones) nor other programs messing with it (F8 / single-stepped). So I started using "X=C000-CFFF VERBOSE", thinking that would work (since "I=TEST X=TEST" didn't do what I hoped).

Then today I got exception 9 (whatever that is) with the latest JEMM. So I ended up using "X=C000-CFFF I=TEST VERBOSE", which apparently doesn't crash or hang or frell up (yet, anyways). So, that seems to be stable enough.

P.S. I don't think it's a bug in JEMM or FreeDOS, actually (though it's possible). Just reporting it here just because it was a minor issue for me.

---
Know your limits.h

> (What uses that freak-o extender, old MASM?? Norton Ghost??? Whatever it
> is, it's something I don't have, heh.)

it's Ontrack "Easy Recovery" and "Data Advisor"

> Anyways, I've been testing my own mini two-floppy FreeDOS distro
> (development version, soon to be uploaded) with JEMM, but I have had some
> problems lately running it (version 5.65 and later 5.66 too). Basically,
> it would hang (with floppy light "lit up" for endless amounts of time)
> after loading JEMM, but Devore's old HIMEM + EMM386 worked fine.
> Obviously, that ain't good.

I have to agree. However, I bet that v5.64 also won't work, while v5.63 most likely will.

> At first stumble, I turned on VERBOSE ("EPROM at C000", "EPROM at Ce80"),
> and I can only assume the problems are because of the Ultra IDE BIOS
> extension for the extra HDs in this P4 computer (since none of my others
> had problems).

Why didn't you reveal earlier that you own such a cool machine with a ROM *not* beginning on a 4 kB page boundary? That's a very good test case, you're engaged as Jemm "number one" tester.

> I'm fairly certain it's not the DOS kernel (tested
> two different ones) nor other programs messing with it (F8 /
> single-stepped). So I started using "X=C000-CFFF VERBOSE", thinking that
> would work (since "I=TEST X=TEST" didn't do what I hoped).
>
> Then today I got exception 9 (whatever that is) with the latest
> JEMM.

Well, X=C000-CFFF should suffice. And exception 9 is "impossible" on P4s.

> So I ended up using "X=C000-CFFF I=TEST VERBOSE", which
> apparently doesn't crash or hang or frell up (yet, anyways). So,
> that seems to be stable enough.

Hmm, I=TEST should make things less stable. If it improves stability, then there might be another bug which somehow "cures" the effects of the first one.

> P.S. I don't think it's a bug in JEMM or FreeDOS, actually (though it's
> possible).

FreeDOS is innocent, but Jemm most likely isn't.

---
MS-DOS forever!

> > (What uses that freak-o extender, old MASM?? Norton Ghost??? Whatever it
> > is, it's something I don't have, heh.)
>
> it's Ontrack "Easy Recovery" and "Data Advisor"

OpenWatcom doesn't even (barely?) support that extender anymore, right? So why would anyone use 'em? Seriously, what advantages did / does it have? (Just curious, feel free to ignore.)

> I have to agree. However, I bet that v5.64 also won't work, while
> v5.63 most likely will.

I don't reboot this P4 much, it's usually used for other purposes. So, I dunno where such a change (if any) occurred.

> > At first stumble, I turned on VERBOSE ("EPROM at C000", "EPROM at
> Ce80"),
> > and I can only assume the problems are because of the Ultra IDE BIOS
> > extension for the extra HDs in this P4 computer (since none of my
> others
> > had problems).
>
> Why didn't you reveal earlier that you own such a cool machine with a ROM
> *not* beginning on a 4 kB page boundary? That's a very good test case,
> you're engaged as Jemm "number one" tester.

My bro added a few extra HDs to this cpu, and that necessitated adding an IDE adapter (which brought about the Ultra IDE BIOS from CMD Technology (c) 2001).

Actually, that causes a bit of instability booting in pure DOS. I can't even press F1 or F11 b/c it does something weird for "Windows 2000" or whatever (lame).

> > Then today I got exception 9 (whatever that is) with the latest
> > JEMM.
>
> Well, X=C000-CFFF should suffice. And exception 9 is "impossible" on P4s.
>

Impossible how? I don't think I remembered that incorrectly. But anyways, I had to keep tweaking because it kept hanging. Only the first time was I able to exit via Esc, the others required reboots.

> > So I ended up using "X=C000-CFFF I=TEST VERBOSE", which
> > apparently doesn't crash or hang or frell up (yet, anyways). So,
> > that seems to be stable enough.
>
> Hmm, I=TEST should make things less stable. If it improves stability, then
> there might be another bug which somehow "cures" the effects of the first
> one.

Obviously, my testing was not 100% exhaustive, so I may have done something wrong. Or it could be something else entirely (stupid Ultra IDE BIOS extension bugs, probably).

> > P.S. I don't think it's a bug in JEMM or FreeDOS, actually (though it's
> > possible).
>
> FreeDOS is innocent, but Jemm most likely isn't.

As much as I shudder when people claim FreeDOS is buggy (vs. non-free DOSes), I have to admit that it does have some slightly minor flaws. Of course, it's strong enough to run most things with no problem, so I never complain. But truth is truth, it's not perfect. But it's still actively developed, so I'm not too worried.

---
Know your limits.h

Please quote only required text! Usually it's not required to quote another quote.

---
Forum admin

> >
> > Well, X=C000-CFFF should suffice. And exception 9 is "impossible" on
> P4s.
> >
>
> Impossible how? I don't think I remembered that incorrectly. But anyways,
> I had to keep tweaking because it kept hanging. Only the first time was I
> able to exit via Esc, the others required reboots.

AFAIR Exception 9 can occur on a 80386 only - not sure about a 80486SX, however. In any case it "cannot" (shouldn't?) occur on Pentiums or better cpus.

If you can repeat this exception, please post it, with CS:EIP of the failure.

---
MS-DOS forever!

> AFAIR Exception 9 can occur on a 80386 only - not sure about a 80486SX,
> however. In any case it "cannot" (shouldn't?) occur on Pentiums or better
> cpus.
>
> If you can repeat this exception, please post it, with CS:EIP of the
> failure.

For the record, I don't reboot this Intel P4 2.52 GHz 512 MB RAM (Win XP Home SP2) cpu much, so I don't get to test my mini distro on it as often as other cpus. Like I said, it has some fancy Ultra IDE BIOS extension due to IDE adaptor (or whatever) in order to allow like three HDs (thanks, bro). I really think that thing is probably the culprit. But just in case not, here goes ... :

Anyways, I was testing for another bug in something else and (no huge surprise) stumbled upon this again:

FYI, this is disk #1, almost entirely the same as online, if you want to try to reproduce this (though I doubt it but who knows). I've hit this twice in two reboots. (Not all of the following info is useful, just being extra detailed just in case. It will not necessarily cause a crash on your own cpus.)

1). "sudoku 5150.puz" (without hitting Enter, already ran it, so it was in history)

I was moving back and forth on the cmdline words via Ctrl-Left and Ctrl-Right, then I wanted to see if (unlike FreeCOM 0.82, disk #2) it deleted to end of cmdline via Ctrl-End, but that resulted in *crash*! This is via the default setup of disk #1: "JEMM386 SB X=C000-CFFF I=TEST VERBOSE" (5.66).

> Jemm386: exception 09 occured at CS:EIP=3206:00000008
> SS:ESP=0010:f8004E04 EBP=00000A5E
> EFL=4B415453 CR0=80000011
> CR2=00000000 EAX=0A400200
> EBX=00000A6A ECX=00000A6A
> EDX=00000006 ESI=00000001
> EDI=00003629

I manually copied all this down to paper. Then, of course, I had to manually turn off (and then on) the computer b/c Ctrl-Alt-Del didn't work (completely frozen). I figured this would be a good time to test "safely", so I used menu option #5 ("JEMM386 NOHI NOVME NOINVLPG X=A000-FFFF VERBOSE"). I don't even remember what caused a crash this time, but it was the same thing ("exception 09") with very very similar reg values (same CS:EIP).

P.S. I know this makes a difference, so I have to admit that I UPX --ultra-brute --lzma COMMAND.COM (FreeCOM 0.84-pre2) and JEMM386.EXE (bad idea??) while KERNEL.SYS (45,616 bytes: Aug. 25, 2007, separately downloadable here) was already UPX'd.

---
Know your limits.h

Is very excelent memory manager. I have only big trouble
on board Intel MB DG965RYCK. totaly boot crash.

My config:

DOS=HIGH,UMB
DEVICE=A:\DOS\jemm386.exe I=TEST NOEMS VERBOSE
DEVICE=A:\DOS\udma.sys /S3
BUFFERS=10
FILES=30
FCBS=4,0
STACKS=9,256
rem DEVICE=A:\DOS\udma2.sys /O
INSTALL=A:\DOS\lbacache.com 8192 FLOP
DEVICE=A:\DOS\ifshlp.sys
LASTDRIVE=Z
SHELL=A:\COMMAND.COM A:\ /E:1024 /P

Petr

EDIT by rr: added {code} tag

> Is very excelent memory manager. I have only big trouble
> on board Intel MB DG965RYCK. totaly boot crash.
>
> My config:
>
> DEVICE=A:\DOS\jemm386.exe I=TEST NOEMS VERBOSE

The absolute safest setup (according to the README.TXT) is this, so try again with it and report what happens:

X=A000-FFFF NOHI NOVME NOINVLPG

Japheth told me that I=TEST could actually make things a little less safe.

> DEVICE=A:\DOS\udma.sys /S3

cache #1 (does both HD and floppy)

> STACKS=9,256

Supposedly can make stuff better (Bio Menace) or worse (according to Eric Auer, I dunno really).

> INSTALL=A:\DOS\lbacache.com 8192 FLOP

cache #2 ?? (you probably don't need this too)

> DEVICE=A:\DOS\ifshlp.sys

Win9x LFN stuff?

> LASTDRIVE=Z

Do you need all those drives? Save some mem, set it to H or P (otherwise default should normally be E).

> SHELL=A:\COMMAND.COM A:\ /E:1024 /P

What, no 4DOS?

---
Know your limits.h

Japheth, also make sure to double-check that JLOAD.EXE works from the cmdline. I seemed to only get it to work via CONFIG.SYS. (Yes, it was UPX'd too, *sigh*, hope that didn't affect it.)

---
Know your limits.h

> I was moving back and forth on the cmdline words via Ctrl-Left and
> Ctrl-Right, then I wanted to see if (unlike FreeCOM 0.82, disk #2) it
> deleted to end of cmdline via Ctrl-End, but that resulted in *crash*! This
> is via the default setup of disk #1: "JEMM386 SB X=C000-CFFF I=TEST
> VERBOSE" (5.66).
>
> > Jemm386: exception 09 occured at CS:EIP=3206:00000008
> > SS:ESP=0010:f8004E04 EBP=00000A5E
> > EFL=4B415453 CR0=80000011
> > CR2=00000000 EAX=0A400200
> > EBX=00000A6A ECX=00000A6A
> > EDX=00000006 ESI=00000001
> > EDI=00003629

this dump is interesting:

EFL=4B415453 is "impossible". In ASCII it is "STAK".

OTOH, 3206 for CS is also very unlikely, but 3206 is a very common value for the flags register (and this value also tells that interrupts are enabled).

So I guess that an IRQ 1 (keyboard interrupt) is occuring in ring 0 protected mode which Jemm seems unable to handle properly. CS in fact is 0008, which is the Jemm ring 0 code selector, but unfortunately the true EIP is not displayed because of Jemm's stack mess.

What's important to know in this context is that Jemm's ring 0 code usually runs with interrupts disabled.

There is a chance that loading 386SWAT can show more details (the EIP register content). Or, if 386SWAT cannot help, a slight modification in Jemm will display this register.

---
MS-DOS forever!

> this dump is interesting:
>
> EFL=4B415453 is "impossible". In ASCII it is "STAK".
>
> OTOH, 3206 for CS is also very unlikely, but 3206 is a very common value
> for the flags register (and this value also tells that interrupts are
> enabled).

For the record, JEMM386 or JEMMEX work fine on my other cpus (P166, 486), yet last night at my aunts' house, seems my disk #1 / JEMM386 didn't like their P4 (HP, 2 Ghz, 512 MB RAM) b/c using JEMM386 at all seemed to scroll really fast / indefinitely with some error msg ("invalid opcode"??) over and over again. It required a manual power down / up via power button (Ctrl-Alt-Del didn't work). That is definitely weird to me since it doesn't do that on other cpus. And it's the same disk image! (I don't think it was corrupted floppy b/c HIMEMX alone or whatever seemed to work fine, and I tried running pretty much everything as expected / successfully.) Of course, this could be my fault with the "I=TEST" or whatever, and I only really tried normal EMS setup and then NOEMS (neither worked), not the "safe" setup.

The other thing I noticed is that it took a lot longer to change video modes than, say, my P166 (but even my own P4 at home seemed to be kinda slow too). Also, not that you care, but the tiny VIEWGIF (which worked everywhere else) didn't work at all (monitor not compatible with that mode?? no idea, actually).

> There is a chance that loading 386SWAT can show more details (the
> EIP register content). Or, if 386SWAT cannot help, a slight
> modification in Jemm will display this register.

Before it crashes? Are you just thinking outloud or actually suggesting I do this preemptively? (Obviously can't do so after the crash.) I dunno, it's all very strange.

---
Know your limits.h

> The other thing I noticed is that it took a lot longer to change video
> modes than, say, my P166 (but even my own P4 at home seemed to be kinda
> slow too).

Is this related to Jemm? Does changing video modes work faster with other EMMs?

> > There is a chance that loading 386SWAT can show more details (the
> > EIP register content). Or, if 386SWAT cannot help, a slight
> > modification in Jemm will display this register.
>
> Before it crashes?

Yes of course. IIRC 386SWAT can be loaded in CONFIG.SYS only.

> Are you just thinking outloud or actually suggesting I do this preemptively?

If you are familiar with 386SWAT it might be a good idea, if no it is possibly not worth the try.

---
MS-DOS forever!

> Is this related to Jemm? Does changing video modes work faster with other
> EMMs?

No, just an observation, I'm using it now, it's probably just an old monitor (ViewSonic 15G, looks old at least, heh).

My aunts' HP Pavillion (HP BIOS v3.21 ?, Intel Pentium 4, 2 Ghz, 512 MB RAM) doesn't like JEMM at all (my FreeDOS bootdisk #1) except with the ultra conservative X=A000-FFFF NOHI NOINVLPG NOVME. Everything else I tried resulting in a constant stream of reg dumps immediately after loading, even before finished booting (I think ... too fast to read, Pause key doesn't work, Ctrl-Alt-Del won't work either). Other computers are much more reliable with JEMM (esp. P166 and 486, work fine). I almost want to speculate, but I won't.

> > > There is a chance that loading 386SWAT can show more details (the
> > > EIP register content). Or, if 386SWAT cannot help, a slight
> > > modification in Jemm will display this register.
> >
> > Before it crashes?
>
> Yes of course. IIRC 386SWAT can be loaded in CONFIG.SYS only.

Yeah, device driver only.

> If you are familiar with 386SWAT it might be a good idea, if no it is
> possibly not worth the try.

I've used it before, but I never "mastered" it or anything. But maybe I'll try. Have to make another bootdisk for other testing anyways.

---
Know your limits.h

> My aunts' HP Pavillion (HP BIOS v3.21 ?, Intel Pentium 4, 2 Ghz, 512 MB
> RAM) doesn't like JEMM at all (my FreeDOS bootdisk #1) except with
> the ultra conservative X=A000-FFFF NOHI NOINVLPG NOVME. Everything
> else I tried resulting in a constant stream of reg dumps immediately after
> loading, even before finished booting (I think ... too fast to read, Pause
> key doesn't work, Ctrl-Alt-Del won't work either). Other computers are
> much more reliable with JEMM (esp. P166 and 486, work fine). I almost want
> to speculate, but I won't.

Jemm has inherited the scan method for free upper memory blocks from FD Emm386. (One addition has been made: it checks for RAM and excludes such regions automatically.) This method is not always sufficient. You can use the GETI15EX tool from HXRT, which displays the reserved regions returned by int 15h, ax=E820h. Usually this gives a good hint what part of the E000-EFFF region is used by the BIOS and hence shouldn't be used. Then exclude this region for Jemm with parameter X=.

---
MS-DOS forever!

Very thanks for your tips, problem still continues. I use only config.sys

X=A000-FFFF NOHI NOVME NOINVLPG

and problem is identical :O(((

Intel on new board use new BIOS.

Petr

EDIT by rr: Please do not top-post!

> Very thanks for your tips, problem still continues. I use only config.sys
>
> X=A000-FFFF NOHI NOVME NOINVLPG
>
> and problem is identical :O(((

if even X=A000-FFFF crashes, there is little left to try:

- boot with a config.sys without Jemm386 (or other EMM), but with Himem
- on the command line, enter "Jemm386 load x=a000-ffff nohi noems"

if this works, there is most likely a problem with one of your drivers in config.sys/autoexec.bat.

---
MS-DOS forever!

I have only JEMM386 on boot floppy disk. (IO.SYS, MSDOS.SYS and Command.com from standard XP format). I need FAT32 support and MS NDIS client for LAN. I do not use secoondary drivers in test configuration. Jemm386 is very excelent on secoond boards, on this do not work correctly.

Petr

EDIT by rr: removed top-post

> I have only JEMM386 on boot floppy disk. (IO.SYS, MSDOS.SYS and Command.com
> from standard XP format). I need FAT32 support and MS NDIS client for LAN.
> I do not use secoondary drivers in test configuration. Jemm386 is very
> excelent on secoond boards, on this do not work correctly.

Okay, you need FAT32: try FreeDOS. More specifically, since JEMM386 doesn't work for you, make sure to try the last pre-JEMM386 FreeDOS EMM386 (aka, Devore's), and see if that works instead. If it does, then you've probably found a new bug in JEMM386.

http://rugxulo.googlepages.com (disk #2 is what you're looking for)

---
Know your limits.h

> make sure to try the last pre-JEMM386 FreeDOS EMM386
> (aka, Devore's), and see if that works instead. If it does, then you've
> probably found a new bug in JEMM386.

The reference for Jemm is MS Emm386 (MS-DOS v6.22 and/or Win9x), not FD Emm386.

---
MS-DOS forever!

> I have only JEMM386 on boot floppy disk. (IO.SYS, MSDOS.SYS and Command.com
> from standard XP format). I need FAT32 support and MS NDIS client for LAN.
> I do not use secoondary drivers in test configuration. Jemm386 is very
> excelent on secoond boards, on this do not work correctly.

Thanks, but is this an answer to my previous post? Did you try to load Jemm386 from the command line?

Please be aware that you boot MS-DOS without the NOAUTO option. Therefore MS-DOS will (try to) load some drivers not mentioned in CONFIG.SYS!

---
MS-DOS forever!

> I was moving back and forth on the cmdline words via Ctrl-Left and
> Ctrl-Right, then I wanted to see if (unlike FreeCOM 0.82, disk #2) it
> deleted to end of cmdline via Ctrl-End, but that resulted in *crash*! This
> is via the default setup of disk #1: "JEMM386 SB X=C000-CFFF I=TEST
> VERBOSE" (5.66).
>
> > Jemm386: exception 09 occured at CS:EIP=3206:00000008
> > SS:ESP=0010:f8004E04 EBP=00000A5E
> > EFL=4B415453 CR0=80000011
> > CR2=00000000 EAX=0A400200
> > EBX=00000A6A ECX=00000A6A
> > EDX=00000006 ESI=00000001
> > EDI=00003629

To track down the "Exception 09" problem I created a preliminary Jemm v5.67 which displays the error code. In your case, this error code will in fact contain EIP, which might give a valuable hint where the source of the problem is located.

http://www.japheth.de/Download/jemm567b.zip

(this version should not be used in general, it is "unstable")

---
MS-DOS forever!

Hi, Japheth

i use only basic configuration clear config.sys:

DOS=HIGH,UMB
DEVICE=A:\DOS\jemm386.exe X=TEST I=TEST SPLIT NOEMS VERBOSE
BUFFERS=10
FILES=30
FCBS=4,0
STACKS=9,256
LASTDRIVE=Z
SHELL=A:\COMMAND.COM A:\ /E:1024 /P



and clear autoexec.bat

EDIT by rr: removed top-post

Do not top-post!

---
Forum admin

> i use only basic configuration clear config.sys:
>
> DOS=HIGH,UMB
> DEVICE=A:\DOS\jemm386.exe X=TEST I=TEST SPLIT NOEMS VERBOSE
> BUFFERS=10
> FILES=30
> FCBS=4,0
> STACKS=9,256
> LASTDRIVE=Z
> SHELL=A:\COMMAND.COM A:\ /E:1024 /P
>
>
>
> and clear autoexec.bat

Ok, thanks for the info! However, I have to repeat my question - it's now the third time and I will give up if it isn't answered this time - : Did you try to load Jemm386 from the command line? Or, in other words, do this:

- remove the "DEVICE=...Jemm386.exe" line in your config.sys
- reboot your machine
- enter
C:\>Jemm386 load x=a000-ffff nohi noems
- see if a crash occurs

If a crash occurs, test MS Emm386.

---
MS-DOS forever!

> - remove the "DEVICE=...Jemm386.exe" line in your config.sys
> - reboot your machine
> - enter
> C:\>Jemm386 load x=a000-ffff nohi noems
> - see if a crash occurs
>
> If a crash occurs, test MS Emm386.

Doesn't Jemm386 ignore some options (e.g. X=?) when using cmdline? And also, why does JEMMEX refuse to load if XMS is already present (unlike JEMM386)? Shouldn't it be able to do the same as JEMM386, which it is intended to eventually replace? Maybe someone needs/wants to run a different XMS manager?

P.S. Tested P4 again somewhat, but no exception yet. I did remove I=TEST, so maybe that accidentally fixed it? (Doubt it.)

> Jemm has inherited the scan method for free upper memory blocks from FD
> Emm386. (One addition has been made: it checks for RAM and excludes such
> regions automatically.) This method is not always sufficient. You can use
> the GETI15EX tool from HXRT, which displays the reserved regions returned
> by int 15h, ax=E820h. Usually this gives a good hint what part of the
> E000-EFFF region is used by the BIOS and hence shouldn't be used. Then
> exclude this region for Jemm with parameter X=.

Er, then decipher this since it's all Greek to me!

> Int 15h, ah=88h, extended memory: 0 kB
> Int 15h, ax=E801h:
> ext. memory below 16 MB: 15360 (0x3C00) KB
> ext. memory above 16 MB: 7927 64 KB blocks = 495 MB [1000000-1FF6FFFF]
> Int 15h, eax=E820h:
> addr 000000000, size 0000A0000, type 1 (available)
> addr 0000F0000, size 000010000, type 2 (reserved)
> addr 000100000, size 01FE77000, type 1 (available)
> addr 01FF77000, size 000002000, type 4 (ACPI)
> addr 01FF79000, size 000087000, type 2 (reserved)
> addr 0FEC00000, size 000010000, type 2 (reserved)
> addr 0FEE00000, size 000010000, type 2 (reserved)

---
Know your limits.h

> > Int 15h, ah=88h, extended memory: 0 kB
> > Int 15h, ax=E801h:
> > ext. memory below 16 MB: 15360 (0x3C00) KB
> > ext. memory above 16 MB: 7927 64 KB blocks = 495 MB [1000000-1FF6FFFF]
> > Int 15h, eax=E820h:
> > addr 000000000, size 0000A0000, type 1 (available)
> > addr 0000F0000, size 000010000, type 2 (reserved)
> > addr 000100000, size 01FE77000, type 1 (available)
> > addr 01FF77000, size 000002000, type 4 (ACPI)
> > addr 01FF79000, size 000087000, type 2 (reserved)
> > addr 0FEC00000, size 000010000, type 2 (reserved)
> > addr 0FEE00000, size 000010000, type 2 (reserved)

Looks good, the important line is

> > addr 0000F0000, size 000010000, type 2 (reserved)

which means region E000-EFFF is free to use on this machine.

---
MS-DOS forever!

> Doesn't Jemm386 ignore some options (e.g. X=?) when using cmdline?

If it doesn't accept an option, an error will be displayed.

> And also, why does JEMMEX refuse to load if XMS is already present

because it wants to use its built-in XMS host. This simplifies things, some of the paranoid security checks which Jemm386 does to test the XMS host aren't present in JemmEx.

> Maybe someone needs/wants to run a different XMS manager?

Ok, but since both Jemm386 and JemmEx exist, there's hardly a problem (no, I do not care about the limited space on floppy disks ).

---
MS-DOS forever!

> > Maybe someone needs/wants to run a different XMS manager?
>
> Ok, but since both Jemm386 and JemmEx exist, there's hardly a problem (no,
> I do not care about the limited space on floppy disks ).

I just meant that, if JEMM386 will be discontinued in favor of JEMMEX, it would be nice to allow use of other HIMEMs. That's all!

---
Know your limits.h

Hi. Problem is continous. I test clear config.sys and start jemm386 from command line. XMS manager integrated in io.sys (floppy Windows XP format + DOS system - standard format). I have on this board problem whith udma.sys new driver too (copy, copy and stop). :o(((

> Hi. Problem is continous. I test clear config.sys and start jemm386 from
> command line. XMS manager integrated in io.sys (floppy Windows XP format +
> DOS system - standard format). I have on this board problem whith udma.sys
> new driver too (copy, copy and stop). :o(((

Top-post again, Petr and I will delete any of your postings!

---
Forum admin

> Hi. Problem is continous. I test clear config.sys and start jemm386 from
> command line. XMS manager integrated in io.sys (floppy Windows XP format +
> DOS system - standard format). I have on this board problem whith udma.sys
> new driver too (copy, copy and stop). :o(((

If loading jemm386 from the command line with parameter x=A000-FFFF does crash, try MS Emm386 (or FD Emm386, ...).

---
MS-DOS forever!

> If loading jemm386 from the command line with parameter x=A000-FFFF does
> crash, try MS Emm386 (or FD Emm386, ...).

Download: FreeDOS EMM386 (+ src)

But first, make absolutely sure to not try this:

> DEVICE=A:\DOS\jemm386.exe X=TEST I=TEST SPLIT NOEMS VERBOSE

... but this instead (avoid "?=TEST" and "SPLIT" for now):

> Jemm386 load x=a000-ffff nohi noems

If XMS is already loaded (even with NOAUTO??) by IO.SYS, the real question is: do you even need JEMM? Does the LAN software need EMS or are you just trying to get UMBs? (If the former, how much does it need? If the latter, try UMBPCI.)

Japheth wrote:

> Please be aware that you boot MS-DOS without the NOAUTO option.
> Therefore MS-DOS will (try to) load some drivers not mentioned in CONFIG.SYS!

Petr wrote:

> XMS manager integrated in io.sys

And this is of course considered as "feature" ... thanks

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

I'm trying to use FreeDOS 1.0 with Supermicro P4SCA motherboards. (With P4-3GHz and 1 GB ram ).
Using a USB keyboard does not work on this model motherboard, but works OK on old BX motherboards. On boot-up I get a EMM386 error both with FreeDOS EMM386 and Jemm386 5.66, the PC stops. M$-DOS works fine. JEMM386 throws out 8 weird ascii chracters.
I use default settings, plus srdisk, in fdconfig.sys and autoexec.bat.
I have four of these boards doing the same thing. PS/2 keyboards work OK.

> I'm trying to use FreeDOS 1.0 with Supermicro P4SCA motherboards.
> boot-up I get a EMM386 error both with FreeDOS EMM386 and Jemm386 5.66, the PC stops.

Try older JEMM (5.4x or 5.5x) and hacks mentioned above

> M$-DOS works fine.

Mean EMM386 from M$-DOS ?

> JEMM386 throws out 8 weird ascii chracters.

Screenshot ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> I'm trying to use FreeDOS 1.0 with Supermicro P4SCA motherboards. (With
> P4-3GHz and 1 GB ram ).
> Using a USB keyboard does not work on this model motherboard, but works OK
> on old BX motherboards. On boot-up I get a EMM386 error both with FreeDOS
> EMM386 and Jemm386 5.66, the PC stops. M$-DOS works fine. JEMM386 throws
> out 8 weird ascii chracters.
> I use default settings, plus srdisk, in fdconfig.sys and
> autoexec.bat.
> I have four of these boards doing the same thing. PS/2 keyboards work OK.

your report is confusing:

1. does it run with FreeDOS and without any EMM?
2. does "M$-DOS works fine" mean it runs with MS-DOS + Jemm?
3. what params for Jemm did you use when it crashes?
4. "PS/2 keyboards work OK": how is this related to Jemm's crash?

(Jemm doesn't access the keyboard at all)

---
MS-DOS forever!

> I'm trying to use FreeDOS 1.0 with Supermicro P4SCA motherboards. (With
> P4-3GHz and 1 GB ram ).
> Using a USB keyboard does not work on this model motherboard, but works OK
> on old BX motherboards. On boot-up I get a EMM386 error both with FreeDOS
> EMM386 and Jemm386 5.66, the PC stops. M$-DOS works fine. JEMM386 throws
> out 8 weird ascii chracters.
> I use default settings, plus srdisk, in fdconfig.sys and
> autoexec.bat.
> I have four of these boards doing the same thing. PS/2 keyboards work OK.

Try without SRDISK or CTmouse or anything else like that (for now). Also, report to us what GETI15EX.EXE (from HXRT.ZIP) says. Plus, what MS-DOS are you using? (6.22? 7.10? Makes a big difference.) If you don't need EMS, only want UMBs, try using UMBPCI and XMGR.

---
Know your limits.h