"Sierra Gets Creative" by Jimmy Maher

[Collector]

I remember reading something about how Sierra was having trouble with the development of KQ and IBM had to help.

[NewRisingSun]

I suppose it's a good idea then for me to start commenting and annotating the IDA-produced disassembly I already have. (You might think that a non-annotated disassembly is trivial to produce, but if you have ever tried to recompile/reassemble a disassembly after making changes to it, you know that it's not trivial at all. Because if you fail to assign just one hexadecimal number as a reference to the data segment, or assign it to the wrong segment, or assign a number that is not a reference as if it were a reference, your recompiled executable will be useless.)
Doing so will allow me to study the engine more closely, and compare it both to AGI and to the two Hi-Res Adventure PC ports (Adventure in Serenia and Ulysses and the Golden Fleece). Unless Omer suddenly finds an original source code, that is...

So far, I have only disassembled the "PCjr" disk of the Sierra On-Line release, which seems to be identical to the Radio Shack release in that it runs both on PCjr and Tandy 1000, the only difference to the Radio Shack release being that the latter says "Licensed to Tandy Corp.". I also have the August 1984 PC-CGA release as an original disk and the only IBM release for PCjr ("release" refererring to what's on the disk; I'm aware that there were two kinds of keyboard overlays) as well as the Radio Shack release as disk images. There is an earlier PC release that can be identified in the boot sector saying "BOOT v1.1" rather than "BOOT v1.2", and has "King's Quest" printed in gray rather than in yellow/orange at the side of the box. I don't have that version, so unless someone provides it to me, my annotated source will only cover the differences between the versions I have. One difference I already know of is that the Sierra On-Line PCjr disk, upon "restarting" a game, resets all variables by hand, while the PC-CGA version loads a "startup" saved game from the diskette instead.

[lance.ewing]

I personally would love to look over such a disassembly. Although I did at one point have a pre AGI 2 bootable KQ1 disk, I have no idea what the exact version was and I didn't go as far as looking at the code. In those days I tended to look at the data. I have recollections of seeing AGI like data but that may have been the KQ2 disk.

[lskovlun]

Also remember that dissimilarity of code does not mean it isn't AGI. Could be PreAGI. ScummVM supports PreAGI through the AGI engine which suggests some shared characteristics, but PreAGI looks somewhat hardcoded and I'm not sure KQ1 Booter is. I have no experience with the ScummVM AGI engine myself.

EDIT: I don't think anyone has tried running KQ1 Booter on it. Were the other PreAGI games booters? It seems to me they must have been.

[Collector]

Pretty sure that Mickey's Space Adventure and Winnie the Pooh in the Hundred Acre Wood were booters. I don't have the others, so I cannot say about those.

[NewRisingSun]

Mickey's Space Adventure and Winnie the Pooh in the Hundred Acre Wood are not booters, at least not originally. If you wanted the disks to boot, you would have to transfer DOS onto the floppy disks yourself, which the previous owner of your copy may well have done. Troll's Tale could self-boot but also run from DOS, although there is no means of exiting the game. Self-booting King's Quest has a MAIN.EXE file but does not run under DOS because it assumes to be loaded at a fixed memory location.

ScummVM supports PreAGI through the AGI engine which suggests some shared characteristics,

Might be due to oddball modularization choices. Would not be the first time. I certainly will not assume any similarity just because the ScummVM people choose to call it "Pre-AGI".

I have disassemblies of Mickey's Space Adventure and Winnie the Pooh in the Hundred Acre Wood right here, and the only characteristic that vaguely resembles AGI is some code for drawing a picture using vector commands, and the Tandy 3-voice sound routine in the case of Winnie, which is functionally identical and uses the same music files as AGI version 1.x.

[lance.ewing]

The similarity in picture and sound formats could well be why the data looked AGI-like to me. I was quite familiar with both of those formats at the time. I suppose it was an evolution. KQ1 probably wasn't completely new in all areas.

[NewRisingSun]

Okay, but given that the "I" in "AGI" stands for "interpreter", I would have expected that the minimum standard for anything to be considered substantially similar to it would be to also have a virtual machine with a similar set of opcodes or at least a similar architecture, not just a few library routines. Otherwise Stellar 7 and Silpheed would be similar to King's Quest IV, since the music routines are almost the same.

[lance.ewing]

Yeah, you're right. AGI is the whole package, all four resource types. So if the LOGIC equivalent is quite different, then it isn't really AGI. And besides, "AGI" is probably more strongly associated with the language and associated command opcodes than with the rest.

[Kawa]

Kinda reminds me of how SCUMM is usually taken to mean the entire engine as a whole.

[lance.ewing]

Yeah, it's certainly like that. SCUMM was even more of an evolution over time. What we typically call AGI was relatively consistent compared with SCUMM. I wrote an AGI interpreter called MEKA that I never quite completed due to Stuart George's Yggdrasil/Sarien interpreter advancing more quickly. It was more of a proof of concept in any case. But it could run pretty much all the AGI v2 and AGI v3 games with differing levels of stability and differing numbers of bugs.

But I didn't spend much time looking at what I thought of as AGI v1, so even classifying a pre AGI v2 game into v1, v0, pre-AGI or something else isn't my knowledge area. My focus and knowledge was pretty much all on the AGI v2 and v3 games. This discussion above though has awoken my interest in pre AGI v2 Sierra games. I'm actually quite interested now in investigating the evolution of their games through the TrollVM supported games, to the original KQ1, and the AGI v1 KQ2 and BC and see how things changed over that period.

So I'm definitely keen to see what you produce NewRisingSun! Would love to see the commented disassembly.

As a side focus, I've always been interested in AGI games on the Apple II platform, but I've never taken the time to have a look at how they work. My particular interest in the Apple II AGI games isn't because I had an Apple II, because I didn't, but instead because it is a 6502 machine.

It would appear that I've been distracted from my current effort to port KQ1 to a 13K Javascript game. Oh well. It seems there's no such thing as a finished hobby project in my world.

[NewRisingSun]

I'm being slowed down by the original KQ1's nonstandard way of setting up stack frames (for passing parameters to functions and for local variables) that makes it difficult to see what's going on. So don't expect anything this or next month.

[lance.ewing]

Yeah, I can imagine. I've tried using IDA in the past and struggled.

Sounds like its going to be a Christmas present then.   

[NewRisingSun]

Just so you know what I mean by non-standard stack frames: The standard calling convention in all major programming languages for calling a procedure like this:

Code: [Select]

void someProc(1234, 5678)is something like this:

Code: [Select]

caller:
    (... caller doing something)
    MOV AX, 5678
    PUSH AX
    MOV AX, 1234
    PUSH AX
    CALL someProc
    ADD SP, 4
    (... caller doing something else)
someProc:
    PUSH BP
    MOV BP, SP
    MOV AX, [BP+4] ; get arg 1
    MOV DX, [BP+6] ; get arg 2
    (... someProc doing something with the args)
    POP BP
    RET
The Pascal and C calling conventions differ in whether the arguments are pushed onto the stack from left to right, or from right to left, and whether the caller cleans up the stack (as I did with ADD SP, 4) or the callee as part of the RET instruction. King's Quest 1 however does something like this:

Code: [Select]

caller:
    (... caller doing something)
    PUSH BP
    MOV BP, SP
    MOV AX, 5678
    PUSH AX
    MOV AX, 1234
    PUSH AX
    CALL someProc
    MOV SP, BP
    POP BP
    (... caller doing something else)
someProc:
    MOV AX, [BP-2]
    MOV DX, [BP-4]
    (... someProc doing something with the args)
    RET
In other words, the caller sets up the stack frame, rather than the callee. I have never seen any compiler using such a strange calling convention. Obviously, IDA gets confused by this, thinking that BP-4 is a local variable of someProc (which it would be in any normal calling convention), and it makes my head spin as well. Add to that such niceties as one procedure being placed in the middle of another, unrelated, procedure for no apparent reason, with the "outer" procedure JMPing around the "inner" procedure, and you will understand why I cannot go on for longer than 30 minutes at a time.

[lskovlun]

Wikipedia has an article on "Avis Durgan" which states:

"Avis Durgan" is the ASCII-string on which an exclusive OR operation (XOR) was performed in the text of the vintage Sierra Entertainment AGI adventure games to keep the gamers from snooping for clues in these games' resource files. In earlier versions of AGI games that booted directly from diskette, the "Avis Durgan" string was also used to encrypt sections of code as a copy-protection scheme.

NewRisingSun, are you seeing these encrypted code blocks in your investigations?