Would you consider adding a version number on the display screen?

[mrthreeplates]

Fantastic rom, thank you so much for this excellent and very useful image. Works great on my model 1 with ei and 48k, with lowercase mod.

A version number might be useful in case new features are added or bugs fixed. This would remind me that I should grab the latest image.

[ki3v]

This is a good suggestion. I've been thinking about this. Version numbers would be useful for a number of reasons, both on release and on internal builds as well. One thing holding me back is that I don't know Git well enough to get past a certain issue: I'd like to generate the version number automatically, including the release tag. But the release tag doesn't exist until the commit.

The way things are set up now, I commit the built ROM images, so that the binaries are actually available directly from the GitHub page. I suppose I could break them out so people download ROM images from the Release page, but this would mean that people who want to test or use interim commits would have to be able to build them themselves. I don't build on Windows, and some of the scripting tools that I might use to generate the build/version numbers are not going to be available on most people's Windows machines.

So basically I I don't have the right procedure to make it automated, so I haven't done it yet. If anyone has a suggestion for a good, clean way to automatically create build and version numbers that can be included in the assembler source so we can print them on the screen, that would be helpful.

[rawr51919]

I'd suggest using an automated GitHub Actions build job on every commit to build and host the latest version of these test ROMs. Release versions could use a separate tag to differentiate them from a dev version.

[ki3v]

I'd suggest using an automated GitHub Actions build job on every commit to build and host the latest version of these test ROMs. Release versions could use a separate tag to differentiate them from a dev version.

GitHub Actions could automate it, but I still need to work out the process to generate the version string to be inserted into the firmware. But once I had that, manually uploading the release is not really a burden. Also, if I only use GitHub Actions, that won't solve the problem for build numbers when I or someone else is doing development on the source tree and building interim firmware.

I've located a method that mostly uses GNU Make macros (fetching some information by calling the git command line). I think we will have to give up two things to do it this way:

1. Including the built firmware .bin and .hex in the GitHub repository itself (the files that get checked out, so you can just click on it from the main repo page)
2. Building on Windows

The first is I think unavoidable, and the way we're doing it now is convenient for users but not really the proper way (and it's not that much harder to click on "Releases" to download the firmware.

The second is probably not really a problem. Realistically I am the only one building these, and I do it on a Mac anyway (though I periodically check to make sure it will build on Linux too).

So I'll probably update the Makefile to automatically create a version number based on the most recently tagged version number, and simplify the Makefile so it doesn't bother being compatible with being built on Windows. These days it's easy to install WSL if you need a Linux build environment on a Windows box anyway, and for someone who wants to building firmware for an old retro computer from the source, that should be a skill that's within reach.

[MrAureliusR]

git has a powerful feature, automated scripts that can run at various times during a commit. They are called git hooks -- check out the official documentation for more info. The populated .git/hooks directory has some great examples, and it wouldn't be difficult at all to automatically create tags and/or add version codes to a particular file or set of files.