DirtyHairy

You can check out the BIOS stubs used by Stella here and by the Unocart and 6502.ts here. Neither preserves the register values, both overwrite 0x81 -- 0x9d with zeroes, and both use and overwrite a few bytes at the top of RIOT RAM. Both leave the registers in the same state, X = 0xff, Y = 0x00 and a random value in A (it's not actually random on the Unocart though). I am not sure about the supercharger BIOS, but iirc the Stella stub derives from code from Eckard Stolberg that was modelled after the original SC BIOS, and the Unocart and 6502.ts stub was written by me to match the Stella stub in behavior. If your code behaves differently with both stubs, then I guess it either depends on 0xf0 -- 0xff or on the exact value in A (it is random in Stella and 6502.ts, but constant 0x9c on the Unocart).

As a third choice, 6502.ts works fine, too (it does not emulate ARM cycles, though)

I like both ideas, and I think they should both work fine. I don't think that writing garbage to the TIA would really matter, to the best of my knowledge it doesn't start in a defined state anyway.

Using the ESP32 for driving the bus has the advantage that code running on the core not serving the bus could prepare data for the VCS without any communication overhead; once it is ready it can notify the other thread, which then can present the newly generated data to the VCS. This is similar to what CDF and DPC+ games do on the harmony, but the game logic on the ESP could run even while the VCS kernel is busy rendering, while the harmony has to put NOP on the bus while the game logic runs. If an additional MCU is used this would require communication between both processors, while the secondary MCU is also busy serving the VCS.

Hm, this has raised my curiosity. I have done some more research, and it seems that first stage loader loads the second stage loader into RAM before it executes it, so this may still take too long (especially as it is likely that SPI flash has not been configured for full speed at this point). Another alternative would be to use a supercap to provide enough power to keep the ESP in deep sleep while the VCS is turned off. As soon as the bus is powered the ESP would wake up and execute a "wakeup stub" from RTC RAM. It seems this happens instantly, before the first stage loader is executed. The stub could park the 6507, and after that startup can continue normally.

Interesting, thanks, there is conflicting information in other places on the web, so it is good to have something close to an authoritative answer ? What would remain to be seen is whether the logic levels of the ESP32 on input pins are suitable for a clean readout of the 6507 bus. I think the boot issue could be circumvented by extending the second stage loader that runs from SPI flash to drive the bus and run a small payload that makes the VCS jump into a RAM routine that idles until a ROM address is driven to a specific value. At that point the loader can continue to boot. The questionable point here is whether the the time required for the SPIROM loader to come up is sufficiently small. I think this would be a very interesting platform if it can be made to work. Imagine one core driving the bus with a VCS program, and the other core running game logic in Micropython... ?

Oh, and there is one other thing, I think that the boot-up time of FreeRTOS is too long (I brought it down to a few 100 millseconds in my own projects) to take over the bus before the 6507 comes up. You'd have to extend the bootloader to first "park" the VCS in RAM before continuing to boot the OS. However, that's doable

I thought about that some time ago and decided that it isn't worth it. There's barely enough GPIOs, and it is not clear to me whether the ESP32 will tolerate the 5V bus of the VCS over an extended time --- you'd have to level shift It's an attractive platform, though, you get two cores and a full RTOS for managing them --- you can allocate one core to solely driving the bus and run everything else on the other one.

I am afraid this is likely to be a hardware issue. All R77s are identical, and if Stella crashes on an individual console even after reflashing the SD card this is likely to be hardware. A possible explanation for this happening only in the latest version might be a different memory access pattern that hits a bad row in RAM that wasn't hit before, or maybe more heat. I'll see whether I can log stdout / stderr in a future build to be sure that we get log output of the crash though, just in case...

Impressive ?

The biggest performance gain on the R77 was PGO (profile guided) optimization, easily a 10% - 20% performance gain iirc. If you want to max out the speed of Stella on your devices, do a custom build and use PGO to optimize it. Apart of that, hardware acceleration in SDL2 is a crucial difference. I don't think X or direct FB access makes much of a difference, though. You can try disabling all unnecessary daemons though to get predictive performance without context switches. There are also some defines that can be toggled in order to enable a bunch of unsafe optimizations, especially for ARM games --- those will give you another 10% or so for these. If you want to dig into this for real check out the R77 firmware at https://github.com/DirtyHairy/r77-firmware-ng and take a look at the part of the build process that relates to Stella.

I can relate. I earn my money as a web developer, and the levels of bad that you can see in mission-critical in-house software can be unbelievable ?

I am afraid your webhook will not work that way, as you need to run sshfs on the R77 if you want to access the files on another machine. You could enable FUSE in the kernel and build sshfs for the R77, but I think SvOlli's idea is easier and more reliable.

Sorry for your trouble, but I suspect that your console has a hardware issue. If Stella "freezes" this usually means that it has crashed --- the framebuffer driver keeps displaying the last picture. The stock build and the Stella 6 firmware image are very different, so it is entirely possible that your hardware is damaged in a way that does not cause issues with the stock image but crashes Stella 6. Some possibilities: Faulty memory. The new firmware uses more RAM, both for Stella itself and for the GPU, and it is possible that it is hitting a bad row in memory that is not accessed in the stock image A bad GPU. Stella 6 uses the GPU for acceleration and vsync, the stock image doesn't A bad CPU. The stock image underclocks the H3 to 1GHz, the new firmware runs the CPU at 1.2GHz, and it is possible that a bad CPU runs fine at 1GHz and causes random crashes at 1.2GHz Thermal issues You can try a new SD card to be 100% sure, but there is not disk access after the game starts, so I don't think that the card is the issue here. Another remote chance is the power supply, the new firmware sucks up more power, so you may want to try another USB supply just in case...

On Mouser and Digikey the STM32F407 line indeed seems to be out of stock. There is a STM32F407VGT6 listed on Aliexpress for 80$/10pc, but of course I won't order just to find out whether the chips ship and whether they are fake or originals That said, to the best of my knowledge the STM32F407 line are widely used chips, so I am pretty sure the shortage is only temporary. In the meantime, you can always use a development board if you want to build yourself a card, those are for sale aplenty. Using a STM32H750 is a bit like firing cannons at mice, but I don't see why you shouldn't be able to modify the firmware to build for it provided you know what you are doing.

Just use sshfs, I took care to make sure that works ? Sorry, I forgot you need access the other way round. You should be able to get NFSv3 working though if you enable the necessary parts in the kernel and busybox configs.

You can flash any firmware you want, in any order you want, but reflashing will certainly not resolve the issues you are describing.

https://github.com/DirtyHairy/r77-firmware-ng/blob/master/INSTALL.md

Hm, that's a good idea.

I'll take a look. I think this is possible, but not trivial as the R77 does not use udev.

Last time I fixed something like this the issue was that the problematic console started to execute code before the ARM had finished booting. I'll take another look at the firmware when I prepare the next update, who knows, maybe some optimization hits me that I missed before.

It is a Stella bug --- check your bug report on github: https://github.com/DirtyHairy/r77-firmware-ng/issues/6

Thanks for the explanation! Great work btw ?

To be clear, did it work on an earlier version, or did it never work?

Thanks, that's precisely what I was looking for.