I'd have to see someone doing that first. Other methods that I have seen did not rely on bit 7 being set at all, they just reset and read and check for 0xaa. If you have an example, then I can think about it.

then perhaps Sami got it backwards, because STMIK waits until bit 7 is clear, then checks if the returned data is the ack. The only way to achieve that in DOSBox right now would be to empty the buffer by calling DSP_ReadData().

the kit resets the card, then it reads (DSP_READ_STATUS) until either bit 7 is cleared or the loop expires. Bad things happen if the loop expires. However, if bit 7 is cleared, then it reads (DSP_READ_DATA) and expects to see 0aah. I would expect that a reset would empty the buffer, and that nothing …

ah, that's a tricky problem, then. Perhaps we can append a call to DSP_ReadData() so that the 0xaa can be read even though the buffer is "empty", because of the static data?

yes, but that 0x7f value will be returned naturally if the sb.dst.out.used index is zero. I made a patch for the SX demo specifically, which pretends that it happened like that. I haven't looked yet at patching DOSBox.

This causes problems for demos that use STMIK (like SX by Substance, and Min Monitor Briner by Syntax Error) because the card never seems to finish the reset. In case anyone is wondering, I'm going through every demo that I've never seen. I'm up to 1995/s. Long way to go. :-)

Real DOS does not coalesce free blocks during a ah=49/int 21 operation, but only during ah=48/4a. This helps performance a little bit, and the behaviour is relied on by ROSETro demo by Overlook. ROSETro resizes an existing block to a smaller amount, in order to create an empty MCB at a particular …

Maybe - according to some messages in the code (once it's fully decrypted), the protection had the option of using a key file that existed on a floppy. The demo doesn't use the file, it just checks for the existence of the drive. If you pretend that the drive is there, then the demo should run.

It's probably one of those "it works on my machine" situations, for a specific video card that the coders had. Anyway, I have a fix for it on my site, now it runs in DOSBox.

Pandemonium demo by DEMANIACS hooks irq 2, which DOSBox does support, then reads port 3c2h, which DOSBox doesn't support (hard-coded return value, instead of toggling bit 7 occasionally). I'll try patching it to use port 3dah instead, but is there a better workaround?

The code exists to run in raw and XMS mode, too, but it doesn't work properly. The documentation says that it requires EMS because they probably couldn't work out what the problem was.

okay, now I understand. JEMM and JEMM. Easy to confuse. The demo works only in VCPI mode because of a bug in the demo. I'll see about making a patch for it.

I disabled EMS to see if JEMM would load. I thought that JEMM games would require JEMM. Anyway, the stack overflow is a bug. So you have a problem of apps exiting because they find VCPI and not v86, and I have a problem of apps exiting because they don't find VCPI at all. :-)

okay, that makes sense, but the register check means that VCPI can't be detected. Then if I disable EMS from dosbox.conf and try to load JEMM, DOSBox crashes with a stack overflow...

While trying to run Reality Impact demo by HALO, which requires EMS (the non-EMS code tries to load selectors before entering protected mode, which of course doesn't work), the VCPI installation check always fails. I see this check for JEMM in ems.cpp: if (((reg_cx==0) && (reg_di==0x0012)) ... This …

That would be "don't work in DOSBox, or on any modern machine". The problem with enabling the 486 behaviour is that some other demos (and other applications) rely on the Pentium behaviour. You'd need a switch (might be slow) or a separate compilation (inconvenient). Or I make more patches. :-)

Since the DOSBox prefetch behaviour is Pentium-style, some old demos don't work anymore. Flight is one of those. The source of the workaround is a bit long to post, so if anyone is interested, it's available from my site (pferrie.tripod.com).

I see that DOSBox does not support int 2e calls. It is used by Oh No demo by Zool (http://www.mbnet.fi/Apaja/Kopioi.asp?Tiedosto=/0/0/OHNO%2EZIP) Here's some hack code to fix that. It's not the proper method but it works. Run this and then you can run the nice demo. .model tiny .386 .code org 100h …