Stunt GP #2: Timeless issues

When I started playing Stunt GP on Windows 10 I immediately noticed there is an annoying half second freeze every 7 minutes 9.5 seconds, making the game way more annoying than on older PCs, where the problem seemed non-existent. After one and a half years I finally found the reason for that and fixed it 🙂

The problem

The game uses QueryPerformanceFrequency() and QueryPer-
functions to measure time. This first function returns frequency with which the counter will update. This frequency is different on each PC, but I’ll talk more about that later. Performance counter itself is 64bit, on even fastest PCs it would take 24 THOUSANDS years for the performance counter to fill up and overflow, resetting to 0 (assuming 24 MHz frequency). The problem is the game uses only 32 bits of this counter, meaning the counter will overflow after just 3 minutes in worst case scenario.

On older PCs the frequency of this timer oscillated (pun intended) around 2-3 MHz, so the counter would overflow after 23 to 36 minutes. In Windows 10 Microsoft decided to set the frequency of this counter to 10MHz, independent of the hardware, so the counter would fill up after exactly 7 minutes and 9.5 seconds. Users may force Windows to use hardware timer, but instead of seeing 2-3MHz clock speeds on newer PCs with High Precision Event Timer (HPET) this timer may as well have speed of 14 or 24MHz, filling the counter in 5 or even 3 minutes!

Now, the game very badly handles this overflow, simply freezing. The only reason the game unfreezes after 0.5s is code that detects if the game freezes for a half second, but the overflow itself isn’t handled when it happens.

The solution

Using StuntKit solution I was able to create a new module that on the game start replaces function that counts the time with one that detects overflow and resets internal game timers, removing 0.5s freezes.

Stunt GP #1: unpacking files

What is inside the game folder?

In the game directory there are .wad, .pc, and .pmd files. .Pmd files are in “meshdata” directory, so they probably are 3D models. .Pc files are located in “graphics24”, so they could be textures. With only .wad files remaining I assumed they might be some kind of archive, perhaps the same as .wad files used by Doom.

Magic and wizardry

Many binary files contains “magic”, first few bytes of a file that helps identifying it, so we’ll start there. .Pmd files magic were “PMD V1.83”, I haven’t found anything about this format anywhere. .Pc files magic was “TM!”, and .wad files was “DIR”.

Left part of the hex editor shows bytes in the file, and the right part shows text representation of each byte (if it exists)

.Wad files

As it turns out, after first 4 bytes there’s file size written as 32bit little-endian integer. Little endian means that the order of bytes is reversed, so in below example “1C 64 02 00” written in hexadecimal should be 0x0002641C, or 156700 in decimal system, exactly the same as the size in bytes of boot.wad. After that there are 4 bytes of unknown purpose. And after these 12 bytes we see “TM!” meaning that .wad file is really some kind of archive and this one contains at least one .pc file inside.

The unknown value from before is smaller than the file size, so it might point at something inside this file. Let’s look what’s under the address 0x000252B4:

“0A” and many 00 bytes, with some occasional random data here and there. About 4096 bytes after this we can see names of the files inside this archive:

As at the beginning of the file here also most of the fields are aligned to 4 bytes, so after the filename there are “00” bytes. After that there are 12 bytes, probably grouped as 3 4-byte numbers, so the first file should also have these 12 bytes before a filename.

For the first file the first number is 0, second one is equal to 0x0C, and third is 0x448A (17 546). Second value is a pointer to where data starts in the archive and third is a size of the data. These informations should suffice for unpacking all files from the archive.

.Wad files: more info

I’ll skip most of the description how I was able to determine what each value should be or do , this post is already quite long, and I’ll jump straight to some conclusions.

After each file data there is “1A” byte and padding “00” bytes, so the next file will always start on a offset aligned to 4 bytes. As it turns out, the .wad files are just renamed .dir files form Worms Armageddon, what I learned after creating unpacking script 🙁 However the information about the hash array with 1024 4-bytes entries allowed me to create my own .wad files and replace existing files.

.Pc files

In this file values are aligned to 2 bytes: at the beginning there is 4-bytes of magic “TM! 0x1A”, 0x0003 value that never changes and seems unused in the game, width and height of the image and compressed image data.

256x256px image (0x100 = 256)

Luckily, .pc to .bmp converter already exists:,

Sadly, it was just a wrapper for a function written in assembly, ripped directly from the game executable, making it hard to read or edit. I was able to understand how decomproession of these files works and rewrite the converter (and packer!) in Python:

Replacing files works. I’ve chosen the worst possible image to replace, because team logo uses three separate files and I have replaced just one of them.

Smartphones #3: buttons

this is way overdue status update, sorry for that

Sony Xperia L (a.k.a Taoshan):

My power switch broke after few power ons 🙁

Powimod mailed to me that he also wanted to port postmarketOS to this phone, and after about a month there is first success 🙂

I couldn’t help too much in a practical way (the power button broke a week ago), I tried to at least find resources how to solve various problems.

So how the work was going?

  • We both compiled Linux kernel independently, theoretically both of them should work but as it turned out the phone wouldn’t boot
  • We thought about finding UART port, and I broke my power button while searching for it  (that button is just small metal sheet connected to plastic base with piece of adhesive tape)
  • Then we started analyzing boot.img image, usingLineageOS/pmos kernel + ramdisk combinations to no avail
  • Whilefastboot boot didn’t work, requiring us to flash boot.img instead of booting it from RAM, we finally could generate working boot.img by adding two options to image generator(`–kernel_offset` and `–ramdisk_offset`) and using pmos kernel &  LineageOS ramdisk to boot LineageOS
  • After flashing pmos we thought that it won’t boot. It turns out it did, but without screen, LED or ssh/telnet (which we were able to get working shortly after)
  • I was told that patch from Konradybcio for Xperia M (sony-nicki) helped turning screen on, however I was unable to check that since my screen broke 🙁

So now there is working port, but I won’t work on it anymore since my screen broke


boot.img – file that contains everything needed to boot a phone

ramdisk – after turning on a phone a kernel is loaded; it loads ramdisk.gz content into ram and run files that are contained in it; it’s like basic filesystem when normal memory is not yet available

Smartphone + piece of cardboard = VR

Virtual reality is a virtual world we can interface with. While most of the VR sets cost a pretty penny, most of us have a smartphone that can be used for entering the virtual world.How? With a piece of cardboard, or plactic since there are also plastic VR goggles.


Controls in Google Cardboard usually are limited to pressin on button while gazing at some object. Some carboard goggles have a moving magnet that can be used for clicking, and for the rest of the goggles you need to buy a mouse or a gamepad.

With the help of Unity engine we can create games for Google Cardboard, like this simple quiz:

Creating 3D models and environment is just a part of the work, we need to allow user to control the game itself by creating scripts so clicking on a button would do something useful:

Buttons are there but none of them do anything
This is how the editor looks like

Smartphones #2: Working phone? Ain’t nobody got time for that


This phone has a “working” pmos port, if you consider a phone that reboots after 2 minutes as a working one. I wanted to try to flash newest  Linux kernel on it but here’s the problem:

New kernel uses pretty easy to edit and maintain  dtb files that contains all information about phone, SoC and other hardware components. But before that all these information were hard-coded in the kernel, often i many different files, making it harder to edit and update. I’d have to write dtb file from scratch, using old source as a base. Since it’s nice to see what are you doing, I need some kind of output to know what happens inside the phone. Sadly, creating dtb file from scratch I must acknowledge that sound, USB, screen and basically nothing that would help me will work yet :/. There is however one thing that should work always: UART(see glossary), a good old text mode.

Here lies the problem, or rather several problems. The first one is where is UART physically located  in the device, fortunately UART on Samsung devices is easy to get.

Micro-USB plug have 5 pins, as opposed to four in regular USB plug used in PC. By connecting ground and ID (this is that additional pin) through various resistors the phone changes function of USB socket.

When these two pins are disconnected the USB port works as usual allowing you to connect smartphone to PC; 300kΩ — phone enters  download/fastboot mode, on some models the yellow triangle warning about unofficial software disappears (sadly not on this one).

UART mode had caused me some trouble, since there are several similar modes but only few of them are useful to me. So I built small resistor box to test the phone with most popular resistor values, which should make this part easy.

The second issue is what is needed in the dtb file to start and use UART or get any kind of output running, which I’ll probably have to determine experimentally. For now I’m thinking about two solutions: first one is to use “earlycon”, which, in theory, requires only UART address and hopefully the kernel should so everything automatically ; the second solution requires defining where is serial port, its parameters, clocks etc, and that involves digging through the old kernel source code in search for answers.



I wrote more than I initially thought I would, I see that I really need to polish my English, hopefully writing more or less regularly will help me with that 🙂 When it comes to smartphones I’ll probably focus on this phone for a while, the next part of the series will have to wait though as I have more urgent things to do, there is a possibility of new blog post about Google Cardboard VR in near future 🙂



DTS is a compiled DTB file, also known as  Device tree, that file contains information about all components of the device, such as CPU, GPU, memory, screen, etc. It allows to compile one generic kernel which then reads DTS file and activates needed peripherals instead of compiling specialized kernel for each phone.

UART (a.k.a serial port, rs232, COM port) — very simple communication protocol, easy to implement even when nothing else is working

Smartphones #1: two bricks in one day

The beginning of the series about smartphones that I experiment on and try to run postmarketOS.


As it turn out I was able to flash and run recovery made for the different phone with the same SoC, bricking Android at the same time :/. There’s no video but adb works and that alone was enough to make a backup from which I was able to retrieve dts file(see glossary). That file may simplify porting process immensely. Why? With newer Linux kernels (including newest one) I may be able to use generic kernel made for the SoC brand used in this phone (Spreadtrum) and combine it with the dts file to get kernel boot on this device.


This will make a fine addition to my collection, there’s an LineageOS kernel for it which, in theory, should allow for easy porting pmos. Oh naive me. After flashing pmos even kernel didn’t work so I thought about making backup of the whole phone before I hardbrick it, but I needed custom recovery for this. Sadly, as most phones have separate boot and recovery partitions this one does not >:(. I can’t just flash recovery since it would overwrite existing kernel, preventing currently installed system from booting. For each system/kernel I’d have to pack files for recovery mode which would be annoying, so for now I have phone with no working system on it, without backup, waiting for influx of my patience.


DTS is a compiled DTB file, also known as  Device tree, that file contains information about all components of the device, such as CPU, GPU, memory, screen, etc. It allows to compile one generic kernel which then reads DTS file and activates needed peripherals instead of compiling specialized kernel for each phone.

fastboot – special mode in smartphones which allows for installation of new firmware, replacing whole partition instead of single files

recovery – special mode in smartphones which allows for installation of new firmware, or updating it without reflashing everything; resetting phone to factory default or making backups

Short follow-up

It is over 2 months since my last entry, so I made this brief summary and try to write more often (yeah, suuure):

  • Retro Day on my faculty, 8-bit edition, there was an opportunity to touch and code in BASIC for Commodore 64, ZX Spectrum+, Atari 65XE. there were some game consoles too
  • I definitely need to  make more documentation, photos mainly 🙁
  • I was in Bytom in HML, HMF ad HDMI labs, it’s incredible how much space all of it takes and how precise readings you can get, for mocap it’s less than 1mm


  • I looked like princess with OCZ NIA,  now I know why this kind of game controller didn’t catch on (BECAUSE IT DOESN’T WORK!!!111)
    • There’s a chance it could work if the device is properly grounded or I change some options in software, need to check that
  • I lost lots of time to disassemble VCR , unsolder modulator, search to what it was connected, in the end I didn’t find anything interesting sine I lack datasheets to make anything useful out of old TV modulator, so I assembled it back together :/


  • “dsp_enhance_stereo 1” in TF2 wins Command of the Year award for me
  • Saints Row 2 on gamepad is way different than on keyboard+mouse, I remember this game was fun but now it went to overdrive 😀


Retro Day:

Find a path from point A to point B, hard version:

From left to right: ZX Spectrum Vega, place for Uzebox (DIY console, not on the photo), Atari Flashback 8 and C64 mini: