Thanks for checking this out, makes sense.

the patch wanted to let the demo run on a 386. the problem is that it breaks the check when run on a 486. the proper patch would have zeroed the offset for the branch, so it would work on both.

Hive can't open the s3m.

I made a patch for Hive, but it requires the user to rename the .s3m first, because DOSBox can't handle the a-umlaut chars.

A few additions...

Blasphemy by Fatal Justice (resolved): Crashes to command prompt with a bunch of odd text left on screen. This patch from Ripsaw resolves the issue, apparently due to issues with appropriate population of certain registers.

State 808 by Shock! (resolved): Doesn't seem to initialize the video mode properly at it's second scene. Displays two parallel images rather than presumably an image produced by overlaying them. This can be corrected by running the univbe version included in the demo archive, other univbe versions may not work.

Blaspehmy works when booting real DOS in DOSBox. It creates a child PSP (INT 21/55) and subsequently terminates it (INT 21/4C). Register values saved on the stack by DOS are needed, even though the stack space is not reserved. Setting the stack in the child PSP does not seem to be necessary, but DOS does it.

The attached patch appears to fix the problem; but I have to wonder if Blasphemy is using intended behavior or just exploiting machinations of DOS in an unorthodox fashion. A fix program to run the demo is also attached.

I believe its readme states it doesn't run on some Intel CPUs, so I'm guessing it's doing something odd. Thanks for the insight here, Ripsaw, I'll try your patch later today.

Blasphemy's behaviour is legitimate, and not unusual (the joiner that they use was popular). There might also be a thread about that problem.

Whether legitimate or not, relying on data in unreserved stack space does not seem a very safe practice. Resident programs could easily drop a wrench in the works.

Is it relying on the stack? I think that the only register that it needs is DS, which comes from an internal DOS memory address, saved during the last int 21h call or something.

In DOSBox the process is to push registers onto the stack for an execute, and pop them off for a terminate. Does that not follow DOS? The demo crashes in DOSBox because the registers popped off the stack when terminating are not what they were when the child PSP was created.

On terminate, DOS retrieves the ss:sp that was saved during the int 21h call, and uses that to pop registers. However, the DS register comes from another location, and it is all that the demo needs (I checked).

Blasphemy has an INT 21 handler, but it passes function 4C (terminate) directly to DOS without doing anything "extra". The registers popped off the stack by DOS are not the same as when the child PSP was created, except DS *is* the correct value. Also, DOS is returning to a different address in the demo code than DOSBox does after the terminate, so the termination address differs.

DOSBox handles the terminate correctly - it vectors through int 22h to the return address. However, DS is zero on return, and not the original value that is needed by the demo. The demo runs perfectly if you restore DS alone.

808State wants to switch from 640x480 to mode 0x155 (presumably a 320xsomething, so half the width) which is currently not supported.

The graphics in State 808 work correctly with machine=svga_s3 if you use the included VESA driver. First run UVCONFIG.EXE and take the defaults, then run UNIVBE.EXE to install the driver. Maybe other versions of UNIVBE also work, but haven't checked.

The univbe version included in the State 808 zip does work, my problem was in using SDD 6.51 which doesn't. Thanks again for the help here Ripsaw.

r3711
Correct Get Extended Shift States; Int 16 call 12 (thanks ripsaw).

Will that resolve Blaspehmy /wo the patch?

No, Blasphemy requires a different patch because of how it runs subprograms. That's nothing to do with the keyboard.
So either ripsaw's patch or I have one, too.
I also made a patch for State 808 so that UniVBE isn't needed.

New buggy demo...

1st Demo II by Smash Designs: Outputs various garbage characters, then a path statement and drops back to the command prompt. Guessing this is related to Pentium support, as I'm running in a build supporting Glide.