After multiple bugs have been squashed in the beta period, Unix Frotz 2.50 is finally ready for official release and inclusion in all the usual repositories. It can be obtained right now from https://gitlab.com/DavidGriffith/frotz/ either by cloning the repository or downloading a source tarball at https://gitlab.com/DavidGriffith/frotz/-/archive/2.50/frotz-2.50.tar.gz. DOS Frotz can be found already compiled at https://661.org/proj/if/frotz/frotz250.zip. All of this will be available from the IF Archive in http://ifarchive.org/indexes/if-archive/infocom/interpreters/frotz/ when its curators move my uploads there.
What’s next for Frotz? Here are a few:
Add compile-time option for paging Zcode from disk instead of reading the whole thing into memory. This will allow for better perfomance on low-memory machines.
Port Frotz to the PDP-10 mainframe and maybe PDP-11. Contingent on disk-paging.
Create a new GTK3 user interface to resemble the interface of Windows Frotz.
And now, here is the ChangeLog for Frotz 2.50:
Summary of changes between Frotz 2.44 and Frotz 2.50:
Frotz 2.50 was released on Tuesday November 12, 2019.
Added UTF-8 input and output. Plain ASCII is still available.
Added -L option for restoring save file directly from the command line.
Added -R option for restricted read/write path.
Sound effects in AIFF, MOD, and OGG formats supported per the Blorb specs.
Sound driver selection is automated through the use of libao.
Allow for an alternative Blorb file to be specified on the command line.
Overhauled MacOS compilation.
Corrected problems with error handling.
Fixed a lot of unsafe strcpy() and strcat() calls.
Fixed numerous problems with portability to other flavors of Unix.
Fixed adaptive palette rendering for SDL.
Fixed scaling with manually specified window dimensions.
Fixed problem with unnecessary newlines with input timeouts.
Allow fontdir in .sfrotzrc to work relative to user’s home directory.
Fixed problem with memory allocation leading to crashes in DOS.
Fixed problem with DOS Frotz creating non-portable Quetzal files.
How about introducing the ability to trace Z-machine instruction execution, or track and report what portion of the code is actually executed?
[In fact, I have already injected my ugly tracing logic over frotz-2.50b2 source successfully—for personal consumption only—but having that feature “out of the box”, and coded by a real professional would be a nice perk. ]
I’d love to see it. We should be able to get it polished and ready for public use.
A few months ago I noticed there is the source for a QT version of Frotz on IF archive for some ebook reader. Even though I know next to nothing about Qt I have managed to make it work on a desktop to some degree (only lightly tested). Would something like that be of interest?
I just laughed out loud, when i read about the PDP-11 port! As for Qt vs Gtk: Qt is C++, Gtk is C. Both have advantages and disadvantages.
It is gtk2 instead of gtk3, but there is grotz https://github.com/kevinboone/grotz. It looks like it has the adaptive palette issue that was fixed recently in sdl frotz, but it is fairly nice.
The PDP-11 port is a guess that will be addressed after the PDP-10 port. The PDP-10 port is already underway. So far, the Dumb interface works well. The next step there is to figure out how to port a curses library to the various PDP-10 operating systems. I don’t know how necessary disk paging will be to the PDP-10 port, but it would be a great help as it would for the DOS port.
I’m going with GTK because it’s C.
well, the PDP-10 (DECsystem variety) was the original Infocom development environment, so porting Frotz on PDP-10 is very proper…
OTOH, Unix was originally developed on PDP-11, so should be ported, at least the unix frotz variety…
Best regards from Italy,
Now I want to port my interpreter to the PDP-10 as well.
How would I go on about that?
Adam Thornton started the process with Dumb Frotz 2.32. A key concern for the process is that the C compilers available for TOPS20 and other PDP-10 operating systems are pre-ANSI. Another significant hurdle is the fact that the filesystems on these operating systems are limited to six characters plus a three character extension. Compare this to DOS’s 8.3 limitation. @adam wrote a script that massages the source code into a pre-ANSI state and renames the files to fit the 6.3 limitation. These files are put into a directory that is then uploaded to the PDP-10 whereupon
cc -o frotz *.c produces
See Porting Dumb-Frotz 2.32 to TOPS-20 for @adam’s discussion on the matter and https://github.com/athornton/gnusto-frotz-tops20 and https://github.com/athornton/tops20-frotz for his projects to get this started. I will pull in his script into Unix Frotz so that one can type
make pdp10 to produce a directory of source code ready to upload. This approach will be similar to how I’m handling 16-bit DOS compilation.