Is it searching for 512x384 by any chance?

Yes, it actually is searching for 512x384. It doesn't find 512 width, so never saw it test for 384 height afterwards, and the error message says 512x256 (an error in itself, I guess).

Got it to run by adding a mode that it likes:

1{ 0x1b5  ,M_LIN16  ,512 ,384 ,64 ,48 ,8 ,8  ,1 ,0xA0000 ,0x10000,100 ,449 ,128 ,384 ,0   },

Probably didn't get all the params right, and maybe should be double-height and double-width to 1024x768...? Anyway, the demo runs and the GUS sound works.

On my real hardware only the music plays 😠

Thanks for the great feedback so far here everyone. Glad that this discussion may help to identify some DOSBox deficiencies.

ripsaw8080 wrote:

With Zilog there is a PMODE exception that appears to go away with LOADFIX (should always try loadfix with various allocations before reporting a problem). Also saw DOSBox run out of cacheblocks one time, but only the once, so might be random. Normal core can't have a problem with cacheblocks, but might be too slow.

Using "normal" core or a cycle count low enough for my machine to always keep up with (~50000) is a requirement or I consistently get a PMODE crash when it reaches the 3rd or 4th scene (i.e. brown mushroom like objects). Have tried: LOADFIX 1, LOADFIX 127, LOADFIX 63.

Hmm, I get a PMODE (the extender) exception in the "mushroom" section most of the time, but not always; however, it's never happened with LOADFIX.

Still haven't run out of cacheblocks again after several runs, only the one time so far. If you're consistently running out of cacheblocks, maybe fixed cycles or a cycle limit will help. As I understand it, self-modifying code can lead to running out of cacheblocks with the dynamic core, but there could be other reasons.

512x384 modes extrapolated from the 8-bit mode S3VBE20 provides:

1// 512x384 provided by S3VBE20 (only LIN8)
2{ 0x12d  ,M_LIN8  ,512 ,384 ,64 ,48 ,8 ,8  ,1 ,0xA0000 ,0x10000, 80 ,480 ,64 ,384 ,0  },
3{ 0x12e  ,M_LIN15 ,512 ,384 ,64 ,48 ,8 ,8  ,1 ,0xA0000 ,0x10000,160 ,480 ,128,384 ,0  },
4{ 0x12f  ,M_LIN16 ,512 ,384 ,64 ,48 ,8 ,8  ,1 ,0xA0000 ,0x10000,160 ,480 ,128,384 ,0  },
5{ 0x130  ,M_LIN32 ,512 ,384 ,64 ,48 ,8 ,8  ,1 ,0xA0000 ,0x10000, 80 ,480 ,64 ,384 ,0  },

Yes many thanks for the help and the feedback/tests.

At the moment the non working demos are Reve (http://pouet.net/prod.php?which=70) and Uni (http://pouet.net/prod.php?which=690).

I've posted on The DosBox unofficial demo compatibility list but it seems that diskmag Pain itself isn't edited for years.
I'll add these prods at the list if the version of DosBox is updated (still stuck at 0.71).

I've got Alien Sex Clone running by loading unvibe driver 6.51 before execution : http://glennmcc.org/download/sdd/

Got Gus music but the output resultion is quite strange...

@h-a-l-9000: Just out of curiousity, why double-height for 15- and 16-bit modes, but not 8 and 32? With double-height the sphere on the opening title looks like an ellipsoid, and the fingerprints look vertically stretched as well.

Height? The 80 vs 160 is the horizontal total, and these values are twice as high because the S3 chipset expects them that way for 16bpp modes.

OK, but when aspect correction is on, 160 doubles the height of the screen, but with 80 it does not.

Well the aspect correction could use an update. In MB6 it displays 4:3.

kolano wrote:

Have tried: LOADFIX 1, LOADFIX 127, LOADFIX 63.

Maybe you typed those wrong in your post, but just in case, should be like "LOADFIX -1" (with a hyphen), or the allocation size parameter won't be recognized because it could be the name of something to run.

BackSpace wrote:

The output resultion is quite strange...

Something does seem strange in those screen shots. Probably a bit off topic, but how does a 2MB card have 3MB of framebuffer, and then go to 64MB? I see more expected output when using ykhwong's builds.

ripsaw8080 wrote:

kolano wrote:

Have tried: LOADFIX 1, LOADFIX 127, LOADFIX 63.

Maybe you typed those wrong in your post, but just in case, should be like "LOADFIX -1" (with a hyphen), or the allocation size parameter won't be recognized because it could be the name of something to run.

I did mistype that, wasn't paying attention due to using a frontend.

In any case, even when using "LOADFIX -1" before launch I still get the PMODE crash unless using a low cycle rate or the normal core.

That's the location of the framebuffer in physical address space (3GB), not the size of anything.

kolano wrote:

Something does seem strange in those screen shots. Probably a bit off topic, but how does a 2MB card have 3MB of framebuffer, and then go to 64MB? I see more expected output when using ykhwong's builds.

Well i don't have any clues about these video memory amount changes 😁
Edit : Oupppssss h-a-l-9000 give us the reason 😀

Yes the output resolution for Alien Sex Clone seems to be correct/the one expected with the ykhwong's builds.

I think ykhwong has either borrowed the aspect correction stuff from MB6, or done something similar.

@kolano: just to be clear, running out of cacheblocks will cause DOSBox to close with an error to the effect in the console. The PMODE exception will print a message on the screen with the exception info. LOADFIX -1 is only a 1kB allocation and often won't be beneficial, try -10, -20, and so on. Also try the default allocation of 64kB by running LOADFIX with no parameters, that's what I've been using to prevent the PMODE exception.

ripsaw8080 wrote:

@kolano: just to be clear, running out of cacheblocks will cause DOSBox to close with an error to the effect in the console. The PMODE exception will print a message on the screen with the exception info. LOADFIX -1 is only a 1kB allocation and often won't be beneficial, try -10, -20, and so on. Also try the default allocation of 64kB by running LOADFIX with no parameters, that's what I've been using to prevent the PMODE exception.

I can no longer reproduce the other crash I was seeing, so I can't confirm if it was cacheblocks related or not. I continue to see the PMODE crash, seemingly regardless of LOADFIX when using the dynamic core and cycles greater than ~50000. I've attempted using no parameters on LOADFIX as well as the specific values of: 1, 20, 32, 63, 64, 127 (i.e. LOADFIX -1, etc.).

The PMODE exception is intermittent for me, I've just not seen it with LOADFIX yet, but that doesn't mean I won't. Sometimes there's no problem if I do nothing, so countermeasures may have only the appearance of working. However, normal core will definitely prevent running out of cacheblocks. I'll try "cycles auto limit 50000" to see if that works consistently here.