GAL (KQ1) extractor and decompiler

[lance.ewing]

I think that the 30th May 1984 date is wrong for the original IBM PC release of King's Quest. That date is from the timestamp of the MAIN.EXE directory entry on the disk, but the LOAD directory entry has a timestamp of the 31st May 1984, which would mean that the release can't have been the day before that.

These are the timestamps I calculated for the recognisable and properly structured DOS directory entries in the first IBM PC release (which we're assuming was at the end of May 1984):

Code: [Select]

MAIN.EXE           30448 30-May-1984 18:48:36 [cluster=6]
LOAD                3158 31-May-1984 02:39:58 [cluster=2]

290K              296960 19-May-1984 14:02:56 [cluster=66]
IBC                   20 06-Dec-1983 10:20:48 [cluster=350]
PROTECT               22 02-Feb-1984 14:10:08 [cluster=351]
PROTECT.NO            22 02-Feb-1984 14:10:08 [cluster=352]
PROTECT.YES           22 02-Feb-1984 14:09:54 [cluster=353]
MAIN.EXE               0 28-May-1984 03:47:18 [cluster=0]
I think that the first two (MAIN.EXE and LOAD) are the main files, and even seem to be at those cluster locations.

[lskovlun]

And in case anyone cares, what I was looking at is a mysteriously nopped opcode, number 41. It is called in 9 places, all having to do with the various drowning sequences in the game. It doesn't do a thing in the KQ1 interpreters I have looked at! and I'm thinking 'why?' Was there supposed to be some effect (visual? sound?) that was ultimately scrapped, was it for debugging or something else? The integer argument to that opcode looks interesting as well:

Code: [Select]

17.cg: drown.stuff.nop(9);
23.cg: drown.stuff.nop(14);
32.cg: drown.stuff.nop(2);
41.cg: drown.stuff.nop(9);
41.cg: drown.stuff.nop(1);
43.cg: drown.stuff.nop(14);
47.cg: drown.stuff.nop(9);
4.cg: drown.stuff.nop(14);
7.cg: drown.stuff.nop(10);
The numbers look like they could be resource numbers...

[lance.ewing]

The funny thing is that the PCjr image is very different from the others. The PC and Tandy versions have an EXE file (as you say) which is odd because EXE is a DOS file format and these versions don't run under DOS. The EXE is located at the beginning of the image (after boot sector and loader). In the PCjr image, the main program file is not an EXE file, and it is located at the end of the image. It took a few tries to get it to load in IDA (enough to investigate the thing I wanted to).

Yeah, it is strange that the PCJR image is so different. I am starting to think that there is more of a time gap in the build dates between the PCJR version and the first IBM PC version. I'm not sure where the official PCJR version's release date came from, but I suspect it was the copyright registration, which mentions the 10th May 1984. This sounds about right with regards to when it became publicly available, since I know that it wasn't available yet on the 20th April 1984, as I found a newspaper advert that mentions a demo of King's Quest to be given by Greg Rowland at an event in Fresno on that date, and the advert specifically says that it is a "sneak preview of Sierra's yet to be released 3D adventure game".

As a side note, the same newspaper advert describes Greg Rowland as a "star programmer". The exact text reads:

"Come see a sneak preview of Sierra's yet to be released 3-D adventure game "THE KING'S QUEST" and meet this star programmer Greg Rowland, Friday April 20 at 12:00pm & 5:00pm".

If only we had a time machine, then we'd know where to be.

Anyway, the point I was making is that the PCJR build may have been around for a while, but not yet released. There wasn't just this 20th April 1984 demo but others that were quite a bit earlier. There was one quite prominent demo at the 1984 International Winter Consumer Electronics Show that was held in Las Vegas, at the Hilton, Riviera and Sahara Hotels, from Saturday the 7th to Tuesday the 10th January. In the month's that followed, various magazines published screenshots of the game and mentioned the demo at the Winter CES. It is clear from the screenshots that they are all from the same set of screenshots, so I think that Sierra must have given various publishers a standard set of screenshots to use in their publications.

Also of note is that the trademark for the name "King's Quest" was filed by Sierra on the 23rd January 1984, in which it claims that the first use of the name was on the 13th January 1984. I'm not entirely sure what happened on the 13th, and I would have thought that the demo at the Winter CES show between the 7th-10th would have been the actual date of first use. Regardless, the first mention by name that I can find within a publication is a magazine article dated the 24th January 1984. That might be why they filed the trademark for the name the day before.

So what we have is that the PCJR version was being demoed for several month's before the 10th May 1984 release. I'm not sure how we can determine the actual build date though. We're fortunate that the subsequent booter versions have the DOS directory entries that contain timestamps, so we (in theory) know that the first IBM PC release was no earlier than the 31st May 1984. It is highly unlikely that it would ship on the same date as the build though. That's asking for trouble. So there would have been another round of QA after that I would guess, to make sure things were still working. I'm guessing a June 1984 release date for that first IBM PC version.

The one thing that disagrees with this (surely the build date can't lie though?) is that the May 1984 edition of the "ENTER" magazine has a small writeup and states that the game "is available from Sierra On-Line for the IBM PC and other computers with 128K". It specifically mentions the IBM PC. This might be a case of Sierra wanting to get the IBM PC orders starting to flow in without yet having the final release build ready, although, who knows, maybe some early purchasers got a buggy early build. I wouldn't be surprised if the sales and marketing side of Sierra bent the truth a bit, as sales people do, when using the word available. It was probably more "it will be available by the time you've sent your order and we've processed the order". - Incidentally, the "other computers" probably refers only to the PCJR at this stage, since the same "ENTER" magazine has another write up in their October 1984 edition that specifically mentions the IBM PC and PCJR as the machines that it is available for.

[lance.ewing]

And in case anyone cares, what I was looking at is a mysteriously nopped opcode, number 41. It is called in 9 places, all having to do with the various drowning sequences in the game. It doesn't do a thing in the KQ1 interpreters I have looked at! and I'm thinking 'why?' Was there supposed to be some effect (visual? sound?) that was ultimately scrapped, was it for debugging or something else? The integer argument to that opcode looks interesting as well:

Code: [Select]

17.cg: drown.stuff.nop(9);
23.cg: drown.stuff.nop(14);
32.cg: drown.stuff.nop(2);
41.cg: drown.stuff.nop(9);
41.cg: drown.stuff.nop(1);
43.cg: drown.stuff.nop(14);
47.cg: drown.stuff.nop(9);
4.cg: drown.stuff.nop(14);
7.cg: drown.stuff.nop(10);
The numbers look like they could be resource numbers...

An interesting mystery. Looking at the room 41 script, it doesn't look like there is anything comparable in the AGI V2 version of the game. I also had a look at the byte code for room 41 in the Apple II version, which is very similar, but it appears to lack these calls as well. Whatever it is, it seems not to have been required, which is obvious I guess, given it doesn't do anything.

Have you been looking at any of the other currently unnamed opcodes?

[lance.ewing]

Do we know if anyone has previously looked into the AGIV0/GAL picture format? I was looking at this a week or so back, seeing if I can load the pictures into the Java version of PICEDIT. The picture action codes are a bit different. The 0xF4 to 0xF7 codes appear to be the same but the fill codes are different, and I use codes plural since there are multiple, and they support setting the visual and priority colour with the fill action itself. The setting of the visual and priority colours is in general handled differently. There is another code, for example, that sets both the priority and visual in one go, and it seems that certain priority values are interpreted as the priority being off rather than drawing in the priority colour.

I have got my code so that the picture converts to AGIV1/2/3 format on load, so that PICEDIT can display it, and in general they display fine. There is still a bit of work to do with the finer details of the visual/priority colours. Interestingly, the background for the priority screen appears to be black, rather than red, and the priority band colours are shifted when compared with later AGI versions, so the ego walking test tool in PICEDIT doesn't currently work as a result of this.

Commands 0xF4 to 0xF7 are repeated from 0xF8 to 9xFB but are interpreted differently with regards to what they're drawing on.

Jeff & Chris may claim that they didn't create AGI, but it is clear that there was a big refactor of the code in between KQ and KQ2. The tidy up of the picture codes is one example of this. They must have seen that they didn't need 3 different fill actions, or a second version of each drawing command.

[Collector]

What about getting them to load with the AGI library?

[lskovlun]

You could compare them with ADL/PreAGI I guess.

[lance.ewing]

What about getting them to load with the AGI library?

I was thinking the same thing, but I'll wait until I've worked out all the details.

[lance.ewing]

You could compare them with ADL/PreAGI I guess.

I had a look at the ADL and pre-AGI picture formats last night, by looking over the code in scummvm. So the ADL picture format is quite different. The drawing actions are within the 0xE0 range, and it does have the standard four drawing actions, i.e. the X/Y "corner" actions, and the absolute and relative line actions, and also the fill, but as codes in the 0xE0 range. So those drawing actions have been around for a while, but have been shifted around over time. The ADL picture format uses the 0xF0 range for setting different colours, i.e. different codes for different "colours". This is going back to the Apple II days where Ken Williams was the main programmer of the picture editor, and the colours were kind of faked. Sierra published two different picture tools that I'm aware of that were both supposedly the ones that they used for these ADL games. The first was the "Paddle/Tablet Graphics" tool (I think the paddle bit might be where the X/Y "corner" action originated). This tool they were selling back in 1980, shortly after Mystery House was released. Then a few years later, they started selling "The Artist", which was once again claimed to be the tool that they were using internally, but packaged for the general public to purchase.

Looking now at the pre-AGI games:

The scummvm default picture version is the AGIV2 picture format, which is used by the Mickey and Winnie "pre-AGI" Disney games as well, and also  the AGIV1 games (KQ2 and BC). Troll's Tale uses what scummvm calls the V1.5 picture format.  The scummvm picture class also appears to support a "V1" picture format, but it doesn't look like it is used at present. The AGIV1 games such as KQ2 and BC that came out between KQ and the first AGIV2 games were already using the "AGIV2" picture format.

Looking at the implementation code for the various picture formats supported by scummvm, none of them is an exact match for what I'm seeing in the original King's Quest game. Instead what I'm seeing is a combination of the codes used in the V1, V1.5 and V2 scummvm picture formats. Specifically, it contains all of the picture code actions (0xF1, 0xF3, 0xFA and 0xFB) listed in the switch statement for the drawPictureV1 method (this is the one that I can't see any usage of, so might be a work in progress and therefore incomplete), and the 0xF8, 0xF9, 0xFA, 0xFB and 0xFE codes from the drawPictureV15 method (used by Troll's Tale), and the 0xF4, 0xF5, 0xF6, 0xF7 and 0xFC code from the drawPictureV2 method (I didn't even know that 0xFC was a code in AGIV2; it must be one of the pre-AGI games that uses this). In addition to this, it includes codes that none of the V1, V15 or V2 formats have a matching implementation for, i.e. 0xF0, 0xF2 and 0xFD.

Troll's Tale seems the closest, and it might be the case that this game doesn't use all of the codes, and thus why the scummvm implementation doesn't provide implementations for all of them. I would guess that the Troll's Tale engine is using essentially the same picture format as the booter versions of King's Quest, which hints at the placement of Troll's Tale within the evolution of the AGI picture format.

Likewise, the use of the AGIV1/2 picture format by the Mickey and Winnie games is very interesting. These two games were released at the end of 1984. King's Quest was released in May 1984. Development work on the Mickey and Winnie games probably started mid 1984. - Here's the interesting thing: Someone redesigned the picture editor created by the King's Quest project team in between the the KQ project and the release of the Disney games, and they did so within a quick enough timeframe that the artists working on Mickey and Winnie could use the new version. And that new version was what was subsequently used for the AGIV1 games, i.e. King's Quest II and Black Cauldron, and then also for the AGIV2 games.

My guess, a fairly safe guess I would say, is that this person was Bob Heitman. I will have to ask him this to see if he recalls. He must have done this in mid 1984. He has previously said that he inherited the picture editor built by the KQ team, but that it was from a maintenance perspective rather than building any new features in it. The question is whether this redesign/rearrangement of the picture codes qualifies as maintenance.

Regarding Troll's Tale, scummvm only has game definitions for the PC versions. I suspect that there must have been a project within Sierra to port the game to the PC, and at the time when they did this, the King's Quest picture editor was available for use, but perhaps not the new version that was redesigned for the Mickey and Winnie Disney games. The PC Booter version apparently came out in 1984:

https://www.mobygames.com/game/7271/trolls-tale/credits/pc-booter/

And Doug MacNeill (of King's Quest project team fame) did the graphics for it, and Peter Oliphant (of The Dick van Dyke TV show fame) did the programming conversion. Doug must have been quite busy in 1984, because he was also working on the Disney games. I think this places the Troll's Tale PC Booter conversion as taking place between the King's Quest project and the Disney games, since Doug was using the KQ picture editor (apparently built primarily by Ken MacNeill, according to quotes from Doug in Shawn Mills' "The Sierra Adventure" book) for Troll's Tale, but was using the revamped AGIV1/2 picture editor for the Mickey and Winnie Disney games. - I've just checked the Troll's Tale disk image for timestamps, and it looks like the LOAD directory entry has a 5th April 1984 timestamp, which is older than the LOAD timestamps in the first KQ releases. That suggests that the Troll's Tale PC conversation was being worked on prior to the KQ release, but probably after the bulk of the KQ code was written. It makes sense then that Troll's Tale uses the KQ/GAL picture format.

Incidentally, Greg Rowland was involved in converting the "Dragon's Keep" pictures for the PC version in 1984, probably also after the graphics work for the KQ project was complete, with the programming conversion also being done by Peter Oliphant:

https://www.mobygames.com/game/20644/dragons-keep/credits/pc-booter/

Peter was another one that was very busy in 1984, as he was the main programmer for Mickey's Space Adventure. So, Peter was working with Doug on the Troll's Tale conversion to the PC, and with Greg on the Dragon's Keep conversion to the PC. My guess is that Dragon's Keep also uses the KQ/GAL picture format then. I'd like to verify that, but the PC version of Dragon's Keep seems rare. Has anyone seen that one anywhere?

(it being rare might be why it isn't supported by scummvm)

Hmmm, now that I'm looking more closely at the specific picture codes of the King's Quest GAL picture format that Troll's Tale is using, it appears to be specifically the visual ones. All of the priority related codes have been avoided. 0xF1 is specifically for setting only the visual colour. 0xFE is for filling in only the visual colour. The codes 0xF8, 0xF9, 0xFA and 0xFB appear to be visual only versions of the more familiar 0xF4, 0xF5, 0xF6 and 0xF7 that draw to both visual and priority. This makes a lot of sense, because Troll's Tale does not have a priority screen. The original game was built in 1983, then ported to the PC, with the pictures being converted to the KQ/GAL picture format. There would be no need for codes that used the priority screen.

Anyway... very long story short, I think I can use some of what I've found in the scummvm source to validate what I've prototyped.

[HWM]

I've looked into the pre-AGI formats in the past as well (though not that thorough) and I believe the 0xE0 range was being used in the C64 version of Winnie the Pooh. At least I recall I had to shift the drawing actions to the regular AGIv2 codes in order to match them up to the PC version. The picture format in the PC version on the other hand is close to fully compatible with AGIv2 and I remember using the error message of PICEDIT (thanks!) to figure out the difference. It was only one instruction, I believe, that could be removed without any(?) consequences.

That said, I think the C64 or Apple version would fit better in your timeline, as the PC version seems to be ported from (one of) them and has a copyright date of 1985:

https://www.mobygames.com/game/7274/winnie-the-pooh-in-the-hundred-acre-wood/screenshots/dos/32029/

Mickey's Space Adventure for PC was released even later, with a copyright date of 1986:

https://www.mobygames.com/game/7273/mickeys-space-adventure/screenshots/dos/31261/

[...] the PC version of Dragon's Keep seems rare. Has anyone seen that one anywhere?

It's not clear if it actually exists or was released. The MobyGames link you provided contains a thread which discusses the inclusion of the booter. There's quite some evidence, but it hasn't turned up yet. There are other PC versions of early Sierra titles rumoured to exist as well, some more likely than others.

Interestingly enough, the Northeastern Software advertisement, mentioned in the aforementioned thread, lists Golf Challenge (as mentioned earlier, by Hal Schwab) as being available for IBM too:

https://books.google.com/books?id=IJAhwYh-TZkC&lpg=PA297&ots=v2jFo2Ihih&dq="dragon's+keep"+ibm&pg=PA297&redir_esc=y#v=onepage&q="dragon's keep" ibm&f=false

[lskovlun]

That's some impressive work, Lance!

Yeah, I have looked at the missing opcodes. Many of them are related to movers/cyclers and aren't easy to decode. But I have worked out some, and I'm updating SYSDEFS (and GAMEDEFS) as I go. They don't map neatly to the AGI set (for example there's a specific opcode that I have called ego.falls; you can guess what it does). There are also a few mistakes in the ones that NewRisingSun identified (current.room.f takes two var parameters, not a number and a var).

[lance.ewing]

I've looked into the pre-AGI formats in the past as well (though not that thorough) and I believe the 0xE0 range was being used in the C64 version of Winnie the Pooh.

Yeah, I did notice that the drawPictureC64 method in the same AGI picture.cpp file does use the 0xE0 range, and comparing it now to what the ADL games use, they appear to be closely aligned.

I think the C64 or Apple version would fit better in your timeline, as the PC version seems to be ported from (one of) them and has a copyright date of 1985:

https://www.mobygames.com/game/7274/winnie-the-pooh-in-the-hundred-acre-wood/screenshots/dos/32029/

Mickey's Space Adventure for PC was released even later, with a copyright date of 1986:

https://www.mobygames.com/game/7273/mickeys-space-adventure/screenshots/dos/31261/

Yeah, you're right. I had assumed incorrectly that the PC version would have come out alongside the others. So this does indeed change the timelines a bit, and it makes my earlier comment about the PICTURE editor changing quickly after the KQ project unlikely. Instead, given that the PC versions of those Disney games came out in 1985 and 1986, it seems more likely that the PICTURE editor changed during the development of King's Quest II. I found a timestamp for MAIN.EXE in the 1.0W release of KQ2 of 24-Apr-1985. It would make sense then that the Winnie and Mickey PC conversions used that revamped Picture Editor.

It's not clear if it actually exists or was released. The MobyGames link you provided contains a thread which discusses the inclusion of the booter. There's quite some evidence, but it hasn't turned up yet. There are other PC versions of early Sierra titles rumoured to exist as well, some more likely than others.

If it did exist, then I hope it turns up one day, but perhaps it was never released. I know that the Goofy game was never released, despite being advertised numerous times, and despite development still continuing into 1986/7. I found an interview in a magazine with John Williams where he talks about that game and the issues.

Interestingly enough, the Northeastern Software advertisement, mentioned in the aforementioned thread, lists Golf Challenge (as mentioned earlier, by Hal Schwab) as being available for IBM too:

They did supposedly have a big team working on porting their older games to the IBM PCJR, as part of the top secret PCJR project. I've seen a quote from Ken from near the time period stating how much of his current dev team was invested in the various PCJR projects, and that if the PCJR wasn't a success, then he was in serious trouble. Well, we know what happened. He had to reduce his head count by approx. 100 not long after the PCJR release. Things hadn't been good in 1983 either, so it was the last straw I guess.

[Collector]

On a side note, do we have any tools for ADL?

[lance.ewing]

I don't think I've seen any so far, although, as I mentioned in one of my earlier posts, "The Artist" tool is apparently what they used inhouse for graphics, and I did manage to find this tool on archive.org and had a quick play with it inside the emulator on the archive.org website. Whether or not it really can load the images from those "Hires" ADL games (such as the "Timezone" ADL game that it claims to have been used for) is another question.

Some of you might be interested in the attached advert I found for "The Artist". It reads like a resume for a person who worked at Sierra, but is in fact the picture editor that they are referring to.

[Collector]

Not that anyone would be trying to edit the old ADL games or create new one, it would be nice to have a set of tools to explore these old games. I would be curious to see the source scripts and other resources in the games. If nothing else to see more of the process they used to make them.