Unix Frotz and DOS Frotz development

Frotz under Dosbox: (Lubuntu 16.04.3 LTS)
With some games, i can’t quit the game without kill dosbox !


[code]frotz ADVENT.Z5

Are you sure you want to quit?
y[/code](I can’t, I must kill Dosbox!)
I recompiled the source code game Advent.inf with the latest version of the compiler and libraries and now it works.


[code]frotz LOSTPIG.Z8

Really all done with story?
y[/code](I can’t, I must kill Dosbox!)
I don’t have the source code of the game so I can’t try to recompile it.

I filed a new bug report for this. See github.com/DavidGriffith/frotz/issues/58.

I don’t know if it can help you but with 8086tiny and Lostpig.z8, I get:

Really all done with story? y
dos mem corrupt, first_mcb=027c
prev 2375:0000|4d 76 23 c0 64 00 00 00 46 52 4f 54 5a 00 00 00 Mv#�d…FROTZ…
notMZ8836:0000|00 1a 51 4e bc 47 00 00 43 8f da 42 00 05 81 84 …QN�G…CB…��

PANIC: before 4a: MCB chain corrupted
System halted[/code]
Is Frotz (Dos) compiled with only the 8086 instruction set or more? (To use it with 8086tiny.)

This is another ongoing problem. I’m pretty sure I have my Turbo C setup configured this way. Frotz version 2.40 seems to not have this problem.

This shouldn’t be too hard. I’ve added this as an enhancement issue at github.com/DavidGriffith/frotz/issues/59

Take a look at this: https://intfiction.org/t/gargoyle-and-save-file-name-from-inform-6/13125/1
When I save data in file from Inform 6, If prompt is set to true, Frotz don’t ask me for comfirmation of the provided file name.

I have an Issue on that one: github.com/DavidGriffith/frotz/issues/47

Would someone with Mac OS 10.12.6 please try to build Dumb Frotz? I received the following report:

$ make dfrotz Generating src/common/defines.h ar rc src/frotz_common.a src/common/git_hash.h src/common/defines.h src/common/buffer.o src/common/err.o src/common/fastmem.o src/common/files.o src/common/hotkey.o src/common/input.o src/common/main.o src/common/math.o src/common/object.o src/common/process.o src/common/quetzal.o src/common/random.o src/common/redirect.o src/common/screen.o src/common/sound.o src/common/stream.o src/common/table.o src/common/text.o src/common/variable.o /usr/bin/ranlib src/frotz_common.a cc -Wall -std=c99 -D_POSIX_C_SOURCE=200809L -g -I/usr/local/include -pthread src/frotz_common.a src/frotz_dumb.a src/blorblib.a -o dfrotz clang: warning: argument unused during compilation: '-pthread' [-Wunused-command-line-argument] ld: warning: ignoring file src/frotz_common.a, file was built for archive which is not the architecture being linked (x86_64): src/frotz_common.a Undefined symbols for architecture x86_64: "_main", referenced from: implicit entry/start for main executable ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [dfrotz] Error 1

I have a bug : without new line, the word is not displayed ; with new line, the word is displayed.
FROTZ V2.45pre Audio output disabled.
LUbuntu 16.04.5 LTS

[ Main; print "Hello"; ];The word is not displayed.

[ Main; print "Hello^"; ];The word is displayed.

Very late to the party, but if anyone is still wondering, Dumb Frotz builds just fine with the current GitLab code on my computer with macOS 10.12.6.

One warning: $ make dfrotz ** Generating src/common/defs.h ** Generating src/common/version.c ** Generating src/common/git_hash.h /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: frotz_common.a(missing.o) has no symbols /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: frotz_common.a(missing.o) has no symbols dumb_input.c:147:39: warning: implicit conversion from 'int' to 'char' changes value from 142 to -114 [-Wconstant-conversion] case '0': *dest++ = ZC_FKEY_MIN + 9; break;

Bug issue filed at gitlab.com/DavidGriffith/frotz/issues/84
It appears to affect the Frotz core. Windows Frotz behaves the same way.


The problem is that the Frotz core usually won’t flush the buffer until a newline (ZC_RETURN) is encountered. When the test program that provokes bad behavior ends, there are still characters in the buffer and then Frotz happily exits without those characters being flushed out. I suspect nobody found this bug until now because the final character has usually been a newline. Once I worked out what was going wrong, the fix was simple. I recommend all maintainers of the other Frotz ports to adopt this fix.

What compiler are you using? I’m guessing Clang, because GCC doesn’t have a “-Wconstant-conversion” flag. If I specify Clang on Linux, I don’t get that warning, but instead this:

dumb_output.c:301:38: warning: data argument not used by format string [-Wformat-extra-args]
        printf((row == -1) ? ".." : "%02d", (row + 1) % 100);
                             ~~~~           ^
1 warning generated.

which is caused by a funky, though legal, use of the ternary operator.

Anyhow, I’ve pushed fixes for both of these complaints to the Gitlab repo.

Yes, this is with the built-in Clang of Xcode 9.2 on macOS 10.12.6. Apple is notorious for using older versions of Clang in Xcode, so it is possible that the difference you see is due to using a more up-to-date Clang.

I recompiled the latest version of Frotz and it shows me as version name: none.

And it looks like you’re using the sdl2 library, but for the images it’s sdl1.2; I don’t know if this matters?

How did you download and build Frotz? What happens when you type “frotz -v”? Two ways I’m aware that that “none” will show up are 1) you try to build from a Git repository without the Git binary being in your path or 2) try to make a distribution tarball the wrong way. The proper way to make a distribution tarball is to do “make dist”, which will alter the Makefile to replace those “none” strings with appropriate data provided by Git.

$ ldd sfrotz | grep -i sdl
        libSDL2_mixer-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libSDL2_mixer-2.0.so.0 (0x00007ff50e9bd000)
        libSDL2-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 (0x00007ff50e6a1000)

My machine is just pulling in SDL2. What does “ldd sfrotz” give you?

I downloaded from GitLab frotz-master.tar.gz
gitlab.com/DavidGriffith/frotz/ … ter.tar.gz
I extract frotz-master directory to my Desk
I’m going in this one and type make.

FROTZ Vnone Curses interface. Audio output enabled. Build: 20180909.62452 Git commit: none Git tag: none Git branch: none Frotz was originally written by Stefan Jokisch. It complies with standard 1.0 of Graham Nelson's specification. It was ported to Unix by Galen Hazelwood. The core and Unix port are currently maintained by David Griffith. Frotz's homepage is https://661.org/proj/if/frotz/

libSDL2_mixer-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libSDL2_mixer-2.0.so.0 (0x00007f420b7b3000) libSDL2-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 (0x00007f420b4a0000) For SDL I must have been wrong, it seemed to me that he refused to compile without libsdl-image1.2-dev. But not!

You’ll need to clone the repository and build from there. The Git info is lost when you download a tarball. I’ve filed an issue with Gitlab asking if there’s some way I can have the Gitlab server run a script to take care of this prior to gathering files into a tarball.

About Constant NO_SCORE:
without Constant NO_SCORE, Frotz displays Score and Moves;
with Constant NO_SCORE, Frotz displays only Moves but Windows Frotz and Gargoyle Bocfel displays nothing.
Who is right?
ReleaseNotes.html for the compiler says:

I can’t fathom how Windows Frotz and Bocfel do this because the printing of the score and move count is entirely up to the Inform6 Library. NO_SCORE was introduced by Graham back in version 6/11. I tried some other interpreters including Glulxe, Git (glulx terp), Fizmo, glkzip, nitfol, and jzip.

I’d say that Windows Frotz and Bocfel are misbehaving.

Could something be mis-measuring the window so that it wants to print it but doesn’t think there’s space?