Platform
I noticed that it's not immediately obvious which hardware platform I'm using, because it's not exceedingly common. It's impossible to remember its name because is  "ESP32-8048S050". It's cheap and yellow and it shares DNA with the better known "Cheap yellow display", but it's not the same. This one has a 800x480 IPS screen and it's driven directly by ESP32-S3 LCD peripheral, thus allowing me full control of refresh rate, making it as close to 50Hz CRT as possible.

Now for the updates...

mode512
 I was afraid it's not going to be possible because of timing constraints.

But it turns out it's alright. I already implemented the key optimisation for this in the early stages of porting. The pixeling is done in pairs. So that each pair of pixels, which are always the same in 256-pixel mode, requires only one palette RAM access. So I already had the 2-pixel palette in place.

All I needed to add was some palette processing for the 512-pixel mode. The values for left-pixel would be replicated into every index on the right side, and the values for the right-pixel would be replicated into every index on the left side. When the mode switches, precalculated palette is copied in place swiftly. The main raster loop didn't need to be modified at all !

There's something about this version of BASIC called Бейсик-Корвет that I find magical. It's the font and the fact that it's hi-res and black and white and just a bit of childhood sparkle.

A video short featuring giant hands working tiny keys:

RUS led
This is a feature not really well supported in the emulators. The matter of fact is that it's an output line directly connected to a 8255 pin and as such it is subject to all the regular abuse like PWM. Strangely there are no programs known to me that would implement LED breathing for example. The emulators tend to just take the whatever value and display it at the end of a frame, if they bother to display it at all.

In v06x-mini I initially tried to update it immediately, but for now I resorted to just output the state at the end of the frame like other emulators do. The reason for this is very slow SPI communication with ESP32 drivers, which takes at least one FreeRTOS tick to complete. I think implementing SPI link using SPI HAL should not be a problem, but it's a lower-priority task for now.