Trying to improve x49gp

[Claudio L.]

(11-18-2021 07:16 PM)Eric Rechlin Wrote:  Yeah, I'll approve it. I was planning to do an update in the next week or so anyway. How did you get the binary in the first place? Extracted it from a calculator?

And yes, HP sent me a lot of this stuff specifically to add to my site in the first place. I'm sure this is in the spirit of what they already provided.

Excellent, thanks!
The boot code was extracted from a calculator using simple PEEKARM commands and saving the bytes to the SD card.

[Claudio L.]

I packed the bootloader code and requested upload to hpcalc.org.
I also committed a few changes:
* Removed all binary files from the repository
* Created a 'firmware' folder, empty in the repository, that will receive all the binary files
* Made the changes in the code so it looks for the bootloaders in that firmware folder
* Added a bash script (pull-roms.sh) that pulls and extracts the official ROM 2.15 from hpcalc.org, the bootloaders (when the file becomes available I may need to fix the name, we'll see), and the latest unofficial newRPL rom image. All binaries are placed into that 'firmware' folder.

So everything is ready to receive a license file making it explicitly GPL, I don't think there's any other issues that could prevent someone from making clean (as in not in violation of anything) binary packages for Linux. They just need to run the pull-roms.sh script as a post-install script.

Now we just wait for the file to go live on Eric's website...

[Eric Rechlin]

Looks good. Filename will be all lowercase when posted though, so the URL should be the following once I upload it:

https://www.hpcalc.org/hp49/pc/rom/hp-ar...loader.zip

[3298]

(11-19-2021 09:04 PM)Claudio L. Wrote:  I packed the bootloader code and requested upload to hpcalc.org.
I also committed a few changes:
* Removed all binary files from the repository
* Created a 'firmware' folder, empty in the repository, that will receive all the binary files
* Made the changes in the code so it looks for the bootloaders in that firmware folder
* Added a bash script (pull-roms.sh) that pulls and extracts the official ROM 2.15 from hpcalc.org, the bootloaders (when the file becomes available I may need to fix the name, we'll see), and the latest unofficial newRPL rom image. All binaries are placed into that 'firmware' folder.

So everything is ready to receive a license file making it explicitly GPL, I don't think there's any other issues that could prevent someone from making clean (as in not in violation of anything) binary packages for Linux. They just need to run the pull-roms.sh script as a post-install script.

Now we just wait for the file to go live on Eric's website...

I checked out the repository, well spotted on the character-skipping bug. Apparently I never properly tested parameters on long options, only on short ones. That means I have to fix another project which also uses this option parser ... how embarrassing.

The binaries removal has an issue though: the Makefile's install target wants to install the bootcode images, and accordingly the main program (specifically, the flash initialization code in flash.c) expects them to be installed too.
Also, I'm getting doubtful, can we risk packaging the bootcode as downloaded from hpcalc.org, or do we need to ask the user to point x49gp to it, like with the main firmware?
The ultimate solution would of course be the source for an independently developed bootcode, because that would let us install it without license headaches. That's a tall order, though. At least between the two of us, a semblance of "clean-room reverse engineering" would be possible (one person decompiles and writes a specification, the other implements the specification into new code). I am aware that once the firmware starts, the bootcode is irrelevant, but it does contain code to update the firmware if it's not valid ("Kinposhcopyright" signature missing) or the user requested it with + and - pressed during boot; and I don't know what kind of hardware initialization it might perform.

(11-18-2021 06:41 PM)Claudio L. Wrote:  Mmmm... I understood it in a completely different way. The way I understood it is that a license being "compatible" means that source code under that license can be included in a GPL project. GPL being the main license covering the entire project, swallowing the other license. Anyone modifying the code that's under the other license as part of the GPL project would still have to release the changes in compliance with the GPL license, even if those files were originally BSD licensed for example that doesn't require that. In other words, the GPL attaches on top of the other license and imposes its restrictions.
The other way around doesn't work: any work derived from any GPL'd source becomes GPL'd. You can't derive work from a GPL'd project and place it under a different license, even if it's compatible, the new work becomes GPL.

Looks like I should visit the juristic section of the nearest university library then. Wikipedia at least indicates that license compatibility is a more difficult subject than I imagined. Thanks for the headaches, Mr Stallman...
One thing to note though: we may not be allowed to change the license of the QEMU part, but that doesn't prevent us from picking a license for the rest of the code that's compatible in that linking direction. That leaves more than one choice, as far as I can see, which is what contributors should have a chance to weigh in on.

By the way, does anyone know where to get the history from before the CVS to SVN import? Because I fear that part (including committer info) may be lost.

[Claudio L.]

(11-19-2021 11:50 PM)3298 Wrote:  By the way, does anyone know where to get the history from before the CVS to SVN import? Because I fear that part (including committer info) may be lost.

Check out Eddie's (Christian) site on the Wayback Machine:
https://web.archive.org/web/200710201509...index.html

That gives you the complete story, I don't know why he removed this page from his web, maybe the Sourceforge page should point to this wayback machine link just for historic purposes.
The history before git is pretty short, he got the idea and got the whole thing working in about a month! The following year he registered the project in Sourceforge and basically abandoned there. Later Egan took over maintenance from him, and from there the history is in the commits.
I can't recall when but at some point Egan was too busy to pull my changes and my repo became ahead of the one in SF. I tried to contact Eddie (Christian) to pull my changes to make his repo the official one but couldn't get a response from him, so my repo is still ahead of the rest (but shouldn't be!).

[gwh]

(11-20-2021 02:05 AM)Claudio L. Wrote:  

(11-19-2021 11:50 PM)3298 Wrote:  By the way, does anyone know where to get the history from before the CVS to SVN import? Because I fear that part (including committer info) may be lost.

Check out Eddie's (Christian) site on the Wayback Machine:
https://web.archive.org/web/200710201509...index.html

That gives you the complete story, I don't know why he removed this page from his web, maybe the Sourceforge page should point to this wayback machine link just for historic purposes.
The history before git is pretty short, he got the idea and got the whole thing working in about a month! The following year he registered the project in Sourceforge and basically abandoned there. Later Egan took over maintenance from him, and from there the history is in the commits.
I can't recall when but at some point Egan was too busy to pull my changes and my repo became ahead of the one in SF. I tried to contact Eddie (Christian) to pull my changes to make his repo the official one but couldn't get a response from him, so my repo is still ahead of the rest (but shouldn't be!).

The page is still up: http://www.brainaid.de/people/ecd/x49gp/index.html

Good move on the changes. Latest version builds fine for me except the path of the bootloader files about I sent you a tiny PR.

[Claudio L.]

(11-20-2021 06:18 PM)gwh Wrote:  The page is still up: http://www.brainaid.de/people/ecd/x49gp/index.html

Good move on the changes. Latest version builds fine for me except the path of the bootloader files about I sent you a tiny PR.

Interesting, the page is still there but the link from the main page no longer links to it, so it's not accessible from the main page.

Anyway, I fixed the URLs, removed the www on hpgcc3.org (there was an unnecessary redirect) and changed the bootloadets URL with the one Eric provided. Check out the last commit.

I did not fix the Makefile, though.

[Claudio L.]

(11-19-2021 11:50 PM)3298 Wrote:  ...
The binaries removal has an issue though: the Makefile's install target wants to install the bootcode images, and accordingly the main program (specifically, the flash initialization code in flash.c) expects them to be installed too.

The installer should not do that. We need to remove that part. The Makefile will be used to create the package, and the package should not include any binaries either.

(11-19-2021 11:50 PM)3298 Wrote:  Also, I'm getting doubtful, can we risk packaging the bootcode as downloaded from hpcalc.org, or do we need to ask the user to point x49gp to it, like with the main firmware?

Bootcode cannot be packaged. The user doesn't really need to do anything as long as the script pulling the binaries is called at the end of the package installation, as a post-install script. Then the package is distributed clean, it downloads the binaries only for the final user installing the package.

(11-19-2021 11:50 PM)3298 Wrote:  The ultimate solution would of course be the source for an independently developed bootcode, because that would let us install it without license headaches. That's a tall order, though. At least between the two of us, a semblance of "clean-room reverse engineering" would be possible (one person decompiles and writes a specification, the other implements the specification into new code). I am aware that once the firmware starts, the bootcode is irrelevant, but it does contain code to update the firmware if it's not valid ("Kinposhcopyright" signature missing) or the user requested it with + and - pressed during boot; and I don't know what kind of hardware initialization it might perform.

While I've seen what the bootloader does, the code I have is unlikely to fit in 16 kbytes. To make a true bootloader you need a USB driver to flash the firmware, a FAT file system driver to read an SD card and flash the firmware. We have both working on newRPL, but if it doesn't fit in 16 kbytes or ROM and uses only 32 kbytes of RAM, it's game over. Of course, that is for a real bootloader on a real calc, x49gp doesn't need USB or SD card, there's no need to update the firmware so perhaps a simple "pass thru" bootloader able to launch the firmware without doing anything else would work fine.

[Claudio L.]

I noticed Eric uploaded the bootloaders, so I tested the script and worked flawlessly.

Now as far as the Makefile, the pull request I received tries to fix the folders, but we really need to remove all references to the firmware from the Makefile. The Makefile should NEVER pull binaries, that needs to be left for the post-installation script of the package.

If the user is building directly from sources, then the user needs to manually run pull-roms.sh afterwards. If installing via apt/yum, etc. then the package should automatically run the script after installing x49gp.

It's important for 2 things:
* Building x49gp should not depend on whether those binaries are available or not.
* Binaries need to be pulled by the final user, not the person building the package.

[gwh]

(12-02-2021 02:39 PM)Claudio L. Wrote:  I noticed Eric uploaded the bootloaders, so I tested the script and worked flawlessly.

Now as far as the Makefile, the pull request I received tries to fix the folders, but we really need to remove all references to the firmware from the Makefile. The Makefile should NEVER pull binaries, that needs to be left for the post-installation script of the package.

If the user is building directly from sources, then the user needs to manually run pull-roms.sh afterwards. If installing via apt/yum, etc. then the package should automatically run the script after installing x49gp.

It's important for 2 things:
* Building x49gp should not depend on whether those binaries are available or not.
* Binaries need to be pulled by the final user, not the person building the package.

I confirm that the pull-roms.sh works now that hpcalc.org has all the files.

Concerning the Makefile: if I understand correctly, building x49gp doesn't require the bootloaders binaries. It only needs to be documented that these bootloaders binaries are needed at runtime, where to find them (hpcalc.org url) and where to install them ( $PREFIX/share/x49gp/ .) The rest is the packager's concern.

I'd go as far as copying pull-roms.sh to $PREFIX/usr/doc/x49gp/ or $PREFIX/usr/share/x49gp/

Main concern is that

Code:

make install

then installs a non-functional software without manual action from the user (as root) but maybe that concerns a tiny minority.

[gwh]

I've made the proposed changes in a new PR

I updated my personal packaging script to illustrate: https://github.com/gwenhael-le-moine/sla...SlackBuild

[Helix751]

(11-17-2021 09:17 PM)3298 Wrote:  You're not missing anything, there is no icon.

Feel free to contribute one, though, if you feel like you're up to that kind of challenge.

Hi.
Even tough I'm no accomplished designer or programmer at all but just a curious user of both HP calculators (since around 30+ years) and HP emulators under both Windows and Linux, and trying my best to get over the obvious ironic statement above, here's my best attempt to get with an icon for x49gp.



If somebody could please point or direct on how to embed this to the source package and installing, would be great.

Acknowledgements:
* 128x128px image extracted from .ico file in Grokwik's real HP 50g KML script (grokwikreal50g.zip). Couldn't find more info about the original author.

[Claudio L.]

(12-05-2021 08:36 PM)Helix751 Wrote:  

(11-17-2021 09:17 PM)3298 Wrote:  You're not missing anything, there is no icon.

Feel free to contribute one, though, if you feel like you're up to that kind of challenge.

Hi.
Even tough I'm no accomplished designer or programmer at all but just a curious user of both HP calculators (since around 30+ years) and HP emulators under both Windows and Linux, and trying my best to get over the obvious ironic statement above, here's my best attempt to get with an icon for x49gp.



If somebody could please point or direct on how to embed this to the source package and installing, would be great.

Acknowledgements:
* 128x128px image extracted from .ico file in Grokwik's real HP 50g KML script (grokwikreal50g.zip). Couldn't find more info about the original author.

Just email it to me and I'll add to the repository.

Thanks for your multiple contributions, by the way, I don't think he meant it in a bad way, he just may not have associated your work to your forum handle.

[Claudio L.]

(12-02-2021 03:32 PM)gwh Wrote:  I've made the proposed changes in a new PR

I updated my personal packaging script to illustrate: https://github.com/gwenhael-le-moine/sla...SlackBuild

I didn't get a chance to review and pull it yet. Hopefully next weekend I can catch a break. This past weekend I was up on a ladder hanging Christmas lights all the time, so no work done on hobby projects!!

[Helix751]

(12-06-2021 03:33 PM)Claudio L. Wrote:  

(12-05-2021 08:36 PM)Helix751 Wrote:  Hi.
Even tough I'm no accomplished designer or programmer at all but just a curious user of both HP calculators (since around 30+ years) and HP emulators under both Windows and Linux, and trying my best to get over the obvious ironic statement above, here's my best attempt to get with an icon for x49gp.



If somebody could please point or direct on how to embed this to the source package and installing, would be great.

Acknowledgements:
* 128x128px image extracted from .ico file in Grokwik's real HP 50g KML script (grokwikreal50g.zip). Couldn't find more info about the original author.

Just email it to me and I'll add to the repository.

Thanks for your multiple contributions, by the way, I don't think he meant it in a bad way, he just may not have associated your work to your forum handle.

Thanks. Couldn't find your email but you can right-click/save-as the icon to get the PNG.
Regards