Ideas for running "The Elder Scrolls: Arena" with JEMMEX

[vanfanel]

Hi there

I just discovered that JEMMEX offers superior compatibility vs QEMM, etc

So I was trying to run "The Elder Scrolls: Arena" with it on my Vortex86-based mini computer (Tinyllama2: https://github.com/eivindbohler/tinyllama2)

The game needs EMS.

This is how I have my CONFIG.SYS and AUTOEXEC.BAT (DOS 6.22 here for max compatibility!):

CONFIG.SYS

[MENU]
MENUITEM=EMS, XMS and EMS + drivers
MENUITEM=NOEMS, XMS ONLY + drivers

[EMS]

DOS=HIGH
DEVICE=C:\JEMMEX.EXE X=TEST X2MAX=8192 MAX=8192
SHELL=C:\COMMAND.COM /E:2048 /P

[NOEMS]

DOS=HIGH
DEVICE=C:\JEMMEX.EXE X=TEST X2MAX=8192 MAX=8192 NOEMS
SHELL=C:\COMMAND.COM /E:2048 /P

AUTOEXEC.BAT

@ECHO OFF
PATH=C:\DOS
SET DIRCMD=/A/OGN/P
SET BLASTER=A220 I7 D1 P330 T4
PROMPT $P$G

MODE CON RATE=32 DELAY=1

C:\UNISOUND\UNISOUND.COM /V90 /VW90 /VF90 /VL90 /VP90 /VC0 /VM0

ECHO.

However, if I boot with EMS, Arena simply goes back to the C:> prompt, no errors, nothing.

Any ideas about options or parameters for JEMMEX to get it going, please?

[Baron-von-Riedesel]

Any ideas about options or parameters for JEMMEX to get it going, please?

I don't have that game, so cannot try by myself. You might try MAX=32768 to offer 32 MB EMS, also X=C000-FFFF to ensure no UMB is supplied, and MAXEXT=64M to restrict XMS to 64 MB.

[vanfanel]

@Baron-von-Riedesel Thanks for these ideas! I tried all three parameters.
With X=C000-FFFF, the game says "Not enough EMS available..." and exits immediately.
The other two simply don't make any difference.

The game is freeware, officially published by Bethesda now.
You can get it easily (and LEGALLY) here:
https://gamesnostalgia.com/download/elder-scrolls-arena/1895

It would mean a lot to me to get this one working, really. And since it's a freeware game, you can take a look, should you want to.

[Baron-von-Riedesel]

I tried it - and found no real problems.

I used MS-DOS 7.1 ( Win98SE ) and JemmEx:

DEVICE=C:\DIV\JEMMEX.EXE MAX=32M MIN=48 I=B000-B7FF I=TEST

First, I launched a.exe - the game started, without sound.
Second, I run install.exe, selecting SB16 for sound and music.
For the third try, VSBHDA ( a SBEMU clone ) and CTMOUSE was installed; then ARENA.BAT launched - the game started, with sound and mouse this time, no apparent problems so far.

The machine was a AMD ryzen 3600, with 16 GB and onboard HDA sound.

[vanfanel]

Thanks for more ideas! I have both MS-DOS 6.22 and FREEDOS installs, but not MS-DOS 7.1.
Do you think MS-DOS 7.1 would make any difference? Can you try FREEDOS instead, please?

[Baron-von-Riedesel]

Do you think MS-DOS 7.1 would make any difference?

Very unlikely.

Can you try FREEDOS instead, please?

Perhaps, if I find a USB stick with FreeDOS - might take some time, though ...

[vanfanel]

I am trying to replicate your configuration (instead of making you replicate mine... I don't want to waste your time).

I installed MS-DOS 7.1 from CD image, but upon boot I see:
"EMM386 has detected error #1 in an application at memory address C95E:3FB5.." etc
This is on a TinyLlama v2 (https://www.vogons.org/viewtopic.php?t=84880)
Do you know what could be wrong with DOS 7.1 on this machine? I see you are using DOS 7.1 on an even more advanced machine...

[vanfanel]

I have installed MS-DOS 7.1 to try to replicate your configuration on the TinyLlama, and tried to load JEMMEX with it (latest available release in this repository), but I get this:

[Baron-von-Riedesel]

If JemmEx displays "JemmEx loaded", it has loaded fine and the crash is likely to happen with some driver loaded into an UMB.

To "debug", avoid loading JemmEx in config.sys ( press Shift-F5 in the menu ) and instead load it from the command line, with "JemmEx load /v".

[vanfanel]

To "debug", avoid loading JemmEx in config.sys ( press Shift-F5 in the menu ) and instead load it from the command line, with "JemmEx load /v".

Great, thanks.
I found out that the line causing the error is

DOS=HIGH,UMB

...which I have just after
DEVICE=C:\DIV\JEMMEX.EXE MAX=32M MIN=48 I=B000-B7FF I=TEST

That's strange, isn't it??

[vanfanel]

After removing the DOS=HIGH,UMB, I can boot the system with JEMMEX, and I see this:

Jemmex v5.85 [02/11/23]
System memory found at ec00-efff, region might be in use
Using page frame dc00
Jemmex loaded

...But running Arena's a.exe, the game returns immediately to the DOS prompt and the system hangs.

I can briefly see "DIVIDE ERROR" when running a.exe

[Baron-von-Riedesel]

After removing the DOS=HIGH,UMB

This makes DOS load in conventional memory, reducing that kind of mem to ~ 500 kB. Nevertheless, I also tried that ( MEM.EXE reports 498 kB free mem then ), and a.exe still starts the game.

The problem might be your BIOS - perhaps you should run MEMSTAT, supplied with Jemm, to see what regions in the first MB are marked as "reserved"...

[vanfanel]

This is what MEMSTAT says on my system (the Tinyllama v2). What do you think?
I don't know how to interpret this, I see many reserved areas. Does that mean I should somehow exclude them in JEMMEX?

[Baron-von-Riedesel]

Does that mean I should somehow exclude them in JEMMEX?

No. Only the first MB is interesting here. In your case, the BIOS tells that region F0000-FFFFF is reserved. For Jemmex, this means that region C0000-EFFFF may be potentially used for UMBs and the EMS page frame. Jemm scans that region to exclude ROMS ( usually finding the VGA ROM at C0000 ) and RAM ( displaying a warning and ignore such regions ). IOW, Jemm relies on the BIOS that it reports ALL reserved regions in the first MB - if the BIOS doesn't do that exactly, errors like yours are likely to occur. In that case, you'll have to manually exclude the "missing" reserved regions ( using the X= option ).

[vanfanel]

@Baron-von-Riedesel Ah! So this is a BIOS problem, it seems...
The TinyLlama v2 BIOS is in development. Can you tell me what the problem is so I can tell the BIOS author?

Also, what areas should I exclude in JEMMEX X=... exactly? Or is a BIOS fix needed here even with X=...?

[Baron-von-Riedesel]

Also, what areas should I exclude in JEMMEX X=... exactly?

I don't know ( it's actually a guess only ). You'll have to try - perhaps start with X=E000-EFFF...

[vanfanel]

That doesn't work. What would be the progression?

[eivindbohler]

Hey guys, I'm the maker of the TinyLlama. I am however, not the "author" of its BIOS in the traditional sense. I've taken the Coreboot/SeaBIOS version modified by DMP back in 2013 for the Vortex86EX CPU and enhanced it slightly. Haven't touched any memory mapping.
I took a look at a detailed debug boot log now, and it includes these lines:

Space available for UMB: c8000-ee000, f0000-f31d0
Returned 262144 bytes of ZoneHigh
e820 map has 7 items:
  0: 0000000000000000 - 000000000009fc00 = 1 RAM
  1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED
  2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
  3: 0000000000100000 - 0000000007cc0000 = 1 RAM
  4: 0000000007cc0000 - 0000000007f90000 = 2 RESERVED
  5: 0000000007f90000 - 0000000007fe0000 = 1 RAM
  6: 0000000007fe0000 - 0000000008000000 = 2 RESERVED

Looks like the e820 map is somewhat lacking, but the "space available for UMB" line might be of interest? Try excluding the areas outside of c8000-ee000 perhaps?

[vanfanel]

@eivindbohler Thanks for chiming in!
Do you mean leaving c8000-ee000 only as UMB available to JEMMEX?
The problem is that JEMMEX doesn't seem to provide an option to use a range only...
Shouldn't it be made on the BIOS?

[eivindbohler]

Yeah, ideally every reserved area should be included in the e820 map, but what I meant was try to manually exclude the areas around that "space available for UMB" that aren't already in the map: X=A000-C800 X=EE00-F000

[vanfanel]

Tried passing X=A000-C800 X=EE00-F000 to JEMMEX, but it makes no difference.

[vanfanel]

@Baron-von-Riedesel Are multiple X parameters supported?

[Baron-von-Riedesel]

Are multiple X parameters supported?

Why don't you just try it out? You won't cause any damage. You might also try option NORAM, which causes Jemm not to provide any UMBs ( but it will still search a suitable EMS page frame ).

[vanfanel]

@Baron-von-Riedesel As I said earlier, I already tried X=A000-C800 X=EE00-F000, and also I have just tried NORAM, but it makes no difference: Arena exits immediately with "DIVIDE ERROR".

I have the same configuration as you do: DOS 7.1 and JEMMEX.
Also, I have the exact same copy or Arena that you have.
There's something with the Tinyllama that prevents the game from running on DOS 7.1 / 6.22 (On FreeDOS, the game boots but then hangs after the character creation screen: it doesn't get to the actual gameplay).

[vanfanel]

@eivindbohler I have gathered more information on the TinyLlama memory map using Checkit, please take a look:

Do you think some of those areas should be excluded from Jemmex memory management manually?

Also, there used to be options to manage IRQs in the BIOS: what did those do? Game-breaking bugs could be related to that.

[SenhorFlibble]

I've had a similar problem, and "kind of" found the solution.

Recently I installed FreeDOS in 86Box, which I configured to emulate a 486DX2 PC, and tried to run the freeware floppy version 1.06 of Arena that Bethesda distributed a while ago. But the FreeDOS preset that boots JEMM386 with EMS support would result in the game hanging with a black screen whenever I tried to enter the first dungeon or load a saved game (although the main menu and character generation worked fine). I tried rolling back to the old FreeDOS EMM386 from 2006, but to no avail.

Then I decided to try the Arena CD version 1.07 (also freeware, available from GOG), and it worked just fine in FreeDOS with the same JEMM386 preset. So I guess the solution to running Arena under FreeDOS and/or with JEMM(EX) is to use this version, not the floppy one.

UPD: Version 1.06 actually also works with JEMMEX, please see the comment below.

[SenhorFlibble]

UPD2: Fixed the problem as well!

The trick is to load FreeDOS with JEMMEX (not JEMM386) using the custom parameters that were suggested above:
DEVICE=C:\DIV\JEMMEX.EXE MAX=32M MIN=48 I=B000-B7FF I=TEST

With this, fast travel worked as intended. Thanks! Also, version 1.06 works as well.

Original message follows:

Looks like I've been a bit too hasty with my conclusions.

Version 1.07 works just fine at the first glance; I finished the first dungeon, got to a town, and I can successfully enter buildings and exit the town gate to explore the wilderness. However, when I try to fast travel, the game just hangs. It may continue playing the ambient tune, but there's either a black or a white screen where normally it should play the fast travel animation.

Any ideas what may cause this, and how to solve it? JIC, here's the FreeDOS preset that I use to run Arena:
DEVICE=C:\FreeDOS\BIN\HIMEMX.EXE
DEVICE=C:\FreeDOS\BIN\JEMM386.EXE X=TEST NOVME NOINVLPG

UPD: I tried appending MAX=8M to JEMM386 parameters (JIC the game thinks 32M is too much), now it crashes with this error when I try to fast-travel:

[vanfanel]

@SenhorFlibble Did you try to run the game on MS-DOS (any version) instead of FreeDOS?

I'm doing:
DEVICE=C:\DIV\JEMMEX.EXE MAX=32M MIN=48 I=B000-B7FF I=TEST
just as you and @Baron-von-Riedesel both suggested, but the game goes back to DOS immediately, hanging my keyboard in the process.

MS-DOS seems to be more compatible with some games than FreeDOS (Realms of Arkania 2, for example), so I think it's a better option for DOS games.

[vanfanel]

@Baron-von-Riedesel Elder Scrolls: Arena and Ultima Underworld both fail with JEMMEX (Ultima UW shows a black screen while music plays),
but they DO work correctly with QEMM, doing this in config.sys:

DEVICE=C:\QEMM\QEMM386.SYS RAM BE:N RF

The key is using the RAM parameter: without that, the games fail the same as in JEMMEX.
So, maybe JEMMEX could mimic QEMM to let this game work?

I have QEMM of course, but I'd prefer JEMMEX to be my choice since it's free and opensource :)

[Baron-von-Riedesel]

But isn't the RAM option just there to tell Qemm that it is to provide UMBs? That's at least the meaning of this parameter in MS Emm386.

[Baron-von-Riedesel]

Also, I tried Ultima Underworld I and II ( found a CD that contains both games ). Both work with Jemmex - however, only UW I has sound, UW II is silent. But this is very likely no Jemm issue, instead might be a VSBHDA incompatibility.

[vanfanel]

@Baron-von-Riedesel That's specially interesting.

Both TES:Arena and UW only seem to work with QEMM only on the Tinyllama, but they work with JEMMEX on your computer.
Do you know what could that mean? If it's not a JEMMEX problem, what could be wrong with the TinyLlama? What does QEMM do with memory that JEMMEX does not? (or viceversa)

[Baron-von-Riedesel]

If it's not a JEMMEX problem, what could be wrong with the TinyLlama?

I don't know.

The best settings of JemmEx for late 80s/early 90s DOS real-mode games using EMS are:

DEVICE=JEMMEX.EXE MAXEXT=14M NODYN MIN=7M I=B000-B7FF

MAXEXT limits XMS to 14MB - so it's ensured that all memory is below the 16MB barrier.
NODYN & MIN makes JemmEx allocate MIN memory for EMS at startup.

Result: a machine with 7 MB EMS and 7 MB XMS, all addresses 24-bit, compatible with ISA DMA.

[vanfanel]

@Baron-von-Riedesel Ok, thanks. I tried DEVICE=JEMMEX.EXE MAXEXT=14M NODYN MIN=7M I=B000-B7FF and I get this on boot:

System memory found at ec00-efff, region might be in use
Using page frame dc00

Could it have to do with the incompatibilities I am seeing on this Vortex86 SOM?
For example, Lemmings 2 should work too but it crashes:

[vanfanel]

If I add X=EC00-EFFF then Lemmings 2 crashes without any Jemmex errors...

Having to add X=EC00-EFFF could be pointing to some memory problem or incompatibility on the system?

[Baron-von-Riedesel]

Lemmings 2 doesn't work on my machines. At best it "hangs", and the debugger shows it loops while accessing the disk with int 25h - I guess some sort of copy protection... using l2-fix doesn't help.

[vanfanel]

Lemmings 2 doesn't work on my machines. At best it "hangs", and the debugger shows it loops while accessing the disk with int 25h - I guess some sort of copy protection... using l2-fix doesn't help.

What machines have you tested JEMMEX+Lemmings 2 on?
That game sure worked on Pentium-class machines back in the 90's.

Also, does it also hang in the "Sound Initializing" message for you?

[Baron-von-Riedesel]

What machines have you tested JEMMEX+Lemmings 2 on?

AMD Ryzen 2 and Intel I5 Gen 3.

Also, does it also hang in the "Sound Initializing" message for you?

No, I tested without sound. It simply hangs after reporting how much memory is free.

However, I can run the game with sound by launching DosBox under HX DOS extender...

[vanfanel]

However, I can run the game with sound by launching DosBox under HX DOS extender...

Do you mean you emulate DOS on DOS to run the game?

[vanfanel]

Also, Lemmings 2 seems unbreakable under DosBOX!
Setting a Pentium class CPU, 80000 cycles, 128MB of RAM, you name it: the game ALWAYS works. Doesn't seem so picky about hardware...

[vanfanel]

Looking at the 0MHz collection (tailored for FPGAs), they seem to to this to load Lemmings 2 on the AO486 core:

DEVICE=C:\DOS\HIMEM.SYS /TESTMEM:OFF                                                                                                   
DOS=HIGH,UMB                                                                                                                           
DEVICE=C:\DOS\EMM386.EXE RAM I=B000-B7FF 8192 FRAME=D000 D=256 I=C800-CDFF X=CE00-CFFF I=D000-EFFF                                     
BUFFERS=20,0                                                                                                                           
FILES=30                                                                                                                               
LASTDRIVE=Z                                                                                                                            
FCBS=4,0

This is the specially interesting part:
FRAME=D000 D=256 I=C800-CDFF X=CE00-CFFF

Any idea on how to know what memory areas should be excluded on other systems?

[Baron-von-Riedesel]

Any idea on how to know what memory areas should be excluded on other systems?

Well, I know what Jemm does:

• First, it calls INT 15h, AX=E820h. If this function doesn't fail, it will tell the memory manager, what areas are "reserved".
• Then it scans the upper region C000-F7FF for ROMs - usually it finds at least the VGA ROM, perhaps also a Network card ROM.
• Finally, it tests the remaining region - in 1 kB steps - if it is writeable - if yes, it's also excluded ( and a warning displayed ).

[vanfanel]

@Baron-von-Riedesel So, if I theorize that INT 15h, AX=E820h is "broken" or doesn't return correct information on the Vertex86 SOM:
-Is there a way/tool to be sure or rule out incorrect INT 15h, AX=E820h ?
-Is there an alternative way to find out areas that should be excluded?

[Baron-von-Riedesel]

Is there a way/tool to be sure or rule out incorrect INT 15h, AX=E820h ?

There's the MEMSTAT.EXE tool contained in the Jemm package.

[vanfanel]

Is there a way/tool to be sure or rule out incorrect INT 15h, AX=E820h ?

There's the MEMSTAT.EXE tool contained in the Jemm package.

Ok, I ran MEMSTAT.EXE and I got this:

conventional memory (Int 12h): 639 kB
XBDA at segment 9fc0, size 1 kB
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: 1790 64 KB blocks = 111 MB [1000000-7fdffff]
Int 15h, eax=E820h:
 address range          size       type 
----------------------------------------------------
000000000-00009fbff      9fc00  1 (available)
00009fc00-00009ffff        400  2 (reserved)
0000f0000-0000fffff      10000  2 (reserved)
000100000-007cbffff    7bc0000  1 (available)
007cc0000-007f8ffff     2d0000  2 (reserved)
007f90000-007fdffff      50000  1 (available)
007fe0000-007ffffff      20000  2 (reserved)
----------------------------------------------------
available: 124 MB, ACPI: 0 kB, rsvd: 3 MB, total: 127 MB

I don't quite know how to interpret that information: Should I explicitly exclude (X=...) any regions on this machine with JEMM/EMM386 by looking at that?

Also, I disabled sound, and with JEMM/EMM386 loaded Lemmings 2 does this:

lem2_ems.mp4

Without JEMM/EMM386, it loads fine.

So, enabling EMS seems to breaks Lemmings 2 graphics... I theorize EMS is overlapping with graphics memory on this system, does that make any sense?

[Baron-von-Riedesel]

Should I explicitly exclude (X=...) any regions on this machine with

No, JemmEx will exclude region F0000-FFFFF automatically.

I theorize EMS is overlapping with graphics memory on this system, does that make any sense?

No, JemmEx will never automatically put the page frame into region A0000-BFFFF. Btw, launching JemmEx from the cmdline will tell you the address of the 64kB page frame.

[vanfanel]

@Baron-von-Riedesel Yes, it says:

System memory found at ec00-efff, region might be in use
Using page frame dc00
Jemmex loaded

I'm out of ideas about Lemmings2+EMS on this system :(

[Baron-von-Riedesel]

Ok, I think we can close this - IMO the problems with Lemmings2 are not specific to Jemm.
For the record:

1. Lemmings2 does a direct sector read ( Int 25h ), expecting drive C: to be a FAT16 partition
2. If Soundblaster is selected as sound device in v86 mode, an exception 0D occurs in Jemm/Qemm ( MS Emm386 hangs ). It's due to a word write access at offset 0xFFFF, something not allowed in true v86 mode ( no problem for DosBox, apparently ).

[vanfanel]

Ok, I think we can close this - IMO the problems with Lemmings2 are not specific to Jemm. For the record:

1. Lemmings2 does a direct sector read ( Int 25h ), expecting drive C: to be a FAT16 partition

2. If Soundblaster is selected as sound device in v86 mode, an exception 0D occurs in Jemm/Qemm ( MS Emm386 hangs ). It's due to a word write access at offset 0xFFFF, something not allowed in true v86 mode ( no problem for DosBox, apparently ).

Hmm.. Maybe the Lemmings 2 executable could be edited with an hex editor to remove the word write access at offset 0xFFFF then??