Threaded Mode | Linear Mode

3298 · 08-27-2018, 10:39 PM

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

Well, that's at least something to track that down. Although that pop-up window bit puzzles me even more, because I only programmed two places where dialogs are opened, and neither of them is a message window (one is the directory version of the file chooser, the other is the file version; GTK does not support both at the same time, otherwise I'd have used just one). It might be GTK itself complaining about ... something, whatever it is. I'll do some tests with non-ASCII paths tomorrow.

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

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

Oh, so that's what they were for? I'll need to check the user banks in the stock firmware then, to see if I need to do something about them. In an ideal situation, PINIT shouldn't be necessary; if it is, I have to put a note into the manual or, better yet, reimplement the flash sector marking. Custom firmware are forced to deal with remnants of the user's flash banks on real calculators anyway, so I'm less concerned about breaking them with this now.

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