There are at least three "cpu.code.big=false;" which are wrong. The cs size should remain set to whatever was the last loaded value.
Here's a source diff that gets Project Angel working.
I doubt that I can make a runtime patch to work around the current behaviour.
A few more...
Dead Flowers by Haujobb (identified): Starts but immediately crashes back to DOS prompt post clearing the screen. This demo requires MMX support.
Blub! II by Abyss (resolved): Hangs shortly after starting, displaying 10 vertical bars. This demo requires unsupported Pentium instruction support, but can be supported by using this patch (thanks Peter).
Montana by Kolor (identified): Hangs with black screen. Non-final version complains of no DPMI in some modes (at least dynamic). Including CWSDPMI.EXE corrects such, but results in same black screen freeze seen otherwise. This demo requires MMX support.
Dead Flowers: DOSBox does not report that MMX is supported when CPUID is used.
There are at least three "cpu.code.big=false;" which are wrong.
Changing this could create a hell lot of problems, dosbox simply does not emulate the descriptor caching like for example bochs does.
[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.
