Trying to improve x49gp

[3298]

(08-27-2018 01:39 PM)Claudio L. Wrote:  I had a little trouble with patch 28 not wanting to work but I finally fixed it manually and got it all working.

I'm guessing that means you encountered additional compilation errors ... if so, could you post them so I can get them fixed? Because it's all working fine without so much as a note from the compiler over here.

(08-27-2018 01:39 PM)Claudio L. Wrote:  a) Keyboard emulation is somehow not letting me use the + and - press while doing reset from the menu to recall the boot loader. Also it's very hard to do On-A-C or On-A-F. Anyway, I figured the only way to access the bootloader was to delete ~/.x49gp/flash. Perhaps there should be an option in the menu to do a reset while simulating + and - for 1 second or so?

Yes, pressing + and - quickly enough after clicking in the menu is nearly impossible. 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.

Flashing newRPL:

(08-27-2018 01:39 PM)Claudio L. Wrote:  This worked a couple of times and failed horribly about 80% of the times. Got an error message about invalid file name with some chinese symbols all the time, so it might be an ASCII vs. UTF8 problem.

That's weird. I didn't experience anything like that so far. 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...
I also deliberately left the Makefile targets for generating SD images in, just in case someone needs to know how to generate a usable image. That plus the appropriate SD mounting option should work too; it bypasses the whole VVFAT driver and performs direct access to the image file, so it's probably more robust than the VVFAT driver. Especially when taking the age of the VVFAT driver version we have into account (from QEMU 0.9.0); there may be bugs in it.
... I know, going through an SD image is significantly more work. I'm not suggesting it as a permanent solution, but as an option to test once. Due to the simplicity of the code behind that, it'll probably work; if it doesn't, we'd have to bust out the debugger to find out if there's a bug hiding in that simple code or if it's the bootloader acting up (I hope not, because that would be really painful to work around).

(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.

(08-27-2018 01:39 PM)Claudio L. Wrote:  On second thought, we could also have an option in the menu to "manufacture" a flash image from a firmware file without using the bootloader. This functionality was in the original Makefile, it would copy the boot loader, patch the serial number and write a firmware image into the flash file. Much of this is already done when the flash file is deleted and recreated, all that's needed is to ask the user to select a firmware file. Ideally, a command line option to do this would be handy too, so the IDE can load custom firmware when starting the debugger.

Correct, I took that section out of the Makefile. 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.