[quote="wd"]Changing this could create a hell lot of problems[/quote]
You know this for certain, or you are guessing?
Montana: uses MMX which is not supported by DOSBox.
The Blub! II 256-byter uses unsupported FPU instructions FUCOMI and FUCOMIP introduced on the Pentium Pro (P6). Similar to FUCOM, but set the integer flags instead of the FPU flags with the result of an unordered comparison. Couldn't find examples of instructions that work with integer flags, or I might have attempted to get them working in dyn_fpu_dh at least. Anyway, probably not high on the list of things to add to DOSBox.
Blub! II works and runs at a good speed in the NTVDM. DOSBox can be hit-and-miss with stuff made after 2000...
You know this for certain, or you are guessing?
Simple example: your patch screws v86 mode 64k limiting for far jumps.
I won't even start to try checking what effects such changes may have so
i'll rather not change anything like that just for some strange demo.
I know that v86 is affected, but that code is kind of wrong anyway - the place to set the 64kb limit for v86 mode is in the code that loads any selector, since all segments are 64kb in v86 mode, not just cs.
Well, yes, DOSBox is not intended to be a perfect emulator.
the fucomi instructions simply use the eflags instead of FPU status flags, so instead of c3, it's zf; c1 -> pf, c0 -> cf. It would be easy enough to include that functionality, but it would be yet another core for maybe just this one demo.
Well, yes, DOSBox is not intended to be a perfect emulator.
It's certainly closer to "perfect" without that patch.
Okay, then change line 1006 to:
if (reg_flags & FLAG_VM) cpu.code.big=false;
and now it's more perfect with the patch than without.
--
Blub II: patch is available from my site.
I was only taking this as a simple example when really analyzing the effects
of such a patch, i will NOT go into any details so you can fix up the patch step
by step. I don't care.
Legend has a strange issue: its timing gets thrown off if the timer doesn't have a chance to tick during video mode changes. Real video BIOSes have the same problem if they don't execute enough code with interrupts enabled, or if cycles are too high.
The attached loader program idles after mode changes to simulate BIOS overhead, which also prevents a brief graphical glitch in the 320x480 tweaked mode used for the bouncing blue sphere. The idle loop may be insufficient with more than 8000 cycles, but the demo doesn't need near that much. Run the loader where LEGEND.EXE is located.
The parts before and after the glass spheres are not rendered correctly in DOSBox. The DAC pel mask is used extensively in the effect, which is seldom used in games.
Legend's music in MOD format: Reverie of Truth
wd, that's what we call regression testing, but okay, you're not interested in supporting this thing.
Thanks everyone for the ongoing help here, very much appreciated.
A few additional problematic demos...
hive by fascination (resolved): Crashes /w GUS emulation enabled. to not being able to read it's s3m file which contains a-umlats. Pete's patch resolves such, if the s3m files is renamed to not include the a-umlaut.
Optic Nerve by The Silents (resolved): Reported as working, but under .74 just blanks screen and hangs. It requires XMS and EMS memory settings to be FALSE.
Hive seems to have some problems with protected mode switching. The umlaut characters on the .S3M file might also be an issue if you get that far, but would be easy to work around that.
Optic Nerve works fine with ems=false, xms=false. If you run the OPTICPAT.EXE patch program, it modifies the demo to react differently to CPU identification, causing a crash. So, don't run the patch program.
it modifies the demo to react differently to CPU identification, causing a crash
Do they mis-identify the cpu? Like using some undefined flags behaviour?
Well, it's going through a series of flag tests, but don't know if what it's looking for is an undefined behavior. The purpose of the patch was supposedly to allow the demo to work on a 386, as it would originally only work on a 486. However, it seems that the identification routine comes to the same conclusion with cputype=auto and cputype=386, so perhaps it warrants investigation.
The usual flags tests are described here:
http://www.rcollins.org/ddj/Sep96/Sep96.html
where this one:
http://www.ukcpu.net/Programming/Hardware/x86 … PUID/x86-ID.asp
has a few of the more strange identification routines.
prefetch queue checks may occur as well though they're hard to identify.
Looks to be all about flags, including a dword stack alignment. I've attached a disassembly of the ident routine. It returns 86, 286, 386, or 486 (decimal) in AX. The final "cmp ebx,ecx" results in a 486 return value with cputype=auto and cputype=386.
Do you have the latest svn sources? As coincidentally i've fixed AC flag handling short ago.
But any way the crash happens when a 486 is detected, right? So 486 and auto would be affected.
Ah, with your recent changes it seems to work fine. The original version works with cputype=auto and the modified version works with cputype=386 because a 386 is detected. They could have handled a "wrong" CPU better than crashing, but oh well.
and the modified version works with cputype=386 because a 386 is detected.
But the modified version doesn't work with auto or 486, right? Is that the intended behaviour??
With your flag changes and cputype=386 the original version cleanly exits with a "You need a 486" message. Without the flag changes the original version runs with cputype=386 because it detects a 486, but didn't check to see if it would mess up later as a result.
With your flag changes and cputype=auto (or 486_slow) the patched version crashes because of a conditional jump changed by the patch. Hard to know what the patcher's intention was, but if the conditional jump had been left alone the same message would be displayed (which could have been hacked to "you need a 386", but it wasn't). I suspect the patch simply wasn't tested to see what would happen if used on a 486.
