Ah, Magic Carpet again... (;

I've played through the game in Lo-Res mode some days ago (my rig is not fast enough to handle SVGA smoothly), without one single crash. Knowing that MC2 is considered a very buggy game (see the Wikipedia entry on MC2), i was impressed by the stability.

Here's my setup:
- DOSBox 0.70 latest AEP CVS (you should try this first!)
- DOS/32A
- Dynamic core, fixed cycles (the max number of cycles my machine can handle)
- SB16 for sound, General MIDI for music (you should check if the setup program uses the right IRQ, DMA and IO settings - sometimes, setup programs will auto-detect wrong settings)

Hope that helps...

Thanks for the reply!

- DOSBox 0.70 latest AEP CVS (you should try this first!)

I was clueless about this. I'll see if I can get that and see what effect it has.
Edit: Are you referring to the build from here?
http://cvscompile.aep-emu.de/dosbox.htm
I can't get ipxnet commands to work on that build, making it impossible to play networked games. Do I have to get a patch or something?

In general though, now that I have tested it some, it does appear to work better. I did still recreate the crash in single player, but no Illegal Reads occured and I was able to play through 5 levels twenty minutes per level. I attached a screenshot of the crash.

- Dynamic core, fixed cycles (the max number of cycles my machine can handle

I actually tried dynamic core to no avail, but I haven't tried fixed cycles. Once I have the latest AEP CVS this is what I'll mess with first.

And it looks like my sound settings match yours, so hopefully there are no problems there.

I've played through the game in Lo-Res mode some days ago (my rig is not fast enough to handle SVGA smoothly)

So is switching to High-Res mode the same as switching to SVGA mode? Because one thing I noticed while browsing among Dosbox patches were things messing with SVGA modes, and the raw Dosbox 0.70 download has no options regarding SVGA.
Also, there is no reference in Dosbox 0.70 to the emulation of a video card. A video card is actually recommended in the Magic Carpet 2 Readme file. Could this be anything?

Again, thanks for the help, I was beginning to think that I was on my own.

Sorry, i should have included the link to the AEP pages in my post... Yes, i'm referring to that build. Can't say anything about IPX, though, as i haven't tried it yet. You shouldn't need any additional patches with this build. Maybe IPX is broken with the build you've tried - you could wait some days, and download a new build afterwards, to test it (they are building the executable daily AFAIK). You could also try using the AEP build with the SDL DLL's from the official 0.70 DOSBox build (i have to use the original SDL.dll to get DirectDraw to work correctly). For IPX, i'd try to change SDL_net.dll.

By "high-res", i mean the SVGA mode. I'm not quite sure about DOSBox's video card emulation, but AFAIK it emulates a VESA video adapter. You can't change the type of emulated adapter, but there's Ykhwong's build, which allows changing the type of emulated video adapter. Ykhwong's build is quite different from the original and AEP ones, as it contains a lot of special patches. It may be worth to try that one.

You write that your sound settings do match mine, but have you really checked the IRQ, DMA and IO settings? With the MC2 setup application, you have to go through some menus to get to the screen where these settings can be changed. You should double-check these, as sometimes, games will actually work with the wrong settings, but may have problems later on.

You should also try fixed cycles, and finally the DOS32/A extender. For me, DOS32/A is a lot faster than DOS4GW, and it seems to be more stable in DOSBox. For finding the correct cycles-setting, just change cycles=auto entry in dosbox.conf to cycles=10000 or something similar. Start MC2, get into the game, and switch to windowed mode. Now watch your CPU utilization in task manager, and change the cycles with CTRL-F12 and CTRL-F11, until you have close to 100% CPU utilization.

OK, so there's still some things to try for you. Let's see if we can expand the time where you can actually play the game... 😀

So... I have tried most of this stuff. Here is my report.

Unfortunately, I couldn't get the AEP CVS build to work with ipx networking. This is essential, since the whole reason I'm using an emulator to run Magic Carpet 2 is to network games. Otherwise I can play it nearly flawlessly on an old 486.
I tried mixing and matching DLLs, and nothing seemed to enable the IPX commands.

This is a real shame too, since the build is much more consistent and stable with the game. With cycles around 112000 (is this too high?) my CPU hovers near 100%, and crashes take much longer to occur. When combined with dos32a it works even better.

Now, all these same settings on the regular .70 release of Dosbox don't help much, except for the dos32a extension.

I rechecked the sound settings, and they look good from what I can tell.

Now, all this stuff is on an Athlon 64 cpu. On the other computer I'm networking, which has two Opteron cpus, the game is much more stable on regular dosbox .70 (auto cycles, etc.) and regular dos4gw; so I haven't tried any of these things on it. The next thing I'll try is putting the dos32a extension on that computer and manually setting its cycles, just to see if the different dos extensions were speeding up the crash with incompatibility issues. However, I doubt this is a problem.

What I really want to do is get networking working on the AEP build, because from my play in single player it was obvious it was capable of lasting longer. Any ideas?

Oh, and I also still want to try using a non-usb mouse. I saw in another thread that someone's MC2 crash was prevented by just using a non-usb mouse.

I've been playing through this game as well and have been getting the same/ similar crashes. However, I only get the crashes in high res mode. When I switch to low res the crashes stop. I actually remember similar crashes in high res mode back when I was playing this in real DOS, so I thought it was being emulated perfectly. 😀

Interesting. You're right.

I guess it must have been an isolated incident when I got it to crash in lo-res mode, since now I'm able to play indefinitely without a crash as long as I stay in lo-res mode. Even using the regular .70 build of DosBox I haven't gotten a crash in lo-res mode.

And yes, I agree, I have seen the same/similar crashes in Magic Carpet 2 while playing on real Dos on an old 486. Thanks for the tip.

I suspect Magic Carpet 1 & 2 need a Pentium CPU (ideally w/o the FDIV bug) to work correctly.

The game runs through a different path of code if a Pentium CPU (or compatible) is detected at load time.

I suspect the crashes on 486 systems and in DOSBox may be related (perhaps even isolated) to the CPU feature flags, CPU ID, various support instructions, etc

As in the 486 code path does something different, and the code was never considered stable, not even by the games author.

Even on a K6-2 / Cyrix MX it would display the Pentium Logo at load time, and execute different code path. (From memory, It worked on some AMD CPUs too, but I could be recalling it incorrectly and thinking about a Pentium 120).

I am less sure about the Cyrix, but nearly certain about the K6-2, and 100% certain the Pentium's did it (obviously enough, 🤑 ).

PS: The reason I recommended Pentium 120 was because all Pentium CPUs 120 MHz or faster did not have the FDIV bug. (Excluding overclocked CPU that did 😜).

Is it possible to add emulation for such instructions to DOSBox, so it appears as a 85 - 95% Pentium compatible CPU ? .

Using CORE=DYNAMIC, and CYCLES=MAX, I've found it more stable [Search for other Magic Carpet forum threads].

ie: It may do a timing calculation BEFORE switching to Protected Mode, etc

The irony with this is that the game was never stable on the 486 platform, and would crash on several of the first Pentiums (up to and including some families of the Pentium 100) because of the FDIV bug.

However to my knowledge Magic Carpet one uses ZERO x87 instructions.

I know Magic Carpet 2 requires the x87 instructions though.

However the 'Pentium' code path for Magic Carpet 1 (and 2) may require [or expect] the x87 / FPU instructions, but alas I never had such a system.

If anyone has a Pentium 120 - Pentium 233 MXX with an ISA audio solution (not using 16-bit DMA) would they consider playing the game to the end in High Res mode ? [Press R once 3D landscape engine loads to toggle res].

I don't think it will have many issues (if any) on such a hardware configuration.

Is it possible to add emulation for such instructions to DOSBox,
so it appears as a 85 - 95% Pentium compatible CPU ?

Depends on what instructions they use and if it's certain that usage
of this instruction set results in less errors.
The cpuid thing is rather trivial, it's mostly present in dosbox just
set to 486 compatibility only.

The game runs through a different path of code if a Pentium CPU (or compatible) is detected at load time.

Tabris:DarkPeace: how do you know that? Have you debugged the game, or rather both games? I have read that a "Intel Pentium" logo was displayed by MC (1, not 2) when an "original" P5 had been detected, but i believe this has to do with marketing, not with coding... (;

To remind you: the forced rushed release of the buggy MC2 was the reason (or one of the reasons) why Peter Molyneux stopped working together with EA (see here).

The fact is that MC 1 and 2 do not crash (or very rarely) on DOSBox with recent CVS builds, and the correct configuration. After many problems, i was finally able to play through both games recently, with only a few troubles. With MC2 in VGA mode, i did not see a single crash.

Umm, what crap is this about Pentium support and alternate codepaths? I played MC 1 and 2 pretty damn extensively and while the "deedoodoo Pentium Intel Inside swirly" ad was there, neither games had alternate codepaths for Pentium support...as far as I know MC2 just loaded hidden levels (2 I think) that became visible/available for Pentium owners. Athlon owners could also play these levels.

http://www.mobygames.com/game/magic-carpet-2- … he-netherworlds

MC 1 and 2 play fine on DOSBox. I know, I've played them both almost to completion. I play MC2 exclusively in SVGA and have seen not a single crash. I use YHKWONG's CVS - second to latest release.

However to my knowledge Magic Carpet one uses ZERO x87 instructions.

I know Magic Carpet 2 requires the x87 instructions though.

However the 'Pentium' code path for Magic Carpet 1 (and 2) may require [or expect] the x87 / FPU instructions, but alas I never had such a system.

I have to ask again: how do you know this? Did you debug the game? To be honest, i'm more than sceptical about the validity of your claims.

I'm thinking more 'offering' these instructions would result in a different code path being taken and executed.

... and that code path just happens to have less errors.

Some of the stuff they did in the engine really needed a Pentium, and getting it to work on a 486 likely resulted in extra code + diff code path, more like an after thought (except it was planned ahead if you get my gist).

eg: 'OK so this code does this, but the 486 can't do that, so we'll need to figure out how to make some code that the 486 can execute and will do result in 'as identical as possible' execution.

One instruction that comes immediately to mind is RDTSC (it counts clock cycles, and I suspect it was introduced in 5th generation x86 CPUs).

http://www.digitalmars.com/archives/cplusplus/3078.html
http://en.wikipedia.org/wiki/RDTSC

... of course RDTSC is only one example that comes to mind, chances are it was not used in MC1 or MC2, but other 'newer / similar' instructions would have been (in the Pentium code path).

neither games had alternate codepaths for Pentium support

I think this is a misunderstanding, he means for example code paths
during the timer setup where they might use different algorithms
on pentiums compared to lower cpus.
I'll try to figure out if this actually happens with MC2.

ADDiCT wrote:

I have to ask again: how do you know this? Did you debug the game? To be honest, i'm more than sceptical about the validity of your claims.

Because Magic Carpet 1 runs on a Intel 80486 SX-25, and Magic Carpet 2 does not.

- SX series lacks x87 FPU. (Either disabled due to defeat isolated to FPU, or just not present in transistor count 😜).
- DX series integrated x87 FPU into the CPU.

- http://en.wikipedia.org/wiki/486_SX
- http://en.wikipedia.org/wiki/Floating-point_unit
- I know Wiki ain't the best source, but its articles are far easier to read than TechDocs and WhitePapers from Intel or AMD.

MC2 required Q87 software at the least to run on an x86 SX series processor.

Q87 emulated a x87 FPU using EMS memory (for 20 min in the shareware version, I still have old BBS CD-ROMs of shareware, so Q87 it'll be on one of them).

Magic Carpet 2 did not execute on a Intel 80486 SX processor, it requires a x87 FPU to execute.

It is quite obvious pressing 'D' in game (MC2) and comparing the engine feature set to MC1. (eg: Non-Flat Shading, Light Sources, etc).

The spells in MC2 also require Floating Point Arithmetic (Gravity Well, Whirlwind, Maybe new code for Mana Magnet, and the like).

FYI: x86 SX series processors lack a x87 FPU (Floating Point Unit).

I'm not a coder, but trust me : I know x86 hardware.

Heh... Wd, if you have the time... I just think it's a bit ridiculous to chase after a piece of code, just because someone says it _could_ or should be there, without giving any kind of proof or explanation. I mean, this is like i would say "Hey, i'm sure there's a hidden optimization routine in Blood that will make it run 10x faster in DOSBox! I won't tell you why it is there, or how i know about it, but you have to find it and change DOSBox' code to use it. Good luck.". Strange...

Tabris:DarkPeace, that's insightful information, but i still fail to see how you come to the conclusion that MC2 must have different codepaths with processor specific optimizations. I can't follow your logic. Knowing the difference between a SX and a DX processor doesn't necessarily qualify you for making guesses about how games are coded. It's funny that you give in-depth descriptions about 486 processors, when the topic should be Pentium processors, don't you think? (; To be honest, i wouldn't trust your knowledge, but maybe that's just me.

Tabris: please stop the excessive use of boldness. It's a bit like shouting and gets annoying with times (I understand bolding a word to make it stand out more, but doing that with several sentences...).

ADDiCT you'd be amazed just how many different code paths exist within 10 year old 3D engine based systems.

You asked how I know MC1 contains ZERO x87 FPU instructions, while MC2 does, the x87 was not introduced on the Pentium series, so simply attempting to execute both binaries on a i486SX is the easiest way to check.

FYI: Intel never made a Pentium with the FPU disabled.

This was high performance coding best practice until languages like Java became popular.

eg: Code checks CPU feature flags, if given flags are present then different code paths execute at runtime.

There are many ways to implement this:

eg: Check for flags and store them in an array of variables, then check the variables when calling various functions, libraries, loops, etc and execute 'blocks' of code specifically designed to give better performance / detail / precision / quality / etc when given flags are present.

Quite often a library, esp CPU manufacturer supplied ones, will automatically do this. So often the programmer is unaware it is happening (in that scenario, although any skilled programmer / tester would know why a given bug tends to occur on one CPU family / revision and not on others).

Some would even go so far as to optimize for various CPUs, as two different CPUs with [mostly] matching feature flags may be internally different. (MMX implementations are one obvious example, but this concept predates MMX - the input and output are the same, but the process used and the speed between various implementations can, and do, differ).

eg: Compile a block of code for a given CPU family, feature-set, etc - then insert it as ASM to be called if given vars are flagged. Rinse, Wash & Repeat this many times to create some very high performance code. (This process can be automated BTW).

It is quite possible, likely in fact, that a dedicated programmer born when Peter Molyneux was, in: 1959 in the UK, would do this.

It is also quite likely 'manager' types with only a basic understanding of the architecture would dispute the requirement at times, and the testing... Oh, and it looks like Peter Molyneux had disagreements with his short-term employer - wow, what a coincidence. I wonder how many other experienced, dedicated programmers suffered a similar fate. (Hint: Thousands globally).

A more recent example is SSE2 implementation between say the Pentium 4 Northwood, P4 PreScott, and Core 2 Solo (I say solo because the 2nd core has nothing to do with the implementation being different).

Why do you need to be such a sceptic ?

================================================
Quote Source: http://www.mobygames.com/game/magic-carpet-2- … he-netherworlds the

Trivia
Magic Carpet 2 features several, what I think are, somewhat hidden ads for the Intel Pentium processor. In several of the regular levels you can find an entrance to bonus Demon Lord levels. While these Demon Lord are being loaded, briefly a screen with the Intel Inside logo and the message "Pentium processor detected, configuring for optimal performance" is shown. The funny thing is, you also get to see this message when your PC is equipped with an AMD processor.

================================================

Why would such a message appear for AMD CPU owners (note: The person making the claim in the Moby Games Triva did not provide specific a generation AMD CPUs, but it doesn't take a genius to figure out it would be the K6, K6-2, and maybe K5 series AMD processors.

Obviously Magic Carpet 2 looks at CPU features, not CPUID (the wiser of the two methods).

Now the text "...configuring for optimal performance..." - what does that imply ?

No, no, it is just an Advertisement and nothing else.

It is for these reasons Developers, Testers, and Software Support people ask for full system specs, sometimes crash dumps of code in memory, and at the very least a basic system overview when people indicate 'their PC' has a 'potentially unique' problem.

It is not that far fetched at all, and there is no need to be such a sceptic.

The point is, instead of having end users re-compile software, and needing to share 'secret' source code the end source code is more like a fat binary and contains pre-compiled / pre-optimized blocks of code for various CPU families.

If you had a 6th/7th generation processor, and say, the Linux source code, would you only compile it for i386 support and miss out on greater performance due to fear of a few new instructions, or a better/faster way of executing code on a given CPU family ?

- Of course not.

Sorry to 'rant', but it needed to be said.
[/b]

I don't have a debugger here, but they do some CPUID detection.
That pentium logo thing didn't come up though, anybody know when
exactly that should pop in?