I’ve teamed up with @sijnstra for a workaround to support building TRS80 targets on MacOS / OrbStack hosts. Fingers crossed! :fingers_crossed: :tardis:
I’m currently experiencing an error related to the version of Glibc included in my Ubuntu-based WSL. If I recall, the version shipped from the Microsoft Store at the moment is 20.04.
~/FictionTools/inform: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34’ not found (required by ~/FictionTools/inform)
I could compile Inform from source, which is easy enough, but when I update to the next version of the build tools, it bitches about file changes not synching up with the git repo.
So I went to Github and got into the .bashrc file. I’m skipping various disk formats right now. What I wonder is about this end step:
Type below command and enter the path to your PunyInform installation, then save.
nano ~/FictionTools/.pi6rc
Congratulations! You've completed the setup.
I wonder is that the directory on /usr/share or what? What’s the directory for standard install? Can you give me the exact text/line for it?
Sorry, but .rc files are of unknown skill to me.
Also, it builds of PunyInform source file, right?
Can it build standard library Inform6 source files?
First of all, you get the Puny BuildTools only from Github. It’s a live system which needs a GIT repository to update itself.
It depends on where you have installed PunyInform, the library itself. In my installation, the resource file looks like this:
# Puny BuildTools pi6 resource file
# path to the PunyInform library files. if your path contains whitespaces, you need to provide it as an escaped string.
lib=~/Projects/PunyInform/lib/
The resource files are basically Bash script extensions which contain data that is read on demand.
Yes.
Here are the answers to your other questions:
No. But Inform 6 standard library games are way too big and that makes it behave way too slow on old hardware like the Commodore 64, so this has never been the aim of the Puny BuildTools and likely never will be.
Nope. Only PunyInform sources.
If you have a precompiled .Z5 game and you want to distribute it on various retro disk images, that is possible. The documentation also mentions how you can do it. But keep in mind that a full featured 256k file is way too big for some of the oldschool systems. To be on the save side, I recommend not going beyond 140k. Also, if the Z5 file had been compiled against the standard library, you might run into performance issues when building a disk image with it, especially for 8-bit systems. For DOS, Amiga or Atari ST it should be okay. Z5 files build with PunyInform should perform well on any of the supported targets.
@fredrik Would you like to add something here? Your brain is usually bigger than mine
2: If you pretend to write a PunyInform game, but you don’t actually include any of the library files, I think you could use the tool chain to compile a game which doesn’t use a library.
I read something about replacing PunyInform library with my own custom made library. But I think if I do use my own custom library, it’d be easier for me to just package my own z3/z5 programs for it.
I’ll have to watchout for Atari (90K) and C64 (??) limitation.
For the Commodore 64 there is no hard limit since Ozmoo (the interpreter used for C64 and various other Commodore machines like the Plus/4) is a multi-disk interpreter which asks you to swap the disk. So if you for example intend to bundle a 170k game for the Commodore 64, no problem.
For Atari 8-bit, the limit is not that harsh anymore. It used to be like that in the early days and with Infocom’s (Z3 only) interpreter. The Puny BuildTools have integrated Jindroush’s modified Atari 8-bit interpreter, which does not only allow to build bigger disks and use the later Atari disk formats, it also allows running Z5 games. By standard, the BuildTools use this interpreter so the disk size is 180k. You have to subtract around 16k for the interpreter so the hard limit for A8 is around 164k.
A little disclaimer though regarding Jindroush’s interpreter. It works very well with all the Infocom games floating around, and I worked closely with Jindroush to debug it with all of Puny’s features, meaning it works well with PunyInform games. I don’t know what happens if you throw a standard lib game on it. Likely it will be fine but it needs to be mentioned.
Five clean-room Z-machine v5 interpreters built from scratch: Ceres (CoCo/Dragon), Varuna (Atari 8-bit), Eris (Amiga/Atari ST), raising the platform floor on systems that previously had hacked, buggy, or absent z5 support. All five interpreters support accented characters for French, Spanish, German and Nordic.
Three new targets wired in: Agon Light, Commander X16, ZX Spectrum Next.
Four dependencies dropped: Wine (was used for TRS-80), amitools/vamos, zip2st, python3-pip. the toolchain is now Linux-native and largely stdlib-Python.
A guided installer (kenobi -i), and from-scratch python disk builders (mkdsk.py, mkatr.py, adf.py, gemdos.py).
Screenshots from the brand-new interpreters below. The Amiga and Atari ST interpreters (sharing the same 68000 core) even support Z-Machine colours and the full range of styles, in addition, they also support z8 (was cheap to add). All interpreters comply to the Z-machine 1.1 standards document and pass CZECH and TerpEtude without issues.
Please note that I will start a separate thread on the interpreters soon and share the full sources with the community. Each interpreter comes with its own Python stdlib based disk builder, no external dependencies.
Which licences are these being distributed under?
(Are people allowed to distribute disk images that contain them independently of using your build tools?)
The same license the Puny BuildTools are under applies. It’s BSD 2-clause, so you don’t have to look it up.
Everyone that uses the BuildTools creates disk images that are distributed independently, both free and commercially. I see no difference in whether you are using the BuildTools to bundle your game with the interpreter or do it by hand with the interpreter’s host system specific disk builder. I actually encourage you to distribute games containing the interpreter. I am doing community service here
On a side-note: when I am sharing the sources, there will be the documentation and the specific disk utility available in the repository as well. So there is no need to use the BuildTools when the terps are out to distribute your games with it.
The only reason I am right now holding back on the release of the interpreter’s sources is that in the commit history of the repositories, there is my upcoming, unreleased game Hibernated 2 as it was a great test candidate and one of the reasons I did this work. So I’ll have to wait until that is out first (a week or two from now). I will make a separate post here in the forum about the ‘Trans-Neptunian Interpreters’ (they are all named after trans-Neptunian objects).
Hope this helps. Let me know if you have additional questions!
