The Puny BuildTools provide a command-line interface to PunyInform, a lightweight but powerful Inform 6 library, optimized to perform well on old hardware. The Puny BuildTools assist interactive fiction authors as a project management solution for Infocom Z-machine games. They make the whole process of development fast, streamlined and accessible, from structuring your project to compilation, testing, building disk images for retro systems, converting pixel artworks to loading screens compatible with classic targets and bundling your releases for distribution.
Version 2.0 code name âHelix Nebulaâ release notes:
Nearly every line has been rewritten, the structure and logic completely redesigned, 19 systems are now compatible with Z-machine version 5 (making it the new standard architecture for targets), it comes with an integrated CLI controlling every task from project management to building disk images, a completely rewritten documentation and so much more. This update is about convenience, saving time and providing a high level of accessibility.
The software is intended to run on a Linux 64-bit host but you can run it on Windows via WSL2 and on MacOS via OrbStack without problems. After installation, you can keep it up to date with the integrated updater Puny-Wan Kenobi.
Please refer to the installation guide, which you will see when you scroll down on the Github repository. It will tell you exactly how to install the Puny BuildTools. You are not intended to download everything and compile it yourself. As I already stated in the initial post, this is Linux 64-bit software. You can run it on Windows, but you need to do that via WSL2. MacOS users need to do it via OrbStack by setting up an Intel architecture Linux machine.
This has been used successfully for releasing my latest game for a lot of systems. It took circa 26 SECONDS (making of the game and graphics for the loading screens not included, obviously). So itâs 4 weeks plus 26 seconds.
If the update is done with git pull and the git repository has the correct permissions set on the files, why does the update script have an option to override the permissions? Do some files somehow come from an external source?
Yes, Sir! The components such as the CLI, pi6 (the Inform compiler wrapper), the release bundler, the image manipulation tools as well as the modules (which are responsible for creating the retro disk images from story files)⌠all Bash scripts. I wanted the system being a playground for hackers. The scripts themselves make extensive use of binaries though which are either installed on Linux by default, installed as dependency during the installation process or supplied with the Puny BuildTools. pi6 for instance uses the Inform compiler, the Amstrad CPC/PCW module uses âidskâ to store files on the disk image and so on.
Good observation! And I agree. Under normal circumstances, you wonât need the option to override permissions. Git doesnât store permissions but keeps track of the executable bit of a file. So when you clone the repository, the permissions should be correct and +X should be set for all executable files. I can confirm this for Debian and Ubuntu. But there are many Linux distributions and flavors around, so one can never be sure if there isnât distro XYZ that disables the executable bit for security reasons or sets wrong permissions. During the installation of the Puny BuildTools, you can check if the permissions are correct and if so, youâre good, if not you can fix them, the latter is unlikely. So the two options to check or fix permissions are meant to be a fallback solution during the initial installation process.
But itâs also a useful option for me for maintaining the system. For example when I add a new version of z88dk or other software to the BuildTools. Because I am the only person that has to set permissions/+X correctly before I push the changes to the Github repository.
In practice, however, the user will only need the kenobi -u option. I am confident about that.
I see the Apple II build target has been updated to use Vezza. This allows z5 support (which I think was broken for Apple II in v1.5?) but has the side effect of requiring a Z80 softcard, which is a comparatively rare and expensive addition that most hobbyist Apple II users probably do not have.
Is there still a way in the 2.0 version to build for Infocomâs native z3 interpreter for Apple II?
Unfortunately yes. In theory, the scripts will work just fine on 32-bit but all the binaries that come supplied with the system would need to be recompiled to work on a 32-bit system. Itâs not recommended and not supported, sorry about that!
The support itself was not broken but Infocomâs z5 interpreters for the Apple II are unfortunately very buggy. I tested them with Ghosts of Blackwood Manor (my latest game) the results were more than disappointing. I did a test with @fredrik for Punyâs talk menu extension, which at some point waits for a key press and translates that to a ZSCII char and that did not work at all. So the menu froze on screen. I am glad that @sijnstra came to the rescue because otherwise I would have deprecated the Apple II target.
Someone from the Apple II community told me (I think on the FujiNet Discord) that the card actually is pretty common because it was not that expensive back in the day. I donât know unfortunately since I did not grow up with an Apple II. But VEZZA was the only option to make the target work at all.
Unfortunately no. I could put it on the roadmap for 2.1 but it would require a lot more testing to make sure all the features that come with Puny are fully supported. The key press/ZSCII bug did not make me confident so I wanted to be on the safe side for 2.0. Happy to look into it but no promises until Iâve tested it properly.
Fair enough. Switching to Vezza for z5 makes sense, but IMHO is something of a loss for z3, where the Infocom interpreter is reasonably robust and lot more compatible.
In general I think the community move away from the Infocom interpreters towards better, legally-unencumbered modern alternatives is a good thing, but the Apple II world unfortunately isnât quite there yet. There is actually a patched version of Infocomâs z5 interpreter (called On Beyond Z-Machine! / Pitch Dark) that may fix some of the originalâs bugs, but itâs meant to run from a third-party mass storage device, which is probably even less compatible than the softcard requirement.
I totally get your point of view. For me it was more that I knew Vezza would work without side-effects. Hibernated ran without issues in Infocomâs z3 terp, but it did not make extensive use of Punyâs extensions, such as the talk menu. So that really needs to be tested again. In the end itâs the Puny BuildTools, so the interpreters shipped should work with a reasonable amount of features that come with the library.
But I will add a âhackâ option for you and will mention it in the documentation. Something like "if you place line `z3apple2 = âinfocomâ in your config file, it will use Infocom terp for the z3 build. That should be doable. Will give you a nudge once that has been done.
In fact, I bought a 320kb extension for my Atari 800XL last month. The new z5 interpreter for Atari 8-bit needs 128k and I wanted to test how it performs on real hardware. Very well I have to admit. I really enjoyed giving the old machine a cool upgrade
