Final Countdown - Amiga - Investigating the files

1. Intro

Final Countdown is a relatively obscure Amiga game that is often compared with Impossible Mission (a game I don’t know), created by German developers Demonware.

The entire game is a kind of big puzzle; the protagonist, Laira Tyrik, is a human scientist (wearing unusual clothes for a scientist) in the year 2437 that is transported to an “asteroid” to investigate. The asteroid is actually a spaceship coming to our solar system, and it seems unfriendly. Laira has to avoid obstacles that can kill her, and find information about how to disable the asteroid’s systems so it does not destroy Earth. She can try to access the computers that are available in many places in order to manipulate the ship systems and gather information.

The game is hard to figure out, and there is no guide anywhere on the internet about how to finish it. After watching Eric from Cosmic Effect play the game and get stuck in it, I tried to play and got stuck the same way.

So I decided to look into the game and try to better understand stuff. First step: trying to open the disk image files.

2. Amiga disk images

I don’t know much about the Amiga (never had one, though I wanted to), but the most common disk image format seems to be ADF (Amiga Disk Format). It is a dump of AmigaOS-formatted disks, track by track. However, game developers often defined their own disk format, sometimes adding some copy protection scheme on top. Because of that, these games can’t be dumped to ADF directly. The IPF (Interchange Preservation Format) was created to dump these kind of disks.

When looking for Final Countdown I found two versions, a no-intro version in IPF and a cracked version in ADF. Both have two disks. The cracked version was created to be copied easily, so it was formatted according to the AmigaOS format, and so it can be dumped to ADF. Because there are more tools to work with ADF files, I chose this version to look into.

3. unadf

There is a library called AFDlib that can be used to manipulate ADF files, but for my current purposes the unadf tool (made with ADFlib) is enough: it can extract individual files from the ADF image. It seems to be possible to mount ADF files directly in linux/unix systems but the linux system where I tried did not have support for the Amiga file system.

4. Disk 1

Using unadf, these are the contents of the first disk: 

x - gfx/
x - gfx/Count
x - gfx/Logo
x - gfx/TText
x - gfx/Asteroid
x - gfx/Stuff
x - gfx/SysCompC
x - zob
x - c/
x - c/Type
x - c/echo
x - l/
x - devs/
x - devs/system-configuration
x - s/
x - s/startup-sequence
x - s/start1
x - s/start2
x - intro
x - songs/
x - songs/Title
x - libs/
x - space
x - snd/
x - snd/SSound
x - snd/Sound

What we have here are graphics (gfx), the title song (songs/Title), sounds (snd) and other files.

startup-sequence seems to be the starting script. It runs the Paradox intro/cracktro (intro) then shows the start2 file (message saying that it needs 1Mb to play sound effects), runs zob (a 4kb program) and then space, which seems to be the main program.

5. Disk 2

The second disk has a single file in the gfx directory, then the directories Txt and Lev. Txt seems to contain all the texts that appear in the computer terminals along the game, in plain text. Lev seems to contain binary data files, in series like 

Elements0  Elements1  Elements2  ...
Foes0      Foes1      Foes2      ...
Matrix0    Matrix1    Matrix2    ...
Struct0    Struct1    Struct2    ...

Some of the files are recognized by the linux command file but the reported formats doesn’t always make sense and maybe a coincidence. Probably binary files with a specific format used by the game program.

6. Going further

We can read all game text already and this may provide a lot of information about how to solve the game. We can also start to analyze the executable files, zob and space on disk 1. The former may be a startup program, while the latter is probably the main program. Both are recognized as having an AmigaOS executable format: 

$ file space
space: AmigaOS loadseg()ble executable/binary

So the next step would be to look into this format and how the executable code can be extracted from it. Maybe we’ll do that another day.

Comments

Post a Comment

Popular posts from this blog

How many instructions per frame?

 To get an idea of the complexity of code executing during one frame of the game, we can calculate an estimate of how many instructions are executed for each frame.  The main CPU is the Motorola 68000 running at a 10MHz clock. 10MHz means each clock cycle takes 100 ns or 0.1μs. The game runs at 60Hz or 60 frames per second so each frame takes 16.6667ms. So in each frame there are 166,667 cycles.  The M68k is a CISC processor and its simplest instructions take 4 cycles, but there are instructions that take more. An upper bound to the number of instructions executed per frame is thus 166,667 / 4 = 41,666.75 or just about 42 thousand instructions per frame. The real number varies per frame depending on the mix of instructions that are executed on it, and it probably never reaches this value of 42k instructions per frame because you don't expect to execute only instructions of 4 cycles, but something in the order of tens of thousands of instructions per frame seems right. 
Read more

Reference on D88 disk image format

 To investigate what code gets executed when a disk is loaded in one of the Japanese computers, we can investigate the contents of the disk image. Disk images for many Japanese computers are often distributed in the D88 format. Luckily it is a simple format and there's a reference about it in English here: https://www.z88dk.org/tools/x1/XBrowser_User_Guide.pdf Look in Appendix II. It is a reference to a tool intended for Sharp X1 users, but the format is the same used in PC88 and other Japanese computer emulators and tools.  The information is organized by tracks and then by sectors, as in a real disk. File header The file begins with a header with the following fields: struct header { char[17] name; // image name, usually empty u8[9] reserved; // reserved, usually zero u8 write_protect; // non-zero value means write-protected disk u8 media_type; // 0: 2D, 0x10: 2DD, 0x20: 2HD, 0x30: 1D, 0x40: 1DD u32 disk_size; //
Read more