Original AGI Interpreter

[Kawa]

I think that the SCI source would be using a newer version of MASM (6.xx) that has those built into MASM itself.

6.11 in my case.

[lance.ewing]

It looks like they had various preprocessors for the different platforms, which makes sense. I found mention of:

AP65.EXE
AP68K.EXE
AP86.EXE

...in the slack space of a KQ3 v1.01 int 2.272 disk. So these would be the preprocessors for the 6502 (for Apple II), 68K processors (Amiga, Atari ST and Mac), and the 8086 processors (DOS). The question now is: What product did these tools come with? Was it a product? Or did they write these themselves? I'm not finding anything so far online.

I have also found a file in slack space called AP86.LNK, which is a bit suggestive. In addition to that .LNK file, I have also found mentioned:

BILOAD.LNK
SIERRA.LNK

[OmerMor]

Maybe this (make file?) would give more clues:
https://github.com/historicalsource/leisure-suit-larry-1-alt/blob/8d7352d4d08336a97d92432a66c22a950a50aedc/SND/READMIDI#L5

Code: [Select]

readmidi.obj: readmidi.c
msc readmidi /Zi /Od;

midi_int.obj: midi_int.s
ap86 midi_int.s midi_int.tmp
masm midi_int.tmp;

readmidi.exe: readmidi.obj midi_int.obj
link readmidi+midi_int,readmidi,, /co;


[lskovlun]

My God, there was something I'd missed in that package. I thought I'd seen everything there was to find.

[lance.ewing]

Maybe this (make file?) would give more clues:
https://github.com/historicalsource/leisure-suit-larry-1-alt/blob/8d7352d4d08336a97d92432a66c22a950a50aedc/SND/READMIDI#L5

Code: [Select]

readmidi.obj: readmidi.c
msc readmidi /Zi /Od;

midi_int.obj: midi_int.s
ap86 midi_int.s midi_int.tmp
masm midi_int.tmp;

readmidi.exe: readmidi.obj midi_int.obj
link readmidi+midi_int,readmidi,, /co;


Thanks Omer. Very interesting. So that seems pretty clear then. They passed at least some assembler files through AP86 first, then used MASM. A shame that the .TMP file wasn't in that repo. That would have been interesting, to see the in between code.

Still not sure if AP86 was something that they wrote themselves but I'm currently assuming that. That other BILOAD.LNK file certainly appears to have been associated with them building something called BILOAD.COM. The same fragment of slack space on the floppy where this appears (its a fragment of a DOS directory table) also includes the files: MKBI.BAT, BILOAD.MAP, BILOAD.LNK and BILOAD.COM. The .LNK file appears to be part of the output of building certain files. So the existence of an AP86.LNK file in the slack space on another original Sierra game disk suggests that AP86 was also built by them.

What it is looking like then is that I have written the equivalent of what AP86 did but in MASM macro form. In the case of pcall, it only works with MASM 5.0 and above, but they were most likely still using MASM 4. I'm in two minds what to do then. It doesn't feel right to be using MASM 5.0. I might have to build my own equivalent to AP86 that isn't part of the main MASM execution step.

[lskovlun]

There is this tidbit from the SCI changelog:

Code: [Select]

3/3/92 - Jeff Stephenson
  [...]
  The assembly language preprocessor for Intel code (as.exe and ap86.exe)
  are now obsolete.  All assembly source code for the interpreter has been
  converted to use the MASM 6.0 structured assembly constructs, which are
  far superior.

     ***** PLEASE use these constructs rather than labels and jumps! *****
there's at least one commercially available preprocessor tool, made by HP, by the name ap86. But no references to ap65 or ap68k, so I think you're right. I wonder what BILOAD.LNK is (you didn't post it) - could be either the standard Sierra loader or a special loader for GAL (and other booters) so you wouldn't have to boot all the time during development. Or something else entirely.

[OmerMor]

there's at least one commercially available preprocessor tool, made by HP, by the name ap86.

I found this document that mentions it:
http://www.bitsavers.org/pdf/hp/64700/software_toolchain/B1449-97000_8086_Assembler_Apr93.pdf#page=54

ap86 accepts the macro preprocessor language that is described in the Intel 8086 Assembler Reference Manual. This macro language allows the definition and use of macros, evaluation and replacement of expressions, loop control, and including of other text files. Correct use of a macro preprocessor can simplify the task of writing assembly language source when redundant operations are performed or code is shared between files.

I believe this is referring to the following:
http://www.bitsavers.org/pdf/intel/ISIS_II/121703-003_ASM86_Language_Reference_Manual_Mar85.pdf#page=285

[lskovlun]

It is interesting to compare the various Sierra booter games. Many of them share the two-stage loader scheme (which would generally be required on an IBM PC) but with different and comparable version numbers. Others have written about the LOADER 2.0 versus LOADER 3.0 in DOS AGI games, but there are earlier ones out there. These were used in non-AGI games as well. In KQ1, the main executable is an EXE file, but is not run in a DOS environment. So the loader has to implement the EXE file parser itself. Even the Championship Boxing diskette uses these tools (now known as ABSBOOT and ABSLOAD) - but I don't think there's an EXE file there.

[lance.ewing]

there's at least one commercially available preprocessor tool, made by HP, by the name ap86.

I found this document that mentions it:
http://www.bitsavers.org/pdf/hp/64700/software_toolchain/B1449-97000_8086_Assembler_Apr93.pdf#page=54

ap86 accepts the macro preprocessor language that is described in the Intel 8086 Assembler Reference Manual. This macro language allows the definition and use of macros, evaluation and replacement of expressions, loop control, and including of other text files. Correct use of a macro preprocessor can simplify the task of writing assembly language source when redundant operations are performed or code is shared between files.

I believe this is referring to the following:
http://www.bitsavers.org/pdf/intel/ISIS_II/121703-003_ASM86_Language_Reference_Manual_Mar85.pdf#page=285

I am fairly sure that this HP ap86 is something different. The macro calling syntax is quite different. It appears that this HP tool requires a meta character at the start of the call and for the parameters to be in brackets.

%MOVE_ADD_GEN(INPUT, STORE, 100H)

The calls within the AGI source do not require a meta character at the start and the parameters appear without brackets, e.g.

pcall   ClearRect,topline,#TEXTLEFT,bottomline,#TEXTRGHT,attribute

pcall   open,&fontFile,#INPUT0

[lance.ewing]

I wonder what BILOAD.LNK is (you didn't post it) - could be either the standard Sierra loader or a special loader for GAL (and other booters) so you wouldn't have to boot all the time during development. Or something else entirely.

I'm not sure what it is, as there is only DOS directory table entries that I have found, not any part of the file itself. Let's dig a bit into that though. Where I found it was in a slack space fragment on a PQ1 disk:

Police Quest (1987) (v2.0G, Int. 2.917) (360K) (Disk 1)

...around offset $13F00. The DOS directory table fragment also contains the following files, which are also very interesting:

MKNONPRO.BAT
TESTSQ .BAT
MESSAGE.O
DOSRELOC.S
AGILOAD.O
BILOAD .MAP
MKBI.BAT
CHECK.MAP
MKCHECK.BAT
BILOAD.LNK
LOAD.COM
BILOAD.COM
GRAPHICS.O

I wonder if, given they appear in the same directory, we can assume that they are related. Obviously the AGILOAD.O implies a connection to AGI, and TESTSQ.BAT suggests a connection to Space Quest (despite this being a PQ disk, but that isn't unusual really, as these kinds of fragments usually came from a completely different disk, quite often a hard disk). What we can do is decode the other details of these DOS directory entries, such as the datetime and size, to reveal a bit more info. For example:

BILOAD.COM          2797 30-Jun-1987 08:08:02 [cluster=6694]
AGILOAD.O           1546 16-Nov-1987 13:31:58 [cluster=4838]

I'll check the dates for the others later today but the dates of the two above suggest it is the loader used by AGI. The cluster numbers definitely suggest the origin was a hard disk.

[AGKorson]

The assembler program that was bundled with their C compiler, Let's C, was named 'as.exe'. This is what the manual has to say about it:

as is a multipass assembler that will assemble functions written in i8086 assembly language. as will assemble programs into either SMALL or LARGE model, and will generate an object module in MS-DOS object format. It also supports i8087 opcodes, and it allows you to write functions in a model-independent manner.
as is not intended to be used for full-scale assembly-language programming; therefore, it does not include some of the more elaborate features found in full-fledged assemblers. For example, it has no facility for conditional compilation or user-defined macros. However, Let?s C allows you to use preprocessor instructions to perform conditional assembly and expand macros. In addition, as optimizes branches to take advantage of short addressing forms, where the span of the branch permits.

It says it doesn't support user-defined macros, but it will expand macros. But then it goes on to say that files must be named *.s or as won't run.

Is it just a coincidence that this file is named as.exe?

[lance.ewing]

I'll check the dates for the others later today but the dates of the two above suggest it is the loader used by AGI. The cluster numbers definitely suggest the origin was a hard disk.

These are the ones that I think are worth highlighting at this point:

MKBI.BAT             178 29-Jun-1987 10:42:02 [cluster=6685]
BILOAD.LNK           101 29-Jun-1987 10:42:38 [cluster=6689]
BILOAD.COM          2797 30-Jun-1987 08:08:02 [cluster=6694]
BILOAD.MAP          2736 30-Jun-1987 08:08:02 [cluster=6682]
LOAD.COM            1833 29-Jun-1987 12:01:04 [cluster=6690]
LOAD.MAP            2092 29-Jun-1987 12:01:02 [cluster=6710]
MKCHECK.BAT          146 29-Jun-1987 10:40:20 [cluster=6688]
CHECK.COM           2686 29-Jun-1987 12:02:26 [cluster=6715]
CHECK.MAP           2622 29-Jun-1987 12:02:26 [cluster=6686]
LOADCHK.EXE         3457 29-Jun-1987 10:45:00 [cluster=6702]
MKCRYPT.BAT          172 29-Jun-1987 10:37:48 [cluster=6719]
DECRYPT.MAP         2620 29-Jun-1987 12:01:30 [cluster=6704]
DECRYPT.COM         2689 29-Jun-1987 12:01:30 [cluster=6724]
SIERRA.LNK            88 29-Jun-1987 10:27:00 [cluster=6718]

MKNONPRO.BAT         197 05-Nov-1987 10:52:44 [cluster=1709]
PROTECT.COM         3121 05-Nov-1987 10:54:38 [cluster=5083]
PROTECT.MAP         2807 05-Nov-1987 10:54:36 [cluster=4961]

AGILOAD.O           1546 16-Nov-1987 13:31:58 [cluster=4838]
GRAPHICS.O           441 30-Sept-1986 10:19:22 [cluster=6696]
MESSAGE.O           1070 16-Apr-1987 14:09:22 [cluster=6676]
DOSRELOC.S          5048 04-Nov-1987 10:17:02 [cluster=1655]
DOSCPC.O            1469 30-Jun-1987 08:07:28 [cluster=6728]
DOSRELOC.O           747 16-Nov-1987 13:31:30 [cluster=3484]
DOSERR.O             308 28-Apr-1987 08:38:08 [cluster=6717]

Particularly the first batch, which are all dated around the same date and appear to show several small executables and the artifacts related to building those executables. I wanted to highlight again the .LNK files, both the BILOAD.LNK and SIERRA.LNK files. It is relevant to AP86 because of the existence of AP86.LNK in a DOS directory table entry in the slack space of one of the disks.

AP86.LNK              21 07-Sept-1986 17:02:58 [cluster=342]

Hmmm, didn't expect it to be so small though. Whatever these .LNK files are, they're always quite small. I also found the details of the AP86.EXE file on one of the disks:

AP86.EXE           17742 28-Sept-1987 11:35:04 [cluster=1511]

Edit: I found another occurrence of AP86.EXE in a slack space DOS directory table entry, which gives a slightly different size and date:

AP86.EXE           18070 26-Mar-1987 16:36:38 [cluster=4876]

But its still roughly the same ballpark with regards to size.

Edit 2: I have found yet another occurrence of AP86.EXE in a slack space DOS directory table entry:

AP86.EXE           14848 01-Oct-1986 12:10:02 [cluster=52]

[lance.ewing]

The assembler program that was bundled with their C compiler, Let's C, was named 'as.exe'. This is what the manual has to say about it:

as is a multipass assembler that will assemble functions written in i8086 assembly language. as will assemble programs into either SMALL or LARGE model, and will generate an object module in MS-DOS object format. It also supports i8087 opcodes, and it allows you to write functions in a model-independent manner.
as is not intended to be used for full-scale assembly-language programming; therefore, it does not include some of the more elaborate features found in full-fledged assemblers. For example, it has no facility for conditional compilation or user-defined macros. However, Let?s C allows you to use preprocessor instructions to perform conditional assembly and expand macros. In addition, as optimizes branches to take advantage of short addressing forms, where the span of the branch permits.

It says it doesn't support user-defined macros, but it will expand macros. But then it goes on to say that files must be named *.s or as won't run.

Is it just a coincidence that this file is named as.exe?

Yeah, I did wonder whether Jeff meant the AS.EXE tool that comes with MWC when his comment in the SCI change log says:

The assembly language preprocessor for Intel code (as.exe and ap86.exe)
  are now obsolete.

I wonder why two tools would have been required. Wouldn't it have been possible to write a small pre-processor as a single executable? - It seems clear that they used MASM for the actual assembler, and that snippet that Omer found appears to show that, i.e. ap86 followed by masm. No need for AS.EXE.

I think that they would have had the AS.EXE tool from the MWC compiler on their machines, since it comes in the BIN directory of the distribution disks, the same BIN directory that has the C compiler EXE files. The various EXE files for the C compiler steps appear in slack space DOS directory table entries across multiple original AGI game disks, and there are also occurrences of AS.EXE. The question is whether it really is the one from MWC, or is the one Jeff is referring to, or are they're both the same tool... and if its the latter, then how was it used with AP86?

Edit: I have found two occurrences of AS.EXE in DOS directory table entries in the slack space of original AGI games disks:

AS.EXE             31409 29-Nov-1985 09:09:26 [cluster=29]

AS.EXE             13980 23-Jul-1987 11:36:50 [cluster=9128]

It is curious that the older occurrence is larger in size.

[lance.ewing]

I wanted to highlight again the .LNK files, both the BILOAD.LNK and SIERRA.LNK files. It is relevant to AP86 because of the existence of AP86.LNK in a DOS directory table entry in the slack space of one of the disks.

AP86.LNK              21 07-Sept-1986 17:02:58 [cluster=342]

Hmmm, didn't expect it to be so small though. Whatever these .LNK files are, they're always quite small.

I am not sure if this is true of the MS DOS LINK tool, but certainly for the PLINK86 tool that was used as the linker for the AGI executable and overlays, the .LNK file extension is the default extension for the linker "command" file. I think that Sierra would have used PLINK86 for some things, like AGI where the PLINK overlay system was used, but also LINK for other tools. LINK did also support a command input file but I'm not sure if .LNK was also the default file extension for that. Regardless, it seems very likely that these .LNK files were to instruct the linker, and therefore AP86.LNK would have been for defining how to link AP86.EXE. With a size of 21 bytes, it wouldn't have said much at all, perhaps only enough to specify the name of the input and output files. I am assuming it was a simple one module program, so maybe there was an AP86.OBJ that was linked into AP86.EXE.