We are looking for treasures in the source code Aladdin

At the time of its release in 1993, Disney's Aladdin on the Sega Genesis (or Mega Drive, if in the early 90s you lived on the other side of the puddle) was an amazingly beautiful game.

Thanks to the use of technology, which later became known as Digicel, the correct choice of middleware and the impressive talent of the authors, Aladdin was able to stand out against other Genesis games of that era. Beautiful hand-drawn graphics Aladdin set a new quality bar for what can be achieved on Genesis hardware. This was made possible not with the help of particularly interesting raster effects or secret hardware techniques, but with a combination of spectacular graphics, design, and the right technology.
')
This unique blend of graphics and technology was the main reason that allowed Aladdin to occupy a special place in the history of video games. Therefore, I was so glad to find the archive with the full source code of the game in the Video Game History Foundation collection! In addition to the invaluable source of data, this archive is an excellent opportunity for me to create standards for preserving source code, tracking tool dependencies and many other process-oriented aspects in VGHF.



In this archive almost all development tools and materials remained intact. I quickly began to combine their fragments, and began to work on obtaining the source code (which is completely written in M68K assembly language) embedded in the working binary file. I will tell you about my travels and about the discoveries made at each of its stages. Including finding a lot of unpublished materials, and even re-implementation of objects and enemies that were removed before the commercial release of the game!

Hope you like tech stories, because I won't hide anything. If you do not like it, then there are pictures (and you can go directly to part 3.0 Hidden treasure)! You can also download a copy of Noesis to explore the project with me. If this tool is unknown to you, then I will briefly explain: it is built on the basis of the framework and helps in reverse engineering and the study of all types of data. It has a fmt_virginmd_chopper.py script that allows you to extract all the Chopper tile data from all known (commercial and other) Aladdin ROM images. The obtained data can be viewed in the Noesis itself. Although he will not allow you to access data that has not reached the release, but you will be able to view the footage and watch how tiles are used in the completed product.

It is also worth noting that Noesis can extract a backup of the Chopper data from the Aladdin demo assembly for CES . In this assembly there are a couple of unique things, including additional sketches that are not available in the assembly during the normal game process.



The demo for CES is labeled Chicago CES, but as noted in the TCRF article on the assembly, the date of June 27, 1993 is shown in the SNASM generated time stamp. This proves that the assembly was created a few weeks after the exhibition.

Referring to the archive of the source code, we can see that part of the source graphics was changed in June, and removed from the ROM in the demo assembly for CES. No conclusions can be drawn from this (we can’t find out if the source graphs have changed since the removal of the Chopper database), but this confirms the idea that a demo assembly for CES could be created from the active development branch on June 27, 1993, and was not a further development of an earlier snapshot of the project. However, for simplicity, when discussing materials related to this build, we will continue to call it “demo build for CES”.

1. Overview

The archive with the game Aladdin looks as if it is someone's working copy of the source code and game data, and not some kind of common repository. The archive lacks some data dependencies, which is a bit surprising, because at some stage the game was going to the same workplace. However, I was able to reproduce the missing data almost without any problems and get a working binary file.

While the content of everything else seems to correspond to retail copies of Aladdin, changes to some source files date back to September 30, 1993. This is ten days later than the build date of the Japanese retail version, released September 20, 1993. There are no noticeable changes to the data, but problems occur because of byte-by-byte comparison due to significantly different assembly conditions.

Very interesting here is that this archive contains a large piece of the original graphic material! Here lies something that has never been in the game. This material is usually collected in a more ideal / compact form with some other tool, and then included in the ROM itself. In the article we will look at all these tools and processes.


An example of the source data frame animation.

Another big discovery in this archive of Aladdin was the large sections of commented code for prototyped and / or remote functions. Nowadays, if a programmer removes hundreds of lines of unused code in a comment, rather than deleting them completely, then the code analysis program will most likely cut it out. But thanks to this amazing practice, after 24 years we will be able to enjoy the possibilities, the enemies and many other things that should have come into play! Take a bite, standards for writing code!

2. Tools

For the entire process, from assembling code to creating and preparing data for use, Aladdin uses a rather voluminous set of tools placed in a convenient MS-DOS environment. This archive allows us to effectively explore the actual content creation process used by Virgin to implement this game. In this section, I will explain what each tool does and outline the chronicle of my research and use of these tools.

2.1. SNASM68K

The old log in the archive says that the source assembler for Aladdin was version 1.29 (or 1.30, as indicated in some code comments) SNASM68K . I already got a little acquainted with SNASM after a brief excursion into the development for the Sega CD many years ago, but I had access to newer versions of this tool. This meant that in order to build the sources I needed to make some changes. The most unpleasant change was that at some point, SNASM decided to switch from "!" and "|" to the OR operator, which led to significant changes in macros. It also required the addition of several branch operators, despite the fact that the memory architecture remained relatively unchanged relative to the commercial binary file.

When studying the code, it became immediately clear that the file called FOLDER.68K was supposed to be the entry point for the assembler. Several variables are defined in this file, something like “build configuration”. Many of the variables conditionally include / exclude code bits and determine which data should be recorded in ROM: PAL or NTSC. Having dealt with this and solved the problems associated with the difference in the versions of SNASM, I tried to run the resulting binary, and was pleased to see this:



This fragment of the screen cheats, which, as it turned out, is active in the retail version. It appears by default when you run this archive code with an updated timestamp added by SNASM. Its appearance at startup also depends on one of these variables “build configuration”.

I happily moved further into the game, but was greeted by a hang when loading the first level. It's time to take up the debugger! So, stop, I do not have a debugger. After a couple of attempts to solve the problem of inserting transitions into myself, in order to narrow the scope of the hang, I decided to stop tormenting the game and see if there are Genesis emulators with built-in debuggers that do not require downloading 50 separate libraries to create your own build with a debugger. At that moment, I stumbled upon a Regen build with the debugger turned on, and it went!

Putting a breakpoint in Regen after the hung state, I saw that the program counter is in an incomprehensible place, the state of the registers are confused, and there is rubbish in the stack, so I could not find the last normal code execution place, even after trying to use the built-in exception handler Aladdin . Then it became clear that there would be no time for fun.

Having created an address scheme using SNASM, in order to understand what was going on, I received an address at a code point that looked like the place where the loading of the level begins. I installed a PC checkpoint at this address and started the program. After stopping at the control point, I continued the program step by step and found that it goes into oblivion somewhere near the ProPack procedure of unpacking into RAM. Namely, when unpacking FLOOR level data. They correspond to their name - this is the lookup table that sets the tiles of the floor level.

I did the unpacking cycle step by step for a long time, without observing any problems, until I finally noticed the destination address. The procedure unpacked the floor data throughout the user's stack. It looks like it's a mistake! I looked at the labels that determine the position of the active floor in the RAM, and indeed, they were right above the user's stack.

As it turned out, there was some kind of magic with macros to get the maximum size of all the unpacked floor tiles and use it to determine the size of the floor area in the RAM. This macro magic in my version of SNASM as a result calculated a great value - 0. I corrected this error and looked for other places in the code where the same magic would be used, and from that moment everything went smoothly. With the superficial passage of the game there were no obvious errors.

2.2. Chopper

Chopper is an unsung hero who became the foundation of what Virgin called Digicel technology. Unfortunately, I don’t have any information about the process used to manually draw graphics and digitize it, except for the fact that at some point the graphics were imported into DeluxePaint Animation . I don’t know if standard hardware / software solutions were used, or Virgin added its own designs. All I know is that after the data entered DeluxePaint Animation, they got it from there Chopper.

Chopper is a fully proprietary interface-driven tool that works based on the native sprite database format. Its main developer was Andy Astor, but it seems that other people were involved in the development. Including David Perry, who invented the Genesis output data format. Unfortunately, there is no Chopper source code in the archive, so we can study its development only from the accompanying documentation.

The main task of Chopper was cutting imported animations into tiles having a size from 1 × 1 to 4 × 4 (including rectangular sizes, in which each tile has a size of 8 × 8 pixels). He had many options for slicing, as well as options for specifying the collision boundaries of each frame of animation and the choice of cutting a frame, a sequence of frames, or an entire database. The interface itself looked like this:



In the picture above, I imported a prisoner (Prisoner), which is excluded from the retail version of the game. We see clear boundaries by which the current frame is cut into groups of tiles. The yellow rectangle represents the boundaries of the frame collision, and each number determines how many times a group of tiles is used.

Although Chopper works with its own database format, it can export tile data to different target formats of an ideal platform with a primary focus on Genesis and SNES. In the case of Aladdin / Genesis Chopper, it writes several .SEG files (from the word Sega, not “segment”, as your internal programmer or Doom map maker would think), which represent the entire volume of raw tile data for each size from 1 × 1 to 4 × 4. Chopper also generates several .68K files, which should be collected as a code and set additional properties of each frame (part number, collision and properties of each part, such as tile size, offset and index). These files also determine the desired order of data attachments, reflecting the final location of the data in ROM and setting all the necessary restrictions on the location of the data tiles themselves.

The Noesis script fmt_virginmd_chopper.py, mentioned above, attempts to find frame data in the expected Genesis format and convert it back to the .SEG file set and the .68K text file that refers to the .SEG files using the same name format as the native Sega Chopper data . You can experiment with a text file to see how changing properties affects the use of tiles as you would on real hardware.

Another interesting aspect of Chopper is that it is configured to search for a single-pixel rectangle to define the boundaries of the animation sequence. I also coded the options option to repeat this in the DeluxePaint Animation importer in Noesis. Therefore, many animation sources look like this:



Many sources contain active image data outside the desired rectangle, which was probably used as a standard for writing notes and comparing. After Chopper imports a sequence with default processing, it looks like this:



For use in the import process, Chopper for the Aladdin game was written another tool that simply processes the native output .68K Chopper for issuing additional frame-by-frame tables / lists. They include a linear list of pointers to each frame. Perhaps this is done because of the desire to increase the frame counter by transitions between pointers, and not by processing a variable size (since there are a different number of parts) of each frame.

2.3. tUME

Aladdin uses the tUME general purpose tile editor . As in any other game of the era that used tUME, Aladdin has its own tUME packer. Packer is a separate tool that exports data into a set of formats that are ideally suited to the platform and a particular game.



In the case of Aladdin, the tUME packer is called “tPJungle”. It is probably named this way because it was intended for use in The Jungle Book. tPJungle creates a lot of files, including block / character data, contour data (which is usually common for levels), search data / floor tiles, various types of room data (depending on whether the level is traditional room or room-picture, like the Genie bonus screen and other cameo screens used in the game), palette and parallax files that allow multiple layers of rooms to refer to character / tile data.

The output of the tUME wrapper is usually then compressed in a separate batch process, after which references to compressed (or in some cases uncompressed) data are manually entered into the .68K file.

Enemies and objects are arranged in accordance with the numbers of their tiles. This means that the tile table bitmap presented below corresponds directly to the table in the code that starts the execution of the spuner / generator of the corresponding object based on the tile index:



There are many unused cells in the table, as well as cells that previously referred to objects that are now deleted (such as prisoner (Prisoner) or sword swallower (Sword Swallower)), which now redirect execution to dummy functions. Unfortunately, remote enemies do not seem to have been added to the tUME sources, that is, apart from the mentions in the design document, we have no information on where and how these enemies should have been located.

2.4. Gems

Aladdin uses the GEMS sound driver, which uses FM and PSG patches to play music. Also in the PAL version there is a separately generated data set. There are no intermediate GEMS sources in our archive, and the code / data generated using GEMS is accompanied by a batch file, which shows that they are copied locally from the network directory. This means that everything we can get from this archive can also be obtained from the retail version of the game by digging into the backup copy of the GEMS sequencer data / samples / patches from the binary file.

However, this archive contains the real Cakewalk MIDI source (used to transmit to the sequencer that transmits GEMS data) and linear PCM samples provided by Tommy Tallarico himself! You can read more about this in section 3.5 Sounds and Music.

2.5. Propack

Many of the Aladdin data types are actively used by Rob Norten's ProPack , including for the data tiles of the gender and character search tables (but not animated / cut). As stated in the article on Sega Retro, the link to which I have just given, only method 1 is used in Aladdin. Due to the large amount of reference documentation for decoders (among others, in 8086 assembly languages, M68K and 6502), I also wrote a decoder implementation for Knowledge.

There are many batch files in the Aladdin archive, which seem to have been manually modified to convert and compress all the necessary data levels, which were included directly in the ROM. I suppose that the process of creating levels was something like this: “change to tUME, save, exit tUME, execute the batch file, build, run the game”.

3.0 Hidden treasure

The most amazing thing about studying this archive was the discovery of a large amount of materials not included in the retail version of the game. I was very surprised that so many things remained unharmed, and I was even more surprised when I found out that the code base still has a bunch of corresponding code (although it is not assembled as a retail ROM image).

Having mastered the Chopper and the rest of the tools, I decided to re-import some of the deleted resources and add different parts of the code for elements such as old object generators, animations and logic of elements (which today are commonly called actors, or entities). Quake). I expanded the ROM size to 4 megabytes (32 megabytes) so that there was enough space in it to return that part of the “film” that was cut on the “editing table” and not to have to carefully choose what I want to return. Part of the code was immediately ready for use, but in other cases I had to tweak and adjust something in order to restore full functionality.

Another amazing bonus found among these files was a copy of the original game design document version 3.3, dated April 27, 1993. I used this document as a reference to deal with the true purpose of the incomplete code and functions that I found in my journey.

I will not describe all the materials here, but I will share the biggest discoveries for today. I also found ready-to-play skeleton animations from the CES demo assembly with additional walking animation. It seems that the creators intended to make it fall in the direction of the player, and then explode. There is no code for this in the archive, and I have not yet become so accustomed to writing a completely new animation / state logic for it, so I left it for the future.

3.1. Bonus Round

Almost first of all, I came across the code of the old genie's bonus round. It explicitly defines the “hand” element, which is a lever of the slot machine, and also uses an additional code for movement and state. I completely returned the genie slot machine code and re-imported all animation dependencies via Chopper. I also noticed that in the source code of the graphics there was an animation of a spinning coin with Jinn, which makes sense considering the theme of the slot machine, so I returned it too. Here is the result:



You may notice that the background does not quite match the lever of the slot machine. Fortunately, I managed to find the source of the tUME map for the background to which it belongs, it was buried in the TRASH directory. I exported the old tUME card using tPJungle and pasted it back into the game:



However, this background has its own problems. The front layer is not completely correct, and there is no logic left in the code that corresponds to the idea of ​​a three-reel slot machine that the background should represent. It’s hard to say, maybe this background didn’t get to the prototyping stage before it got into the cut block, or the code associated with it was completely removed. It is also possible that this copy in TRASH is not the final background that was used before the removal of this thematic bonus round with the slot machine.

To get this bonus game back, we’ll have to fix quite a lot on our own so that it looks logical and matches the original theme of the slot machine. However, we still have all the data that is necessary for a plausible reconstruction of the original idea in the new implementation. The version of this bonus game with the slot machine is described in great detail in the design document of the game. It also describes the game “stone, scissors, paper”, but nowhere is there a trace of its source code or graphics, so it seems that this idea was not even started to be implemented.

3.2. The enemies

Before a commercial release, many enemies were removed from the game. The reasons for the deletion depended, probably, on a specific situation: inconsistency with the design / appearance, lack of development time or limited space in the ROM. Considering how tightly the retail game fits into 2 megabytes (16 megabytes) ROM, we can only guess about the balance of decision making in each case. Some of these enemies were fully working, others demanded love and care for their salvation.

Sword eater

Sword Swallower Sword Swallower is very similar in design to the juggler with daggers (Knife Juggler) and should have become part of the line of enemies at market levels. He sits in one place, pulls from his mouth an endless stream of swords and throws them across the screen. It also took to connect the code of his swords, but it was working without additional modifications. It seems that it acts exactly as in the implementation from the demo assembly for CES.

Prisoner

Prisoner (Prisoner) was supposed to appear on a level with the Sultan's dungeon (Sultan's Dungeon). It is fully completed and has several animation sequences. In standby mode, he cuts the chain off his foot, and when approaching, he begins to swing the core on the chain. He also has a pain / reaction animation that he had to implement from scratch, because there was no trace of the code associated with it. The prisoner also appears in the demo assembly for CES, but in the wrong palette, and there is no response animation in ROM.

Golden monkey

Golden Monkey is a fairly simple enemy that throws an endless stream of gems into a player. In the video, she is shown in the wrong context (in fact, she was supposed to meet in the Cave of Wonders). She no longer has other animations, and no additional code was required for her work.

In the design document, the behavior of the golden monkey is described as similar to the behavior of the statue of Shiva in the finished game.The statue of Shiva also had to become a more interesting enemy, reviving when Iago flies up to her and throws a bubble. It seems that at some point they simply decided to abandon the golden monkey and use the statue of Shiva instead.

Lago flamingo

At the Sultan's Palace level, Iago should have appeared in the form of a flamingo. He walks on the screen on stilts and deals damage to the player when touched.


The sequence of the Iago-Flamingo animation was also present in the ROM demo for CES, although this enemy was not used in the game.

Rolling snake

Although the snake lived to release the game, it was originally supposed to be rolling. In fact, its internal name is ROLLY_SNAKE. I came across a code that argued that she should have skated if after the attack she was close enough to the player. I plugged this code back and saw a rather curious behavior, in which the direction of rolling was very random. Sometimes the snake remained in the “skating” mode even after the completion of the animation. I had to work a little on the correction, and managed to return this attack by rolling to the state in which it looked more logical.


, - , :

, - , , . , , .

, . : , , , . ( ) ROM - CES, , .

3.3.

Several objects related to the Jinn were removed from the game's release, although none of them seemed to have been perfected. These objects were to be used at the Inside the Lamp level and influenced the player’s movement on the map.

Genie hand

A genie's hand is a genie's palm connected to six balls. She moves along a permanent route and carries the player along with her.



- ( ), -:

« » , , . . , , , . .

- , . .

- , . , , .

, , — . .



, - - . , / ( ), ( ) .

:



-:

. , , . , , - , , .

, , - . , , - CES.

3.4.

In the source code there are several digitized sketches. Here, for example, the outline of each frame from the animation of the fall of Aladdin:



In the outline of the second animation of the fall of Aladdin there are more details. The image itself contains specific frames for cycles and holds:



This gives us a little hint of what the process of creating graphics really was. Particularly noteworthy was the animation of Abu, which I had found for the game, which was still in draft:



. , . , , -:

, , , . , - ( — ), .

, «»! ( , ), ( ).

— , , . , , , ( ), , , .

When you return the magic bag, Abu's reaction / behavior depends on the amount of stones that Aladdin spent on the boss. The more jewels were spent, the more violent the monkey’s gestures. If Aladdin does not use stones, then Abu in his characteristic style demonstrates his joy. Most likely, in the version for the cartridge there will be three Abu reactions (joy, equanimity, anger), in the CD version there will be five reactions.

This animation of the fish, also present in the demo assembly for CES, is also preserved along with the finished version of the source code:



She tells us that we have ready-to-play graphics with a mask that is still in draft form and ready for further work, and that part of it was used in the game for the demo assembly. It is unlikely that this would have happened if the process of creating graphics to this point was not incredibly orderly. This shows us a rather interesting workflow!

3.5. Sound and music

GEMS /, : «» Cakewalk MIDI , . «» 8- «» PCM. :

, - PAL-NTSC. , ! 10,4 , :jl87.vmd 8.7honk.vmd 5.2xplode2.vmd 5.8camel2.vmd 8.7finger.vmd 7.3feet2.vmd 7.3feet3.vmd 8.7cash2.vmd 7.3feet5.vmd 8.7

NTSC PAL, GEMS, , GEMS. Aladdin PAL.

, Cakewalk GEMS, , «» PCM , GEMS . Cakewalk ( , GEMS), .



, MIDI GEMS, , , , .

3.6. -

, zip-, zip-. , . - 3.3 27 1993 . : , , , .

, -, , . , .

In general, this document gives us a lot of material with which you can recreate old ideas and opportunities, especially those for which to some extent there is graphics. He also gives us more information about small fragments of graphics for which there are no references in the game / code, for example, like this:



, , . , ( ), . , ROM - CES, , !

, - .

Levels

:

   
 -------------------------------------------------- ----------
1. Marketplace   
2. Desert   1 
3. Marketplace rooftops   2 
4. Prison Escape from Prison No
5. Cave of Wonders (gold) Reach the room with the Monkey Shiva lamp
6 Cave of Wonders (lamp) Take the lamp No
7. Fly out of cave. Escape from the cave. No
8. Inside the lamp Find the Genie No
9. 'Good' Palace Grab Jafar Yago
10. Marketplace To get to the palace Razul 2
11. 'Evil' Palace Destroy Jafar Jafar 

Also there are plans for various levels and bosses for the version of the game on the Sega CD, which we will look at in the Sega CD section. The level structure remained virtually intact, with the exception of a few notable changes:

• Both Gazim and Razul appear at the level with roofs, and at level 1 there is no boss.
• It seems that the passage of the Cave of Wonders is slightly improved and goes into a foot escape leading to the escape on the carpet.
• (Marketplace) , Sultan's Palace Jafar's Palace. .

, , , , , - , - ROM.

. :

• , , , . -!
• - , , , , .
• «-», «» «-».
• / / .
• CD . , - . , , , , , Disney!
  
  
  
  
  
  
  
• On some levels Aladdin was supposed to bring a genie. Looks like I found a couple of animations that seem to be designed for this process.
  
  
  
• Additional waiting animations were planned, even for the cartridge version of the game:
  
  A cloud appears over Aladdin with thoughts of a princess (only after he discovers that the girl on the market square was Jasmine), this underlines that he wants to see her again.
  
  A cloud appears over Aladdin with thoughts of the girl he saved on the market square (only after saving, but before he learns that she is a princess, this may change, depending on how Rasul reappears in the game due to the apple dealer ).
  
  The carpet flies into the frame and gestures invites the player to get acquainted with the program (only after the level in the cave).
• It was planned that when Aladdin’s health falls below a certain level, several scavengers appear on the open-air levels. They are present on the parallax layer and whirl in anticipation of his death.

In general, it seems that the best is left in the finished game, although directional throws and additional throwing objects, as well as purely aesthetic additions, would be fun!

The enemies

Judging by what I found in the original graph (see above), there are quite large differences between what is stated in dizdok and what remains in the finished game. In addition to listing the main list of enemies and their distribution by levels, the document identifies unique enemies within each level.

In many cases, the design defines completely different characteristics and scenarios of the behavior of enemies:

• Low pot-bellied guards were supposed to attack, swinging a stick, and tall, thin guards were to throw knives. In the retail version, they exchanged attacks.
• The large guards, in addition to the ridicule preserved in the release, were to use upper and lower attacks. Aladdin should have been able to sneak under them or jump over these attacks.
• Fat women should have appeared on the market square:
  
  They run left / right, pursued by the mouse, and hit Aladdin, if he does not get out of their way (does not jump). Women can not be killed.
• The circumstances and the pace of the battle with Razul were originally completely different:
  
  Razul must stand on the roof of the prison building. The width of the building takes up about half of the screen, and Razul is visible from behind the wall (only the upper part of his body is visible). On both sides of the roof are pyramids, composed of barrels.
  
  Razul strides forward and backward at the top of the roof. Since the building will be in the middle of the screen, Aladdin is able to climb on its sides using a series of platforms on both sides of the building, at the edges of the screen. The platforms will allow Aladdin to get under Razula, and either to the side of him, or by jumping from the uppermost platform, directly above him. Aladdin will not be able to climb onto the roof.
  
  When Razul gets to the edge of the roof, he pushes a barrel from the edge. The barrel rolls down from platform to platform until it reaches the ground (as in Donkey Kong), then falls into the central hole. Razul should push the barrels once a second or so. Razul continues to roll the barrels until Aladdin reaches the opposite part of the roof, and then runs back to the other side of the roof and again begins to push the barrels.
  
  Razula can only be hit when he runs from one side to the other. When Aladdin is on the uppermost platform, Razul throws knives at him. Throws of knives are performed between pushing the barrels so that Aladdin does not stay in one place for too long.
  
  The barrels inflict damage on Aladdin and cannot be destroyed, with the exception of barrels with special colors. They can be destroyed with a sword blow, while opening up bonus items (health, life, etc.). To defeat Razulom, Aladdin must run from side to side and up the platforms on both sides of the building. In the middle of the floor there will be a hole through which Aladdin must jump, otherwise he will lose a life. Over the middle of the floor there will be a shed, preventing Aladdin from throwing objects directly into Razula.
• Planned version of the green snake with yellow stripes.
• The periodic attacks of the Yago brothers (different from Yago in the color of feathers) were planned:
  
  Each of the Iago brothers can carry one red vial in their paws. Red bubbles explode, touching any object. Birds fly into the screen, try to be above Aladdin, and then throw a bubble. Then they fly away from the screen again (keeping the direction in which they moved when the bubble was thrown).
  
  Falling on Aladdin, the bubbles cause him damage. Aladdin can also get into a puff of smoke when a bubble falls next to him, and he also takes damage. Smoke disappears after 0.5 seconds.
• At the level of the desert, enemies — mirages — were planned to appear and disappear, taking on the appearance of existing enemies. Mirages can do damage and be killed by Aladdin.
• The enemy “prisoner”, found in the original schedule, was originally supposed to wear a robe with a black and white striped turban. He was supposed to be the same height as Aladdin, and not a very tall, gangly character, whom we saw, and have an additional chain waving attack.
• It was originally planned that the bats will have a special dive attack.
• It was planned that one of the brothers Iago should fly and drop a bubble on the first skeleton in the Sultan's dungeon (Sultan's Dungeon). This would explain that at this level the skeletons come back to life.
• Gold monkeys were originally planned for another gold level, Cave of Wonders, in which the cave should be filled with gold coins, precious stones and other treasures. Most likely, the golden monkey was removed because it was decided to completely cut this level, and its behavior was transferred to the statue of Shiva.
• At the second level, the Cave of Wonders planned stone monkeys, which were supposed to behave like golden monkeys, but throw stones, not coins / gold / jewels.
• The Shiva statue, appearing in the Cave of Wonders level with a gold / stone monkey design, was originally supposed to appear in the palace and have the following design:
  
  Act:
  
  Remains motionless, like most of the statues, until Iago arrives and drops a bubble on her. Then she magically comes to life and begins to attack Aladdin.
  
  Attack:
  
  With her numerous hands, she should pull out the gems from her headdress and throw them at Aladdin. When the jewels fall to the ground, they magically turn into flame and burn for 2-3 seconds. Every time Aladdin hits her, she loses one of her hands.
  
  Appearance:
  
  About the growth of Aladdin, but has 8 hands. Dressed in trousers and a hat with lots of gems. Must have the color and texture of the marble statue even when it comes to life.
• The flamingos in the Sultan’s palace initially had a slightly more aggressive mechanics:
  
  If the player is too long standing on the flamingo, the bird turns and pecks at it. One of the flamingos will be Yago, in disguise, and he always moves out of the way when a player is going to land on him.
• In the battle with the boss, Iago initially focused on the use of Abu's jewels to attack Iago. It was the only way to push Iago closer to the gears.
• In human form, Jafar sometimes had to throw down red bubbles that create a cloud of dangerous smoke that did not dissipate for a long time.
  
  
  
• Jafar in the form of a snake should have had an attack with his tongue, and if the attack succeeded, he should have smiled. He had quite a few other variations of attacks / behaviors.

This in no way affects anything, and there are still many small differences between design and implementation in the game.

Rock Paper Scissors

Although neither the corresponding code nor the data has been preserved, there is a complete description of the game in "stone, scissors, paper." It is worth quoting it here in its entirety:

Once on the bonus screen, the player sees in the left center of the screen a rug waving with his left brush. Aladdin is standing in the right center of the screen and waving his right hand. The stone corresponds to the A button, to the paper - to the B button, and to the scissors - to the C button. The hint is shown in the lower center of the screen.

The rules are similar to the rules of a regular game: each player chooses a stone, paper or scissors. The stone is indicated by the fist, the paper is indicated by the open palm, and the scissors are indicated by the index and middle fingers extended in the shape of the letter V. User plays for Aladdin.

While the carpet is swinging with his brush, and Aladdin with his hand (this continues until the player makes a choice), the player must choose one of three buttons: A, B or C. After selecting the desired item, the carpet and Aladdin wave the arm and arm two more times. and then, on the third wave, show your choice. The winner celebrates the victory and it is displayed on the screen.

If Aladdin loses, the game ends and he returns to the same place where he left the level. After that, he becomes invulnerable for a few seconds (this process also occurs after the third game, regardless of who won). If Aladdin wins, his prize is displayed graphically (just like in a regular game) and / or text form (in case of extra points).

The player is then asked whether he wants to play again, to be able to win more, or to leave the game, retaining the items already received. If a player plays again, he can lose and lose all previously won items (for example, if in the first game Aladdin won one life, in the second - 10 jewels and two more lives, and then in the third game he loses, then he loses everything that he won previously: 10 jewels and two lives).

For one visit to the bonus game, you can play no more than three times. Aladdin can play the second game only if he won in the first, and in the third - only if he won in the first and second.

In the case of a tie, the game repeats until someone wins.

rules

Stone beats scissors
Paper beats stone
Scissors beat paper

If both players have the same items. then a draw is counted and the game is repeated.

Prizes

First victory: life
Second victory: 10 jewels and two lives
Third win: one genie smart bomb, 15 jewels, three lives

Note: we can change the prizes according to the selected difficulty level of the game (winnings are better with low difficulty). This will be decided during game setup.

Note: prizes are summed up, if Aladdin wins all three games, he gets six lives, 25 jewels and one smart genie bomb

It seems that this idea arose in the early stages of development, apparently, some elements of the description no longer correspond to other design mechanics and objects.

ROM breakdown

In dizdok, an attempt was made to pre-break the memory requirements of all characters, levels and functions, despite the fact that in reality this was not fully achieved. This gives us a wonderful opportunity to evaluate how attentive designers and artists had to be to the technical limitations of the target media.

2048 KB - total available cartridge memory
Estimated Memory Usage
480 KB - 8 levels, 60 KB per level (this includes a set of tiles, triggers, contours, and everything else)
132 KB - three levels without tile sets, 44 KB per level
175 KB - music and sound effects
64 KB - the program
64 KB - sprite tables
64 KB - checklists
120 KB - initial splash screen / interludes / final splash screen / final movie (image of each interlude = 4 KB)
30K - Sega, Disney, Aladdin and Virgin logos
491 KB - Aladdin and all characters not tied to levels
369 KB - level-linked sprites
241 KB - bosses
80 KB - all bonus games
___________
2274 KB required
2048 KB -___________
226 KB extra. Hmmmm
60 KB breakdown by levels:
11500 bytes - data of background characters (compressed)
32768 bytes - links and combinations of background blocks
1200 bytes - the floor and the information to switch sprites (compressed)
400 bytes - contour information
10699 bytes - map data (compressed)
2171 bytes - card parallax data (compressed)
___________
Approximately 58738 bytes per level. [This estimate will decrease if the graphic style will be simpler, or if the size of the levels will be less than the maximum possible size]

Such careful coordination and planning are in fact for many reasons sound practices, and this is very far from the imbalance that we often see between graphics, design and programming in modern game development. I would like to say that I never once swore at the artist who stuck a huge monochrome texture 4096 × 4096 into the game, or at designers who first make the level loading last three minutes, and then hope that they will be repaired. I used to shame employees with the words “your empty texture takes up more space than the whole game took 20 years ago.”

3.7. Sega cd

It seems that the version of the game for the Sega CD was planned from the very beginning. Unfortunately, despite the frequent mention of the Sega CD in the design document, it seems that the original graphics did not live up to our archive with Aladdin. Here are all the features and elements related to CD that I managed to pull out of dizdok:

• It was planned that in many additional levels of Sega CD Aladdin will appear in the guise of Prince Ali. Dizdok mentions that Prince Ali will appear in only one version level on the cartridge, but he was deliberately cut to save space in ROM.
• It was planned that in the CD version of the game Jafar would have a third form in the form of a genie. There were no traces of graphics for this stage in the archive.
• In case the Abu magic bag lives on to the retail version, two more additional reactions were planned for the CD version by Abu to the amount of jewels used by Aladdin.
• In the CD version, it was planned to replace the boss of the Razul market square with the boss “Apple Merchant”. Razul himself was to become a level boss with a prison.
• In the CD version at the desert level, the sand scorpion boss was supposed to appear. There is no additional information for this boss in the design.
• At the second level, with the market square leading to the palace of Jafar (which did not reach the release), in the CD version of the game, instead of the second meeting with Razul, the boss was planned to be a Fire Eater.
• For the CD version, an additional throwing object was planned - a snowball.
• Especially for the CD version, additional waiting animations were planned:
  
  
  • The genie flies into the screen and says one of the phrases (only after the level with the cave in the CD version)
  • The carpet flies onto the screen, pats Aladdin on the shoulder and flies away again (only after the level with the cave in the CD version)
• In the CD version, an obstacle sometimes appeared in the form of a man lying on nails; it allowed Aladdin to jump away from him once, without taking damage. After the first jump, the person “in indignation” rose and could no longer be used for jumping.
• On the desert level in the CD version, quicksand was planned:
  
  When Aladdin passes through certain areas of sand, he begins to sink. Jumping, he can gradually get out of the sand and go through these areas without drowning. If a player leaves him too long, Aladdin is buried in the sand and loses his life (or the game ends if it was his last life). The quicksand must look a little different from ordinary sands in order for a careful player to anticipate this danger.
  
  One patch of quicksand leads to a secret area. To get there, Aladdin must overcome his natural desire to escape from the trap, and remain in place. When Aladdin falls beneath the surface of this quicksand, scarabs fly and fly, saying that he has discovered a new area in the desert, perhaps something like a cave (if we have these tiles) where Aladdin can find an extra life, the continuation of the game and various other bonuses.
  
  With the visual and gameplay mechanics of Aladdin’s return to the desert surface, we still need to decide, but for integrity, we use another frame transition with the scarab.
• For the CD version, the probability of using cacti was also planned:
  
  They will be of various shapes and sizes (maybe two kinds). We will remove them from the game if they do not match the style of the world of Aladdin. Touching the cactus deals damage to Aladdin (1 point of damage with each touch).
  
  One type of cactus can be destroyed by throwing an object or striking a sword. Another, more thorough-looking view of the cactus does not go anywhere, it can only be avoided.
  
  Both types of cactus will be graphically arranged so that you can create several different-looking cacti without using too much graphics, and therefore memory.
• In addition to the static ropes, which can be climbed at the level of the market square, swinging ropes were planned for the CD version of the game.
• The carpet had to have a special animation with burning brushes after it was getting too close to the flames.

Plans for the CD version are often intertwined with the elements / functions that were planned (but did not live to see the release) of the game version on the cartridge.

3.8. Code

You can tell a lot about the source code itself. One of the most interesting aspects of the gaming code itself is that it is driven by a mechanism that is essentially an incredibly simple finite automaton. , , :

;  AN_ROLLY_SNAKE: dc.w SN_SLTHR_FRAME1 mface_man R_S: dc.w SN_SLTHR_FRAME1 dc.w SN_SLTHR_FRAME1 dc.w SN_SLTHR_FRAME1 mif_within_X 85,AN_ROLLY_SNAKE_BITE dc.w SN_SLTHR_FRAME2 dc.w SN_SLTHR_FRAME2 dc.w SN_SLTHR_FRAME2 dc.w SN_SLTHR_FRAME3 dc.w SN_SLTHR_FRAME3 dc.w SN_SLTHR_FRAME3 

This generates bytes / words for each "command". Each frame of the animation is set by word generation, and this word is a pointer to a list of frame pointers approximately at the beginning of the ROM. Then there are a lot of macros for things like the conditional logic mif_within_X shown above, which generates the corresponding command byte. The command bytes are conveniently located outside the range of known frame pointer values. As a result of this command for the next run cycle, the state data pointer may have some other value.

Elements (objects / actors) are most often controlled by processing the code for such state data. Movement is also handled in a similar way. The motion logic is determined by the generated bytes, and each element can pass a pointer to its motion state data. Also very often, the animation state data replaces the pointer to the motion state data, therefore there is a special macro used to generate the corresponding bytes for this operation.

There is a fairly large amount of code dedicated to the execution of these small blocks of states and controlling the calculation of such things as physics / collisions and even the hierarchy of basic movements. Of course, the player is processed in his own way. Like standard elements, it uses state data, but it has its own assembler boilerplate logic that processes most of the more complex state logic, which also often directly specifies state pointers.

This method of processing simplifies the work of adding new objects, and allows you to reduce memory costs by minimizing the amount of new code required for each object and packaging the logic into fairly effective state commands. Combined with the fact that the state logic itself is very simple and there are special macros for all fairly complex cases of logic, then for a game of scale Aladdin is an excellent system.

In addition, there are many boilerplate codes for handling such system-level aspects as data transfer with direct memory access in VRAM. The DMA_IT procedure was the basis for recording Chopper tiles by blast processing in VRAM. Chopper was designed to minimize costs quite effectively. He avoided the cost of unpacking in the CPU, while minimizing the number of unique tiles per frame of animation. I did not work on profiling Aladdin and did not study how many cycles are usually spent here, but judging by the final result, the system does its job quite well.

Here we can immerse ourselves in the study of countless systems, but if you don’t go into too much detail, then I listed the most remarkable high-level operations in the Aladdin codebase.

In addition to all the above, there are other interesting fragments that I noticed while studying:

• There is a variable assembly time MAKEDEMO, which can be used to record demo. When recording a game, each frame writes commands from the controller to VRAM. Interestingly, when recording demo, you can see how artifacts appear on the background tiles. After filling in the dedicated VRAM buffer, the game copies the data from the VRAM back to the main RAM, then loops indefinitely in place (because it only destroyed the main memory), so you can connect a debugger and unload the demo data from a known address. For fun, I created my own demo this way.
• Other interesting facts about the demo: The demo data itself is the raw stream of frame-by-frame input from the controller. Both the recording and the demo playback use the same initial number of the pseudo-random number generator "12345678" to provide deterministic results.
• There is also the MASTER assembly time variable. It seems that in the retail copy it is OFF. When set to ON, it disables parts of the cheat screen that has survived until the release, but when it is turned on, the code is not assembled without modifications. It can be assumed that the cheats screen (still containing phone numbers and fax numbers) should not have remained in the retail version.
• Cheat codes along with many other static data are listed in the TABLES.68K file. They are read one byte. The logic of cheat codes increases the pointer to the corresponding table of cheat codes, and resets it when you press the wrong button. No additional (except known / documented) hidden / disabled cheat codes were released in the source code.
• While recording the video for this article, I wanted to turn off the high-frequency flicker that occurs when Aladdin is damaged. It was necessary to avoid its complete disappearance into several frames when transcoding video to lower frame rates. Having found the necessary part of the code, I found around it an assembler check “IF TO_DEMO = OFF”. Obviously, I was not the first to encounter this problem while recording a commercial! It seems that TO_DEMO was removed from the demo assembly for CES, or this particular part was added later, assuming that flicker is present in this assembly (when invulnerability is disabled).

I don’t know how about you, but personally all these things made me feel nostalgic about the golden era of game development.

4.0 What's next?

Each game has its own story, and sometimes binary code speaks louder than words. But the source code usually speaks even louder! Due to canceled prototypes, discarded demos, and hardware failures, we already lost too many amazing moments in the history of video games. If we don’t begin to take a closer look at storage and archiving in the video game industry, especially with hardware-based DRM technologies, we may lose a lot more.

I started this project in order to prepare the Aladdin archive for proper preservation, taking the first steps towards standardizing the preservation and archiving of the source code on the VGHF. This meant documenting source code from the top level to determine its purpose and all external dependencies on other tools and / or data so that these dependencies can be tracked in a standardized way. In the process of work, it immediately became obvious to me that Aladdin can tell an interesting story. I hope that this is only the first of many other stories, and I can't wait to find out what else is hidden in the game!

See you!