I have created a detailed specification of the story files used by the original adventures by Scott Adams (and others), one which I hope would be useful to anybody wanting to write an interpreter for these games from scratch (as I did).
This is not meant as criticism, but although you mention the TI99/4A format, I think it might be worth pointing out that there are also plenty of UK cassette releases that use a slightly different binary format (created by Brian Howarth for his Mysterious Adventures, I think.)
By the way, Questprobe featuring The Hulk uses opcode 90 to draw fullscreen images.
EDIT: It might also be noted that the US releases for Apple II, Atari and Commodore 64 used their own binary format, usually credited to Mak Jukovic Jukić. This is closer to the original ASCII format than Brian Howarth’s, though.
EDIT 2: I would perhaps add to section 12.8, The Lamp Timer, that some games (at least the Mysterious Adventures) do not, in fact, replace the lamp item with its turned-off version, so if the interpreter does not handle this, the result will be a second lamp appearing while the player is still holding the lit lamp.
You probably mean Mak Jukić. He definitely wrote the drivers for the Apple II and C64 platforms, as well as the BBC Micro in the UK. I’m unsure about the 8-bit Ataris, but he’s at least credited in the Questprobe series, so probably that too.
Credits are not too reliable, though, especially where famous authors were involved; today we know that Scott Adams did not write either Pyramid of Doom or Golden Voyage, even if credited with these. Their authors were Alvin Files and William Demas respectively, who independently had reverse-engineered the game format and were cheeky enough to build their own games based on it and submit them to Adventure International for publication. Or Brian Howarth, who was credited with Seas of Blood but did not even go near it (it was Mike Woodroffe instead).
Thanks! I was copying from the readme of beeb2sf.zip, but I definitely should have googled the name. If you are reading this, Mak, sorry for mangling your name!
if you have ti99 format questions i might be able to help. been a while since i worked on bunyon + scottcom compiler but i have notes and stuff laying around.i dont remember if i added it to the github repo or not.
Thanks, I did some work to reverse engineer the TI99 format (starting from a description of the header made by @pxdiv, and without looking at the Bunyon code) but my decompiler doesn’t handle certain things in actions.
So yeah, I would like to create an addendum spec for the TI99 games. I’m tending to think it should be semi-separate from this spec, but they share a lot of behavior so I’m not completely sure…
Do you mind if I come back to this later? I am currently working on some other things and I’m not very good at working on too many things at once.
i think there are fixes in there that never made it to the ifarchive back in the day, but dont really remember what I changed, its been so long. bunyon builds against garglk as well.
there is one or two quirks about the ti99 format i didnt work out I think, maybe an opcode or two still. I didnt know they shoehorned the bunyon code into scottfree. seems weird as the ti99 format is far more expressive format than the old text one. but if it works, its fine.
The differences are pretty much a) the order of the opcodes, e.g. the “swap item locations” opcode is 0x48 in the original SACA format, 0xec in the TI-99/4A format, and so on, b) condition-action lines can be longer than in SACA, and c) the TRY command, which defines a code block of several lines which will be skipped if a condition fails, much like brackets after an if statement in C.
The current TI-99/4A code in ScottFree is tested with all of the original Scott Adams adventures available in the format, which should be completable, I’ve also checked that all the home-brew games I have been able to find at least start.
Just a quick note to say I’ve begun working on a specification for the TI99/4A format, I call it an “Addendum” since it will assume knowledge of the original SAGA (TRS-80) format.
Looking at the Bunyon and ScottCom code and docs has been very helpful to understand some aspects of the format which I didn’t before, such as some opcodes which I had seen in games but had no idea what they did.
Firstly, when reaching the end of the block, or executing a condition or get opcode which fails, then the current block is terminated and execution continues at the opcode immediately after the block.
Secondly, the end opcode ($FF) terminates all try blocks, as well as the action itself, and produce the SUCCESS result.
Perhaps it should be mentioned that the lack of a continue opcode is not only compensated for by the try opcode, but also by the fact that the format allows for longer lines.
Some notes about the get opcode in the text (SAGA) format:
I have looked at all the games I have, and it became clear that get definitely should abort the action – as currently specified.
The Scott Adams and Brian Howarth games were very consistent, they print the “OK” message (or set flags or move items) after the get opcode, so that the message is only displayed if the get succeeded.
However, the home-brew games often get it wrong, printing the “OK” message (or setting flags etc) before the get opcode. One place in adv11.dat was also wrong like this.
So I think now that interpreters should move any get opcode in the text-based SAGA format to be the very first opcode, so that when it fails (because of the carry limit) the whole action fails. I’m fairly confident that this won’t break anything, but I’ll double check shortly.
P.S. I see some games move a carried item before the get, which means it will never fail (since it can only fail due to the carry limit) – moving the get here could make things worse. Hmmm…
Oh, how that name raises my hackles! The Count was the first text adventure game I ever played on my old Acorn Electron, but the Mak Jukić port has a bug that makes the game unwinnable. (You can’t get back in through the window after tying the sheet to the bed.) I was convinced that I knew how to complete that game, but I had to wait twenty years to prove to myself that I was right!
