Exult Forum

Is Exult complete? Will I be able to complete Ultima VII with all the original features or is it missing anything? What does Exult add to the game?

Will I be able to complete Ultima VII

Yes; you can complete U7 (with or without FoV) and SI (with or without SS).

with all the original features or is it missing anything?

Hard to say. Certainly there are things missing but, with equal certainty, they will not be apparent. The most apparent change is the cheat system, which is not identical to the original.

What does Exult add to the game?

Lots and lots of things. For example: new (and configurable) key commands (you can see the spell book by pressing 'B', or view the time by pressing 'W' if you have the watch); the notebook (you can record your travels through Britannia; press 'N' to open it); if you have SI, you can enable paperdolls in BG; etc. Overall, the game experience is much better (IMO).

...and there's the new 'savegame' screen, FAR better than the original.

I second that one

Serpent Isle paperdolling system ported to Black Gate: that's my favourite feature!

I've played through the original and Exult-ed version many times and there appears to be nothing missing, only cool stuff added.

The only thing I miss is the "Room of the dead", where the dead bodies go. Now they just go poof.

I spoke about some of these features you mentioned in a short Exult Review I wrote almost 3 years ago, if anyone wants to take a look.

About a year ago, I finally got Exult up and running. Ultima VII was the only Ultima I hadn't played (I was running OS/2 at that time, and it wouldn't run under that do to the infamous Voodoo memory manager), so I used Exult to play BG and SI through to completion without consulting cheat guides or doing anything odd, so it's definitely possible to play the games through to completion. I later discovered that there were a couple of very nice features in Exult that weren't in the original (key handling, for the most part), but nothing that interfered with gameplay.

What's paperdoll?

This is:

http://exult.info/images/screenshots/bgpaper.png

And also explained in the docs http://exult.info/docs.php#terms. I recommend reading the Documentation and the FAQ.

... and player-made patches that fix plot holes and other original problems.

All very tempting, but I have played U7 until it coloured all my nightmares. Movement involved holding down one of the mouse buttons, and I developed hand cramp that took eighteen months to subside.

What would bring me back would be a radical perspective change such as the 3D port, and I encourage any developers with the energy and time to complete the 3D models set.

With a complete set of 3D models, however crude, the game can be played in this perspective. Better models can always be added afterwards.

I have a question to ask about Ultima 7's memory manager. Why exactly was it made that way? I know that it was terribly hectic to work with even when I had a pure Dos to work with back in the mid 90's (thankfully, a boot disk fixed the problems that I had at that time and now you guys are there for support! )

Anyway, I would once again give my praises for you people in making Exult, since I thought I'd never play the game again after I had my PC updated and even making a boot disk didn't seem to help.

Speaking of which, this puts me in the mood for playing Ultima 7 and finishing it once more! I wonder, which part should I play? The first or the second...

You'd have to ask someone who worked at Origin for the real answer, but I can guess. Back then, DOS didn't make it easy to use more than 640K of RAM. There was a commercial memory extender, PharLap386, but it required per-seat licensing.

Hmm, it's funny that you say it was difficult to work with more than 640K of RAM. When I got my first 386 PC way way back in 1990 (and back then it was state of the art) it had 1MB of RAM just fine. A couple of years later, there were friends of mine who had 4 or even 8 MBs with their computers (all working on MS-DOS) without much of a problem.

One thing that I remember about playing Ultima 7 on my old 386 (many years after I first got it) is that it was very slow. My computer was none too powerful by the time I got it, in a way I had no real problem with it since it meant that I had plenty of time to react to what was going on around in the game world. I played it on my dad's PC at his office when he took me there during his nightshifts (when most people were away and I could play on their PCs) the game was mind numbingly fast and I didn't have time to react to anything. One moment I'm walking by in warp speed and the next thing you know, I get attacked and I'm dead before I can move my mouse around!

Also the game that I had was terribly corrupted, and I thought I'd never get a clean copy of the game... until I found the Ultima collection at my local computer shop. My dad knew I loved the game and since it was in the discount bin (at a luducriously low price) he bought it for me. So I finally had an uncorrupted game to play with that DID crash constantly and didn't wreck some stuff on my PC and didn't need me continually starting over and over again because of the bugs. Thank goodness for bargain bin games!

You likely owned a 386 with a full meg of memory, but only applications with memory managers could access the memory. Windows 3.1 had a memory manager for instance.

DOS programs without a seperate memory manager however could only access 640k of memory.

That is why Ultima 7 had its own memory manager.

Here goes a full account of the subjects: both, about DOS only allowing 640kB -- technically wrong -- and the principles behind the Voodoo memory manager -- those have been widely known and used by many (assembly) programmers independently.

Warning: this might be too long and too technical for some.

First, let's see about the 640kB limit. It should come as a surprise to many that it is due to the processor architecture of the 8086 processor (aka "XT"), which was a 16-bit processor. The issue here is addressable memory -- if you use a single 16-bit integer (the maximum size a 16-bit processor can manipulate in one clock cycle), and each value of that integer points to 1 byte of memory, you will be limited to 65536 bytes, or 64kB of memory. For this reason, memory in the 8086 was divided into several *segments*, each with 64kB, and you used two 16-bit integers to address memory: the segment *selector* and the *offset*. For a given segment:offset pair, the physical address was segment*16+offset.

But that is not all: not all segment values are allowed. In the 8086, only the first 4 bits of the segment are used, so that the processor had access to a total of 1MB of memory; while this was changed in latter processors, the change was for *protected mode* (more below), not for real mode (again, more below). Thus, there was a processor-defined limit of 1 MB of addressable memory while in real mode. DOS ran in real mode, so it had to obbey this limit.

That is *not* all of it! There still remains the fact that DOS was limited to 640kB of conventional memory, not 1MB. The issue was that the *BIOS* required some of the 1MB of memory for its code and for other things like video memory. It reserved the upper 384kB, to be precise, leaving 640kB for programs. *That*, plius the fact that DOS ran in real mode, is the origin of the 640kB-384kB split of conventional-upper memory, and is the reason why you could not always load everything you wanted into upper memory.

When the 80286 processor came out (aka "286"), sthe "protected mode". The protected mode, unlike the real mode, did not calculate memory address by the formula given above (segment*16+offset). Rather, the segment register was an index in a *descriptor* table, which contained information about the segments of memory (such as the physical address and access rights). Each 64kB-page of memory can be shifted or paged in protected mode -- and in fact was, a lot of times. The OS updated the descriptor table after each such operation, so that the program never knew it happened. Moreover, protected mode had access rights, as I mentioned; basically, you could have read-only memory which would reject all write attempts with an error. None of these characteristics are present for the real mode; you have read/write access to all addressable memory and memory is not paged/shifted by the OS without crashing the program.

While the 80286 real mode was still limited to 1 MB due to backward-compatibility issues, the protected mode could address up to 16 MB of memory. The 640kB-384kB split for the first 1MB of memory was still in effect for protected mode, but now the OS could try to load things in the upper 384kB of memory -- but only the portions which were not used by the BIOS. By the way, the upper 15MB of memory is the "extended memory".

The 80386 processor (aka "386") is the interesting one. It was the first 32-bit processor, and thus featured 32-bit protected mode. The differences are that offsets are expanded to 32-bit integers (doing away with segments for 32-bit mode) and that pages in memory are now 4kB in size, instead of 64kB. The protected mode still uses descriptor tables, which now store the size of each memory block as well (you can now have memory blocks with different sizes). Also, addressable memory in protected mode is now 4GB (due to the use of 32-bit integers); memory above the first 16MB is the "expanded memory".

And the 80386 also introduced a "bug" which was the basis of the Voodoo memory manager: if you switch to protected mode, set the descriptor table to what you want, then return to real mode, the size limit you set remains in place. The memory address will still be calculated by real mode rules (segment*16+offset), but -- with an appropriate descriptor table -- you will be able to access all of the system's memory while in real mode. This mode of operation, while not sanctioned by Intel, has been extensively used; it has many names: Unreal Mode, Flat Real Mode, Voodoo Mode.

What are the advantages of using this? Well, for one you are in real mode. This means that the OS is not constantly paging memory to/from the disk -- which incurs a performance hit which would be unacceptable for a game like U7 (which was already pushing the limits otherwise). It also means that the processor does not have to check your access rights for every write operation, which would also incur a performance hit. It also means that you don't have to write a fully featured memory manager to access extended memory, nor do you have to rely on (slow) BIOS calls to use extended memory. Finally, and just as importantly: interrupts (such as timer interrupts for animations/sounds, or hardware interrupts for mouse and keyboard) are handled in a slower, safer way in protected mode -- another performance hit for a game like U7.

Given the host of benefits, the most likely answer that Origin would give it this: Why *wouldn't* we do it that way?

Something you didn't mention is why that was all a problem trying to run the game under a protected environment.

What the problem is the 'unreal mode' bug only existed in real mode. It did not exist in Virtual86 mode which is used to run real mode applications within a protected mode environment (which is what Windows uses). Oddly enough since the bug was used so much it forced Intel (and all other x86 CPU manufacturers) into including the same bug in all processor revisions (including the latest 64bit cpus), but still, only in Real Mode, not Virtual86 mode.

Wow, now THAT'S an explanation!