Trying to improve x49gp

[Claudio L.]

(08-27-2018 08:20 PM)3298 Wrote:  But there's a solution: Use F12 to reset instead of the menu. That way the menu won't eat your + and - keypresses, so they can be held down before punching F12. The F12 keybind is not mine, it comes from chwdt's fork which my patches go on top of.
Alternatively, right-click on + and - before opening the menu. As long as you don't left-click on any keys or press / release any hardware keys mapped to virtual keys, that should keep them down even across menu actions. That mechanism is not mine either (it's ancient), though one of the initial big batch of patches did tweak something about it.

Ohhhhh... so right-click on a key leaves it pressed? I had no idea, that's an interesting feature.

(08-27-2018 08:20 PM)3298 Wrote:  I did flash x49gp a few times - not with newRPL, but as far as x49gp and the bootloader are concerned, the difference to the stock firmware should be just data and a filename. I noticed that you made your newRPL filenames fit into 8.3 limits with only alphanumeric characters, so that filename should be fine. The only things that might cause trouble are the names of other files in the same directory. The obvious thing to try would be using a directory with just update.scp and newrplfw.bin in it. Unless you did that already...

Yes, I did. Created an empty dir, put just the firmware newrplfw.bin and update.scp, and still the same error. The error comes up in a GUI pop-up window, it's not the emulated firmware complaining about the FAT image, but I think the VVFAT emulation layer complaining about perhaps the path of the directory I passed. The firmware never even detected the virtual SD card.

(08-27-2018 08:20 PM)3298 Wrote:  

(08-27-2018 01:39 PM)Claudio L. Wrote:  c) The text in the menu comes up green when using grayscale mode. It's correctly black when using B&W mode. I think we need to save/restore the state of the gdk context while doing a screen update.

WHAT? That was supposed to be fixed with patch 24, the one from end of May... I'm confused.

Me too, and when you use the stock firmware it's all black, but under newRPL it does come out green on mine, it's the latest from my github + your new patches.

(08-27-2018 08:20 PM)3298 Wrote:  I initially planned to put equivalent C code into flash.c - but then I found out that the bootloader is perfectly fine without firmware. Overwriting the serial number is not necessary either, because the ones from the Makefile were already baked into the bootcode versions at the appropriate place; it was a no-op unless one overwrote the bootcodes shipped with x49gp. However, the Makefile had another step, which was writing certain values to specific places (at regular intervals, but not throughout the entire flash). I wasn't so sure that this would be appropriate for firmwares other than the stock one (I explicitly want to support custom firmware), so I figured it was best to hand the job of finding out what needs this treatment over to the bootloader and/or the firmware, which ought to know their own needs better than me.
I see the point about automated re-flashing though. Maybe have the flag build an SD image in memory and inject some keypresses? Resetting the calculator should be done anyway after switching the firmware, because not doing so amounts to an unsafe hot-patch.

The other bytes that were written were to initialize the user flash banks for the stock firmware. That's easy to do with the command PINIT, so you are right, there's no need to do that.
If the serial number doesn't need touching, all you have to do is have the user select a firmware file, open it and load it at offset 0x4000 of the brand new flash, that's it. That's all the bootloader does.
PS: When I say offset 0x4000 is in bytes, from C (as opposed to an offset in nibbles from the emulated side).