I did not mean you MiniMax.

Yeah, I think it's the sensitivity of FC's Second Reality program itself. I remember running it on a real 486DX2-66 and VESA video card about 13 years ago under MS-DOS, and unless my CONFIG.SYS and AUTOEXEC.BAT were configured just right, along with my Pro Audio Spectrum 16 card (with SB emulation TSR driver), the program would actually crash back to DOS or freeze when it got to the cyclonic vectorballs part.

Oh, I've also tried running with the sound off and I still get that problem.

One interesting thing though is that if I run using SB Pro (stereo) or soundblaster (mono) instead of GUS or no sound, the Second Reality program does something different for me under DOSBox 0.72 when it gets to the cyclonic vectorballs part. Instead of garbage characters or that "integer divide by 0" message, it will start skipping sound and then lock up, but the DOSBox window doesn't go blank.

I've also tried deleting both DOSBox 0.72 and Second Reality and reinstalling each from the respective .exe installer and/or ZIP files just to make sure each one didn't have a corrupted file on my system. I still get the same problem, even with DOSBox 0.72's default dosbox.conf file that gets installed.

I'll make a special 2ndreal.conf file and play with the settings some more, reducing them to the least demanding ones and see how it goes.

Looks like there are two potential errors at play so far.

hal : If you were referring to my comment and quote as nitpicking I can only say that I'm only trying to help as best I can (when memory serves).

Yeah, it looks like the issue is with how Second Reality is interacting with the sound driver or expanded memory driver since it behaves differently in the cyclonic vectorballs part depending on the sound device I choose. At least on my system anyway.

Using GUS or No Sound, Second Reality displays garbage/error message and DOSBox 0.72 window goes blank until next sequence. Music, if using GUS, continues playing as normal.

Using SB Pro (stereo) or Soundblaster (mono), Second Reality begins skipping the music when it gets to the cyclonic vectorballs and then locks up inside DOSBox 0.72. No more music or anything. I have to close the DOSBox 0.72 window at that point and restart it.

Second Reality requires 1 MB of EMS memory for Soundblaster, while using the GUS or No Music, I can set XMS, EMS, and UMB all to false and it will still run properly except for that one sequence.

Well works just fine for me with all settings.

I was able to finally get it working under a specific configuration.

By setting the CPU cycles all the way down to 4000 and using the 2ndfix.exe file with GUS emulation and cpu=normal or cpu=auto, the cyclonic vectorballs segment starts and plays fine.

If I try to use cpu=dynamic or cpu=simple the Second Reality program has problems at that one spot as I detailed above.

It seems this program is really sensitive to system timings on my particular PC. It has historically been sensitive to such anyway, even on "real" 486 and DOS machines at least a decade ago.

As long as the CPU cycles are 4000 when the cyclonic vectorballs portion begins it works fine. If it is any higher or lower, like 3000 or 5000, the program exhibits the "crash" behavior above.

I then discovered that I can even start the program with 2ndfix and CPU cycles at something high, like 10000, and as long as I use CTRL-F11 to lower it to 4000 right before the cyclonic vectorballs, that segment starts fine. I can then increase it right back up to 10000 and vectorballs segment continues without any problems. The program continues fine the rest of the way as well at the higher setting. Weird huh?

So, what I've got configured now in my special 2ndreal.conf file is cpu=normal, cycles=10000, cyclesup=6000, cyclesdown=6000 so that I just need to hit CTRL-F11 once to drop down from 10000 to 4000 right before the spinning vectorballs portion. Then once it begins, I hit CTRL-F12 to jump back up to 10000 and it continues fine.

However, that's with GUS emulation and the 2ndfix.exe file.

If I use the regular second.exe or try the SB Pro (stereo) or Soundblaster (mono), it crashes on the vectorballs portion, regardless of CPU cycles setting.

So it looks like something in the initialization code in that segment of the program regarding audio that causes the issues on my particular system. It seems to be all system timing related.

It's interesting that the 2ndfix.exe patch works on my system with the lower CPU timings but the regular second.exe doesn't. It seems related to motherboard timings possibly.

Here's what the readme file for that 2ndfix.exe file states, regarding motherboard timings:

Patch to Second Reality

This patch fixes the slow-down bug in Second Reality:
In some machines (especially new fast ones) the demo seemed
to crawl at an incredibly slow rate (1-5 frames/sec). This
was caused by differences in motherboard timer operation.
Once we found a single motherboard with this bug, we were
able to fix it.

This patch requires the original Second Reality package (files
2NDREAL1.ZIP and 2NDREAL2.ZIP) to run. Just copy the 2NDFIX.EXE
to the same directory you unpacked the original zips and just
execute 2NDFIX and the demo will (hopefully) start.

NOTE: To keep the size of the patch small, we didn't include other
minor bug fixes (like problems with some ATI vga cards in the credits
part) which would require repackaging the whole demo.

signed:
Purple Motion / Future Crew

WonderSlug - you make a big deal out of explaining a lot of unnecessary details. Both wd and I have confirmed that it runs perfectly with standard 0.72 with default settings (except it is a bit sensitive about the path).

I run it on Windows XP Pro, and I think wd runs it on Linux(?).

You will not get much co-operation from here unless you can make either the program or DOSBox crash under similar conditions.

Look at the Zip file I posted. It contains the exact commands used to unpack, install, and run the demo. If you can get the demo to crash with the same setttings, after having made sure that all kinds of dosbox.conf, .dosboxrc and similar files are GONE from your system, then you might attract the interest of the DOSBox authors.

well it´s a tricky piece of code. I can't remember how many times i watched the demo while trying to figure more about it.

Actually, you know what, MiniMax's suggestion in his attached ZIP file really helped a lot.

I moved the 3 files SECOND.EXE, REALITY.FC, and 2NDFIX.EXE to the root dir of the mounted DOSBox drive and now the program executes properly regardless of DOSBOX settings.

So, instead of changing directories into C:\SCENE and running the Second Reality demo from there, the files now exist in C:\ and I run it using the 2ndfix.exe program.

Come to think of it, I vaguely remember having to do the same thing on my old 486DX2-66 DOS 6.0 machine about 12 years ago.

Anyway, under DOSBox 0.72, I can now use SB Pro Stereo, Soundblaster Mono, or GUS emulation with this "fix".

As long as the CPU cycles are at least 8000 to be able to handle the processing required by the program, it works fine all the way throughout. No crashes or anomalies anymore.

Thanks to MiniMax and everyone else for helping me solve this problem!

😀

i remember that on my old P1 with GUS 2nd reality freezed in the vectorball scene also, so i guess 2nd real has some bugs... which can be luckily overpowered as listed above...

Based on what I've seen, Second Reality likes your soundblaster to be setup with an IRQ of 5 rather than 7. When I use 7 on DOSBox on my mac, the sound is choppy and not so great, though bearable. When I change the IRQ for the soundblaster to 5, it works much better. I notice that at least one config posted here is using 7, so it may be worth changing that setting to 5 and then trying it.

To get the vectorball effect working I had to not only move all the files to the root C:\, but also rename 2ndfix.exe to 2.exe (so I would execute C:\2.exe).

The vectorball code appears to use an uninitialized variable on the stack. The stack also contains the full pathname to 2ndfix.exe so that changing the path the initial garbage value for the variable also changes. The code works if you're lucky. If I set the variable to 0 under dosbox debugger, the vectorball effect works regardless of the path.

Do you have memory addresses from dosbox and a real system at hand?
DOS stack changes may be because of IRQs or routines that use more stack
space than dosbox.

I only have memory addresses from dosbox (0.74) heavy debugger. The vector ball code is loaded after the plasma cube and you can alt-pause to the debugger right before or during the vector ball floor fade-in.

The first time the uninitialized variable is read is at instruction 2720:0829 (mov bx,[bp-1C]). This code is part of a loop and a bad initial value causes the instruction at 2720:087B (mov es:[bx+01A4],ax) to e.g. overwrite code with garbage during some loop iterations. The address ss:[bp-1C] was 2EC3:09BA when the path was C:\DEMOS\2NDFIX.EXE (this path was at 2EC3:09F2). A crash causing initial value for [bp-1C] is 0xAD37.