Messages

31

AGI Development Tools / Re: Original AGI Interpreter

« on: June 25, 2024, 12:59:52 PM »

Have you looked into the FILEIO source from the SCI interpreter? Perhaps it's similar.

Omer, I probably should have asked this before now, but I assume that you don't have any original AGI interpreter source, other than what was extracted from the game disks?

Would save some time 

32

AGI Development Tools / Re: Original AGI Interpreter

« on: June 25, 2024, 10:57:24 AM »

I'm certainly making more progress with MASM 5.0.

The MASM 5.0 manual does mention a couple of new features not in MASM 4 that would explain why I was finding it hard to get it working under MASM 4:

The use of angle brackets to force string evaluation is a new feature of Version 5.0 of the Macro Assembler. Previous versions tried to evaluate equates as expressions. If the string did not evaluate to a valid expression, MASM evaluated it as a string. This behavior sometimes caused unexpected consequences.

I was aware that MASM 4 didn't support the <> syntax for string equates, but this quote stresses the difficulty that people (like me I guess) had with trying to make MASM 4 treat something as a string.  It is possible to define a string equate, by relying on that fallback mechanism described above, but I'm now thinking that there isn't a way in MASM 4 to perform string concatenation, which is certainly possible in MASM 5.0, as I have that bit working now, i.e. building up a string character by character (which seems to be what is required to perform a substring in MASM 5.0 in the absence of the SUBSTR directive, which doesn't become available until 5.1).

The other big difference that make it difficult/impossible under MASM 4 is this one:

%text

MASM computes the expression's value and replaces text with the result. The expression can be either a numeric expression or a text equate. Handling text equates with this operator is a new feature in Version 5.0. Previous versions handled numeric expressions only.

It's that last point, i.e. that MASM 4 handled numeric expressions only, that causes issues with what I'm trying to do in the pcall macro.

I still don't have it working in MASM 5.0 yet. The biggest blocker is with the & character. It is certainly possible to loop over the characters in a string, and it is possible to test for the # character and other normal alphanumeric characters, but trying to test for & isn't working. I think it must be trying to do a substitution, which is what & does within a macro, by default. It is apparently possible to create a & literal using <>, e.g. <&>, but I haven't yet worked out how to make use of that. There is also something going on with types. I am wondering whether internally it treats a single char and a string as different types when doing an identical test, since my logging within the macro shows that I am comparing a character of & (from the irpc loop) with a & string constant (since I can't seem to use & directly in the comparison, due to the substitution issue I mentioned), but the comparison evaluates to false, even though my logging shows that both sides contain &.

Anyway, this is where I am at the moment. I have a couple more ideas to try, but they're starting to become work arounds and hacks. If one of them works though, I'll go with it.

33

AGI Development Tools / Re: Original AGI Interpreter

« on: June 24, 2024, 02:17:25 AM »

Unfortunately its bad news. The syntax shown in that MASM 5.0 MIXED.INC file doesn't' work in MASM 4. The IRPC bit to loop over the chars does work but not much after that. I'm going to try MASM 5.0 next using this approach. If it works, then I guess I can switch to MASM 5.0, since that was released at the end of July 1987. It is possible that they switched to MASM 5.0 at that time and started to make use of new features. For that to be true, it would mean that they weren't previously using a pcall macro.

34

AGI Development Tools / Re: Original AGI Interpreter

« on: June 23, 2024, 07:28:58 AM »

After more reading, it looks like 'Let's C' will use their internal assembler if the source file ends in '.s' and it will use MASM if the source file ends in '.asm'. Since all the assembly source files end in '.asm', it looks like Sierra wasn't using the MWC built in assembler. So I guess that theory is debunked.

The fact that MWC by default uses MASM when the file extension is .ASM adds further support to MASM being what Sierra used for those files. So we have the comment in the SCROUT.ASM file that mentions MASM, and now also the fact that MWC uses MASM by default for .ASM files. We don't have a copy of their make file for AGI, so its hard to say if they used MWC for everything (with the .ASM files being delegated to MASM), or whether they built the .ASM files directly with MASM. I guess there wouldn't be much difference.

Further support that MASM is what they were using (can't remember if I mentioned this already) is that the floppy disk slack space for some games has directory entries for MASM. I checked the timestamp and file size mentioned in that dir entry and it matches MASM 4 exactly, which is the main reason I started out with using MASM 4.

I think that this IRPC directive is most likely going to work. I've drafted an initial implementation of the pcall macro using IRPC and logically it appears that it should work, from reading through the macro code I've come up with. I just need to work through the various syntax errors I've got in there at the moment, but I have a good feeling I should be able to resolve those and have something that works. Hopefully there will be good news later on.

35

AGI Development Tools / Re: Original AGI Interpreter

« on: June 22, 2024, 07:54:09 PM »

I may have finally found something available in MASM 4 that should do the trick. It's the IRPC directive. It loops over the characters in a string. So it should be possible to use that to check the first char and split off the rest. There is an example of doing something similar to that in the MIXED.INC macro file provided with MASM 5.0.

Code: [Select]

; Split argment into argNameCur and typeNameCur

fetType macro arg
    cbType=0
    fColon=0
    argNameCur equ < >
    typeNameCur equ < >
    .xcref fColon, argNameCur

    irpc aChar,arg
        if fColon
            conCat typeNameCur, %typeNameCur, aChar
        else
            ifidni <aChar>,<:>
                fColon=1
            else
                conCat argNameCur,%argNameCur,aChar
            endif
        endif
    endm
    adjustType %typeNameCur
endm

This example is splitting strings like the following:

rectype:byte

It looks for the colon in the middle to switch between concatenating to the arg name vs the arg type name.

The cool thing is that the macro code it is using should also work in MASM 4. I'll give this approach a go tomorrow.

36

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.

37

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.

38

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.

39

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.

40

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.

41

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


42

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?

43

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.

44

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.

45

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.