Messages

31

AGI Development Tools / Re: Original AGI Interpreter

« on: June 22, 2024, 06:42:44 PM »

In the MASM manual there is talk of a "TYPE" operator that can be applied to an expression to see what it is. It says it returns "a number" but I don't see what the possible numbers are. I would make a macro that takes a parameter and print out the TYPE of the parameter, and then I bet you could use that with some IF directives to select the code to emit based on the type of thing (register / word / pointer?) passed to the macro

I couldn't see how this would work with the values starting with # and &. I think TYPE must be for determining the type of data. The documentation talks about the size being returned for simple types like byte, word, etc. The problem with these values that are prefixed with & and # is that they aren't valid symbols. They don't actually refer to anything as such. Without the & and #, then do refer to something. I think that when these values, e.g. &noMemMsg or #TEXTLEFT, are passed into the macro, they must look like string values at that point, rather than a symbol that references data, since # and & do not have the meaning within MASM that these pcall usages appear to convey. If the macro uses them as-is with an asm instruction, then it wouldn't be valid. When I try to do that, I get the message "error 101: Missing data; zero assumed". It treats it as a warning, which is quite strange actually, as it clearly isn't correct for it to assume a zero value.

I'm stumped to be honest. I've skimmed through the MASM 4 manuals a few times and can't see anything that would be able to do what needs to be done here. It needs two different mechanisms: One is to recognise the &, #, or neither of those based on the first character, and the other mechanism is to get the substring from the second character to the end, which would give the actual symbol name in the case of & or # being present. Later versions of MASM do support INSTR and SUBSTR, which would be useful, because they could presumably be used to detect the # and & characters, and then to get the substring after that character. I looked at the strings in versions 5.0 and 5.1 of the MASM.EXE. Version 5.0 has no mention of INSTR and SUBSTR but version 5.1 does. I feel like it would be cheating though to write something that targets MASM 5.1, since that version wasn't yet available (the two 5.1 versions are dated 31st Jan 1988 and 1st Feb 1988). I may end up having to target version 5.1 though, as I can't see how it can be done in MASM 4.

I did wonder whether maybe they used more than one assembler. As was mentioned earlier in this thread, one of the files, SCROUT.ASM, mentions MASM by name in one of the comments. SCROUT.ASM also happens to be one of the files that uses these strange pcall macro calls, so it is difficult to suggest that a different assembler was used for that file when MASM is mentioned within the file. Of course, it could be the case that the comment is old and that they were using a different assembler at this time and hadn't bothered to remove that comment. It is worth considering. I'm not sure what other assemblers would have been around that might have handled this type of syntax. Or is it possible that some kind of preprocessor was used on the .ASM file before MASM was used?

One thing I'm trying not to think too much about is that the SQ2 disk itself was prepared in mid-March 1988, i.e. that is when the AGI interpreter and game files for SQ2 were copied onto the master disk. So it is theoretically possible that the AGI interpreter source is more recent than the October 1987 date. The problem with this though is that AGKorson's analysis of AGI versions, i.e. the evolution of the different sizes of the various internal data and code parts within the interpreter, places the source code around that 2.903 version, which can't be any later than early Nov 1987, since the 2.911/2.912/2.915 are from Nov 1987, and 2.917 is early Dec 1987. The point to make though is that MASM 5.1 was available prior to March 1988 when the SQ2 disk was prepared, thus the reason why it being theoretically possible that the AGI interpreter source is more recent is of relevance, as it would then bring MASM 5.1 into the picture. I feel like that is stretching the evidence a bit though.

32

AGI Development Tools / Re: Original AGI Interpreter

« on: June 22, 2024, 12:34:53 PM »

Have you seen anything that indicates what version interpreter the source is from?

AGKorson answered that question earlier in this thread:

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.

The source code appears to date to a few weeks before the first game using 2.903 was released. The memory map file is dated the 7th October 1987. Version 2.903 was used for an early Police Quest release. I don't have that disk image, so I can't check myself what the timestamp is for the AGI and AGIDATA.OVL files on that disk. I found a date of 23rd October 1987 mentioned online though.

AGKorson has done a detailed analysis of the sizes of the various parts of the AGI.MAP memory map file and deduced that it predates 2.903, but is mostly a match for 2.903, with, as he mentioned in the quote above, a few bits still matching what was in 2.440.

33

AGI Development Tools / Re: Original AGI Interpreter

« on: June 21, 2024, 06:23:03 PM »

Version 5.1 of MASM has some new features apparently not in MASM 5.0 or 4 that look like they could be useful, but MASM 5.1 wasn't released until 1988, whereas the code is dated the 7th October 1987. I'm trying to use 4 since this is likely what they used at the time.

34

AGI Development Tools / Re: Original AGI Interpreter

« on: June 21, 2024, 12:27:13 PM »

I think the logic for this is all inside the missing macro. The # and & is indicating to the macro what type of parameter it is, and then the macro must be somehow detecting that and behaving differently. If I compare some pcall usages with the disassembly of the same code, then these are some examples of what gets generated:

#15

becomes:

mov   [bp+var_2], 15
push   [bp+var_2]

and:

&noMemMsg

becomes:

push   ax
lea   ax, noMemMsg
mov   [bp+var_2], ax
pop   ax
push   [bp+var_2]

where the [bp+var_2] is a local variable (var_2 is negative).

And then there is the normal case where it pushes the macro parameter as is:

ax

becomes:

push   ax

Three different behaviours, based on whether the first char is #, & or neither.

Now I need to read up more on macros to see how this kind of determination logic and be implemented.

35

AGI Development Tools / Re: Original AGI Interpreter

« on: June 21, 2024, 09:48:56 AM »

So, yeah, I think it is mainly the "pcall" macro uses below that are causing issues:

Code: [Select]

DOTEST.ASM:     pcall   Error,#15,ax    ;bad test number
EQUIPCHK.ASM:   pcall   _SetTextAtr,#WHITE,#BLACK
EQUIPCHK.ASM:   pcall   open,&fontFile,#INPUT0
EQUIPCHK.ASM:   pcall   printf,&noFontMsg
EQUIPCHK.ASM:   pcall   read,ax,heapBase,#FONTFILESIZE
EQUIPCHK.ASM:   pcall   printf,&noMemMsg
INTRPT.ASM:     pcall   WindowNoWait,&badStackMsg
SCROUT.ASM:     pcall   PutChar,#RETURN ;out of window -- recurse on
SCROUT.ASM:     pcall   ClearRect,topline,#TEXTLEFT,bottomline,#TEXTRGHT,attribute

i.e. any usage that uses # or &.

The following are working fine:

Code: [Select]

DOTEST.ASM:     pcall   TraceTest,ax,savedTestPtr
DOTEST.ASM:     pcall   CompareStrings,ax,bx
EQUIPCHK.ASM:   pcall   close,ax
EQUIPCHK.ASM:   pcall   ErrBeep
SCROUT.ASM:     pcall   ClrLines, theLine, theLine, clrAtr

There must be a way to translate the # and & into a form that MASM understands. For example, if & could be translated into "OFFSET " then maybe that might work (?). Maybe there is a way to define/override what these chars do. The & char is a tricky one though, as that is by default used for substitution, which I'm making heavy use of in the macro definitions.

36

AGI Development Tools / Re: Original AGI Interpreter

« on: June 21, 2024, 02:16:06 AM »

1. The TYPE keyword as understood by MASM is clashing with a "type" symbol in one of the source files. I think there might be an option to support using keywords for symbols. Haven't tried it yet though.
2. The "return" macro is clashing with the RETURN constant that is defined in one of the source files.

Actually, rather than there being an option to support using keyword names as symbol names (I thought I saw one but can't spot it now in the MASM 4 command line options), there is instead an /ML option that allows symbols to retain their case. Using that option allows, for example, "type" to avoid clashing with TYPE.

I don't think the RETURN constant was clashing with the return macro btw. I misinterpreted the error. It's another example of the 4th issue. This is in the SCROUT.ASM file:

Code: [Select]

pcall PutChar,#RETURN

where RETURN is defined as follows:

Code: [Select]

RETURN               equ     13


37

AGI Development Tools / Re: Original AGI Interpreter

« on: June 20, 2024, 11:57:28 AM »

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.

Yes, very interesting, in fact it isn't the only reference to a specific game. I'd like to explore that a bit more in a later post. I recall seeing a KQ II reference as well.

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.

I've tried MASM 4.0 with every one of the ASM files now, using my implementations of the missing macros. Most of the files are producing .OBJ files without error. Obviously not tested though, so there could very well be errors in my macro implementations. I won't really be able to test them properly until I've fully linked it together. I have successfully compiled all the C source using the MWC compiler (version 4 for that one as well). Its going to be some time before the missing bits are ready though, as I'll have to reconstruct each of those. I've done it already for a couple of files, one of which I haven't yet pushed to the repo.

MASM had no problems with the "enter" macro. It does have problems with a few things though. I think I have three separate issues at the moment, or maybe its four if I'm being picky.

1. The TYPE keyword as understood by MASM is clashing with a "type" symbol in one of the source files. I think there might be an option to support using keywords for symbols. Haven't tried it yet though.
2. The "return" macro is clashing with the RETURN constant that is defined in one of the source files.
3. Some of the "pcall" macro calls are using a & char in front of a string parameter, presumably to get the address of the string. MASM doesn't seem to like this. It outputs a warning and uses a value of 0, which doesn't sound good.
4. Some of the "pcall" macro calls are using a # char in front of either a number (e.g. #15) or a numeric constant (e.g. #TEXTRGHT"). This is presumably meant to indicate an immediate value but MASM doesn't like this either. It doesn't seem to recognise the # char being used in this way, in fact the macro calls would probably work without the #, so not sure why they are needed.

I've searched online a bit, and read through bits of a few MASM books online, but can't see anywhere where # or & are used in this way. It suggests that something else other than MASM was looking at these.

Any ideas?

38

AGI Development Tools / Re: Original AGI Interpreter

« on: June 19, 2024, 06:02:37 PM »

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.

39

AGI Development Tools / Re: Original AGI Interpreter

« on: June 15, 2024, 03:01:29 AM »

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.

40

AGI Development Tools / Re: Original AGI Interpreter

« on: June 14, 2024, 02:25:43 AM »

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.

41

AGI Development Tools / Re: Original AGI Interpreter

« on: June 14, 2024, 02:18:50 AM »

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.

42

AGI Development Tools / Re: Original AGI Interpreter

« on: June 14, 2024, 01:50:28 AM »

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.

43

AGI Development Tools / Re: Original AGI Interpreter

« on: June 13, 2024, 05:22:38 PM »

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.

44

The Games and other Sierra Adventure stuff / Re: New Sierra Documentary In the Works

« on: June 13, 2024, 12:41:59 PM »

This documentary sounds very interesting, and I'd certainly be interested to talk to them. I watched something on Netflix a while back that had an episode that featured Ken & Roberta quite prominently. What was it called...? "High Score", episode 3: https://www.netflix.com/gb/title/81019087. The same episode featured Richard Garriot as well, who features within the Sierra story, him and Chuck Bueche, although I don't think Chuck Bueche was in that Netflix episode. I spoke to Chuck Bueche a while back in relation to the 1982 video that Ken posted on the Colossal Cave Youtube channel. There is a scene that has Chuck in the foreground.

I also tracked down employee number 3, Eric Griswold. He is quite a friendly guy. You probably won't have heard of him, as he wasn't with Sierra for too long. One of the games he was involved in was Time Zone.

45

AGI Development Tools / Re: Original AGI Interpreter

« on: June 13, 2024, 12:29:39 PM »

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.