Uni apparently needs a Pentium, because it uses the RDTSC and RDMSR opcodes. It crashes because an invalid opcode exception occurs on RDMSR, which is not implemented. Not sure which MSRs, if any, are emulated. The MSRs being read are ECX==0x12 and ECX==0x13.
wrote:Uni apparently needs a Pentium, because it uses the RDTSC and RDMSR opcodes. It crashes because an invalid opcode exception occurs on RDMSR, which is not implemented. Not sure which MSRs, if any, are emulated. The MSRs being read are ECX==0x12 and ECX==0x13.
Thanks for the info Ripsaw. Tried using cputype=pentium_slow but it didn't help, so I presume the MSRs aren't emulated. I think that explains this comment from the top of the Pouet thread...
"fix available for those who don't have real msr's"
...unfortunately I can't find the mfx_ufix.zip linked there.
Last unaddressed item here would be the "DMA segbound wrapping" console output caused by: Booth 2 by MFX, sexadelic by Byterapers, and Te-2rb by Tpolm. And the crash/hang toward the end of Booth 2, though I think such is unrelated to "DMA segbound wrapping".
DMA segbound wrapping causes an error exit in 0.74, but in SVN it only causes a warning in the console. If warnings are flooding the console and causing slowdowns, try running without it (-noconsole). Don't know if the devs intend to remove the warning for releases.
[quote="ripsaw8080"]Uni apparently needs a Pentium, because it uses the RDTSC and RDMSR opcodes. It crashes because an invalid opcode exception occurs on RDMSR, which is not implemented. Not sure which MSRs, if any, are emulated. The MSRs being read are ECX==0x12 and ECX==0x13.[/quote]
Ha, beat me to it. I was about to post the same finding. The two MSRs are event counters, so a source of random numbers in this case. Easy enough to patch.
Tried hacking the RDMSR instructions to RDTSC, and the demo runs, but jerky.
Strange thing: there is a WRMSR instruction in the executable that writes to the CESR (0x11), which would specify events for the counters, but the instruction is not executed for some reason. According to docs I found, the default event is an internal counter, so I figured the TSC might work, and it does, sorta.
If anyone is interested, the hacked executable is here. Because of the way DOSBox currently implements RDTSC, it may be less jerky with fixed cycles.
wrote:Tried hacking the RDMSR instructions to RDTSC, and the demo runs, but jerky.
Strange thing: there is a WRMSR instruction in the executable that writes to the CESR (0x11), which would specify events for the counters, but the instruction is not executed for some reason. According to docs I found, the default event is an internal counter, so I figured the TSC might work, and it does, sorta.
If anyone is interested, the hacked executable is here. Because of the way DOSBox currently implements RDTSC, it may be less jerky with fixed cycles.
Thanks so much Ripsaw. Your assistance here has been awesome! 😁 Was definitely glad to replay one of the MFX demos I hadn't seen for a long time.
A few other problematic demos...
Juggler 2001 by The coexistence: Works, but only in it's 200 row and fake high-color modes. 240 and 400 row modes seem to fail to initialize properly and play music over mispositioned command line text.
Into the shadows by Triton (resolved): Only starts /w SVGA_S3, or VESA_xxx modes, but then only blanks screen and either hangs, or forces a restart. Outputs "Invalid link state 5800 when reconfiguring MCB chain" to console all the time, and another console message if a restart occurs. I've been unable to catch what the second message was.
For the later one, it seems like patches exist. This site provides DOSBox patches for a number of demos/games.
Juggler 2001 uses specific VESA modes:
200 lines = mode 10Fh
240 lines = mode 136h
400 lines = mode 133h
Mode 10Fh is a VESA standard, but the other modes are not, and tend to vary from one manufacturer to another. Alien Sex Clone does the "correct" thing by scanning all modes for one that has the right characteristics. Juggler compounds the problem by ignoring the error that is returned when it tries to set the unsupported modes, but I suppose that kind of thing is to be expected in a program limited to 4k.
You can, of course, try svga_paradise and svga_et?000 machine types with an appropriate VESA driver to see if the mode numbers happen to align with what is expected.
Into the Shadows fix (and some others) is available from my site:
http://pferrie2.tripod.com/misc/dosbox.htm
The issue is in the way that it uses paging, which would cause severe performance issues in DOSBox if it were supported.
Patch for Reve is now available from my site.
A few more problematic demo...
project angel by Impact Studios: Assembly winner from 1994. Vacillates between accepting and not accepting that setup had been run (vgaonly=no, svga_s3=yes), but fails to start when setup is accepted. Outputting a black screen with a few odd white characters.
legend by Impact Studios: Goes haywire during it's glass orbs scene.
In the angel demo, it seems like things go wrong after some protected mode switching. It occurs inside the INT FA (fallen angel, heh) handler, so it's easy to set a breakpoint there and watch what happens.
BTW, the jerky motion in the hacked Uni demo occurs with SB sound, but with GUS it is smooth. Since the NFO says GUS, perhaps the hack works better than I thought.
Patch for Uni is now available.
Yes, it's smooth with GUS.
One more for today...
Void 3 by Kolor (resolved): Crashes DOSBox with an "Illegal GRP4 Call 5" error. This can be resolved by running it /w CWSDPMI.EXE (i.e. CWSDPMI.EXE VOID-3.COM).
Void 3 - it thinks that DPMI is installed (but it's not) because it checks the registers in the wrong order. Jumps into space and eventually crashes.
Try running CWDPMI first.
Angel - it thinks that it's in 32-bit protected mode when reloading the IDT, but it's not (at least in DOSBox), so it reads the wrong pointer and crashes.
Something funny going on there, I'll take a closer look.
Ah, it's using "huge" mode (32-bit cs selector). The cached value is not honoured by DOSBox.
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.
