I think not. There is not only Tetris, but also Snake, and two types of "shooters" - one removes blocks, the other creates. And many variations of these four basic games.
I don't know if the Mediatek chips have overridable pins, but the Spreadtrum does. There are also different LCD panels that have slightly different interfaces for which you will need to write a driver (and find it from the original firmware). The button mapping also may vary.
So writing firmware that will work on most phones on a particular chipset will not be so easy.
I recently ordered and researched the cheapest feature phones (and some smartwatches), looks like half of that market is occupied by Unisoc with the SC6531(E/DA) chipset (from the Spreadtrum company they bought). It uses Mocor OS. The second half of this market is occupied by Mediatek MT6260/MT6261 chipsets. I wrote tools to run my code on these chipsets.
There are also phones on Mocor5 OS, a little more expensive, it's actually Android 4.4 on the Spreadtrum SC7715 chipset.
I didn't find any Java here, but these CPUs have a Jazelle ARM extension to run Java bytecode.
I wanted to run Doom on one of them. So far I have LCD control for SC6531E (with 9306 LCD panel), USB control for SC6531E/SC6531DA and USB control for MT6260/MT6261 (using API from bootloader).
I load the code not while the OS is running, but through boot via USB.
SC6531DA is similar to SC6531E, but some constants have been changed, so additional research into its firmware is required.
I have enough knowledge to run some game on the SC6531E, but a lot of work still needs to be done.
1. There are no data members inside X, in this case the size of the structure is 1 byte.
2. main() does nothing.
3. *x = new X[100]() - this requests a new array of 100 elements of type X, at a stage before main() is called.
4. The new[] operator is overloaded in the class, this operator must return the address for the requested array. It returns the address of the empty string object plus 1.
5. For each of the 100 elements, the X() constructor is called, the "this" address for those elements will be the value returned by new[] plus an index from 0 to 99. The X() constructor converts this to a number from 1 to 100 by subtracting the address of the empty string. This is the only UB here, but it works in all major modern compilers since they combine the same strings into one instance.
1. new[] doesn't return a pointer that is suitable for storage for the objects. Yes the objects are empty (only contain padding), but that doesn't absolve from UB.
2. "" is used at two places, assuming that they refer to the same const char array. This is optimization is allowed, commonly implemented, but not guaranteed.
3. An empty struct having 1 byte size is also implementation defined, although common ABIs specify this. It also wouldn't make sense to implement it differently.
Since new[] does not actually return an array (returns a pointer to 1-past-the last element in "" string/array) and later "this" pointer is calculated using an arithmetic operation that goes out of bounds (for elements that > 0), that would also be UB. ""+2 would be UB for example.
But maybe it is not UB because it is not calculated explicitly by the program, hard to tell
The compression method in UPX is much simpler (therefore smaller and faster), but the last time I saw it was over 10 years ago, something may have changed. But LZMA should provide better compression.
I want to make the decoder small enough to be used in compressed executables. Where decompression performance doesn't matter because LZMA is far from fast decompression, and small code without inlining makes it worse (but bearable).
I have suggested them to look at my version, but I think UPX not much hardcore for that. Because I'm guessing decompression speed is more important to UPX than the extra 2kb.
Replace the text to the right of the Start button with: doomp.bin
Click the Start button.
Doom will launch in your browser.