Commander X16

As you might know from my previous posts I have been working on the construction of a Sierra AGI Interpreter for the CommanderX16. This will allow old Sierra games like King's Quest to run.

These past few months I have been testing games other than King's Quest III, which has helped me to iron out a lot of bugs.

I can now run Space Quest I and II and King's Quest I, as well as the King's Quest III you have previous seen.

https://youtu.be/1QQPcwJxzV4
https://youtu.be/30RIplYHT70
https://youtu.be/NFPKbLQBAso


Each game I fix is easier than the last .

I removed the loading screen in-between screen loads, as suggested by others previously.

The goal of the next iteration is the implementation of a faster flood algorithm, as well as the drawing of the priority screen.

My current algorithm is slow enough as it is without the priority screen even being drawn.

I will most likely use the Span Filling algorithm as suggested by DragWX ages ago.

It is here for reference: https://en.wikipedia.org/wiki/Flood_fill

I will also implement some basic keyboard input.

Hey keep up the amazing work!

I forgot that I promised to share my code for my faster pic drawing routine. So anyway here it is:

https://github.com/cosmicr/astral_body

And here is a real-time recording of how fast it is:



It can render this screen in approx 3 seconds. This uses a stack approach on a line by line basis, rather than the diamond queue that you're using. A lot of it is done in assembly. I'm also using a back buffer like the original interpreter used too. The good news is that there is still room for improvement! I reckon I could get it down to 2 seconds or maybe even 1 second!

I notice also you haven't yet implemented sound - if you check out my repo I have done this (albeit there is a new bug I'm hunting at the moment that stops it from working). The main goal for my version of the interpreter is to do it all without using bank ram for code. It's quite the challenge!

My text box display routine is special - it calculates how many 64x64, 32x32, 16x16, and 8x8 sprites would fit in the area, and then uses a palette trick to create black filled sprites behind the text layer and in front of the bitmap layer 0. The corners of the window are petscii chars.

Anyway, pick through my code, you might find some useful things in there. My code is very messy and illogical in places. Take what you like. If you prefer, I could make a modification to your code and do a pull request.

cosmicr wrote: ↑Tue Apr 16, 2024 10:24 pm Hey keep up the amazing work!

I forgot that I promised to share my code for my faster pic drawing routine. So anyway here it is:

https://github.com/cosmicr/astral_body

And here is a real-time recording of how fast it is:



It can render this screen in approx 3 seconds. This uses a stack approach on a line by line basis, rather than the diamond queue that you're using. A lot of it is done in assembly. I'm also using a back buffer like the original interpreter used too. The good news is that there is still room for improvement! I reckon I could get it down to 2 seconds or maybe even 1 second!

I notice also you haven't yet implemented sound - if you check out my repo I have done this (albeit there is a new bug I'm hunting at the moment that stops it from working). The main goal for my version of the interpreter is to do it all without using bank ram for code. It's quite the challenge!

My text box display routine is special - it calculates how many 64x64, 32x32, 16x16, and 8x8 sprites would fit in the area, and then uses a palette trick to create black filled sprites behind the text layer and in front of the bitmap layer 0. The corners of the window are petscii chars.

Anyway, pick through my code, you might find some useful things in there. My code is very messy and illogical in places. Take what you like. If you prefer, I could make a modification to your code and do a pull request.

Hello,
Sorry for the late reply.

You have a really great algorithm, and I admit it is objectively better than mine.

I have an enormous amount of memory dedicated to my diamond flood bank queue, which would all be freed up if I used your algorithm.

I would love for you to do a PR, I will drop you a private message.

Thanks

There are some complicated topics I need to discuss with you.

I wanted to say that you're both doing amazing work. I'm really impressed.

I was wondering if either of you saw my blog post about a week ago where I covered the discovery of Sierra's original AGI interpreter source code on a SQ2 game disk? It went a bit viral on Hacker News, reaching the top spot for a while.

https://lanceewing.github.io/blog/sierr ... -disk.html

It isn't exactly new news, as it was previously discussed on the sciprogramming.com forums back in 2016, but it occurred to me that not many people know of its existence, despite potentially thousands of people unknowingly having it. So in the interests of preservation, and spreading the word, I thought I'd put it into a github repo:

https://github.com/lanceewing/agi

In the past 24 hours, I added the file AGI.MAP, which is the Memory Map file extracted from the same SQ2 game disk. The version of the disk was missing the first few pages of the document, but after identifying it as a PLINK86 Memory Map output file, and playing around a bit with PLINK86 in dosbox, I was able to deduce what the other pages contained, so was able to reconstruct it. It is now a complete Memory Map file of the AGI.EXE as output from PLINK86 when they ran it on the 7th October 1987. As far as I can tell, it is roughly version 2.900 of the Interpreter, which isn't actually a known version from any game disk, but since the 7th October 1987 predates the known 2.903 version of AGI by a couple of weeks, I suspect it is at least very similar to version 2.903 or might be ever so slightly earlier.

The repo contains roughly 83% of the original AGI interpreter source code, and given its close proximity on the disk to the Memory Map output file, I think the source code must date to the same period. I had originally stated that the SQ2 disk had 70% of the source on it, and another 5% was found on a KQ3 disk. I have since reevaluated the percentage, taking into account the actual sizes of the modules, and ignoring bits that were linked in from libraries (such as PLINK's OVERLAY.LIB, and a couple of modules from the compiler's libraries), I eventually arrived at that 83% figure.

Anyway, long story short, I thought I would point you both in the direction of the repo as it will no doubt be a valuable source of information for the development of your Commander X16 AGI interpreters. The comments in the code, and the original names of the functions, should hopefully both be very useful.

Wow - I didn't know this existed actually.

Could be very helpful. I always assumed the original interpreter was written in assembly, but happy to see it's in C (somewhat). The source for NAGI has been my reference so far, but this should prove very helpful. I already see a few similarities though.

I've ditched my C version of the interpreter and am re-writing in 100% assembly. I've got about 40% of logic opcodes implemented, and am re-using the assembly I'd already written for my picture drawing. I'll be able to easily fit all the code in less than 32kb which means I don't need to use banked ram for code. I'm also helping out Manannan with integrating my pic drawing code into his code base. It's all a long way off yet, there are so many intricacies in the interpreter that you don't think about that have to happen, they are accentuated when you're on an 8-bit system with limited memory. Some things that are easy to do in C are quite complex in assembly too (like the menu system for example).