Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - lance.ewing

Pages: [1] 2 3 ... 64
1
Yeah, I've listened to that one a few times over the past couple of years. It's great, especially the early stuff about the King's Quest project.

The Apple IIe was supposedly released at the start of 1983, when the King's Quest IBM PCJR project was in its early days. Sierra had obviously created a lot of Apple II games before that, but it would have been the older models. The Apple II+ supported up to 64K, which would have ruled it out, but with the IIe supporting more memory, it opened the door to Jeff trying to squeeze it in. It is interesting what he mentions about the first 256 bytes of memory. I don't know much about the Apple IIe yet but I plan to one day disassemble the 6502 code for the Apple IIe AGI interpreter to see how it works, which would be a first step towards potentially writing something for another 6502 based machine. Some sort of similar memory bank switching mechanism would need to be used, as the standard 6502 can only address 64K.

2
I get an error trying to run it in scummvm: "WARNING: AgiLoader_A2: disk 5 not found!"
Do you have a copy which scummvm can run?

I assume we have the same copy, as my one also doesn't work in scummvm. It does run in the Apple II emulator I'm using though (JACE).


3
I looked at a few other Apple II AGI games, and was not able to spot any graphical differences.
Perhaps the pictures in KQ4 were more elaborate and had too many commands for the Apple II to handle?

Did the Gold Rush pictures look the same? That is another one that strikes me as having more elaborate pictures.

4
Yeah, I had the same thought when I saw that. It would be an interesting part of the history, in fact it is interesting that he put the name of his company within the interpreter version pop-up. Multiple apple II games show this, e.g. PQ1 attached. I haven't checked them all though. The earlier games probably wouldn't have this.

5
I've been fascinated with the Apple II AGI interpreter for quite some time now. It's amazing that all but one of the AGI games were released for the Apple II, including KQ4 and Gold Rush. It is what gives me hope that one day I might be able to write an AGI interpreter for other 6502 based machines. I am thinking that the Oric might be a possibility. Someone is already working on one for the BBC Micro.

When I was looking at it a year or two back, it was obvious how much this particular AGI platform (i.e. Apple II) was Jeff Stephenson's baby. When you bring up the dialog for the interpreter version, it only mentions Jeff's name. Example attached for KQ4.

Jeff was the one that ported the AGI interpreter to the Apple II in the first place (in 1984), and it would seem that he "owned" the further development on that for the duration of its lifetime.

6
There does already exist a hack that gives the AGI interpreter 256 colours for both the pictures and the views, where the pictures are no longer vector based but bitmap. The resolution is still 160 wide though, so I assume that that is still too low resolution?

When you say upgrade the AGI engine (fork the code), are you referring to the original AGI interpreter code? If so, unfortunately we don't have a full copy of all of the original AGI interpreter source code. We are lucky to have about 80% of it. The people that implemented the various hacks for the original AGI interpreter would have hacked in small machine language hacks into the executable. It might be possible to do something like that to provide what you want, but I think it might get a bit tricky, as it isn't as "easy" as what the 256 colour hacks did. The problem with a higher width resolution is that it changes many things across the interpreter. The LOGIC file format will have to change, for example, since setting the position of views on screen will need to represent a number bigger than 256, so will require more than one byte. That's just one example. I personally wouldn't be able to update the original AGI interpreter to do that. AGKorson understands the internals of the original AGI interpreter better than anyone, so could probably give a more authorative answer, but I'm guessing it would be a lot of work, even for him.

If you are not necessarily referring to the original AGI interpreter, but could instead live with one of the fan-made AGI interpreters (of which there are quite a few now), then the problem would become easier. The updates to the fan-made AGI interpreter wouldn't be too difficult to make, but you'd then require an AGI editor suite that supports the new formats. As I say, the LOGIC files would be different, the PICTURE and VIEW files would be different. An editor like WinAGI wouldn't understand the format, unless a special fork of that was also created.

I think that the "easiest" way to achieve what you want would be a custom build of WinAGI and AGILE. It would then be its own thing, but closer to AGI than AGS.

7
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 :D

8
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 :D

9
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.

10
Another amazing video about the 40th anniversary:




11
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

12
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.

13
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:
Quote from: Let's C Manual
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:

Quote
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.

14
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]

15
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.

Pages: [1] 2 3 ... 64

SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.033 seconds with 20 queries.