Ward Shrake

Pretty cool stuff, guys! Good work -- (as always) -- Mister Adam!

I immediately thought of what you had said, above, when (at random) I unexpectedly ran into this quote on someone's Facebook page: "The legendary cellist Pablo Casals was asked why he continued to practice at age 90. 'Because I think I'm making progress,' he replied." (I just liked the quote. Figured I'd post it here, just for kicks.)

Adam said: > Finally, there is an interview with Ward Shrake, > who created multicarts for several systems, > including one for the Bally Arcade/Astrocade. I just listened to that interview, tonight -- and I gotta say that, in terms of listening to myself talk: over time I'd forgotten much of what Adam had asked me, and what my answers had been, so it was kinda weird listening to that interview. It feels different -- (at least in terms of perceived speed of listening to someone and then replying; when hearing it, long after it was recorded) -- than it felt when it was just me sitting there and B.S.'ing with my good friend. As for how "I" sounded, or think I sounded ... I guess if a person is gonna sound like a dork, maybe sounding like a dork on coffee makes it better!?! Apologies to the hardcore Astrocade types, that so little of what I said was on-topic for that system! (Sounded more like a VIC-20 interview, almost!?) As for how the interview sounded, and "flowed": I thought Chris did quite a good job on editing what he had. Kudos to him for that! Thanks, man! Anyway ... ignoring how weird it feels to be listening to myself, and focusing on the other parts of the three podcasts (counting episode zero) ... yeah, it was informative. Adam's highlights from the various newsletters, for instance, gave me a much better grasp of how various users once must have felt, with all of the delays and set-backs and what not. The huge wait times between promised dates of delivery and the actual deliveries, must have really been an upsetting thing! I'm finally able to see more of the motivation for things like the efforts users put forth, to support their little community. At the same time, it was good to see signs that Bally (or whomever) did try to get things out there, such as programming information. Weird, that so few years later, other companies were so insanely good (in comparison) at releasing things like programming manuals. Guess I had taken that stuff for granted? I'm used to the whole "digital archaeology" thing, from the perspective of someone investigating a system, after it's commercial death. But seeing those users having to do stuff like that, right up front, when the system's initial launch and library were still basically brand new!? Wow!! That was trippy!? Cool that there's a sense of humor involved, throughout all of the episodes I've listened to. Gotta say another thanks to Chris Plus Plus, for his funny asides and so forth. (But Adam's not as dry in his commentary as he seems to think he is.) Glad to see that Dominic got a shout-out (in an earlier podcast) for his opening theme music contributions. Having known him since he was like, what, negative six or so, it's been a cool thing for me to see him grow into adulthood and to always be creative; even if it's "creative" mixed with a healthy dose of intelligent parents, which not everyone is used to. That mix of "nerd" and "artist" is something Dominic's parental influences have, to be proud of. Overall: You're onto something, guys. Keep it up! I'm being entertained, and I'm learning "new" stuff as I go. Looking forward to the next episode(s) ... !! -- Ward Shrake --

Thanks muchly!

Thanks! I've bookmarked that web site, and will check it out. Might take me a while, what with all that's going on around here ... but it's "on my list of to-do's" now, and I intend to give it a good look-see before too long. With that said, though, we should probably get back to the thread's subject of Multicarts for the Bally Astrocade, before I get us in trouble.

I'll totally trust Adam's memory on the "why wasn't that title screen visible, front-and-center," on that m'cart I once made. Where at, Mr. Jeff? Point the way, and I'll see if I can't pop in from time to time.

What he said! That ("War") game wasn't around, back when I was making my multi-carts, or it would have been probably been something like the "dips all set to zero, or all set to one" mode ... with maybe WoW as the other. But I always liked that system's version of Space Invaders, too ... and there are other cool ones that were fun to play. In the end, I relied in large part on Adam ("BallyAlley") and Mike (White), to suggest what programs were on there, in those two major or no-brainer "dip positions".

I can't resist saying this: "good for you!" (But don't take that as a bad thing, against any of the other games!)

Adam ("BallyAlley") just pointed me to this thread. I've read it all, top to bottom. Coolness, seeing people still playing with this stuff. As for that bottom label: if memory serves, that only made it onto the first (few?) batches of carts, because I was using the Bally-made cart cases at first; but then, due to shortages in those, had to switch case types. Off-hand, I don't recall how many of the "double label" ones went out to various people who bought one of those carts that I once made. (But no longer make: sorry!) If that info is stored or written down, anywhere, it'd probably be that ridiculously long FAQ I once wrote. Adam's site probably has a copy of it, "somewhere". I should mention -- (for no major reason, other than General Nerdiness or "information completism" I suppose?) -- that the bottom side of the carts that did have that second label, aren't showing a totally completed circuit board. What's shown, through the "cracks" as it were, is a somewhat un-stuffed or only-partially-assembled circuit board. That is, it looks like some of the jumper wires and such, which had to be there for it to operate, and that had to be there or it wouldn't work, aren't yet soldered on. I suppose that makes that image sort of a glimpse at the process of making those carts, by hand -- in that the image shows it partly, but not completely, "done". As for that cool-looking multi-cart screen: Adam, maybe my memory of such things is just mush right now, but I don't recall that one. Are you 100% sure it was ready to go, when I first made those carts? It seems like something I would have thought was very cool, and would have wanted to include -- so I'm at a loss myself, to understanding why that wasn't on the carts I once made, those dozen or whatever years ago, now? I could be mistaken, but the only reason that jumps to mind is that, maybe, the screen was done later?

Thanks, Adam and Chris, for sharing this bit of "new" gaming fun with the public! (And Bill, for chiming in!) I gotta say that while my last-minute pre-release testing period wasn't super-lengthy or detailed, hopefully no super-major bugs snuck through (shouldn't have! seemed to work ok for me) ... and it was definitely still good clean fun running around and killing hi-level beasties with single off-hand swats! It felt good breaking out that pair of programs, and radically increasing character specs to ridiculous levels, after 30 years of not having played with my old "cheating" program. Anyway ... enjoy!

I like what you did there. The idea of mapping what's there, and documenting it in detail, is cool in itself. You know I feel you do fine work in that regard, so there's not much "new" I can say on that part of things. (Other than "Fine work, as usual, my friend".) The "in the spirit of the original writings" additions you made to the backstory or "vibe" add something really cool. I've enjoyed your past additions in that mode or spirit, and feel you really nailed things. (Again.) This time, though, it feels like you'd taken it up a notch. (Using "Scarfoot" as a play on "Nailfoot" as just one example.) What you're doing makes the "deepening the gameplay" experiences, feel "even deeper" and more immersive than before. And that's a good thing for fans of these cool old dungeon-style games.

That wasn't exactly what I had meant ... but as the saying goes, I suppose it's "close enough for government work". Just to clarify: once I had seen that posting (#28, above) I had dropped the thought of someone perhaps doing a "port" or conversion of the C64 program ... but I hadn't "announced" that mental drop of that prior idea. So, having abandoned that thought, my more-recent comments were much more along the lines of "just observations". But no biggie, either way.

Coolness! That's very close to the sort of thing I was thinking of! I know from having used the Cross Ref program on the C64 "forever," that having the variables sorted, alphabetically, in the program's output listing, is just absolutely the way to go if you're trying to actually analyze the program you're studying / trying to make more efficient or readable, etc. No question in my mind, there. "Sorted" rocks! The Quick Ref program's output, within the sub-listing for each variable, is pretty much how Cross Ref does the "variables" portion of its listing ... but with "repeats" included. I'm not used to seeing that. The code for Butterfield's program didn't list the same variable two or more times, in cases where it appeared more than once on the same line. Guess that's a personal preference type of thing. Either way, you still end up with the same essential information -- even if, arguably, it's easier to read things the way that Butterfield listed his output. I guess the argument could be made that the Quick Ref way of doing things gives a person more information? (Again: I'm just not used to that.) That sorted list of numeric constants is pretty cool. The Cross Ref program on the C64 didn't have that feature. I can see how that would be pretty useful to have. Cool! The summary table shown is a new-to-me idea. I'd have to actually put it to use, to see how useful it would really be -- but more info is (almost) always a good thing. The one thing that the Quick Ref program's output listing seems to be missing, however, at least when compared to the Cross Ref program for the Commodore computer line, is a way to show which line or lines in the program under study, "calls" which other lines. To me, that was 90% of the point of such programs. Having put that feature to use, over and over and over, over the years, I consider it absolutely a "must" for such programs. (Especially with BASIC code written in a style that's as "hard to follow" as what I'm seeing in the "Temple of Apshai" code. Gosub calls, apparently ending with a sudden GoTo. Several different possible RETURN exit points, from Gosub's. Etc.) The best analogy I can come up with, to explain what I'm seeing in the "Temple of Apshai" BASIC code on the Commodore (and other) lines of computers, is that the program is written much like one of those "pick a path" books. Same logic applies to the code. It's not written in the sort of modular or "black box" style that's easy to follow, visually, when a person is trying to "trace" the flow of what's actually happening. With the sort of thinking that easy-to-follow code is wrapped around, each major sub-section of the code does one specific thing. There's one entry point, for every place in the program that "calls" that module. There's some decisions made, and some work done. And then, there's a single exit point. "Enter; do stuff; exit". Really easy to follow. That's exactly what the "Temple of Apshai" code is NOT doing! Again, the "Pick a Path" style of thinking is what's going on in that code. So, having an analysis program which tells you what lines call what other lines, is necessary to understanding the actual flow of that particular code. Question: did the Quick Ref program simply not have that (awesome!) feature? Or is it, perhaps, a user-selectable option; which we're just not yet fully aware is there? Quick Ref seemed to do so much, so well, that it would be a major shame if that "big" feature wasn't included. All in all ... good to know that such a nifty program is available, over in Atari Land! Adam's review, and what I've seen in the uploaded output listing, makes it sound like a really useful program!

Cool to know. I was mainly curious about "how the other half live" ... and you've given me some good input on that! (Thanks!) So as not to pull things TOO much farther off-topic, I'll be quiet and behave, and basically just "lurk" ... but before Running Silent, I'll mention in passing that I just now did the Cross Ref thing on the "Temple of Apshai" BASIC code, for the VIC-20 version of the game. And passed the resulting reference files to Adam / BallyAlley, via email. Figuring that, if nothing else, it might be half-interesting to see if there's any huge similarities or differences in how the code was written, on the Atari 8-bits versus the VIC-20. I'll leave any follow-up on that to Adam, though ...

I suspect that what appeared in "Compute!" as a type-in was probably a fairly well-known PET-based program, first ... and there's probably source code for it, via that route; even if it turns out there's no easily-available source code for that program on the C64. But seeing how good Butterfield was, in that way: it's probably out there, commented and all; for both / all versions. Off-hand, though, I wouldn't know where either the earlier or the Compute!-published version's source code might have been printed. This next bit is probably sorta wandering a bit more off-topic, so I'll just mention it in passing and then "shut up" about it, so things can get back to their regular "flow". Okay. Bear with me, for a moment ... In taking a peek (BASIC pun sorta half-intended) to see if Jim Butterfield's book(s) on writing Machine Language code for Commodore computers might have that Cross Ref program in there (no luck, at least per the table of contents) ... and then doing a bit of half-random searching to see what else is "out there" ... I came across this link to what used to be some Commodore VIC-20 web info I once had online ... which reminded me the date of the program that RUN magazine once ran (May/June 1991) about a "profiler" (BASIC program speed analysis) program that I had adapted from another author's prior code. https://www.digitpress.com/the_digs/vic20/texts/rundisks.htm This also came up, in my next searches ... https://archive.org/stream/Re-Run_1991-06_IDG_Communications_US/Re-Run_1991-06_IDG_Communications_US_djvu.txt Which, again, I probably shouldn't mention here -- (too hard, anyway) -- but once we get to where Adam (BallyAlley) is happy with his output / program choice / etc., I might ask this as a follow-up to my original question (if there was a Cross Ref program, similar to Butterfield's, for the Atari 8-bit computer line). That future question being: back in the day, or even now, was anything similar to that "profiler" program that RUN magazine had printed (and also once had on a ReRun disc) available for the Atari 8-bits? ... but, again ... we'll save that discussion for later. Meanwhile ... back to the original topic; already in progress!

You had said (back in post #13) that the "Inn" file was fine; then said it again, for the next attempt (with another program); then said it a third time ... and then said this: > I'm beginning to suspect that the INN.BAS program has problems. > It was taken from a copy protected disk. See this posting for > the version of INN.BAS that I'm using: I was just thinking that you probably meant that "DM.BAS" had problems ... that's all. But no big deal, either way. It's 99.xx% moot, as everyone seemed to understand what you had meant, anyway. <Pickinesss mode OFF>

Adam, did you perhaps post the summary portion of your initial question (in post #13) "backwards"? Double-check your question's summary, as posted above, please. re: 2800 different variable references, in one part of the Atari's code Hmm. I wonder how many of that large number of references are "repeats" of previous ones? Any idea if that's a possible problem here? I partly ask because the C64 Cross-Ref program by Jim Butterfield had no problem with the C64's code -- and that's basically a "one-piece" combo of the Dungeon and Inn pieces of code. So, the C64 version should be larger than both "halves" for the Atari version; or so I would think. And all ports -- (as far as I know, anyway) -- of the game, on various computers, seem to be using a generic "engine" with only a small amount of changes. (Other than those required for varying display devices, sound devices, etc.) So, if correct, that would seem to imply that the cross reference programs used to date, on the Atari version of the code, aren't as robust as might be hoped. (Yes, no?) I guess that surprised me. The program for the C64, by Jim Butterfield, as originally published as a type-in program in Compute! magazine, not only listed every variable (of any type) in an alphabetized way, but also made a complete reference listing of every single line of BASIC code which got "called" by any other line in the program. And I've used it a LOT, over the years, with various pieces of code written by various authors (including my own BASIC code). So, I'm surprised Adam's having this many problems, on the Atari side of things. Hopefully, one of the programs will work out fine, sooner or later ... but if not, maybe some Atari coder could do a "port" of Butterfield's code?

Just as an aside -- what started all this was Adam (BallyAlley) and I having a discussion in e-mail, about the details of the Commodore 64 version of the "Temple of Apshai" game. (Not the Trilogy version of Apshai. That version came a few years later than the one he and I and another person were discussing.) Somewhere in that conversation, I had brought up the idea of how much I loved the C64's "CrossRef" program, by Jim Butterfield ... and I had mentioned to Adam that I had re-written the BASIC portion of that (hybrid Basic / machine language) program, to send the output either to the screen -OR- to a file on a floppy disc drive (instead of screen or printer) ... etc., etc. ... and I was just stoked, in general, that I had gained a version of Jim's great old program, which didn't need to have its output sent to the screen -- (which is useless, for programs of that size) -- and which didn't need to go to a printer, either. In that context, I had off-handedly asked if the Atari 8-bit computers had some similar program. (Which Adam asked, over here; above.) Sounds like there's a lot of CrossRef type programs for Atari 8-bits ... as written by various parties, back in the day ... but I guess my original question, to Adam, was if there was a conversion of that one specific program, by that one specific author. (Since I had always loved how great that program is, for the Commodore series of computers.) So ... are any of the actual Cross Ref "type" of programs, conversions of what Butterfield had done on the C64? I'm not trying to knock the other programs. Just wondering what's out there.

On second thought ... don't anyone answer those (technical, C64) questions. We're getting way off-topic! Before it gets any farther off-topic, I'll just quit bringing such things up, in public. And now, back to your regularly scheduled message thread ... already in progress.

Even though I'm (mostly) trying to focus on "just" figuring out where one thing ends and another begins, staring at the code does make one more familiar with the "logic" -- and I can't help "thinking ahead" to certain parts of the desired re-write. Quoting 8Bitter: > 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. Okay, just to clarify ... if I'm understanding what you said, and assuming I'm also understanding the program's coding and logic, then here's how I see things: - - - - (1) There's a portion of code about two thirds of the way into the program, which seems to be how the program determines what a user pressed; and what to do about it. (2) As a major part of doing that, the original programmers had set up a long, seemingly non-sensical "string" made up of seemingly-random, individual letters and symbols. (3) That "string" of letters and symbols appears to be being sort of "scanned" to see if what key the user pressed, correctly corresponds to a command that the program understands. (4) If a match is indeed confirmed, between what key the user pressed and one of the program's commands or functions, then the program branches, or "goes somewhere" else -- with "where it goes" being determined by a bit of code involving some logic like, "ON (variable) GOTO (line A, line B, line C...)" - - - - My list of questions about that could go on and on, for a while ... but I'll let these brief highlights suffice. My main question about that is: if I'm interpreting that stuff, above, correctly, then why in Geb's name would they "bury" that VERY speed-critical bit of code THAT far back?! I ask that because, in BASIC, any subroutine which needs to be accessed all of the time, over and over, ought to be located as near the beginning of the code as possible ... so that the computer's BASIC Interpreter does not have to search through every line of code, starting at the code's beginning, every bleeping time that routine gets called. My main comment on that state of affairs -- (if, again, I've correctly figured their "logic" out) -- is that Job Number One, when it comes to be re-write time, is moving that bit of very speed-critical code to as near the start of the program as possible. I'm confident that one alteration, alone, will most likely make a noticeable improvement in speed. Re-writing that one section of code, to make it "faster" ought to be another big priority with the re-write I anticipate being an itch that I'll have to scratch, at some future point.

Hi back, 8Bitter! Good to hear from ya / see some added interest in all this. For what it's worth, be advised that Adam ("Bally Alley") and I have been e-mailing one another about all this, and we're kinda thinking that an "article" over on his "Orphaned Games" web site might not be a bad thing. So I'll be heading in that direction, long term. Short term, I'm open to suggestions and stuff, and the sharing of stuff between us, via e-mails ... if that's a way you wouldn't mind going, with all this? Meanwhile, just to fill you in on what I've managed to get done, of late, on the C64's program documentation effort: I'm halfway through the one largest program's BASIC code, now (eight printed pages worth), as far as typing in all of the hand-scribbled notes I've made over the last several days. The idea of this stage of the game being to add some white space after one "brick" ends, via adding a line with only a ":" on it (which BASIC will just ignore; but it makes it a LOT easier to see that a "run-on sentence" or module of some kind just ended) ... followed by a newly-added REMark line, which generally says something like "Gosub (routine, which was called) from (lines) 123, 456, 789" or whatever the exact line numbers are, in each case ... and then, after that, another "white space" line. To back-step and explain: while I admire what you're trying to do, and partly have already done, I'm not yet ready to try to figure out what each of the "bricks" actually does. I'm trying to hold back, intentionally, on figuring that out ... until I know what's a brick and what's mortar and where each of those materials actually ends, in any given section of the code. Which is admittedly a weird way to go about things ... but my feeling is that if I do it any other way, with some code THIS convoluted and head-hurting, I'm probably just making my overall job harder. With that added white space, and those "headlines" added in, the first half of the listing is no longer just one big, run-on, "monster without a pause" blob of code. Ultimately, yes, figuring out "what does what" is an end goal ... (with cleaning things up as, visually and whatever, being a secondary goal of mine, with this project) ... but for now, I'm just muddling through the sort of things that will tell me where each "subassembly" starts and ends. I've never had to be this thorough, with anyone else's Basic code, to make sense of it. But it is what it is ... and the challenge is motivating. It's very tedious, picky work, trying to define and then label exactly what lines in the program's code are calling exactly which subroutines ... but the "mortar between the bricks" is becoming more evident, as the work gets done. And hopefully, things will make more sense as we go. For now, I'm also fighting my urge to re-write this mess ... err, this wonderful code ... and am thus refraining from moving any of the code around (to "where it belongs") ... but yeah, I can definitely see why someone would want to do it! Way too much "misplaced code" in there!

After spending a bunch of time, recently, playing around with the code for the C64 version of "Temple of Apshai" (the original version, not the later "Trilogy") I think I have a very good idea of what the first user-created module should be: a visit to a spaghetti emporium! More tongue-in-cheek commentary on that program's internal workings: I can also see how certain rooms might be "magical" in having exits and entrances not matching up, and so on. In fact, I'd almost (almost) bet money that those rooms might have been directly inspired by the original game's programming work. By which I mean: back when I used to write programs in Basic, for the C64, I thought it was just expected that any given routine would be off, by itself, and would have three basic features. First, you'd have a common entry point. Any other part of the program, trying to access that subroutine, would "enter" from that "door". Then, inside the "room" itself, there would be some sort of useful work done. A single, well-defined purpose, for lack of a better way to put it. And once that work had been accomplished, there would be a single "exit" from that "room". Back then, I came to expect that from any module or routine, as a given. "Single entry point. Single purpose while you're there. Single exit point." I've always thought that it just makes perfect sense, to code things that way. That is, if you're planning to maintain or upgrade the code, over time. (And especially if someone else, who came after you, was trying to figure out what was going on.) But, hey, this thing was written in the Official Dark Ages ... so I guess I shouldn't fret too much, if it's not up to later standards, internally. As for descriptions of the actual work done, recently: I spent the bulk of my leisure time, on Sunday, just going through the "gosub" routines -- totally ignoring any of the program's hard (that is, unconditional) "goto" statements; or the conditional goto's; etc., etc. I wanted to deal with the "gosub's" and the "return's" first. So, over the weekend I had isolated every single "gosub" call, from anywhere in the program -- (long story shorter: I'd done so by creating a printable, straight-forward, PC-compatible ASCII version of program's listing, by using "CBM2ASC.EXE" on my PC; and then, using the "find" command in DOS, on that same PC, to show me any line in that text file that had "gosub" anywhere in it ... and had routed the output of the "find" command, into another straight-forward ASCII text file. And then, I did oodles of editing that text file, by hand; and sorting of lines via both DOS and Word; and so on. First sinking feeling I had, once that was in a usable form, was the somewhat disturbingly large amount of "subroutines" which were called, using the GOSUB command, by precisely one line. In other words, it looked, just from the list, like a lot of "misplace code" rather than what I think of as a true "subroutine". (That is, something used over and over, by many other pieces of the overall program. And a few of those did exist -- some of them being called nearly 30 or 40 times. But for the most part, what that sorted list of GOSUB calls showed me was that there were a LOT of "subroutines" called by just one line of code, on one occasion. And a nearly-as-large amount that were only used, twice. But in case I'm getting ahead of myself: end result of the yesterday's work on that program's code -- I had a PC-print-able, standard ASCII text file, which contained every GOSUB call found in that program's listing. Each main entry had been sorted, twice; in a sense. (Sorting the whole list, first, by what part of the program the GOSUB call was pointing to; then, when more than one line had called a certain area of the program, I had sorted those separate entries numerically: so it would be more obvious which line or lines had done the actual calling.) Having come up with that neatly organized list of GOSUB's, I could then use the brute force method to go through a print-out (on paper, with various pens and hi-liters) of the program's listing, itself, by hand and eye -- with the main goal there being able to better "see the cracks" between where each subroutine started or ended -- thus, it was hoped, showing me the "black boxes" that make up the program, as a whole. By searching for the "cracks" between those software modules, or the mortar between the bricks, as an alternate analogy, my hope was to better define each "room" -- thus feeling a lot like Adam's adventures, when he's mapping the program's screen-visible gameplay output. What I'm finding is that the "black boxes" which make up the program's code, might have six different exit points apiece. I kid you not! That's not happening in just in one section of the code; but rather, all over the place. I'll triple- and quadruple-check things, as work progresses, but at least one subroutine call just went right to a "RETURN" and then back! Now that I'm able to better see the "mortar" between the "bricks," as it were, I'm seeing one or two short routines which may not have ever been called by any other part of the program! (At least on the c64 version of the code; which I'm presuming was a straight-forward port, probably by simply typing in another computer's code, from a printed listing; and then debugging it until the Basic Interpreter didn't whine.) I'm doing this documentation work, step-by-step, and I don't want to get ahead of myself by rewriting code as I go. But I'll definitely be making some internal alterations to the way things look, before I'm done! For right now, I just want to add some "white space" to the listing, and some REM statements near the "entry door" of various subroutines. Trying to better define the mortar, where it's in between various modules. Some of the peices of code are already "trying to escape" on the first line of the code which makes up that individual "black box"! Instead of doing a series of checks on the current state of some variable or condition, or other, and then making adjustments as needed to whatever needs adjusted, and then, exiting from a single "door" (and, since these are GOSUB's I'm examining, at present, then nicely doing a RETURN to wherever the program had left off) what I'm seeing over and over and over in this code is that the programmers had gone out of their way, seemingly, to point the program's "flow" towards as many "secret, hidden doors" as possible. In quite a few "black boxes". I guess the main point I'm trying to make is that, had I just tried to "eyeball" this code, there's no way in blazes it would have worked out! Adam had to take pains, when he was making his maps, to be sure that he had checked every section of wall, in every room, before he concluded his search of a given room. I'm basically doing the same "brute force" sort of exploration, through the lines of code which make up the program itself. Bottomline: it's good practice, I suppose, for getting back into the swing of looking at other people's (Basic-language) code. It's definitely keeping me thinking, and double-checking my work, as I go! And making sure I am not falling asleep on the job, or making too many assumptions, as I go. Having said all that: I don't mean to knock the game, or the programmers. That's not my goal, at all. I'm just stating my personal opinions, based on considerable work and analysis of what I'm seeing, as I reverse-engineer this (at least) 30-year-old program. And one of the major conclusions I've reached, in the time that I've been "mapping" the code for the C64 "Temple of Apshai," is that there was a reason they had modules that worked with the core engine; rather than "simply" rewriting the core engine, itself! But, hopefully, down the road: the old code will be documented well enough (and/or cleaned up enough) that people like modern hobbyist Basic game coders won't mind making user-made modules for the game. Because, despite being the sad state of the "behind the scenes" part of the game, it works. And people do like the end result. Anyway ... just wanted to chime in, a bit, and pass on some news about the arguable similarities between what I've been doing lately, and what Adam's been doing, all along.

Adam already knows this, but for 8bitter's sake I'll say that I got a wild hair, and I'm actively working on playing around, now: exploring that Basic code (for the 1983 version of ToA, on the C64 home computer). And, yeah, initial impressions are that things could be more "organizee" in that code! But, it's not TOO too horribly bad. Having rewritten Jim Butterfield's (great!) old Cross Ref program over the last couple of days or so, has allowed me to send formerly printer-only program output to disk. It seems to work fine, in that new mode. So, 8Bitter, if you don't already have access to a list of what line calls what other line, in that program; and/or don't have the complete / alphabetized list of what variables the program uses: just ask! Adam has a copy of it now, too. (But as far as I know, wasn't gonna get too deeply into exploring that code. I think he's likely gonna leave that stuff to other parties...?) Anyway ... part of me can't believe I'm playing with coding stuff on my C64, all of a sudden. And Adam can't believe it, either. But there ya are ...

Interesting stuff, Mr. Adam (and 8Bitter)! Kinda fun, reading about all this old "exploring the code, which is about exploring dungeons" sorta thing. As someone said in the reader's comments, over there in the (linked-to, above) blogger's page, where other decoding work was happening: "Nothing like the smell of hexadecimal in the morning!" Be sure to post a link here, if / when the topic moves / switches over to exploring the (Basic? C64? Hopefully!?) code for this old game. Till that part of the subject possibly moves, elsewhere: other hoary old versions of Basic I wouldn't be any help on, but I do recall some really great utilities and programs and such, for analyzing Basic code on Commodore 8-bit computers. "CrossRef" (if memory serves on that utility's name) by Jim Butterfield was a truly wonderful bit of code. A real GebSend, when it came to the idea of finding every single variable used in a C64 BASIC program; every line it was used in, and so on. I think it listed all "jumps" and such, as well -- goto's and gosub's, alike -- making it a LOT, and I mean a LLLOOOOOOTTTTTTTTT easier to go through someone else's code, and figure out what it's doing. And where, specifically, each part of the code is. Breaking things into visual "blocks" was made oodles easier. "SysRes" (again, if I'm recalling these old utility's names, correctly) was another HUGE boon to Basic programming on the C64. You could do all sorts of renumbering of other people's code, if you wanted to ... and it would all work, after you'd told it to renumber the code in logical "spacing" between line numbers. Something that someone had written in "line 1; line 2; line 3..." fashion could be "opened up," sequence-wise, very quick and easy. (In case you wanted to grab some isolated bit of code from somewhere, off by itself, and cut-and-paste it to movie it, in a sense. Lots of other great stuff it would do, that made life SOOO much more pleasant and fun, when exploring other's Basic code. One of the other utilities, or types of programs that helped a lot, were compilers. Sometimes people thought a program was written in machine code, due to it being a lot faster than pure Basic would have been, to do the same tasks ... but early on, some things were just "compiled". It sounds, though, like you folks may be looking through actual Basic code, though ... and if so, then that interests me a surprising amount. If it's machine code, or compiled Basic or something, then it's a lot less easy to go through and "play with" ... but if it's actually in "real" Basic...? Anyway ... just saying! ... and now that I've chimed in, I'll just say "Carry on, chaps!" ... and will pop right back into Lurk Mode.

Well, at least some organizations appreciate preservation and the like ... organizations such as the Smithsonian!?! http://krqe.com/2014/04/28/smithsonian-wants-unearthed-atari-games/