Original AGI Interpreter

[Collector]

I have a memory of Ken or one of the early Sierra devs mentioning using MASM.

[lskovlun]

I have a memory of Ken or one of the early Sierra devs mentioning using MASM.

There's also the SCI changelogs (but this is of course later), which mention a change from MASM 5.1 to 6.0.

[Kawa]

And I recall adding some .if uses to what might be slightly older parts of SCI 1.001.100. To improve readability, dig?

[lance.ewing]

Yeah, it is starting to look like these were defined as macros, given that that example you found has shown that it is possible to define very similar macros. I think we can deduce what the macros contained based on comparing the usage of these macros with a disassembly of the AGI interpreter.

I'm working on putting together some MASM macros that hopefully behave like the ones that the AGI interpreter source is using. Took a while to get my head around what was possible in MASM 4, which is what I'm targeting, since I am assuming that that version of MASM was what was used during the development of most of the code that we have. They probably would have switched to MASM 5 as soon as it was released, but I still think that their macros would have originally been for MASM 4.

Most of the useful documentation online is for 6, and some for 5. I did find a couple of manuals for 4 and earlier as well. That STRUC.INC file from the MS DOS 4 repo is quite useful in seeing what is possible. The trick of creating symbols to represent a stack that things can be pushed to is quite clever and I think also necessary in order to properly handle the nesting of the various block types (loops, ifs). The equivalent macros in that STRUC.INC file are more complex than required though, e.g. they handle testing a condition, but the AGI ones do the test before calling the macro, so the macro doesn't need to be as complex. So I have tried to come up with something a bit simpler. Hopefully it will work. I'll report back on progress after testing it out a bit.

[mnicolella]

Very cool. Let me know if you want any help with that. You should also be able to mostly reconstruct the missing files by ripping the asm straight out of the executable. For a lot of the missing functions, you will probably find source code that calls into those procedures, and so you can cross reference the source code with the disassembled executable in order to know what the function's symbol is.

[lance.ewing]

Very cool. Let me know if you want any help with that. You should also be able to mostly reconstruct the missing files by ripping the asm straight out of the executable. For a lot of the missing functions, you will probably find source code that calls into those procedures, and so you can cross reference the source code with the disassembled executable in order to know what the function's symbol is.

Yeah, that is the plan, to reconstruct the missing bits, and then the long term plan is to set up a github action to build it using dosbox with MWC, MASM and PLINK86.

Regarding the symbols, the names are also in the AGI.MAP file, which contains every module. Those are all in uppercase though, whereas the source code references would show the original names, usually upper or lower camel case. I think between both, most symbols could be worked out. The data that is internal to a module isn't included in the AGI.MAP though, so there would be some internal bits with guesses as to the names.

I was discussing the code with AGKorson recently, who did a detailed analysis of the AGI.MAP, and we think this source is earlier than the 2.903 interpreter. Its an unreleased test version between 2.440 and 2.903. Most of it matches 2.903 but there are some bits that still match 2.440. The latest date mentioned in a source code comment is Sept 87. The AGI.MAP is dated the 7th Oct. A game using 2.903 was released about 2 weeks after that.

[Collector]

Any chance that some of the source files from the disk slack came from different versions? ie, an old version to reference against a newer version?

[lskovlun]

Any chance that some of the source files from the disk slack came from different versions? ie, an old version to reference against a newer version?

Yeah, that's what I'd think too. If I understand correctly, the files were taken from two very different AGI games.

[lance.ewing]

Yeah, you're right, and to prove it, I just compared the IOBJSBRS.ASM file between the SQ2 and KQ3 disks, which is one of the files that appears in both. The SQ2 version has two additional lines:

Code: [Select]

$ diff IOBJSBRS.ASM.SQ2 IOBJSBRS.ASM.KQ3
18,19d17
< data  segment byte public 'data'
< data  ends    ;dummy segment

Haven't compared others yet but they'd also likely be slightly different. I guess we can compare all the files extracted from the KQ3 disk with the 2.903 disassembly (being the closest released interpreter version) so see what differences there are and tweak as required. The KQ3 files are still useful with regards to things like comments and symbol names and general code layout.

[AGKorson]

Any chance that some of the source files from the disk slack came from different versions? ie, an old version to reference against a newer version?

That was one of the first questions I had when I started looking at the source files in detail. Based on what I've found so far, I'm inclined to believe these are more than likely from the same version, at least most of them. The files appear to match the memory map in size and position, and also match version 2.903 except for a few places where there is code matching 2.440.

There are over 30 dated comments in the source. I sorted those and compared them to the disassembled code from all versions to build a timeline of versions 2.272 (which appears to be the base version of these source files) through 2.903:


2.272: < 17 FEB 1987
2.411: >= 17 APR 1987 < 30 APR 1987
2.425: >= 30 APR 1987 < 11 MAY 1987
2.426: >= 30 APR 1987 < 11 MAY 1987*
2.435: >= 11 MAY 1987 < 27 MAY 1987
2.439: >= 27 MAY 1987 < 01 JUN 1987
2.440: >= 01 JUN 1987 < 14 JUL 1987
2.903: > 01 SEP 1987
*No comments found that are attributable to this version because the only change is a very minor adjustment to the RenderPic function which is in the file PICDRAW.ASM, one of the missing source files.

[lance.ewing]

Yeah, you're right, and to prove it, I just compared the IOBJSBRS.ASM file between the SQ2 and KQ3 disks, which is one of the files that appears in both. The SQ2 version has two additional lines:

As AGKorson said, the files on the SQ2 disk are probably from the same date, but the files on the KQ3 disk appear to be from a different time period.

That IOBJSBRS.ASM file might be the only one that is in both actually. I can't spot any others. There is less overlap than I thought. There are some asm header files on the KQ3 disk for which there are C header files on the SQ2 disk. I think Sierra may have maintained C and ASM versions of at least some of the header files. I can see one example where Jeff Stephenson added a comment to the C version only a minute after the ASM version:

Code: [Select]

;GAME.AH
;Header file for King's Quest
;
;Change History
;18/02/87  15:02:16 JAS
; Increased NUMCONTROL and KEYMAPSIZE to 50.


Code: [Select]

/* GAME.H
** Header file for King's Quest
**
** Change History:
** 87.04.30 9:58 JAS
** Added NO_PRMPT_RSTRT flag to not prompt user on a restart (allows
** programmer to restart game from logics).
** 18/02/87  15:03:27 JAS
** Increased NUMCONTROL to 50.
*/

(I don't think we can read too much into the "Header file for King's Quest" comment. I don't think this file has anything game specific as such, so that might be a very old comment line that they didn't bother to update)

Interesting that the later comment from April 87 does not have an equivalent in the .AH file, suggesting either that it wasn't required, or that the .AH version predates that change.

[lance.ewing]

That NO_PRMPT_RSTRT system flag isn't the only one that the GAME.AH is missing though. All of the following appear in the C version but not the .AH version:

Code: [Select]

#define TRACE_ENABLE 10 /* to enable tracing */
#define HAS_NOISE 11 /* does machine have noise channel */
#define RESTORE 12 /* restore game in progress */
#define ENABLE_SELECT 13 /* allow selection of objects from inventory screen */
#define ENABLE_MENU 14
#define LEAVE_WIN 15 /* leave windows on the screen */
#define NO_PRMPT_RSTRT 16 /* don't prompt on restart */

Its starting to look like the KQ3 code is quite a bit older, unfortunately.

[lance.ewing]

That was one of the first questions I had when I started looking at the source files in detail. Based on what I've found so far, I'm inclined to believe these are more than likely from the same version, at least most of them. The files appear to match the memory map in size and position

There is something unusual about these files that I have noticed many times but haven't really stopped to think about the implications of until now. The observation is that all these files on the SQ2 disk are not cleanly separated by the start of a cluster, i.e. one file runs immediately into the next and that happens within the same cluster, literally the next byte! The logical conclusion is that they were all in the same file. My current assumption is that a backup tool was used to join them all into a single file but where no compression was involved.

This is good for us because it would seem to suggest two things:

• The source files on the SQ2 disk are all from the same point in time, since they were archived together at the same time.
• The AGI.MAP memory map file is also likely to be from the same point in time, e.g. from the last time they compiled that source.

[lance.ewing]

Its starting to look like the KQ3 code is quite a bit older, unfortunately.

I have found more evidence that the code from the KQ3 disk is older. I started out with the MACRO.AH file as it appears on the KQ3 disk, but it is clear now that the "bios" macro isn't correct, since one of the uses of that macro assumes that the second parameter is optional, which it isn't. But compare that with the "bios" macro found in the SCI source, where that parameter is optional, and we probably have what the code on the SQ2 disk is expecting.

I was initially thinking that these other macros, such as ".if", "pcall", "break", "while", "until", "repeat", "enter", "exit", "breakif", "retif", "continue", etc. were perhaps in another macro file, but now that it is obvious that the MACRO.AH file on the KQ3 disk is older, then it could be that all those macros were in the version of the MACRO.AH file that the code on the SQ2 disk expects.

[lskovlun]

(I don't think we can read too much into the "Header file for King's Quest" comment. I don't think this file has anything game specific as such, so that might be a very old comment line that they didn't bother to update)

It is interesting nonetheless. If it really came from King's Quest it would have to be the GAL version, since by the time of AGI, Sierra was all about generic code. We have established that GAL is not simply an early kind of AGI. And yet, the file wasn't rewritten from scratch.

I noticed another macro-related thing. They use 'enter' as an assembly macro, but 'enter' is an opcode on 80186 and later processors. So it seems their assembler didn't complain about this.