there are definitely places in ti99 adventureland (get firestone) where it will print “OK” then do the get… then in the same game will do for other items a GET then an OK… and spiderman does everything via STEAL instead of GET!
its crazy to me that this is all over the place
Yeah, thinking about it overnight (perhaps a bit too much), it would have been better to have a single opcode which never failed, and force the game writer to properly check for carrying too much.
Anyway, I guess it’s not really possible to “fix” the bugs in various games due to this, just by a simple rule or two. But it’s worth thinking about – and I don’t think I’m done thinking about this one 
It might seem so, but if you look deep enough, it is. 
This is a consequence of the system growing organically over an extended number of years, and additions being made to it that maybe should have prompted a total redesign of the specification, but lack of time, resources, or other factors kept the status quo going on. So crazy it may be; surprising, much less so.
All in all, I still admire the compactness of the design and how it maximizes player agency (filtered through 1970s semantics) within very tight constraints.
sure. steal doesn’t check, and spiderman ti99 does every pickup with steal. its interesting that adventureland does steal on the chigger bites so you always get infected and cant not by way of max inventory count. but it means, if you have max, get chigger bites (max+1), drop something, you still now have max! I dont like when a game breaks its own internal rules like that.
I finally released version 1.0 of the specifications.
The main change is I’m simply calling the format “the Scott Adams format” rather than the term “SAGA” which is not commonly used.
I also mention that in Brian Howarth games, the lamp should be destroyed when the lamp timer runs out. Plus a few other additions / tweaks here and there.
Links:
The Unofficial Scott Adams Specification: The Unofficial Scott Adams Specification
The TI99/4A Scott Adams Format: The TI99/4A Scott Adams Format
Thank you, this is very useful.
I have been investigating some of the 1982 graphical re-releases (the ones Adventure International called SAGA) lately. Let me know if you are interested in any additional notes.
Thanks for your work on this.
SAGA is a different (later) format. Should this be documented separately or as an extension to the earlier format?
Scott Adams named the earlier format SACA (Scott Adams Classic Adventure) after he started releasing games in the SAGA (Scott Adams Graphic Adventure) format. From memory, there was also SAGA+, which had a multi-word parser.
What is different about it?
Apart from the support for graphics, I don’t know, as I’ve never seen a spec or made any attempt to analyse the file format. It would make an interesting exercise for anyone that’s interested.
I just opened the SACA and SAGA versions of the same Atari 8-bit game (The Count) in a hex editor and they look very similar. However, they have binary characters intermixed with the ASCII data. I have no idea how the graphics data is indexed or stored.
I also opened a SAGA+ game (The Adventures of Buckaroo Banzai) in a hex editor and it looks to be in much the same format, so the latter formats are probably extensions of the earlier format. @Angstsmurf may be able to shed more light on this.
Interesting.
Would you mind sending me that game file so I can take a look?
I’ve got a pretty good collection of Scott Adams games for various platforms, so yell out if you need any others. I usually look at the Atari 8-bit ones first, as I bought them all back in the day.
Atari 8-bit files for The Count.zip (80.1 KB)
I just had a thought. If the files are stored on disk using Atari DOS, then each sector contains 128 bytes. The last 3 bytes are the file continuation data. As the atr file is a disk image, then the binary data I mentioned is probably that data, so I may have given you a bum steer.
Had a quick play of the Count with graphics.
If the ATR files are disk images, then I wonder if there’s a way to look at the actual files on it.
The SACA version is stored using Atari DOS 2.5. This contains 3 files: DOS.SYS (the Disk Operating System), DUP.SYS (the Disk Utilities Package) and AUTORUN.SYS (the autorun executable). The program and data is in the latter. To see the contents of AUTORUN.SYS on screen, boot with a DOS disk. When the menu appears, insert the adventure disk and enter:
C [return]
AUTORUN.SYS,S:[return]
This will copy the file to the screen. Press Ctrl+1 to pause and restart the display. You will quickly recognise the Scott Adams data. The heart characters are zero bytes. The other funny-looking graphics characters are binary data. There appears to be binary data between each string, perhaps a string length?
The SAGA version is stored on two disks in a non-DOS format, but that’s not unusual for games. The directory on the second disk is gobbledegook, so this is probably a fragment of the raw graphics data stored in a custom format, i.e. written directly to sectors without using DOS files. Again, that is not unusual for games.
To me it looks like some of these 8-bit ports don’t load a story file, like the TRS-80 version did, the data has just been embedded with the program.
They’re probably not files. There will no doubt be some sort of index that tells you where each image is located on the disk. Once you know that, you can just read the data from the appropriate sectors. The data is probably saved in the same format that it’s stored in memory. The Atari 8-bit computers have several custom large-scale integrated circuits. One of these is a graphics processor. It has it’s own program called a display list and numerous graphics modes that can be mixed and matched (within reason). The normal display is 320x192 pixels. This particular display looks like it uses 8 lines of text at the bottom leaving 128 lines of graphics at the top. The graphics themselves use a 4-colour indexed palette. Each dot in the image is 2 pixels x 1 pixel. It looks like there is 24 blank pixels on each side of the graphic. It might use a narrow playfield to save memory.
Having said all that, I just noticed that once you get out of the start room, there are 4 lines of text at the bottom, leaving 160 lines for the graphics. The colour palette changes from room to room, so the colours also need to be recorded somewhere.
Most graphics formats would record the palette data, then the graphics data, sometimes compressed, sometimes not. In this case, it may also need to contain the image size so that it knows how many bytes to read from the disk.
I wouldn’t say that the SAGA games have a different format, but it depends on what you mean by “different format”. The binary database format matches @andrewj’s specification, and the way it is stored and formatted is pretty much the same across all the Mak Jukić versions. The ascii format used in the IBM PC versions can be used unmodified in ScottFree.
The main difference to the @andrewj specification is the use of opcode 90 to draw images, with the image index as parameter. Some of the SAGA games also use opcode 89 (no parameter) to specifically draw image 80, which does not really make a lot of sense.
This is the only incompatibility with the Brian Howarth versions released by Atari International UK, which use a parameter with opcode 89 to display images. An interpreter needs to take this into account in order to be able to play both versions, even if it does not support images. I took me far too long to figure out that this is why the Adventureland genie would drop a fish instead of a diamond ring in ScottFree.
Regarding the Atari 8-bit format: I have a listing of every image in the Atari 8-bit SAGA games, with their ATR image file offsets, in the source of my ScottFree fork:
https://github.com/angstsmurf/spatterlight/blob/e4908725dfb32b4daea3b00bd9e4a9d0a52eb3ae/terps/scott/saga/atari8detect.c#L34
There is also code to read and draw the image data. Atari 8-bit (and C64) bitmap format here:
https://github.com/angstsmurf/spatterlight/blob/e4908725dfb32b4daea3b00bd9e4a9d0a52eb3ae/terps/common_sagadraw/c64a8draw.c#L681
Atari 8 vector format here:
https://github.com/angstsmurf/spatterlight/blob/8fbdffb0a9714ce177b5b6bb8a0e84ac81cf41a5/terps/scott/saga/atari_8bit_vector_draw.c#L989
Wow. That’s great to know.