jpegqs

3x memory access then, because read+read+write. And extra 0 to 3 reads in this work.

> 3 If the low bit on any operand is set, remove it, and replace that operand with m[operand] i.e., a dereference of that address

This dereference option makes a second instruction, this is not OISC.

Open the link: https://www.ioccc.org/2024/kurdyukov3/ogvm.html

Replace the text to the right of the Start button with: doomp.bin

Click the Start button.

Doom will launch in your browser.

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.

Sadly, the Brick Game model from which the ROM dump was taken doesn't contain a racing game, which was in the Brick Game that I had as a child.

Does it count as a screenshot?

Game select screen:

       HI-SCORE              0
         
 /--------------------\
 |                    |
 |                    | NEXT
 |                    |
 |      [][][]        |
 |    []      []      |
 |    []      []      |
 |    []      []      |
 |    []      []      | SPEED  0
 |    []      []      |
 |      [][][]        | LEVEL 12
 |                    |
 |    [][][][][]      |
 |    []              |
 |    [][][][]        |  ROTATE
 |            []      |
 |            []      |    -->
 |    []      []      |
 |      [][][]        |
 |                    |
 |                    |
 \--------------------/

Tetris game:

          SCORE            1000
 
 /--------------------\
 |                    |
 |                    | NEXT
 |                    |
 |                    | []      
 |            [][]    | [][]    
 |            [][]    |   []    
 |                    |
 |                    | SPEED  0
 |                    |
 |                    | LEVEL  0
 |                    |
 |[][]                |
 |[][]  []            |
 |[][][][]            |  ROTATE
 |[][][][]  []  [][][]|
 |[][][][][][]  [][]  |    -->
 |[][][][][]    [][][]|
 |[][][][][][]  [][][]|  PAUSE
 |[][][][][][][]  [][]|
 |[][][][][][]  [][][]|         
 \--------------------/

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.

Anyone want to cooperate with me?

From the ones I got, I found MAUI in the name of the firmware, and on Wikipedia I found these notes:

> MAUI, a feature-phone operating system used with MediaTek-based shanzhai devices, also used on Motorola phones and some Samsung feature phones.

> MediaTek developed an embedded operating system named MAUI Runtime Environment which is based on Nucleus RTOS.

So it's not raw Nucleus.

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.

P.S.: There's an old project based on reverse engineered MT6260 firmware: https://github.com/xobs/fernly

Explanation:

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.

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.

I looked at the latest version of UPX, they began to use LZMA, if this is considered an LZMA decoder:

https://github.com/upx/upx/blob/devel/src/stub/src/arch/amd6...

Then it takes ~2500 bytes, mine is ~500 (static version). But the decompression speed for larger code should be higher, as I noticed.

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).

Still can't improve this stage of encoding, it requires a lot of operations. Maybe there is something trivial, but I don't see it.

Great description, but there is a typo in the second row:

    00000000 abcdefgh ijklmnop qrstuvwx
    -------- -------- -------- --------
    00abcdef 00ijklgh 00qrmnop 00stuvwx
    0000ijkl 0000qr00 0000gh00 00mnop00 <-- missing "qr"
    000000qr 00000000 00000000 00gh0000

I know that. My approach is different: instead of finding the fastest solution to deal with the existing base64 standard, I modify the standard to make it easier to decode. (There are cases when it isn't necessary to follow the standard.)

> Is the rest of the table[1] unchanged?

The rest is unchanged, but there is a trick in that the table indexes are shuffled, and shuffled differently depending on the neighboring values in a 24-bit block of source data.

> but I have had to decode a ton of 64-bit base64 strings, for example

Should be good for small data. It's a pity that no one (or I haven't seen such benchmarks) measures the performance of decoding a large amount of small data (like 1..64 bytes).

Memory bandwidth is the limit, so you can't make it faster than memcpy(). However, copying memory is still faster than these algorithms, аnd it's complicated to make the conversion speed closer to the speed of copying memory.

> but two ternaries become a branch

I need to use inline assembly because of this.