• Please review our updated Terms and Rules here

PS/2 Model 55SX (8555) unusually slow video output — traced to EMM386. Is there a fix?

L

linoleum

Member
Joined
Nov 10, 2024
Messages
17
I've been trying to understand why my PS/2 Model 55SX (8555) shows noticeably slower video performance compared to my PS/2 Model 30‑286 (8530‑286). Using CheckIt’s video test (BIOS Mode), the 286 consistently scores around 2800 chars/sec, while the 386‑based 55SX only manages 2000 chars/sec.

After reading this post (https://forum.vcfed.org/index.php?threads/ps-2-rom-shadowing.1248362/#post-1387680), it seems the culprit may be EMM386 interfering with the PS/2’s ROM shadowing, which would definitely explain sluggish video memory writes on these MCA systems.

So I ran a few tests:
  • With EMM386: 2000 char /sec
  • Without EMM386: 4400 char /sec (WOW!)
  • With QEMM: 3300 char /sec (but so many things just don't work)
  • With EMM386 excluding E range: 2200 char /sec
  • With EMM386 excluding C000-C400 and E range: 2200 char /sec

For context, I’m running PC‑DOS 6.3. Ideally, I’d like to keep EMM386 enabled so I can use SOFTMPU and still have UMB support to free enough conventional memory for certain games.

At this point it really looks like EMM386 is breaking the PS/2’s ROM shadowing and tanking video performance, but I’m hoping someone here has found a workaround—or at least a configuration that preserves both speed and UMBs on MCA systems.
 
Last edited:
V86 mode is slower, but should not be 50% slower.

Are all those measurements BIOS char/sec? Is direct video char/sec affected?

You can try configuring EMM386 for ROM shadowing: ROM=C000-C7FF (video BIOS) and ROM=F000-FFFF (system BIOS)
 
Plasma said:
V86 mode is slower, but should not be 50% slower.

Are all those measurements BIOS char/sec? Is direct video char/sec affected?

You can try configuring EMM386 for ROM shadowing: ROM=C000-C7FF (video BIOS) and ROM=F000-FFFF (system BIOS)
Click to expand...
Direct Video is slightly affected. Something like 5%...

I gave the ROM settings a try and got the same low results (2000 char/sec).
 
Does PS/2 have the video BIOS at C000 or is it in E000? Might need ROM=E000-FFFF.

HIMEM.SYS also has MACHINE and SHADOWRAM switches that could affect things.
 
Plasma said:
Does PS/2 have the video BIOS at C000 or is it in E000? Might need ROM=E000-FFFF.

HIMEM.SYS also has MACHINE and SHADOWRAM switches that could affect things.
Click to expand...
Good guess regarding HIMEM... I was also looking into this. But, HIMEM automatically identified the system as a PS/2, while SHADOWRAM gave a 33% hit to Direct Video and the same 50% on BIOS Video.
 
Just to put things in perspective… With EMM386 enabled, SimCity Classic takes 38 seconds to scroll from left to right in the Detroit scenario. Disable EMM386, and the same scroll takes only 7 seconds. That’s six times faster — a massive difference.
 
I would try loading EMM386 with NOEMS and X=A000-FFFF. This will effectively disable EMS and UMBs, but still put the CPU in V86 mode. If even that is slow, then there is some larger problem.

Alternatively, you can try BlueMax or Jemm. Jemm port trapping is different from EMM386, but there is a SoftMPU version.
 
Plasma said:
I would try loading EMM386 with NOEMS and X=A000-FFFF. This will effectively disable EMS and UMBs, but still put the CPU in V86 mode. If even that is slow, then there is some larger problem.

Alternatively, you can try BlueMax or Jemm. Jemm port trapping is different from EMM386, but there is a SoftMPU version.
Click to expand...
I also gave the aggressive exclusion and NOEMS a try and it gave me the same results… Same with Jemm…

I forgot to mention that I am using a MCIDE-CF as well… Not sure if that’s relevant info. I tried moving the ROM address everywhere between C000 and D800 and that did not change anything.

I wonder what was IBM’s default (config.sys) setup for their PS/2 386s?!
 
linoleum said:
I also gave the aggressive exclusion and NOEMS a try and it gave me the same results… Same with Jemm…

I forgot to mention that I am using a MCIDE-CF as well… Not sure if that’s relevant info. I tried moving the ROM address everywhere between C000 and D800 and that did not change anything.

I wonder what was IBM’s default (config.sys) setup for their PS/2 386s?!
Click to expand...
I don't know enough about MCA to know if McIDE could be contributing. Can you pull it out entirely and boot from a floppy?
 
I went back and redid most of my tests, and it turns out the culprit isn’t EMM386 (or QEMM or JEMM) after all — it’s SOFTMPU.

Whenever I enabled an EMS manager, I was also loading SOFTMPU at the same time (since that was the whole point of using EMS in the first place). Not exactly the best way to isolate a problem, I know…

What’s interesting is that EMM386 by itself still cuts BIOS text‑mode video speed by about 50%, but it doesn’t tank game performance. In contrast, SOFTMPU absolutely destroys performance, even the version built specifically for JEMM.

I’ll admit it — running General MIDI on an MCA system with a quirky card like the Resound New Wave is a serious edge case. Realistically, SOFTMPU was never designed with this configuration in mind, so I can’t expect it to work reliably.
 
Last edited:
Interesting about SoftMPU. I looked over the code some and it's reprogramming the RTC to 4 KHz and hooking the interrupt with a handler that does a lot of things. So there's quite a bit of overhead there. The rate could probably be chopped down substantially before the jitter is noticeable.

Did you try BlueMAX at all? I'd expect it to have the best chance at not slowing down BIOS access since it's specifically for the PS/2.
 
Plasma said:
Interesting about SoftMPU. I looked over the code some and it's reprogramming the RTC to 4 KHz and hooking the interrupt with a handler that does a lot of things. So there's quite a bit of overhead there. The rate could probably be chopped down substantially before the jitter is noticeable.

Did you try BlueMAX at all? I'd expect it to have the best chance at not slowing down BIOS access since it's specifically for the PS/2.
Click to expand...
Wow, I’d never even heard of BlueMAX before — thanks for the tip.

I gave it a try and it’s impressively well done: fast, stable, and games behave exactly as they should. The Video BIOS score is about 400 chars/sec faster, and Direct Video is roughly 1000/sec faster than EMM386. Compatibility seems excellent… with one exception: SOFTMPU. :rolleyes:

At this point, SOFTMPU would either need to be forced to run regardless of whether it detects QEMM or EMM386, or someone would have to build a very BlueMAX‑specific workaround. Sigh…
 
It would be easy to modify SoftMPU to skip the check, but unfortunately 386MAX/BlueMAX version 6 doesn't have the EMM386-style port trapping interface. Because EMM386 itself didn't have it until mid 1993 (4.46).

I checked the 386MAX source and it is present in the last version, so at least version 8 should work.

I can't find any downloads for BlueMAX 8, but if someone was motivated it should be possible to build it from the 386MAX source by setting CORECODE=U in MAX.MAK.
 
I might give 386MAX 8 a try… Some old forum posts suggest that the BlueMAX optimizations for IBM PS/2 systems might still be present in that version.

If that works, I may have to tweak SOFTMPU’s code so it doesn’t block 386MAX during detection — something Copilot seems pretty comfortable with. I just hope there aren’t manager‑specific quirks baked into SOFTMPU for each memory manager...
 
So, I hope I did the right adjustments in those two files (also attached) to add 386MAX compatibility...

STRINGS.ASM
....
EMMDevice2 DB 'EMMQXXX0',00h
QEMMDevice DB 'QEMM386$',00h
MAX386Device DB '386MAX$',00h
...

TRANS.ASM
...
@@SingleDigit: call NumToChar
mov SBIRQNum,al
; Check if 386MAX is loaded
mov ax,03D00h ; Open file R/O
mov dx, OFFSET MAX386Device ; points to '386MAX$'
int 021h ; Get handle
jnc @@FoundEMM
; Check if QEMM is loaded
...

My darn MASM611 installation is giving me troubles so I can't test it. I am truly punching above my weight here... Ugh...
 

Attachments

For fun (and to satisfy my curiosity), I created a version of SoftMPU that doesn’t check the memory manager… That part worked, but it made 386MAX crash as soon as there was a MIDI port call. So yeah, I need a 386MAX specific version...
 
This 55SX stuff interests me.

Wiki says "BlueMax was a special version designed for the IBM PS/2 with ROM compression to get the most of the Upper Memory Blocks."

Whether this ROM compression stuff is true is another thing...

DPMIONE Documentation File Version 0.91 ? MSDPMI "However, DPMIONE (by Bob Smith based on the 386MAX code) can do it. Currently DPMIONE and 386MAX is also the only DPMI host which supports DPMI 1.0 completely (e.g. uncommitted memory) and they are the main supporter of DPMI 1.0.[12]"
 
Last edited:
linoleum said:
For fun (and to satisfy my curiosity), I created a version of SoftMPU that doesn’t check the memory manager… That part worked, but it made 386MAX crash as soon as there was a MIDI port call. So yeah, I need a 386MAX specific version...
Click to expand...
What version of 386MAX?

ardent-blue said:
Wiki says "BlueMax was a special version designed for the IBM PS/2 with ROM compression to get the most of the Upper Memory Blocks."

Whether this ROM compression stuff is true is another thing...
Click to expand...
The "compression" isn't data compression, but rather removing/shifting things around. Once the system is booted, you can get rid of POST code and ROM BASIC. From what I can tell, the compression code is here. There is a BCF (BIOS Compression File) for each system that defines what gets (re)moved.

There is also a utility to put ROM BASIC in EMS, if you still needed it (PC-DOS required ROM BASIC for IBM QBASIC/EDIT).
 
You must log in or register to reply here.
Back
Top