Since Twitter is getting weirder and weirder here’s what I’ve decided to do:
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 game uses QueryPerformanceFrequency() and QueryPer-
formanceCounter() 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.
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.
I’m moving between servers, for a few days some parts of the website may be unavailable.
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.
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”.
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.
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.
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.
Luckily, .pc to .bmp converter already exists: https://forum.xentax.com/viewtopic.php?f=16&t=16944&p=160362#p146133,
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: https://github.com/StuntKit/stunt_gp_formats
this is way overdue status update, sorry for that
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?
fastboot 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 LineageOSSo 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
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:
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
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
It is over 2 months since my last entry, so I made this brief summary and try to write more often (yeah, suuure):
Hardware:
Entertainment:
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:
Finally I’ve made this website bilingual and easier to manage for me 😀