Unix Frotz and DOS Frotz development

I wasn’t previously aware of this place. It seems that most people bailed out of Usenet for this place. Kinda sad really. Anyhow, I thought I’d let people know that I’ve picked up Frotz development again. The codebase is now in a Git repository hosted at Sourceforge. The latest code supports Blorb. I’ve also been bringing the DOS interface up to date. The DOS interface as written with Turbo C in mind is quite different from the one written with DJGPP in mind. I’ve resolved those differences and now have 2.40 compiled such that the IBM PC 5150 should be able to run it. Everything works with it except compiling with sound support and saves. There’s also a strange problem with Arthur causing DOSbox to freeze after a random period of time. The next step is to bring it in line with the master branch, add Blorb support and hopefully correct the aforementioned bugs in the process.

Please take a look at sourceforge.net/projects/frotz/ and let me know what you think.

I’ve pushed into the Master branch DOS code that should work. I’m having some trouble with a complaint of “Invalid combination of opcode and operands” relating to certain macros. If there are any people out there who grok programming with Turbo C, I’d appreciate it if you take a look and let me know what the problem and solution might be.

The “invalid combination…” line refers to assembly language, not C. You’re either using opcodes that don’t exist on the older processor(s) you’re compiling for, or, you’re using the wrong DOS memory model. To change the latter in Turbo C, go to OPTIONS, COMPILER, CODE GENERATION, and its the left-most selection. You’re probably on Small but need Medium or Compact or whatever. (DOS memory models is a subject unto itself, and I’m not an expert. I never aimed at older hardware even in 1991.)

Anyway, I can’t compile any Frotz at all. (But Hello World and my own old Versus project compile, so it’s not the installation.) Does the download on the link you gave above missing its makefile? Or the .PRJ project file for Turbo C? Or are you compiling Frotz with one extremely long line at the command prompt? I ask because under the /common/ subfolder there’s a file called main.c which I presumed was the, ahem, main file. But it doesn’t #include anything except that folder’s header files… such as the 20 or so C files that sit next to it in said folder.

I tried looking in the other folders in your download, but same problem. What am I missing here? How are you compiling it?

The file Makefile.tc is for use with Turbo C. Typing “make -f Makefile.tc” should start the compiling process. Also, I forgot to put the latest makefile in place. The git is now at the point where the build complains about invalid combinations. The problem seems to be coming from the fact that those macros it’s complaining about resolve to some assembly code. That isn’t done with any of the other ports. I’m fiddling with using C instead of assembly there. Maybe if I simplify things, I’ll more clearly see what needs to be done.

Ah, there’s the problem. There is no Makefile.tc. There is a Makefile – no extension – but it’s clearly for UNIX and the GNU compiler. I think you gave me the wrong download link. Can you just email me the zip or tarball or whatever?

You can rewrite the asm into C of course. If you’re trying to backport a 32-bit DOS app (i.e., DJGPP) to a 16-bit DOS app then you may have no choice anyway. Pull up an opcode list for the x86 line and see what shouldn’t be there.

To get the latest source code, give your git client this url: git://frotz.git.sourceforge.net/gitroot/frotz/frotz. Please PM me your email address if this doesn’t work.

For anyone who’s interested, I’m scaling back things to first make sure that the 16-bit DOS interface works completely and THEN move on to getting it to work with the trunk. In the trunk, it just doesn’t want to work at all. The 2.40 interface code runs, but won’t restore saved games. It also won’t compile with sound support. So, if there’s any of you out there who still know DOS and would like to contribute, I’d love to hear from you.

Why might you ask am I bothering with the DOS port? There’s a bunch of people out there who get their jollies by running old hardware.

Is there any current relationship between the Sourceforge Frotz and the Frotz that is in, for example, Gargoyle?

The Frotz in Gargoyle is forked from Frotz 2.42. Merging stuff from there back to Unix Frotz is one of my ongoing goals.

I tryed to compile Frotz with Turbo C++ 3.00 under Dosbox and I couldn’t.
It works if I comment lines with errors.

I’m aware of the problem. See github.com/DavidGriffith/frotz/issues/41

I know this is a detail, but is it possible to propose in the command line options a translation of the sentence: [Hit any key to exit.] (for other languages.)

# Exit_sentence "Hit any key to exit." Exit_sentence "Appuyez sur une touche pour quitter."

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