search

Baron-von-Riedesel / Jemm

Jemm386 and JemmEx are socalled EMMs ( Expanded Memory Managers ) or, more exactly, V86 monitors.
127 stars 11 forks source link

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

Closed vanfanel closed 4 months ago

vanfanel commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 #01 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 commented 1 year ago

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:

repo3

Baron-von-Riedesel commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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?

repo8

Baron-von-Riedesel commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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

eivindbohler commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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

vanfanel commented 1 year ago

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

Baron-von-Riedesel commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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

checkit1 checkit2

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 commented 10 months ago

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 commented 9 months ago

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: arena_crash

vanfanel commented 4 months ago

@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 commented 4 months ago

@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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

@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 commented 4 months ago

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 commented 4 months ago

@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: jemmex_crash_lem2

vanfanel commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

Well, I know what Jemm does:

vanfanel commented 4 months ago

@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 commented 4 months ago

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 commented 4 months ago

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:

https://github.com/Baron-von-Riedesel/Jemm/assets/837585/6b866193-d5dd-49ce-97a0-61181c97c662

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 commented 4 months ago

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 commented 4 months ago

@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 commented 4 months ago

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 commented 4 months ago

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??