8Bitter

Hi Ward Shrake! Nice to see someone take an interest in this. Thanks for the heads up on those Jim Butterfield utilities. I'll take a look into those, hopefully soon, to see if they are of assistance. For my part, I ran ToA in Vice (C64 emulator), had Vice emulate a printer, did the old "run-stop" and sent to output of the BASIC listing to a printer (i.e. Vice sent it to a file) wherein I had and ASCII representation of the code that I then loaded into CBMPrg which did some syntax highlighting (big help). As you've pointed out in the quotes above, there are a LOT of subroutine calls and, unfortunately, delineating the boundaries (entry/exit) points of those subroutines is non-trivial in BASIC. One way to figure out what does what runtime is to look at the calls based on which user command was called (i.e. T, !, A, L, R, V). From there, you can map out the call chain for a "T" (thrust) command or a ! command (speak to creature) which will lead you to the combat code. I've not done it fully yet as I've not delineated enough of the bricks-and-mortar (to use your analogy) in the combat code but that's what I'd plan to do next. I've got my copy of the code broken out into the following printouts wherein I've copy/pasted code that seems to work together into the following groups: * game initialization (all program initial variables and the loading of the music files) * character initialization and equipping (includes haggling code with Innkeeper) * save game (which seems to have a bug for this never works right in Vice) * combat engine (largest file with lots of x and y variables for character and monster position) As you point out, looking over the code, one would almost think that obfuscation by confusing goto/gosub calls was a form of early protection! There's just some plain old weirdness in there. Look at how the weights are stored for weapons vs armor to get an idea... I'd love to have a separate thread to deep dive this but I'm not up to speed on how far we can take this in an online forum. I presume this code, even if commercially dead and trivial to access, is still protected so I refrain from posting any listings here. Anyone have thoughts on that?

I think that'd be an intriguing topic. Seems like the right place to have that discussion. Hmmmm....well, for the most part. Though I did, when I was deep diving the code about 4 years ago, print the code out, break it up into logical parts to make it more sensible and heavily annotate it to help me remember what some of it did. I just dug up those old notes and refreshed myself on some of my more interesting comments. Ha! Interesting that someone else, at just about the same time, was doing the same thing on the Atari platform! I decoded about 40+ variables (non-trival given the limitations of Commodore basic wherein only the first 2 characters are considered significant so you get a lot of difficult to decipher variables like "lo" or "ak" and so forth). That said, he's spot one saying the code is a $%@# mess. I really gave the author the benefit of the doubt as I was printing and slicing code into logical chunks and co-locating on separate documents to make the "flow" easier to read. All the while I kept reading, decoding and thinking thoughts like...."hmmm,.that seems unnecessary....why store values in 'ounces' for armor only to then divide by 16, add 0.5 and then convert to an int to round up when you're storing values for other equipment in whole pounds?..... Wait? Is that a goto to another goto!.....why is this code literally all over the place?" I think it was an early form of copy protection --- write the code in the most obfuscated form imaginable to defeat even the most dedicated code readers. That said, with time, the code can be deciphered and I suspect I've actually gotten farther into it than the blogger. Well, the C64 version shares some similarities here as it has the same 16,000,000 experience point limit (i.e. anything OVER this is considered to much). However, the formula is very straightforward and logrithmic -- a one-liner in fact that results in a very clear pattern wherein anything <2000 is level 1 with 2000 = level 2 and then doubling thereafter. As such: Level 1 = <2000 Level 2 = 2000+ Level 3 = 4000+ Level 4 = 8000+ level 5 = 16000+ . . . Max possible level under cap (16,000,000) = level 14. Once you're at level 15, you're too worldwise. Well, looking forward to your mapping updates! Maybe, in addition to a programming thread about adding new expansion modules, we should add a "decoding Apshai" thread where we answer questions such as: * just how strong are certain monsters? * how likely am I to get hit by a creature -- what factors are at play? * what's the difference in defensive strength between different weapons when parrying? * what's the difference in attack strength? * what impact does experience have? * what role do the attibutes really play in the game?

Oh, naturally I hung onto it and just requested the Temple of Apshai from my parents at the time. It was an agonizing two week or so wait. I dutifully began play with level 1 of the original series as it just "seemed proper" and recall my first monster was right in room 1 -- a skeleton with glowing red eyes. Magical. The original game was composed as a BASIC / machine language hybrid (at least, on the C64). I listed the code and, in that version, in theory, this seems entirely possible. It would be some slog interpreting all of the variables as there are dozens but I've been able to decipher a number. So yes, this seems entirely plausible. In fact, I've considered doing this very thing myself. I'm also surprised no one else did. Chalk it up to having the rights to do so... I guess I was referring to the monster graphics most of which are bit-for-bit identical (i.e mosquito, leech) and some have differences but just in a way that's 'different' rather than much better. The walls of the dungeon and the look and feel of the main character are, however, very different. Looks like they used 3 hi-res sprites to form the main character whereas, in the original release, they used one multi-color sprite to create that rather odd looking "Robin Hood" if facing left, "Armored Knight" if facing right character glyph. I recall listing and inspecting the code to learn how it all worked. I've always wanted to know exactly how combat worked, how strong certain monsters were, what effect did "parry" vs "attack" vs "thrust" have on combat, etc. I've learned a lot but not quite figured all of the above bits out. Just for grins, here's a few bits I recall learning you and the Atari fans of the game might find interesting: * monster speed – Was always bit of a mystery to me: was this about how quickly they moved onscreen? Nope. It’s their attack speed. Expect to have less time to react to a monster in combat if this is ‘high’. * you’ll be hit more frequently if there are more monsters appearing (though there’s no mechanism in the game for telling you how many are present). The relationship is linear (i.e. 3 monsters present will hit you 3x as fast as just one) * It takes more strength to wield a hand-and-a-half sword than a great sword. I believe it takes a 16 strength for the hand-and-a-half sword and 15 for the great sword. I’ve seen this same behavior in the VIC-20 version and, I believe, the Atari 800 so this is by design (or a repeated bug…). * mercy rule: if a random character starts with <60 silver and/or has a Strength and/or Constitution that’s too low, it’ll silently re-roll your character before presenting to you. * There’s a 1:200 chance that the inn keeper will, in response to a sufficiently low-ball offer, just give in spontaneously with “I see the gods look with favor on thee – so take it for that!” I’ve never seen this in play myself but it’s in the code. * Character levels advance like D&D fighters: 2000 exp = level 2, 4000 = level 3, 8000 = level 4 and so on. I believe a character of > level 8 is considered too experienced (need to re-confirm but there is such a 'status' in the game) * If your combined intelligence and ego score is <20, there’s a chance that the innkeeper will actually raise the price during haggling. If your combined score is <14, you’re likely better off just taking the asking price as you’ll almost certainly be offered a higher price.

This is a neat series of articles about a game that defined my first experience with micros. I owned a C64 but my close friend owned the original Atari 800. We were exploring Apshai at the same time and comparing notes because the play was so similar. Upper Reaches of Apshai was actually my first computer game which was ironic as it was also my first introduction to the concept of a "dependency" (i.e. I was unable to play it as I didn't read the fine print indicating that I needed the Temple of Apshai program tape to play). Bang. My first introduction to home computers and I find myself with a game I'm unable to play because I lack the core engine. Temple of Apshai was ahead of its time in that way I think (i.e. having a core engine with lots of the differentiation in the 'data' files which were sold like D&D modules). I like that you're comparing graphics and the table you've got is really neat. As you've pointed out, the Atari graphics are, unfortunately, a bit blockier than their cousin micros. Likely this is due to an exclusive reliance on player missile graphics to render the creatures which is done at a 160x192 resolution aspect ratio. If they'd chosen, instead, to use hi-res graphics mode (320 x 192) and character-based graphics to get hi-res pixels and just used player missile graphics as "fill" to add color, that might result in higher res monsters. Maybe that'd be a neat project for someone to try. The C64 graphics in the updated trilogy look largely unchanged from the orginal series released in 1983. There, they used 3 hi-res sprites per monster and overlapped them to achieve the look of a single multi-color hi-res sprite (C64 only supported a single color per sprite in hi-res mode). This resulted in very detailed looking monsters using 320x200 aspect ratio pixels (i.e. about 2x as fine in the horizontal as the Atari monsters). I think a neat next step would be to compare the original monster graphics for some of the systems compared to their updated versions. I can say from my experience that the Atari version, though still relying exclusively on player missile graphics, at least overlapped them in the updated version to achieve multi-color monsters with better detail than their first version (all of the monsters were monochromatic as they relied on a single player missile graphic). Again, the C64 versions largely only differ in color choices between the two versions though I do see some monsters represented slightly differently. Music in the *original* C64 version is unique and I recommend you play that version a bit to hear the haunting organ-like score used there. When I played, I truly felt that I was in a haunted house and the sense of tension it added to such a simple game was amazing. Years later, when my brothers and I think about playing the original C64 temple of apshai, we all remember the music and the heart-beat inspired tempo that played when a monster appeared. It was truly unique and it would be neat to compare sound effects and musical scores. Anyway, fun series of posts that is near and dear. Thanks for putting this together!