Messages

1

AGI Development Tools / Re: AGI reverse engineering with AI

« on: Today at 07:02:30 AM »

Yeah, when it starts out with the disassembly, it uses very generic sounding terminology, almost incomprehensible tbh, but it seems to know what it all means

I did try to put it through several iterations of asking it to update the comments and symbols used to better reflect AGI terminology but there are probably still bits left in there using the original very generic terms. It is a lot better than it was though.

2

AGI Development Tools / Re: AGI reverse engineering with AI

« on: Today at 05:44:57 AM »

Yeah, I think you should pick that up again and see how the AI models can help out. I haven't tried Fable or Sol yet. I was mainly using GPT 5.4 when I was doing the Apple II AGI interpreter work, and when I then had a go at starting a C64 interpreter.

Another thing I used AI for recently was to port a small game to the VIC 20. The AI model was very useful in speeding things up. I put it through many iterations of calculating the cycles spent rendering things to the screen, identifying where most of the time was spent, and then asking it for proposals for how it could be sped up. I'm sure your animated object rendering could be made faster using a similar approach.

It looks like you're far further advanced that where I got to. I was only just starting out. That KQ picture looks really good. Four colours per 4x8 pixel cell, that KQ picture shows how that is probably sufficient for the picture, in most cases. Some of the busier games, like KQ4 and GR, might encounter a few cases where more colours are needed. As you say though, its when the animated objects are added on top that the colour limit per 4x8 pixel cell would be more likely to pose a problem, if the pixels are rendered as part of the C64 hires picture. I don't know much (or anything actually) about the C64 sprite capability. Are sprites free of the colour limit? I mean, do they have their own colours?

3

AGI Development Tools / Re: Original Sierra Source Code analysis

« on: Yesterday at 11:22:11 AM »

You've probably tried this, but have you looked in local newspapers from that time? Maybe one of them published a piece about the big Sierra layoff, which could help to narrow the dates.

I would love to be able to do that, but the Sierra Star archives, which I think was the main one in Oakhurst, is not available online. Apparently the archives can be searched physically if you visit the area, so if I ever do at some point in my life make a visit to Oakhurst, that will be one of the things on my todo list. As you say, there would surely be news articles in the local newspapers from that time. It was a big local event, given how many people lost their jobs. I think I'd be spending days with those archives, searching for any little news snippet of relevance.

I recently came upon this conversation with Jeff Stephenson on YouTube. This might be the podcast you mentioned.

Yeah, that is the one.

4

AGI Development Tools / Re: AGI reverse engineering with AI

« on: Yesterday at 07:25:20 AM »

I have tidied up the Apple IIe/IIc AGI interpreter disassembly a bit and put it here:

https://github.com/lanceewing/agi-apple-ii

5

AGI Development Tools / Re: AGI reverse engineering with AI

« on: Yesterday at 06:04:49 AM »

The main challenge in getting AGI onto the C64 is graphics. From what I understand, both the bitmap modes and the character/tile modes are insufficient to accurately display a full EGA picture, due to limitations such as the number of allowable colours. Additionally, the C64 is really designed more for tile-based graphics (40x25 I think).

To be honest, I'm not that familiar with the C64 either. I'm very familiar with the VIC 20 but that's definitely not an option. The graphics on the VIC 20 are far too limited. On the C64 though, I don't know this as absolute fact, because AI told me this, but apparently three of the colours can be different every 8x8 character? - I asked AI what it thought about the graphics limitations on the C64 in relation to AGI. It suggested that AGI pictures in general don't use a lot of colours per 8x8 block, so maybe in most cases it might look okay. - But there would certainly be some cases where it would need to use a different colour in certain pixels due to the limitations. I compare that with the Apple II AGI graphics, that also look a bit less than perfect, with various colour artifacts clearly visible. The C64 might be able to use raster effects, or maybe some stationary sprites to fill in bits that don't otherwise look good. Some of the games that have come out on these old retro computers these days are quite amazing, so there are bound to be tricks used by those devs that could be applied.

I reckon the most promising approach is to not have the engine actually run all the drawing commands in-game, but rather to have a conversion tool which pre-renders and picture into tiles, and then builds disk image(s) containing the converted resources.

Might require a lot of disk space, if disks are your target. I think the C64, even with the modern SD card options, would still be restricted by available floppy disk space for the disk images, so you'd be switching "disks" a lot. One of the annoying things about the Apple II AGI games is having to swap the disks all the time. I don't have a physical Apple II machine, only an emulator, but it is rather annoying. - I think a C64 version of AGI might need an alternative way to load data, like a cartridge with lots of storage space that it can very quickly load from, rather than from disk. Maybe with a REU, something can load all the data into RAM up front, so that it becomes really quick changing rooms.

I don't know anything about how the Apple II interpreter worked (i know this was used for KQ at least). It might be easier to try to port that to the C64 instead. Either one would be a fun challenge.

The only AGI game that didn't come out on the Apple II computers was Manhunter: San Francisco; all the rest did. I guess by the time that game came out in 1989, they didn't think it was worth releasing an Apple II version, although they did release Gold Rush, which is interesting. Someone could probably take the interpreter from the Gold Rush game and the data files from the IBM PC version of Manhunter: San Francisco and create an Apple II version of the game.

Regarding porting the 6502 disassembly to the C64, it is funny that you say that. I did set out trying to do that after creating the Apple II disassembly, but ended up getting completely stuck in some kind of loop with the AI that spanned over several days. Burnt through a lot of AI credits and it kept going around and around in circles on one particular thing. And with the code all being written by AI, I didn't feel like I could take over. I'd be quite happy to pass it over if you like, in case any of it is useful. It might even be a good approach, for someone else to take over, get their AI to analyse what is there at the moment, identify the gaps, look for existing bugs, etc.

6

AGI Development Tools / Re: AGI reverse engineering with AI

« on: Yesterday at 04:57:21 AM »

I bet if you tried hard enough you could port AGI to the Commodore 64, perhaps with some limitations (eg using a REU, and other tricks), of course with the assistance of an AI model like Fable etc.

I also think it should be possible these days to port AGI to the C64 (someone has actually almost finished a C64 port of Leisure Suit Larry already, for the C64, but from what has been said about it, it doesn't sound like an AGI interpreter as such). - As you say, it would definitely need a REU.

Someone had an AGI interpreter for the BBC Micro working a few years back, another 6502 based computer.

7

AGI Development Tools / Re: AGI reverse engineering with AI

« on: Yesterday at 04:49:58 AM »

While none of the work it's produced is novel (this is all well-trodden ground thanks to the work of the community), I've been able to get it to generate an *extremely* detailed analysis of every aspect of the interpreter and produce a high-level spec, including coverage of different subsystems and different interpreter versions ("profiles"). There's only a few outstanding details left but I think it's pretty close now.

I'm currently having it generate playthroughs of games based on analysis of the logic scripts and use of the QEMU debugger to interact with the interpreter. Once I have winning playthroughs for all games, I'll use that as a corpus for validation and see how well I can get codex to produce a new implementation of the interpreter in Rust.

Spec: https://peterkelly.github.io/agi-re/spec/

RE documentation: https://peterkelly.github.io/agi-re/docs/

Github repo: https://github.com/peterkelly/agi-re

Wow! I'm going to be taking a closer look at this later today.

You mention that none of it is particularly novel. One area that isn't well understood is the evolution of the interpreters before AGI v2, i.e. the GAL interpreter and the AGI V1 interpreter versions. It would be interesting what you get if you give it the disk images for those original game disks, i.e. the KQ GAL disks (for IBM PC JR and IBM PC), then the KQ2 and BC disks that use AGI V1. This would be a great way that AI could make a big contribution to the understanding of the early history of AGI.

I actually did something a few months back with AI and AGI. I asked it to reverse engineer the Apple IIe/IIc AGI interpreter used on the Gold Rush game, which would be probably the last version of the AGI interpreter for the Apple II computers. It produced a fairly decent 6502 disassembly, completely documented, and some supporting markdown documentation of how it all works. I will put that in a repo and point people to it soon.

I started out by asking AI to convert AGKorsson's WinAGI Windows help file to Markdown first, so I had an easily understandable (by AI) set of documentation on how AGI works. WinAGI's help file is easily the best and most complete AGI documentation resource out there. I gave it that markdown output, and the original AGI source code for the IBM PC version, and it used that to help with its understanding of things like terminology and what it should expect to see in the 6502 disassembly.

8

AGI Development Tools / Re: Original Sierra Source Code analysis

« on: Yesterday at 04:36:36 AM »

Ken Williams can barely remember some of the key people that originally developed GAL/AGI and SCI.

No one can remember the GAL name. Jeff believes it was always called AGI, certainly that what was built as part of the original top-secret King's Quest game was the start of AGI. I actually tracked down the author of the 1985 magazine article that mentions the name GAL, to find out where it came from. He said that in the preparation of that article, he had only phone interviews, with John Williams, Ken Williams and Roberta Williams, no one else. He said the name came from one of them. - They almost certainly won't remember it. My guess is that it was a short lived name.

Jeff was interviewed a few years ago in a podcast. It was very interesting, if you haven't listened to it yet. He was actually "in the room" where the King's Quest team built the original interpreter, although he himself was not involved in the King's Quest project. He was working on other IBM PC JR software, such as Home Word, which was just as secret, because the secret was the IBM PC JR.

9

AGI Development Tools / Re: Original Sierra Source Code analysis

« on: Yesterday at 04:14:44 AM »

I'm sorry if I'm being na?ve for saying this, but, Lance, if you want to find out more about this topic, wouldn't it help if you raised the issue to Ken Williams himself? Or to programmer Jeff Stephenson? Or maybe Al Lowe, who seems to be more chatty and approachable? I'm asking from complete ignorance. I don't know if you've already tried to contact them about this subject.

@pabuslem: The thing is, when we're dealing with the earliest part of the timeline, people don't remember! That the earliest language was called GAL (not AGI), that Arthur Abraham was the lead creator of GAL, and so on. These are things that we (i.e. Lance) have had to dig up ourselves, because the Sierra alumni have forgotten.

@pabuslem, I have spoken to Jeff and Al multiple times over the past 15 years or so, and Collector is right, they don't remember specific details, such as dates. 40+ years ago is indeed a long time. They remember the big events but not exactly when they happened. Jeff wasn't one of those that was laid off mid-1984 (I think Jeff and Bob were two of the only programmers that were not laid off), but Al was laid off, but was hired back almost immediately as a contractor working on the Disney projects, across several of those Disney games. He remembers that kind of detail but not exactly when that happened. They usually remember the relative order of when things happened though.

I haven't spoken to Ken in the past, other than swapping a few comments in places like youtube. I know that I could easily do so, but I would probably prepare a set of questions that I think he would be more likely to remember. Ken admits himself (as he mentions in his recent book) that he can't remember the details, and that what he covers in his book is not guaranteed to be accurate (not sure he uses exactly those words, but words to that effect). I've also seen a number of video interviews with him where he mentions he struggles to remember the details. I am currently thinking that I will probably send the timeline to him when I have it ready.

My approach is to try to find as many dates that can't be disputed, things that can be set in stone. For example, I know that one of the programmers that worked on one of the Disney contracts in 1984 signed the contract on the 17th July 1984. I also know that Sierra and Disney announced their partnership and initial line up Disney educational games at the start of June 1984 (at the Summer CES show that year). I also know that a newspaper article from the Sierra Star dated 28th June 1984 mentions the same Disney/Sierra partnership, mentions the change in name from Sierra On-Line to simply Sierra, and mentions that the new building is still under construction. I found another article from towards the end of 1984 that states that Sierra got another $2 million in venture capital in July that year, i.e. July 1984.

These are the kinds of dates that everything else can be slotted between. If we know that some events happened after or before one of these fixed points in time, then we can narrow in more on a rough date.

Dates like the timestamps on original game disks, or like in this big source code archive, are also indisputable. I've been looking at the file timestamps from 1986 in the Donald Duck's Playground game in that archive. It is clear from that that Al was working on the first AGI version of that game in early 1986. Dev work began at the end of February 1986, the majority of the work happened in March 1986, with a bit more in April/May, finally finishing early June 1986. The AGI documentation in the DOCO folder have timestamps dated 29th May 1986. This happens to be just before the timestamp usually associated with AGI v2.001 (9th June 1986), which was the first AGI V2 interpreter version we know of, that was used in that first AGI version of Donald Duck's Playground. That all ties up then. Al was working on converting the original Donald Duck game (which came out on the C64 at the end of 1984) to AGI v2 over that first half of 1986. Jeff was most likely providing him with early cuts of the AGI v2 interpreter, with 2.001 being what ended up in the release.

10

AGI Development Tools / Re: Original Sierra Source Code analysis

« on: July 05, 2026, 07:37:32 AM »

Yeah, it is a fair point, and I did wonder the same thing, but I do have one other bit of evidence to support Sierra being in the new build in September 1984, which is that Chuck Benton, the coder that wrote the original C64 version of Donald Duck's Playground (who didn't normally live in Oakhurst, but did a couple of stints working in the Sierra offices) remembers a final 6 week push to finish Donald Duck's Playground where he spent those 6 weeks in the Sierra office working 16 hour days. He seems to recall that the 1st November was a deadline that they were aiming for, so that it would be ready to sell for the lucrative Christmas period.

The reason this supports Sierra already being in the new building is because Chuck Benton says that this 6 week period was in the new building. It was definitely before the end of 1984 because he was working on Donald Duck's Playground (the C64 version), which was released in December 1984 in time for Christmas. If the 1st Nov was the deadline they were aiming for with their 16 hour days, then 6 weeks prior is September. Maybe the 6 weeks overlapped slightly into Nov, in case they ran over the deadline a bit, but I assume not much over. If he was asked to be based on site for 6 weeks, with a deadline in mind, then most of that time would likely be on the September side of the deadline.

11

AGI Development Tools / Re: Original Sierra Source Code analysis

« on: July 04, 2026, 08:41:12 AM »

Quick update regarding my 1984-1985 timeline investigations:

I have found aerial photos of the site of the "Redwood" Sierra On-Line building (i.e. the one that features in SQ3 at the end) from 1983 and 1984. These are the dates and what I can see in the photos (the dates are not exact, just a range that covers when the aerial photography was being done in that area):

1983-06-28 - 1983-08-25: The site looks like bare land with no obvious indication of a building or building work.

1984-09-15 - 1984-09-25: The building appears to be complete, with the surrounding car park area also complete, and at least 25 cars parked in the car park.

So someone at least was already working in that building mid-September. I've read accounts from people like Ken Williams that when they first moved in, they had to sub-let the building to pay for the rent, so some of those cars might be from non-Sierra people. People like Mark Crowe and Chuck Benton have commented on how empty the building was when they first moved in there. This is because of the big layoffs that happened a few months before that.

Judging by those dates, the building site went from "ground breaking" to competition in about a year. I have found an article from the Sierra Star newspaper, dated 28th June 1984, that says that Sierra are currently constructing a new building, so they hadn't yet moved in at that point.

12

AGI Development Tools / Re: Original Sierra Source Code analysis

« on: July 04, 2026, 03:50:44 AM »

Sierra had their own rudimentary .EXE file parser. In fact, the GAL version of MAIN.EXE is bigger than those you cite.

What size in bytes do you calculate the GAL interpreter executable to be?

When did they start to write AGI in C? From the beginning?

I'm not sure to be honest. The date times recorded in the header comments of the original AGI source code only includes dates from 1987. I guess that doesn't prove much other than that they started adding a few change history comments from a point in time.

Has anyone disassembled the AGI V1 interpreters to see how similar (or not) they are to the AGI V2 interpreters? I realise that the AGI command opcode orders are different but I would assume that given AGI V1 is so similar to AGI V2, there must be a lot of similar code. And if this is the case, then does the executable code show in parts any signs of being compiled from C?

13

AGI Development Tools / Re: Original Sierra Source Code analysis

« on: July 03, 2026, 11:14:34 AM »

I would love it if any findings you make gets documented on the new Wiki.

I shall indeed.

I'm trying to sketch out a timeline for 1984-1985, using several different sources. One of those is old magazine articles. I'd already seen the following one in the past, but I've realised that it provides a rough starting date for when the King's Quest 2 development started:

https://www.atarimagazines.com/rom/issue8/interview.php

https://archive.org/details/ROM_Magazine_v1i8/page/n7/mode/2up

While her husband runs the company as President and Chief Executive Officer, Roberta works as Product Development and Creative Director with input into all the creative areas of the company. In addition, she designs her own games. I was able to talk with her on August 13th and had quite an enjoyable interview which was as follows.

This bit above mentions that the interview happened on the 13th August 1984, which is a very useful fact for a game historian to discover, as quite often articles like this don't mention the interview date. The magazine issue is allegedly the October/November 1984 issue, which highlights how often the "news" in these old magazines can be a few month's out of date already.

With this date in mind, what does Roberta say?

Q. What game are you working on at this time?
A. I'm just finishing up "Mickey's Space Adventure" as we now have Disney products. It doesn't look like King's Quest, its like the old style adventure game, but it will have some animation in it.

Q. Have you ever thought of writing a sequel to any of your games'?
A. Yes, because this week I'll be starting on the sequel to King's Quest.

This article therefore takes place at a very interesting moment. The 13th August 1984 was a Monday. Roberta says that she is just finishing off the Mickey's Space Adventure Disney game, and that that very week she would be starting on the sequel to King's Quest, i.e. KQ2.

So there we have it. The KQ2 development began mid-August 1984. The game was released in May 1985.

Worth noting that when Roberta says that she was finishing off the Mickey's Space Adventure game, I assume that this would be from a design/story perspective. The devs were probably still hard at work. It wasn't released until December 1984. - So it is also likely then that Roberta starting on KQ2 that week mid-August was also from a design/story perspective and that the artists, coders, etc. didn't begin work on KQ2 development until later in the year.

This is the official KQ2 team in the credits from the original release of KQ2:

Designed & Written by: Roberta Williams
Game Logic: Ken Williams, Sol Ackerman, Chris Iden
Programming: Jeff Stephenson, Chris Iden
Scenery: Doug MacNeill
Animation: Mark Crowe
Music: Al Lowe

"Programming" in this context, given the "Game Logic" distinction on the line above, would refer to the development of the AGI interpreter, in fact the very first AGI interpreter in this case, i.e. AGI V1. - GAL was something very similar but was different enough that these days we tend to refer to it as GAL rather than AGI V0. When you think about it, the fact that AGI V1 is numbered with a version 1 number is quite a good indicator that they considered it the first version of AGI as well. We don't often see versioning for released things start at 0. Perhaps GAL was considered a kind of prototype that they learnt from and then rebuilt it the way they needed it to be going forward.

I can just imagine Jeff Stephenson, in his one man effort to port the GAL engine to the Apple IIe/IIc in mid 1984 (to support the Apple II version of King's Quest), thinking to himself that things could be done in a better way, a more portable way, and maybe that experience is what prompted the rewrite that produced AGI V1 in time for KQ2.

14

AGI Development Tools / Re: Original Sierra Source Code analysis

« on: July 01, 2026, 03:51:34 AM »

Starting to look at some of those BC timestamps, the resource files that still have 1985 timestamps suggest that the dev work was being done between the end of June 1985 and the end of October 1985. I've seen magazine adverts advertising BC for sale from December 1985 (there are some magazines mentioning it prior to release from earlier in 1985). And the MAIN.EXE interpreter executable on the 1.1J booter version of BC has a datetime of 16-Oct-1985 14:00:52. Given that some of the game resource files were still being worked on after that (up to the end of October 1985), this timestamp for the interpreter suggests that they prepared and built the interpreter version a couple of weeks prior to the end of game dev work.

Worth noting that the KQ2 1.0W booter disk has a MAIN.EXE on it dated: 24-Apr-1985 11:45:28 and that the file size of KQ2's MAIN.EXE is smaller, 22205 bytes for KQ2 vs 25566 bytes for BC. So that does suggest additional work was done on the AGI1 interpreter in between KQ2 and BC.

15

The Games and other Sierra Adventure stuff / Re: Rare AGI Games on standard PC DOS

« on: July 01, 2026, 03:34:33 AM »

There is both an AGI2 and an AGI3 version. So someone had to have these versions of the game.

Black Cauldron has the distinction of having AGI1, AGI2 and AGI3 versions.

The versions of BC that where mentioned in the original post are the three AGI1 booter versions known to exist, but as 1.1J suggests earlier versions, my guess is that those earlier versions were internal versions and never actually released to the public. The fact that there exists the 1.1J version in the wild would suggest that that version was released to the public.