DirtyHairy

I agree. There are no hmove pulses in the visible part of the scanline here. Generally speaking, to the best of my knowledge this doesn't happen for a sufficiently late hmove strobe --- afaik (and as we have implemented it in Stella), hmove clocks only happen at hclock values that are a multiple four, and for a late hmove the first clock will coincide with the first clock of hblank, although the "extended scanline" is triggered before (and subsequently reset when hblank starts). Only if the "late" hmove happens sufficiently early there are pulses during the visible part of the scanline, and the result will be influenced by the phase difference Eckhard describes. If I play with the parameters of hmove, (delay, shift the pulse times, etc.) I totally break the kernel (the systematic positioning change smears it over the whole screen), so I think something else is happening here. In addition, we also support changing the "phase" of the movement pulses as Eckhard describes in Stella, and doing so does not affect the moviecart kernel.

I can only repeat myself: enabling PGO (profile guided optimisation) will easily give a 20% - 30% speedup. Moving from Retroarch to plain Stella would probably give another sizeable boost. The R77 has a similar CPU, and while we had to switch to PGO and do some optimisations to Stella for ARM games, CPU usage for non-ARM games was more like 60% to 80% (instead of 70% to 100%). With PGO and plain Stella the R77 hovers around 100% for very heavy ARM games (like Mappy) and much lower for everything else.

Source code needs to be compiled into an executable before you can run it. I am afraid that, unless you know how to build from source, you'll have to wait for a new release. What OS are you using? Sorry, didn't read closely enough, you said .exe, so evidently Windows 😏

Yeah, looks the same on Stella. If you look at the code, you find It uses the value at D9 to index into a table and loads the playfield from there. The players are positioned such that the flags align exactly with the playfield pixels, so any value in d9 will load something that covers a subset of those four flags.

At least that's the maximum that can be displayed.

Fixed in git, thanks for discovering and reporting this issue 😏 The technical details (if anybody cares): The code positions P1 and P0 next to each other for the 48 pixel trick on the right side (to display the fuel gauge) and briefly switches to two copies, wide spacing to get an additional decode for both players on the left side (and display 16 pixels worth of lives). The players always show all four flags, and the playfield is used to cover the lives that have been lost, starting from the left. P0 comes first, and it so happens that NUSIZ is written in the same cycle in which the draw is decoded. As we always process the tick before the writes we miss this decode, and P0 is never displayed. Other explanations are possible, but we have very hard constraints from https://github.com/stella-emu/stella/issues/63 and other testcases that work correctly, and the solution that I settled arguably has the smallest possible fallout on all the other tests and testcases that probe those edge cases.

OK, that explains the issues. The original firmware for the R77 uses an ancient version of Stella 3.x. Starting with version 4 has a new and much more accurate TIA core, the old core has multiple accuracy issues.

Is this the official R77 firmware, or the Stella 6 community build? The community build should now have any graphical glitches.

I strongly agree 😏 Either emulation is running too slow, or something is wrong with the timing (I still haven't fully ditched my theory of something being wrong with the oscillator).

@karri The dump is in /tmp, although I don't remember the filename. I suppose you can hex encode and then copy it over the serial line by doing something along the lines "sleep 10; dd if=/tmp/rom.bin.b64 of=/dev/stdout bs=1" on the device and then starting a corresponding dd on your computer while the the terminal is running --- then you can check the contents of the dump.

Sure, in the sense that people would use the same web page to first flash the Linux image, and then flash the dumper.

You can use the proprietary Rockchip flashing tool ("update_tool") for Linux to flash from a Linux VM. On Apple Silicon you can either use a Rosetta 2 enabled VM, or you use qemu-user. Not very convenient, but it works fine *and* it works on Apple Silicon. The elegant solution would be to create a JavaScript flasher that uses WebUSB and runs in Chrome. There are reverse engineered OS tools for flashing, and the protocol looks straightforward. Unfortunately, I couldn't get flashing with those to work, so some reverse engineering would be required to get that working, but I think it is definitely doable.

Good point. My chip just got slightly warm, not hot, so I didn't consider it, but I didn't check the temperature systematically. Maybe someone who has issues should open their device and check the temperature with their fingers.

Yeah, pretty much certain. I couldn't find this for the 3128, but this is from another Rockchip "datasheet" (or what they like to call the public documents that they publish 😏) for a different SOC. Most likely the scheme is similar, and the diverging number is just die lot and production date.

I think this is very unlikely. If this were the reason, that corruption would have to affect several people, all in the same sector, and the damage would have to be just in the right place to corrupt the config and not damage anything else.