Trying to improve x49gp

[Claudio L.]

(08-27-2018 10:39 PM)3298 Wrote:  

(08-27-2018 09:07 PM)Claudio L. Wrote:  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.

At the risk of sounding annoying, does "new patches" actually include the one from May or just the bunch from the last few days? Because the one from May didn't end up in your GitHub repository yet, so you might just have skipped it unintentionally. If that's not it, I'm out of ideas for now.

I tought everything ended up in my gihtub fork, if not then that explains it. I'll fix it by reapplying old patches too.

(08-27-2018 10:39 PM)3298 Wrote:  

(08-27-2018 09:07 PM)Claudio L. Wrote:  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).

Yeah, that's kind of obvious. A file chooser window is pretty straightforward (I can steal code from the SD file chooser windows in a pinch), and after that it's just a 'read' call with the firmware location (just behind the bootcode, which I already know is 16KiB long) in the mmap'ed flash file as buffer. The fancy command-line parameter parser I wrote makes adding new flags pretty much a drop-in affair, so the IDE automation isn't that much more complicated either. I can even make that flag trigger the interactive selection when no filename is passed on the command line.

Sounds perfect. I did some tests with 'dd' to create the flash file manually and it's very straightforward but there's something else I didn't catch before:
1) Dump the new firmware at 0x4000 as we discussed.
2) Change the 16-byte string at 0x4000 from "KINPOUPDATEIMAGE" to "Kinposhcopyright" (case-sensitive!). This is a marker the bootloader uses to tell if there's a valid firmware installed or not.

Also, there should be perhaps another option to wipe out with 0xff all the way to the end of flash. This is not needed for newRPL but stock firmware needs a clean flash after the binary, so it can initialize those banks.

PS: Can we add another command-line option '-r' to reset the CPU when x49gp starts? When you manually change the firmware you must trigger a reset, and if the change in firmware happens outside of x49gp, we need to tell x49gp that we need a reset. Otherwise it will try to resume execution with a completely different ROM, it's a sure crash (resolved by Reset from the menu, I know, but still, the idea is that when used as a debugger we should be able to start x49gp from a script to a well-known state).