Messages

1

The Games and other Sierra Adventure stuff / Re: KQ6AGI - Complete after 18 years of development!

« on: August 22, 2024, 11:17:38 AM »

This is truly amazing! It's great to see so many AGI labours of love being released over the past year or so. I was aware of the project from way back, but didn't realise that it was close to release. I've just watched through the whole video and it looks great. I'll give the game a go in AGILE this evening to see how it works there. It will be interesting to see. AGILE (both the C# and web versions) wouldn't have the resource limitations that the original interpreter had, so hopefully the customisations to the interpreter won't be an issue.

Watching the video has made me realise that I played the original KQ6 so long ago now that this is like a new story to me. I have images of the original graphics in my mind from back then, but the story line feels almost new. I really should play this through, and also KQ5 at some point. It's been a while. I've been so focused on AGI over the years that my memories of SCI games are getting vague

2

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

« on: August 07, 2024, 11:03:03 AM »

Was also quite interesting to hear from Bob Heitman; there was one comment he made in particular that struck me:

"A goal of mine for years - and I don't think I'm going to realise it, because it takes a lot of effort still - is to return game development, at least adventure game development, to a one or two person format. Something, a set of of tools - I can't really phrase how they'd be written - that would put the power of creating games back into the hands of one or two people who just have an idea and they want to get it out there, but they can't affort 20-50 million dollars put their game out there to entertain people. That's something that I still want to see somebody do."

Yeah, I remember him saying that.

It does make me wonder though, what might a modern adventure game engine and development environment, one designed for today's technological capabilities, look like? I'm "between jobs" right now and hunting around for something to do to fill my time and feel kind of tempted to have a go at this, but I'm curious to hear what others think of this. A few ideas - 3d world, procedural generation of graphics and/or some game elements, a nice & simple scripting language, interactive programming (game world updates as soon as you change it, no compilation), publishing to web/native, online play and online collaborative editing. Just a few random ideas, but I'd love to hear yours.

Something that I've been thinking about for a while now is an integrated online editor and interpreter for AGI games, and with AGILE now running in the browser, I guess my approach would be to extend that. Obviously that is quite niche though, and only a handful of people are ever going to use it

You seem to be thinking of something new that will capture a modern audience, but perhaps in the same spirit as AGI and SCI. I think that the online collaborative editor and interpreter would be a key part though, something similar to what kids use in schools these days, e.g. Scratch and Construct3D, where they have an account and can build away, save, execute directly in the browser and share. I'd say yes to the simple scripting language as well, it could even be visual in nature, such as with Google Blockly, whose demos show switching between source and visual, which I think would be needed for people who like to code quickly directly in the source.

The cool thing about a web based interpreter is that it can easily be packaged up to run on mobile devices as well, the game execution bit I mean. Editors on mobile devices are pretty neat at first, but its more of a gimmick I think. It's difficult to actually be productive when "building" within such a small screen size, so the novelty seems to wear off pretty quick... at least in my own experience

3

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

« on: August 06, 2024, 11:34:46 AM »

For those who haven't been keeping an eye on it, the crowd funding campaign is in its last 8 hours. It is currently over 400% funded, which means that it has exceeded a few of the stretch goals along the way. The latest one is the mini-doc series, which means that in addition to the main documentary, they'll do a further series of mini-docs with even more in-depth coverage. I think its going to be great. If you were intending to back it, then you have 8 hours left.

The other thing that was really cool recently was the Adventure Game Fan Fair. I didn't attend, but I watched some of the streams online. It was great to see the former Sierra employees speaking in the various panels, including Bob Heitman in a couple of them. Always great to hear what he has to say. I think that his memory of those days is second to none. I have my fingers crossed that since the team behind the documentary were at the Fan Fair that they will have spoken to Bob about being involved in the documentary as well. They already have a rather impressive cast of ex-Sierra employees lined up.

4

The Games and other Sierra Adventure stuff / Re: 40 years ago (KQ1/GAL/AGI)

« on: July 26, 2024, 02:21:10 PM »

Another amazing video about the 40th anniversary:

5

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

« on: July 10, 2024, 09:36:17 AM »

The Backerkit campaign for this launched yesterday and it has already exceeded their lowest goal amount, so I guess that means it is definitely going ahead now. The first 48 hours apparently has cheaper amounts for the pledges. I was very tempted to back it yesterday, in fact almost entered my card details. The bonus for backing in the first 48 hours is not only the cheaper price, but also a free PDF of Ken's book. I already bought that book about 20 months ago, so if I don't back it now, its only the cheaper price I'd be missing. I am wondering if anyone else has backed it yet? And, if so, do people have a feel for how safe this website is? It looks like they don't charge the card until the end of the campaign, which implies that they hold on to the card details, right?

https://www.backerkit.com/c/projects/legends-of-adventure/legends-of-adventure

6

AGI Development Tools / Re: Original AGI Interpreter

« on: July 05, 2024, 12:50:07 PM »

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.

7

AGI Development Tools / Re: Original AGI Interpreter

« on: July 04, 2024, 02:14:55 AM »

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.

8

AGI Development Tools / Re: Original AGI Interpreter

« on: July 03, 2024, 02:37:39 AM »

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]

9

AGI Development Tools / Re: Original AGI Interpreter

« on: July 02, 2024, 02:24:03 AM »

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.

10

AGI Development Tools / Re: Original AGI Interpreter

« on: July 02, 2024, 02:00:39 AM »

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

11

AGI Development Tools / Re: Original AGI Interpreter

« on: July 01, 2024, 02:18:11 AM »

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.

12

AGI Development Tools / Re: Original AGI Interpreter

« on: June 30, 2024, 03:42:16 AM »

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

13

AGI Development Tools / Re: Original AGI Interpreter

« on: June 30, 2024, 03:01:46 AM »

I think that the SCI source would be using a newer version of MASM (6.xx) that has those built into MASM itself. The interesting thing is that the .if control flow directive is quite different from what the AGI source is using. One difference is that it ends with a .endif, whereas the one used in AGI ends with .end. Another is that the condition that appears after .if in the SCI source (and supported directly in MASM 6.xx) is more complex. It supports complex conditional expressions, e.g. .if ah && (al == eofCode). The one used in AGI only supports things like: .if not_equal, all variations of which translate to a conditional jump. It relies on the state of the processor already being set, so usually has a cmp immediately before. The SCI code does show examples of that simpler form as well, e.g. the zero, sign, etc. that you mentioned. The MASM 6 documentation mentions the two cases, i.e. "C-style" expressions, and simply checking the state of processor flags. I don't think the one used with AGI supports the C-style expression format.

Some other differences: The AGI code uses "repeat", "while", "until", "break", etc. without the dot at the start.

Given that the MACRO.AH file extracted from the KQ3 disk is dated the 24th March 1987:

1987-03-24 14:24:02 MACRO.AH       728 bytes   728 bytes  From KQ3 2.14 (720K disk 1)

and the INTRPT.ASM file that uses pcall (and several of the other missing macros) is dated only a couple of weeks later:

1987-04-07 09:00:32 INTRPT.ASM    6760 bytes  6760 bytes  From SQ2 2.0D (720K disk 1)

then it seems quite likely that the missing macros were never in the MACRO.AH file and instead came from somewhere else. Although having said that, the fact that the MACRO.AH file on the KQ3 disk has a datetime that isn't the 5th Feb 1987 means that they added something to it, the most recent update being on the 24th March 1987, so they were working on it to some degree. Is it possible that they coded all those missing macros in a couple of weeks? It seems unlikely, especially given that an implementation for pcall does not seem possible until MASM 5.0.

I have noticed that MASM 4 had a beta release that presumably came out before the official release date of MASM 4. That sets some precedent for MASM 5.0 being available in an early release of some kind, but I can find no mention of that, so currently we might have to assume that MASM 5.0 wasn't available until the 31st July 1987.

So if they weren't defined in the MACRO.AH, then what does that leave us? It seems unlikely to be honest that they were defined in a different macro file. If they were custom macros that Sierra wrote, then I'd expect them to be in that file. I have seen that the IBM Macro Assembler supported a pre-processor called SALUT but there is nothing in there that looks like these. However, it did give me the thought that something similar may have been used by Sierra, i.e. a pre-processor of some kind. If it was a standard pre-processor product though, that provided direct support for these directives, then I would expect to find some other examples of code online that uses them, but I haven't turned up anything so far.

Oooohhh, interesting. I just did a search for "masm" across the SCI interpreter code base. Some very interesting comments turned up in the SCI.DOC file that I believe has finally answered the question!!

Code: [Select]


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! *****

If you don't have a copy of MASM 6.0, get one from Larry.

Jackpot!!

So that does indeed solve the mystery. It confirms that they switched over to using the MASM 6.0 structured assembly constructs, but it also confirms the name of the pre-processor they were using prior to that, i.e. AS.EXE and AP86.EXE. I have seen both of these mentioned in the slack space of original AGI game disks, but wasn't able to turn up much on them. The comment above appears to suggest that SCI was using the same as AGI for these "structured assembly constructs" in early versions, i.e. before changing to MASM 6.

The comment in SCI.DOC is from Jeff, dated 3/3/92. So this is roughly when they switched from MASM 5.1 to MASM 6, or shortly before that.

I assume we don't have access to an earlier version of the SCI source? Or better yet, AS.EXE and AP86.EXE hiding somewhere?

14

AGI Development Tools / Re: Original AGI Interpreter

« on: June 29, 2024, 03:59:04 PM »

I have been able to successfully build all "complete" files of those extracted from the SQ2 & KQ3 disks. As mentioned, one of them is truncated due to the end of the disk.

This is a link to the macro file containing my implementations of the missing macros:

https://github.com/lanceewing/agi/blob/main/missing/MACRO.AH2

This could be quite different to what they had but it seems to work. I haven't been able to execute the code yet, as I can't really do that until all the missing modules are reconstructed, and everything then linked together, but a quick visual check seems to confirm they're doing what they should, the macros I mean.

I am currently in the middle of reconstructing the ACTION module. This is the one that contains the table of details about the AGI actions (i.e. commands) and also one subroutine to use that table to execute an action. Reconstruction is going well so far. I'll most likely look at the VAR module after that.

15

AGI Development Tools / Re: Original AGI Interpreter

« on: June 27, 2024, 07:31:28 PM »

I have decoded the details about the files on the SQ2 disk. It turns out that there are details for 85 distinct files, which covers most of the ones for which there is source on the disk. In the process of decoding this, I've discovered that the format is the DOS BACKUP format, i.e. the format created by the BACKUP DOS command. The fields match exactly. So that answers the question as to what tool they used. The physical floppy disk must have been used with the BACKUP command to create an archive of the AGI source, plus a few extras.

The following is the full list of files mentioned, their dates and sizes. Notice that there are two sizes: One is the total size of the original file. The other is the amount of the file in bytes actually stored on the disk. In most cases, the two sizes are the same, but for one of them, JRGRAPHX.ASM, the second size is smaller. This is because the disk ends before the whole file can be completed, so it is only a part of the file. The rest of it would presumably continue on the next floppy.

Code: [Select]

1987-02-05 ANIOBJ.H      2892 bytes  2892 bytes
1987-02-05 BEEP.ASM       758 bytes   758 bytes
1987-02-05 DIRFLAGS.H      87 bytes    87 bytes
1987-02-05 DOSFLAGS.H      89 bytes    89 bytes
1987-02-05 ERRMSG.H      1046 bytes  1046 bytes
1987-02-05 EVENT.H        642 bytes   642 bytes
1987-02-05 FLAG.ASM      2624 bytes  2624 bytes
1987-02-05 FLAGS.H         89 bytes    89 bytes
1987-02-05 HDIALOG.C     1593 bytes  1593 bytes
1987-02-05 INITDIR.ASM    696 bytes   696 bytes
1987-02-05 JRJMPTBL.ASM   415 bytes   415 bytes
1987-02-05 KBDDRV.C      1331 bytes  1331 bytes
1987-02-05 KEYDEFS.H      777 bytes   777 bytes
1987-02-05 KEYMAP.C       481 bytes   481 bytes
1987-02-05 LOG.C         1352 bytes  1352 bytes
1987-02-05 LOGIC.H        528 bytes   528 bytes
1987-02-05 MISC.ASM      3091 bytes  3091 bytes
1987-02-05 MOVEOBJS.C    2608 bytes  2608 bytes
1987-02-05 NEWROOM.C     2170 bytes  2170 bytes
1987-02-05 OBJACT.C      1421 bytes  1421 bytes
1987-02-05 OBJECT.H       494 bytes   494 bytes
1987-02-05 OBJLIST.H      627 bytes   627 bytes
1987-02-05 PICOBJ.C      1981 bytes  1981 bytes
1987-02-05 PICOBJ.H       317 bytes   317 bytes
1987-02-05 PICTURE.H      207 bytes   207 bytes
1987-02-05 POSITION.C    2721 bytes  2721 bytes
1987-02-05 PRIORITY.C     904 bytes   904 bytes
1987-02-05 PRODIO.H       450 bytes   450 bytes
1987-02-05 SAVEAREA.C    1218 bytes  1218 bytes
1987-02-05 SCRIPT.H       400 bytes   400 bytes
1987-02-05 SEGERR.H       371 bytes   371 bytes
1987-02-05 SEGIO.H        482 bytes   482 bytes
1987-02-05 SOUND.C       2199 bytes  2199 bytes
1987-02-05 SOUND.H        209 bytes   209 bytes
1987-02-05 TEXTWIN.H      148 bytes   148 bytes
1987-02-05 TRACE.H         92 bytes    92 bytes
1987-02-05 TYPES.H        774 bytes   774 bytes
1987-02-05 VIEW.C        6793 bytes  6793 bytes
1987-02-05 VIEW.H         990 bytes   990 bytes
1987-02-18 SEGPTR.C      3558 bytes  3558 bytes
1987-02-19 PICTURE.C     3123 bytes  3123 bytes
1987-02-19 TRACE.C       5163 bytes  5163 bytes
1987-02-20 PRINT.C      10989 bytes 10989 bytes
1987-03-24 JOYREAD.ASM   2478 bytes  2478 bytes
1987-03-25 MOVETO.C      2132 bytes  2132 bytes
1987-03-25 OBJLIST.C     4585 bytes  4585 bytes
1987-03-25 STATUS.C      4537 bytes  4537 bytes
1987-03-25 WANDER.C       846 bytes   846 bytes
1987-04-07 INTRPT.ASM    6760 bytes  6760 bytes
1987-04-07 MOTION.C      3990 bytes  3990 bytes
1987-04-30 CMDATA.ASM     937 bytes   937 bytes
1987-04-30 GAME.H        3867 bytes  3867 bytes
1987-04-30 INIT.C        3805 bytes  3805 bytes
1987-04-30 RESTART.C      862 bytes   862 bytes
1987-05-11 TIMERINT.C    1412 bytes  1412 bytes
1987-05-12 JOYDRV.C      3732 bytes  3732 bytes
1987-05-12 MSGSTR.C      1019 bytes  1019 bytes
1987-05-12 SEGMENT.C     6643 bytes  6643 bytes
1987-07-14 STRING.C      3946 bytes  3946 bytes
1987-07-23 CMOBJSBR.ASM 18448 bytes 18448 bytes
1987-07-24 MEMMGR.C      2299 bytes  2299 bytes
1987-07-27 PARSE.C       5531 bytes  5531 bytes
1987-08-16 VGJMPTBL.ASM   578 bytes   578 bytes
1987-08-21 DOTEST.ASM    8701 bytes  8701 bytes
1987-08-24 INITMACH.VGA  1866 bytes  1866 bytes
1987-08-24 IOBJSBRS.ASM  6853 bytes  6853 bytes
1987-08-24 RANDOM.ASM     758 bytes   758 bytes
1987-08-24 SAVENAME.C    1951 bytes  1951 bytes
1987-08-25 INITDIR.OBJ    118 bytes   118 bytes
1987-08-31 MAIN.C        2800 bytes  2800 bytes
1987-08-31 SQSG.3        2774 bytes  2774 bytes
1987-09-03 GETGAME.C     9437 bytes  9437 bytes
1987-09-03 HGRAPHX.OBJ   1852 bytes  1852 bytes
1987-09-03 HOBJSBRS.OBJ   963 bytes   963 bytes
1987-09-03 INTRPT.OBJ    1442 bytes  1442 bytes
1987-09-03 RESTGAME.C    2611 bytes  2611 bytes
1987-09-03 SENDIT.BAT      39 bytes    39 bytes
1987-09-04 CMGRAPHX.ASM 16569 bytes 16569 bytes
1987-09-09 MENU.C        8700 bytes  8700 bytes
1987-09-29 SCRIPT.C      2195 bytes  2195 bytes
1987-09-30 EQUIPCHK.ASM  8204 bytes  8204 bytes
1987-09-30 JRGRAPHX.ASM  7875 bytes  6144 bytes
1987-09-30 SCRACT.C      4869 bytes  4869 bytes
1987-10-01 SCROUT.ASM    7185 bytes  7185 bytes
1987-10-07 PRODFLAG.H      27 bytes    27 bytes

There are a number of things to draw attention to with regards to the dates:

• The earliest and most common date mentioned is the 5th Feb 1987, which is the same date as most of the files on the KQ3 disk.
• The most recent date is the 7th October 1987, i.e. the same date as included in the memory map file. There isn't any later date. That's a strong indication that the source files are a match for the memory map file, which we were already fairly confident in.
• Many of the files were updated during July, August, and September of 1987. This must represent the internal builds that progressed the versioning from the 2.4XX versions up to the 2.9XX versions

I have checked the file sizes mentioned and they match the actual sizes of the files that were extracted from the SQ2 disk, which supports the content being a single DOS BACKUP file, and that these dates are highly likely to represent the actual dates of each extracted file. It all ties together.

There is one thing about the dates that worries me, and that is the timestamp of the INTRPT.ASM file. There are four files that use the pcall macro. Three of those have a date after the release of MASM 5.0, but INTRPT.ASM is dated the 7th April 1987, nearly 4 months before MASM 5.0 was released. That would seem to eliminate the idea that they wrote the pcall macro after switching to MASM 5.0, unless they got an early release. It could mean that they somehow had it working in MASM 4.