Reverse engineering the old dos game “Tricky Quiky Games II”

Update April 2021: Download links have been fixed! Sorry for the long delay

You are playing their mascot, the “quiky”-bunny. The objective is to get the Nesquik recipe back which has been stolen by the evil “Doc”. Of course there are evil worms, bees, fish, crabs, bugs, robots, UFOs, etc. which try to get in your way. Every three levels you even have to fight the evil Doc himself, for every level he built some special contraption with which he tries to kill you…

Since the license clearly states that you can copy the game for PRIVATE, NON-COMMERCIAL USE ONLY, you can download it right here: quiky.zip – the game has already been patched to run on PCs with > 100MHz. Just unzip and run. Language is set to German, sound to Soundblaster at 0×220, IRQ 7, DMA 1. Use SETUP.EXE to change settings. For playing on a modern pc I recommend dosbox.

I always wanted to do somehow more with the game, like editing levels and graphics and so on… Or at least see how it works. Unfortunately there’s no editor – and not even any files you can play with. The directory structure just looks like that:

$ ls -l ~/dos/quiky
-rwxr-xr-x 1 simbone simbone   65312 1999-07-23 12:41 dpmi16bi.ovl
-rwxr-xr-x 1 simbone simbone 3705125 1999-07-23 12:41 nestle.dat
-rwxr-xr-x 1 simbone simbone    4468 2010-10-16 20:02 nestle.ini
-rwxr-xr-x 1 simbone simbone  151552 1999-07-23 12:41 quiky.exe
-rwxr-xr-x 1 simbone simbone  108686 1999-07-23 12:41 rtm.exe
-rwxr-xr-x 1 simbone simbone     130 1988-01-01 00:12 score.dat
-rwxr-xr-x 1 simbone simbone   56320 1999-07-23 12:41 setup.exe 

not really much to mess around with. It appears that all stuff is hidden inside the NESTLE.DAT. Too complicated for me back when I was 10 years old :(

Because I just rediscovered the game on some old harddisk – and was very happy to see it running in dosbox :) – I decided to check it out again. And – YES, there’s something I can do now!
It appears that the NESTLE.DAT is just some sort of archive, a lot like ZIP, but simpler and without compression. The tail of the file shows a clear directory structure. With a little bit of testing I quickly figured out the meaning of those bytes.

The last last 4 bytes probably contain the number of files minus one (that’s at least what my packer put’s there now – seems to work). Don’t know for sure. The 4 bytes before that definately contain the file offset where the directory starts:

Every entry consists of the length of the filename (2 byte integer), the filename itself (length-of-filename bytes, not terminated) and the position where to find it in the datafile:

Note that there is no length information. This is not needed because the files are always listed in the right order. A file always contains “position_of_next_file – position_of_current_file” bytes. The last file goes all the way to the beginning of the directory information.
With that knowledge I was able to write a small program which can extract all the files inside the NESTLE.DAT (all code is at the bottom of this page!). Now you get a lot of strange, small files like BOB, PCC, MAP, ARE, ICO…. If there were BMPs and WAVs it would obviously have been too easy now, wouldn’t it? Luckily Nautilus’ magic can help us with some of those files:

So it turns out all the PCC files are actually just regular PCX files! And it gets even better: I wrote a program which packs all the files back into a NESTLE.DAT. You can just open up some of the static images in your favorite picture editor (I recommend GIMP), edit them, and put them back. QUIKY will load them without complaining.
There are some more goodies inside: the TFX and SAM files contain the music, in TFMX format. However some values are little-endian and all the players expect big-endian and hopelessly crash. I’ll check that later because if you just want to listen to the music, you can get some “fixed” TFMX files on the net (just google for “rudolf stember adverts tfmx”) or download the music here.

When you go through the PCC-files, you will notice some 1×1 or 1×3 pixel files (W?.PCC). They don’t contain an actual image but just the palette for one world (remember, back then we could only use 256 colors at once!)

By messing around with the files (copying, replacing, running the game) I figured out that the ICO-files contain the tileset used for making the game background. Each tile is 16×16x1 bytes large. The ICO files are headerless and always a multiple of 256 bytes. They work in conjunction with the current world’s palette defined in the PCC file. Theoretically you can open the ICO file as RAW image, select 16 pixels width and 16*number_of_tiles height and apply the palette from the corresponding PCC. But then you’d also have to shuffle the columns around, because they are not linear but instead interleaved by 4. That’s most likely an optimization technique for the unchained 320×200 VGA-mode QUIKY uses. Afterall it’s a lot faster, but harder to program, to use pages in video ram then REP MOVSDing around from system memory … back to the ICOs .. because it’s hard to get the columns right manually and working with a 16×6400 pixel is a big pain in the *** I wrote a small C program which makes a nice almost square BMP file like this:

(Yes, for uploading I actually made a bad-quality JPG – not because I’m stupid but because I don’t want you to just grab it off this webpage and use it for your own puroposes! There’s still some copyright on it. That’s why I made it unusable by watermarking, distortion and lossy compression. If you want to shoot yourself in the foot, do so – but I won’t hand you a loaded gun here)
At first I tried to squarify it as much as possible, but it seems that the designers optimized the tileset for a width of 20 tiles in one row. Then most of the images line up vertically too, as you can see.

There are also MAP and ARE files. MAP files contain the information which tiles are placed where in the level. It’s just a 2 dimensional 16-bit per element array with some header in front:

Note that this file is entierly big-endian! This is different to all the other files I encountered so far, which use little-endian. Maybe this was made with a map editor written by a third party – the signature “TLE1″ also suggests this.

To see if my assumption about the array was correct I wrote a small program which makes some kind of ASCII-Art out of a level file. Here’s what the first level looks like:

Putting it all together I started writing a level editor in java. Actually it’s more like a level viewer at the moment, but who knows what might become of it in the future… You point the program to the MAP file extracted from the NESTLE.DAT. Based on the filename it determines the used ICO and PCC files and loads them too:

The nice thing is that other games like “Tony & friends in Kellogs land” (the old DOS game, not the windows version) uses the same file structure. Just the palette looks a little different and needs to be shifted around. This program takes care of that shifting. In QUIKY a lot more colors of the palette are reserved for the map. KELLOGGS just uses 16 or 32, depending on the world. Probably because there is water in the levels too – which makes everything a bit blueish. That should double the amount of required palette entries. Or maybe they make the water somehow different…? However I won’t check that now because this is actually about the QUIKY game:

We’ll leave it at this for now and take a look at the ARE-files which contain the “living” part of the map. If you just blank the ARE file you get a very peaceful (and boring) map where you can walk around, but there are no enemies, nothing to pick up, no leaves falling from the sky, no exit, no elevators, nothing. Even the cereals are just static background because the actual objects are defined in the ARE too. Just the spikes work, ouch.
ARE files seem to have a fixed structure, where certain datastructures reside on fixed positions. If the block isn’t large enough it’s padded out with zeros – except for the very last block in the file which seems to have a variable length.
This is just some prelimary information, however. Most of the ARE file still remains a mystery to me! HELP ME WITH THAT!

Datastructures in ARE files:
@0000 Unknown at the moment

@0160 Map of the level (FFFF=blank)
Most objects seem to be prefixed by 13, the next byte probably is a reference to the table below. moving values here cause them to move around on the map. But somehow this is a lot smaller then the .MAP-file so my guess is that different tiles are put together here to form a bigger ARE-tile.

@14E0 Decleration of the stuff above
So far I’ve only experimented with type 13 objects. (“nothing?” removes the entity from the map. Probably this ID is used for other things, like non type-13 objects – or is just plain nonsense)
20 = nothing?
29 = falling leaf
2A = another falling leaf
2B = yet another falling leaf
64 = nothing?
65 = 1 ammo (map tile 2, sky/water/space background)
65 = 1 ammo (map tile 3, inside some kind of structure)
67 = 1 ammo (map tile 4, inside some other kind of structure)
68 = nothing?
6E = nothing?
6D = nothing?
6F = 10 Ammo box
70 = Extra health package
71 = health up
72 = Temporary invulnerability
73 = nothing?
74 = nothing?
7A = nothing?

Tip: Type QUIKYSUPERHERO in menu, then 4 to jump to a level easy to experiment with. I chose W1L3 (doc level in the nature world) because there’s so little stuff on it. The list above is a result of repeatedly overwriting offset 14E9 with all the values.

Maybe more important then the ARE-files are the BOB files. BOB files seem to contain most of the animated and still graphics.
I tried messing around with BOB files – but unlike ICO graphics, just changing a few bytes in the middle of the graphic can crash the game when the graphic is fist displayed.
I think the height is stored at offset 4, the width at offset 6. But that’s all I can say for now.
Using them as raw images isn’t very helpful either – you can’t make out anything!

Here’s where I stopped. Afterall this is just a hobby project I do in my spare time. If you want to contribute to this PLEASE DO SO! And don’t forget to drop me a line at simon AT dkia DOT at – Your name will be mentioned!

This is the current progress, sorted by file extension:
EXE TODO The game engine itself. Very hard to gather anything from here…
DAT R/W NESTLE.DAT archive, containing all the files below (extract.c and pack.c):
ARE TODO Definition for objects in the level
BOB TODO Graphics and Animations
ICO READ Level-Tilesets (via ico2bmp.c and level editor)
MAP READ** The map of a level (via levelex.c and level editor)
PCC R/W Still graphics and palettes (standard PCX-Image, open with GIMP)
SAM R/W* TFMX Audio samples
TFX R/W* TFMX Audio code

* = well, almost – if it weren’t for the endianess thing.
** = most of it. Since only 9 bits are required for choosing a tile (there is max. of 400), the other 7 bits might mean something. Here are my notes on them – not really sure what they mean anymore:
ABCD EFGX XXXX XXXX
X = Tile seleciton
D = Hit on the head?
B = Solid left/right

Code

Get the code right here! All C files compile with default options. No libraries except libc required. Just type “gcc -o aparticularprogram aparticularprogram.c” to compile. All code is public domain – this means you can do whatever you like with it. The archive contains

extract.c – Extract the big NESTLE.DAT into small files
pack.c – Make a new NESTLE.DAT
ico2bmp.c – Convert an ICO tileset to a BMP
levelex.c – Make an ASCII-Art level
QuikyLevelEditor/ – Level-Viewer, Java-NetBeans Project, includes compiled .jar