DirtyHairy

Audio on plain Stella will start to stutter when the CPU cannot keep up, and if the GPU is too slow you would see dropped frames, but audio and overall speed would not be affected, and you would see an uneven flicker on flickered sprites and slight "jump" in movement. However, I have no idea how RetroArch enters the equation here. It is possible that it dynamically resamples to avoid skipping if the host cannot keep up, and I've no idea whether it uses Stella's scheduler (or something similar) which renders and emulates on two different threads (which is why Stella only skips frames when the GPU is tool slow). All in all, the presence of RA in the equation complicates things and makes it very hard to draw any conclusions from these observations, at least for us Stella developers (the RA driver is not maintained by us).

That's not good, it means that Stella crashed. However, Stella has been rock solid during gameplay for a long time, so this is most likely either caused by a bug in changes made by Atari / Plaion, an out-of-memory or a hardware issue (we have seen plenty of issues with bad RAM and overheating on the R77). @Ben from Plaion is Time Machine disabled in the Stella configuration? I forgot how much RAM is in there, but if Time Machine is turned on saved state will accumulate and may crash Stella if there is not enough RAM.

https://wiki.t-firefly.com/en/Firefly-RK3128/Flash_Image.html 😏

Why two processes? Two threads are sufficient, and they share memory. Use std::atomic to increment an atomic counter.

Defintely. However, imo there is little reason --- so far, the bankings work find, and the way they are written is definitely easier to read than handcrafted assembly 😏

The Uno firmware is written in C and runs from flash, while the Harmony (to my knowledge) is hand-optimised assembly running from RAM.

Don't overestimate the cycle budget on the STM32. From my experience with the UnoCart the headroom is not that big, and some banking schemes like DPC can break even if a new compiler version emits slightly less efficient code. I would estimate that you would get about a factor like maybe 2 of headroom with extremely simple banking schemes, but certainly not more. I wouldn't be surprised if real cards in fact overclock much better than the Uno / Plus.

This is highly nontrivial. Naively, there is about nothing that the emulator can do while waiting for the result of a peek from cartridge space --- anything that could be done depends on the result of the peek. The only thing that comes to mind is forwarding TIA and RIOT emulation in that time window.

Nope. No way to use interrupts from userspace. Afaik the closest you can get is the the in-kernel GPIO driver, which lets you do a select on a fd that returns if an interrupt was triggered --- this is what libpigpio does. But that means yielding to the scheduler, and then we're talking microseconds again. I think polling is the only way here.

Ship two builds of Stella, one rtstella for bitbanging, and a regular build. Run a daemon that watches the port. Once a cartridge is inserted the daemon kills the running Stella instance and starts rtstella, once a cartridge is removed rtstella is killed and ordinary Stella runs again (displaying the dialog). Why do you want to encode configuration in a "dummy cartridge"? Just use a configuration file 😏For the TV format: just add a hardware switch and wire it to a GPIO.

My thoughts exactly. I am not sure what happens on a read from a write location on a real VCS, either. No one is driving the bus, and I would assume that most of the time the bus holds the last value. I guess the driver chip behaves differently than a real 6502 bus. Electronics is not my strong side, but would an array of pulldowns help? That would put the bus in a well-defined state if noone is driving it.

That't the one that I saw initially and that I couldn't find yesterday evening. It gives the corresponding instructions for arm32. However, there is a small flaw: the function on the post only reads the lower 32bit word. The counter is 64 bit wide, and you can use MRRC to transfer both words.

What's the oscillating mess on the purple line at the beginning of the write cycle on the cart side of the SN74?? Seems it takes almost 0.5us until the data bus is stable after DIR has changed.

Sorry, I was mostly afk the last few days. Regarding 64bit vs. 32bit: after looking at some benchmarks, I am not as convinced as I was before that 64bit is a good idea. Sticking with aarch32 is definitely an option, and the performance counter can be used there just as well, with minor differences in setup. I'll order another SD card and set it up for 32bit.

That looks pretty much awesome to me, much better than I would have initially hoped for. We "just" need to get the timing reliable and straight.

Ho-hum, good question. It may be that those threads are dispatched from the emu thread, in which case they would inherit the affinity and RT priority and will start competing with the emu thread for core 3. They should cause a lockup, though. Do you see a difference if you tick that option? Oh, btw, does only the debugger freeze Stella, or does the menu freeze it, too?

I'm not convinced 😏 The performance counters are part of the ARM architecture spec, nothing PI specific, and they should work fine. Maybe we are using them wrong, maybe there is something we overlooked, and maybe there is something else wrong altogether. We'll only find out by systematic debugging. What would help: Test the performance counter against a well-known clock source Generate a square wave on a GPIO pin by using a loop against the counter, and check that with a scope. Both are on my list, but not today (and probably not tomorrow).

Awesome! The lag comes from the scheduler periodically interrupting the emulation thread. Changing /proc/sys/kernel/sched_rt_runtime_us will disable that. 😏 It's not a command, but a kernel parameter. You have to append it to the kernel command line (cmdline.txt) on the boot partition. I just doublechecked and tested myself, you have to append "isolcpus=domain,managed_irq,3" . The nohz part would also be useful, but we'd need to rebuild the kernel to support that. Anyway, this will reserve the fourth core for Stella to claim, and no other threads or processes will be scheduled there. Nah, I think those are just bugs in my thread handling. I tried to make sure that the emulation thread gives up control and yields if Stella quits emulation mode, but it seems I missed something. I am pretty sure that I can debug and solve this when I find time.

The effect would be the same. After more digging, it seems like we can fully disable scheduling on the emulation core after all. Specifically, adding "isolcpus=domain,nohz,managed_irqs=3" to the kernel command line should fully disable scheduling and interrupts on the last core, and only threads with explicit affinity will schedule there --- this will give us full owmership of the core. Furthermore, "echo -1 > /proc/sys/kernel/sched_rt_runtime_us" allows realtime threads indefinitely without interruption (although i am not sure whether this is required with isolcpus). A good reference is https://canonical.com/blog/real-time-kernel-tuning . However, we should first identify and understand the current issue with the performance counter, I don't think it is related to scheduling.

I don't doubt the counter or the timers, I think there is something fundamentally wrong that we are overlooking --- there is too much weird behaviour that does not line up for me. Could you do a test? For a well-known ROM (say Combat) log each peek and poke in an array, and write that to disk after about 1000000 entries. For each peek / poke the log should contain the values of the performance counter at entry and at exit, the address, the type (peek/poke) and the value read (if applicable), preferable in text format, one line per peek/poke. This should give us some insight into what is happening. Just take care to reset the log in ::reset, otherwise the entries from TV standard detection and actual emulation will mix 😏

Hm, my gut feeling is that this is too long to get full speed (doesn't leave enough time for emulation and for catching up with lost cycles), but anyway, that's not the issue here. From a brief look I can't see any issues in the code. You should definitely implement ::Reset though --- Stella first runs the emulation to detect the video mode, and then resets the system before running the actual emulation. Can't see any obvious issues with that here, though. Maybe a look at the generated assembly gives a hint. I'll take a close look later this weekend when I find more time.

Something is very wrong here. You are right, the performance counter measures CPU cycles. If you have set the PI to performance, then one 6502 cycle is roughly 1000 ARM cycles, so 7000 cycles is already too slow by a factor of 7. The bus should stabilise much faster, as it does on a real VCS. Maybe electrical issues? On the Stella end I suspect a bug. Can you maybe push your code to a branch so I can have look at it? Each read should look roughly like this: 1. Check how much time is left from the last cycle and spin until P <= (T_current - T_start) 2. Store the counter at the beginning of this cycle in a T_start 3. Write the address 4. Wait for a short delay until the bus stabilizes 5. Read and return the value T_start = counter at cycle start , T_current = current counter, P = bus cycle length in ARM cycles Emulation happens between 5 and 1, between one call to peek and the next.

Hm, you may be right, I am not sure whether I am remembering it correctly either 😏

Yeah, that’s just a bug, I’ll take a look.

I think a merge would be fine. The rtstella scheduling code seems to be stable and work as it should, and you have an ifdef in your timing code that checks for rtstella, so people can try both variants. Anyway, rtstella is the way forward, the normal scheduler will never work at full speed with a real cart..