The Ciphers of Tarmin's Treasures

[The Eyeball Mural]

I haven't found any posts about rolling over or flipping the treasure score counter in "AD&D Treasure of Tarmin" (although I could have missed something in my search) so please forgive me if what I relate here has already been discussed.

In 1986 I began a marathon session of "Treasure of Tarmin" on my Intellivision II and played the game over the course of several days. To "save" my game I would simply leave the console powered on with the game in progress, press "1+9" on the controller keypad to pause the game and blank the screen, then place the console on a shelf behind some books to protect against housecat-induced accidental resets. I'm sure many readers have done something similar. My goal in playing this lengthy session was to roll the treasure score. I played the easiest difficulty level, and after I had acquired the armor and goodies needed I began speedrunning the dungeon levels, harvesting treasures and doing as little else as possible, all to build the score and roll the counter. Lots of "whoosh whoosh whoosh" with the teleport book, as some say.

After rolling the score at 100,000 I was intrigued to see that instead of resetting the counter to zero or adding another digit the Intellivision replaces the first digit of the treasure score (the ten-thousands place) with "ciphers," beginning with punctuation characters. I had earned over 150,000 points when my console was innocently and accidentally reset by a visitor when I was out of the house one day. I never made another attempt, nor tried to discover the extent of (and logic behind) the character substitutions... until now.

Playing on the Nostalgia emulator, with its wonderful save game feature, I've begun probing the depths of the Tarmin dungeon and documenting the treasure score anomalies. Here is what I've learned, plus some basic exposition for those who don't quite know what I'm talking about:

On the castle map screen there appears a treasure score counter. It occupies a six-digit space on the right of the screen, just above the player's attribute scores (this treasure score aligns with the six-digit attribute scores directly beneath it). The counter is blank when no treasure has been collected; that is, no digits are entered on the counter. When digits appear they are black in color, against the tan background of the island silhouette. Since there are no treasures in the game with values in single digits, the minimum number of digits in the treasure score is two. The ones place is scored in the fifth digit in the counter (this number is always zero), with the tens place scored to the left of that in the fourth digit; the hundreds place is scored in the third digit, and the thousands place in the second digit, natch. The ten thousands place is scored in the first digit. The sixth digit (to the right of the ones place) remains empty (blank). This means a nominal maximum treasure score of 99,990. When this score is exceeded, the last four digits of the counter roll over and continue to count upwards, but the first digit changes to a non-numeric character.

To wit:
100000 reads as :0000
110000 reads as ;0000
120000 reads as <0000
130000 reads as =0000
140000 reads as >0000
150000 reads as ?0000
160000 reads as @0000
170000 reads as A0000
180000 reads as B0000

Here are some screenshots showing the rollover, plus a graphic of all the scores as they are displayed.

 

 

 

 

This is as far as I have explored as of this posting, with the game still in progress. At first I thought the ciphers were more-or-less random, but upon the abrupt veering from punctuation to capital alpha characters (which seemed to proceed in alphabetical order) I thought there must be a pattern I didn't understand. I began investigating the available knowledge about the Intellivision character set, but all this seemed to do was enlighten me on what choices the system has in selecting ciphers, and not much insight into how the ciphers might be chosen, until I found the Intellivision Wiki article on the Graphics ROM (GROM). This article includes a table that shows the Intellivision character set ordered in the sequence that the GROM deals with them.

 

 

The table makes it easy to see that the treasure score counter is first cycling up through numerical characters in proper order, then at rollover it begins substituting non-numerical characters in order according to the GROM's library. This realization takes a bit of the fun out of the discovery process henceforth, since the table effectively maps out the future ciphers, but it doesn't tell me everything I'd like to know. I still have these questions:


Q. Why use only five digits (or cards) in the score counter when the other counters below are using six digits / cards?

Q. Why leave the sixth digit blank, and not the first?

Q. Why implement ciphers instead of just rolling back to zero for the ten-thousands place?

Q. What happens when all the characters have been cycled through? Does the process repeat? Do garbage tiles appear? Does the score freeze?

Q. Is this behavior a glitch, an intentional routine, the result of a limitation, or what, exactly? Is it "correctable?"


This is one of those little in-game quirks that many may find unremarkable but which I (and maybe others) find interesting. I suppose any of the skilled programmers or analysts in this community could quickly understand at a glance what the game and the console are doing when these counter substitutions are made, but to me the inner workings of the hardware and the software are a bit exotic and mysterious, and for that reason interesting to me. Understanding simple matters like this makes for a bit of a detective job for the noob I am. I assume that disassembling or decompiling (which is correct?) the code, coupled with some patient analysis, could explain this behavior easily, but I haven't found the application(s) I need to view the code. Is this due to the Blue Sky Rangers putting the chill on access to their IP? (Which is their right, of course.)

At any rate, if anyone can answer these questions, or simply gets a kick out of this stuff like I do, I'm all ears. Maybe these are more questions for Tom Loughry (hint: nurmix, are you there?)

[+Gemintronic]

How far down does this go? I could have sworn me and my cousin made it to the 100th floor.

[The Eyeball Mural]

How far down does this go? I could have sworn me and my cousin made it to the 100th floor.

 

It goes down to level 256, then resets to level 1 and counts "down" to 256 again. Then repeats...the process goes on forever.

 

I'm posting notes on a potential strategy guide in this thread if anyone is interested:

http://atariage.com/forums/topic/223326-ad-d-treasure-of-tarmin-gameplay/

 

[+JasonlikesINTV]

I'll have to check my notes, but I noticed something similar in Mouse Trap. I got to a point where I was earning extra lives faster than I was losing them. My score kept climbing and when I thought it was going to roll over it added another digit, however I was earning so many lives that I rolled the 'extra lives' counter. I believe the same symbols in the same order were used.

 

Edit: Found it!

 

http://atariage.com/forums/topic/218487-the-mouse-trap-high-score-competition-has-started-nov-10-30-2013/?p=2879048

Edited October 31, 2014 by JasonlikesINTV

[The Eyeball Mural]

That is awesome, thanks for sharing that! Maybe it is just the way the Intellivision handles rollovers, or maybe it was a standard procedure for the programmers. That makes two games that display this behavior. There must be others...

[+intvsteve]

That is awesome, thanks for sharing that! Maybe it is just the way the Intellivision handles rollovers, or maybe it was a standard procedure for the programmers. That makes two games that display this behavior. There must be others...

My guesses:

• Laziness and / or hubris : nobody would EVER do so well as to go above this score, so let's not even bother dealing with it
• Space: We'd like to deal with it, but don't have enough room left on the ROM to code for it
• Time: Gotta ship! See the first item in the list

There's really nothing inherent to "handling rollover". The code just does some math to figure out which GROM card to use to display a digit. When it's at the max digit, rather than hopping one more spot over on the screen. Think of it in pseudo-code:

 

Start at the right-most digit

to display the digit, divide the score by 10

display the remainder as character '0' + remainder

if the quotient > 10 and I'm not out of space, then divide by 10 again, go to previous step

if out of digits, just display the "digit" of GROM card '0' + whatever the remainder is

 

this works great until you're out of room for digits - that's when the final statement makes those funny things. So, on an Intellivision, it'll get interesting once you start addressing things outside GROM. I can't recall the memory map as to what exactly that would be, but I bet it's in the wiki.

Edited November 1, 2014 by intvsteve

[The Eyeball Mural]

My guesses:

• Laziness and / or hubris : nobody would EVER do so well as to go above this score, so let's not even bother dealing with it
• Space: We'd like to deal with it, but don't have enough room left on the ROM to code for it
• Time: Gotta ship! See the first item in the list

There's really nothing inherent to "handling rollover". The code just does some math to figure out which GROM card to use to display a digit. When it's at the max digit, rather than hopping one more spot over on the screen. Think of it in pseudo-code:

 

Start at the right-most digit

to display the digit, divide the score by 10

display the remainder as character '0' + remainder

if the quotient > 10 and I'm not out of space, then divide by 10 again, go to previous step

if out of digits, just display the "digit" of GROM card '0' + whatever the remainder is

 

this works great until you're out of room for digits - that's when the final statement makes those funny things. So, on an Intellivision, it'll get interesting once you start addressing things outside GROM. I can't recall the memory map as to what exactly that would be, but I bet it's in the wiki.

 

Very interesting, thanks for the insight! I understand the scoring logic as you explain it. As for why Tarmin doesn't include the sixth digit in the score counter, if I had to select one of your three guesses (and I'm obviously just speculating) I suppose the space consideration might be most likely, given that Tarmin seems to be a rather complex execution. Again, that's just my naive assumption: the code and programming techniques for Tarmin might be simple as heck and I just don't know any better.

[+intvsteve]

I made an error... should be a quotient > 0, not 10. And of course move a spot to the left for the next digit.

Edited November 1, 2014 by intvsteve

[The Eyeball Mural]

I made an error... should be a quotient > 0, not 10. And of course move a spot to the left for the next digit.

 

I thought that's what you meant... the quotient will be either zero or non-zero, correct? If zero, then stop; if non-zero, then repeat previous. Right?

[+intvsteve]

 

I thought that's what you meant... the quotient will be either zero or non-zero, correct? If zero, then stop; if non-zero, then repeat previous. Right?

Yep

[intvnut]

As I recall from when I looked into it last, the EXEC number printing routine only works up until 9999. If the last digit of the score is always 0, then internally the game would store scores divided by 10. (ie. a score of 5000 is stored as 500.)

 

The EXEC number printing routine works basicallly like this (expanding on the pseudo/code above):

1. Set digit = 0; While number > 1000, subtract 1000 from number and add 1 to digit. Print first digit.
2. Set digit = 0; While number > 100, subtract 100 from number and add 1 to digit. Print next digit.
3. Set digit = 0; While number > 10, subtract 10 from number and add 1 to digit. Print next digit.
4. Set digit = 0; While number > 1, subtract 1 from number and add 1 to digit. Print last digit.

If the original number is > 9999, then that first loop iterates 10 or more times, and you end up with digit = 10, 11 or higher. When you add that to the ASCII code for '0', you eventually edge into the punctuation and alphabetic characters as per the table above. If the original number is > 32767, the routine treats it as negative, which leads to its own fun. It'll start at -32768 and count back toward 0. 65535 shows up as -1.

 

(BTW, I believe you can also ask the EXEC to display a narrower than 4 digit number, in which case it starts at the appropriate power of 10 and rolls over sooner. For example, 3 digits rolls over at 999.)

 

Note that it starts at the top and works its way down, rather than at the bottom working its way up. This is the opposite direction of the pseudo code intvsteve proposed above.

 

At one point, I investigated how different games stored their scores internally. Games that allowed scores above 9999 sometimes stored them as two or more numbers with 4 or fewer digits so they could use the EXEC's 4-digit number-printing routine as-is. The Astrosmash rollover bug is basically the same bug as Tarmin's, only on the upper 3 digits.

Edited November 1, 2014 by intvnut

[The Eyeball Mural]

As I recall from when I looked into it last, the EXEC number printing routine only works up until 9999. If the last digit of the score is always 0, then internally the game would store scores divided by 10. (ie. a score of 5000 is stored as 500.)

 

The EXEC number printing routine works basicallly like this (expanding on the pseudo/code above):

1. Set digit = 0; While number > 1000, subtract 1000 from number and add 1 to digit. Print first digit.
2. Set digit = 0; While number > 100, subtract 100 from number and add 1 to digit. Print next digit.
3. Set digit = 0; While number > 10, subtract 10 from number and add 1 to digit. Print next digit.
4. Set digit = 0; While number > 1, subtract 1 from number and add 1 to digit. Print last digit.

If the original number is > 9999, then that first loop iterates 10 or more times, and you end up with digit = 10, 11 or higher. When you add that to the ASCII code for '0', you eventually edge into the punctuation and alphabetic characters as per the table above. If the original number is > 32767, the routine treats it as negative, which leads to its own fun. It'll start at -32768 and count back toward 0. 65535 shows up as -1.

 

(BTW, I believe you can also ask the EXEC to display a narrower than 4 digit number, in which case it starts at the appropriate power of 10 and rolls over sooner. For example, 3 digits rolls over at 999.)

 

Note that it starts at the top and works its way down, rather than at the bottom working its way up. This is the opposite direction of the pseudo code intvsteve proposed above.

 

At one point, I investigated how different games stored their scores internally. Games that allowed scores above 9999 sometimes stored them as two or more numbers with 4 or fewer digits so they could use the EXEC's 4-digit number-printing routine as-is. The Astrosmash rollover bug is basically the same bug as Tarmin's, only on the upper 3 digits.

 

Fascinating, thanks for the knowledge! If I understand correctly, this explains why Tarmin doesn't simply use a sixth digit to match the other counters on screen (or add one at rollover). It could be done, but the new last digit would also have to be zero, which wouldn't solve anything and would only create new issues with the display of the score (since there are several treasures in the game with two-digit values).

 

So, the game is basically displaying a standard four-digit score with a zero added to the end. Adding digits to a score basically results in ever-greater loss of numerical resolution (since all you can do is keep adding zeroes) and also creates these character display anomalies. A workaround is to use strings of numbers in which each number has four or fewer digits. Do I have it right?

 

Then, this must mean that the attribute scores (player strength or "hit points" | armor | weapon strength) are not six digit elements, but use three digits for the war score, one digit for the slash, and two digits for the spiritual score... spread across six consecutive cards.

[intvnut]

 

Fascinating, thanks for the knowledge! If I understand correctly, this explains why Tarmin doesn't simply use a sixth digit to match the other counters on screen (or add one at rollover). It could be done, but the new last digit would also have to be zero, which wouldn't solve anything and would only create new issues with the display of the score (since there are several treasures in the game with two-digit values).

 

So, the game is basically displaying a standard four-digit score with a zero added to the end. Adding digits to a score basically results in ever-greater loss of numerical resolution (since all you can do is keep adding zeroes) and also creates these character display anomalies. A workaround is to use strings of numbers in which each number has four or fewer digits. Do I have it right?

 

Then, this must mean that the attribute scores (player strength or "hit points" | armor | weapon strength) are not six digit elements, but use three digits for the war score, one digit for the slash, and two digits for the spiritual score... spread across six consecutive cards.

 

I think you more or less have it. You can add a bunch of extra zeros at the end, but you can't have more than 4 non-zero digits at the top without adding another variable in RAM for those digits. For the stats at the right, those are definitely discrete numbers separated by slashes.

 

BTW, fun fact: Treasure of Tarmin uses so much RAM that it actually uses some of the BACKTAB for storage. Tarmin tells the STIC to hide the top row of cards on the screen, and then uses those 20 locations for data. For a fun time, do the following in jzintv:

• Fire up Treasure of Tarmin in the jzintv's debugger. For me, that's something like this: jzintv -d adndtot
• Disable the border extension by typing "p500D 0" and hit enter.
• Run the game by typing "r" and hit enter.

Now you'll see an extra row of "stuff" across the top that changes as you play the game. :-) It appears to be related to what's in front of you in each column of the wall, roughly distance information, or whether there's a door.

 

Edited November 1, 2014 by intvnut

[The Eyeball Mural]

 

BTW, fun fact: Treasure of Tarmin uses so much RAM that it actually uses some of the BACKTAB for storage. Tarmin tells the STIC to hide the top row of cards on the screen, and then uses those 20 locations for data. For a fun time, do the following in jzintv:

• Fire up Treasure of Tarmin in the jzintv's debugger. For me, that's something like this: jzintv -d adndtot
• Disable the border extension by typing "p500D 0" and hit enter.
• Run the game by typing "r" and hit enter.

Now you'll see an extra row of "stuff" across the top that changes as you play the game. :-) It appears to be related to what's in front of you in each column of the wall, roughly distance information, or whether there's a door.

 

Fantastic! I've never been sure if Treasure of Tarmin was resource-intensive or not. On the one hand, there is lots of stuff to keep track of, but on the other hand everything is turn-based, and there is little on-screen movement. Now I'm even more interested in getting at the nuts and bolts of this game. I never would have imagined there was stuff hidden on screen like that! I have to see that for myself!

 

I've used Nostalgia instead of jzintv because it seemed more user friendly. I didn't know jzintv had a debugger, My understanding is that it used to have a disassembler or decompiler but doesn't anymore. Wouldn't the debugger be the same as a dissasembler, or does the debugger incorporate a disassembler? Or am I wrong?

 

I appreciate the responses and the patience. This is all compsci 101 stuff, I suppose... the more I learn, the less I know, as the saying goes.

[The Eyeball Mural]

The technical overview at intellivisionlives.com is also helping me understand these explanations.

[intvnut]

 

Fantastic! I've never been sure if Treasure of Tarmin was resource-intensive or not. On the one hand, there is lots of stuff to keep track of, but on the other hand everything is turn-based, and there is little on-screen movement. Now I'm even more interested in getting at the nuts and bolts of this game.

 

Just be forewarned, to use jzIntv's debugger, you need to be somewhat comfortable with the command line. jzIntv's debugger is actually inspired by debug monitors I experienced on the Apple ][ and MS-DOS's debug.exe. It's bare bones, low level, but very effective if you know what you're doing.

 

For this, you could also avoid the debugger by using a .BIN version of Treasure of Tarmin (or Minotaur, if you got it off of Intellivision Lives!), and add this to the .CFG file:

.

[macro]
@p500D 0

.

In jzIntv, at least, that will do the same as the debugger sequence I gave above. I don't know if Nostalgia interprets the [macro] section, but if I had to guess, it probably doesn't.

 

 

 

I never would have imagined there was stuff hidden on screen like that! I have to see that for myself!

 

Me neither! The only reason I discovered it was that early versions of jzIntv didn't implement the STIC controls for hiding the top row or left column of the screen. Those controls are normally used by games that use the STIC's hardware scrolling capabilities.

 

When I saw "garbage" at the top of the screen in Tarmin, I thought jzIntv had a bug. Then I discovered that it wasn't a bug at all—rather, Tarmin had asked the STIC to cover up the top row of the screen and stored data there. Once my STIC emulation was complete, the "garbage" disappeared.

 

 

 

I've used Nostalgia instead of jzintv because it seemed more user friendly. I didn't know jzintv had a debugger, My understanding is that it used to have a disassembler or decompiler but doesn't anymore. Wouldn't the debugger be the same as a dissasembler, or does the debugger incorporate a disassembler? Or am I wrong?

 

jzIntv's debugger includes a disassembler, so it can show you the code in ROM. But the two concepts (debugger and disassembler) are different. A straight-up disassembler just turns a .ROM into a .ASM file that may or may not be re-assemble-able into a working game. (I believe tacrec has experienced first hand that my disassemblers don't guarantee a round trip from ROM -> ASM -> ROM.) The jzIntv / SDK-1600 tool kit actually includes two standalone disassemblers—Frank Palazzolo's dasm1600, and my own dis1600—along with the disassembler built into jzIntv's debugger. (The debugger's disassembler is based off of Frank's dasm1600.)

 

The debugger offers all sorts of other features, such as setting breakpoints, watching reads and/or writes to various memory locations, modifying memory (RAM and ROM), modifying registers, collecting profile information, and so on. More recent versions of jzIntv's debugger can read symbol table information and source-map information from AS1600, providing a source-level debugging experience, at least for assembly source code. Maybe at some point down the line we can work in IntyBASIC source-level debugging somehow.

 

 

I appreciate the responses and the patience. This is all compsci 101 stuff, I suppose... the more I learn, the less I know, as the saying goes.

 

I'm always happy to share what I can.

[freewheel]

Those of us writing games run into these sorts of "ciphers" all day long Sometimes you get stupid, but a mostly it's just never expecting a player to make it that far in a game. I can tell you that from experience, I'm amazed there aren't more bugs in 8-bit games. These things were rushed out the door so often, and usually only had a small handful of people playing/testing them. All sorts of bad assumptions could have been made.

 

Score/lives/level overflows have a long and fascinating history. Probably the most famous is the Pac-Man (arcade) death screen at 256. It only uses a single 8-bit value to store the level, and once you overflow that - interesting things happen.

 

I've often toyed with the idea of running an emulator/debugger and messing with various values, and seeing what happens. ie: start the score very close to overflow and play for a bit.

[The Eyeball Mural]

Those of us writing games run into these sorts of "ciphers" all day long Sometimes you get stupid, but a mostly it's just never expecting a player to make it that far in a game. I can tell you that from experience, I'm amazed there aren't more bugs in 8-bit games. These things were rushed out the door so often, and usually only had a small handful of people playing/testing them. All sorts of bad assumptions could have been made.

 

Score/lives/level overflows have a long and fascinating history. Probably the most famous is the Pac-Man (arcade) death screen at 256. It only uses a single 8-bit value to store the level, and once you overflow that - interesting things happen.

 

I've often toyed with the idea of running an emulator/debugger and messing with various values, and seeing what happens. ie: start the score very close to overflow and play for a bit.

 

Well, the ideas about time constraints and about not expecting players to reach certain thresholds echoes what intvsteve said above To lean on the old saying, I suppose great game code is never finished, merely abandoned!

 

When I was a young gamer in the 1980's my friends and I were motivated to reach high scores in order to see how the game's counter or screen would react as much as we were motivated by competitiveness or a sense of achievement. It was sort of like tilting a pinball machine, except instead of the game warning you to stop playing rough it was symbolic of beating the computer at its own game, leaving it in a state of "does not compute," spouting gibberish. Even being a non-programmer (though most of my buddies wrote code) I could still grasp the basic idea behind such a glitch i.e. the game has moved into uncharted territory and is behaving oddly or even unpredictably.

 

My fascination with this stuff in Treasure of Tarmin has a different root, though. Since the game is about exploration and discovery, and has an eerie or spooky feel to it, anytime I find something odd it adds to my enjoyment of the game. The quirks (like the score counter ciphers, or the flicker of the item sprites when they render, or intvnut's discovery of the location data hidden onscreen) are not necessarily unique to this one game, but they seem to fit right in with the game's RPG-like theme of prowling an enchanted dungeon. The score counter going "crazy" I can imagine as the gods' warning against greed, as if too much wealth will twist your treasures into something unrecognizable and useless. The glitchy rendering of the item sprites as they sit on the floor makes me think that as the adventurer prowls the dungeon he may suffer effects from all the magic about, and begin to hallucinate and see things not as they are; or the visions can be divinatory, helping the player find the items he needs, as if spirits are coming to his aid. The location data revealed is something like entering the Matrix and seeing more reality than normally meets the eye.

 

Of course, all this is just my imagination running free, while behind all this is, as you say, a frazzled programmer struggling to meet an unreasonable deadline!

[The Eyeball Mural]

 

BTW, fun fact: Treasure of Tarmin uses so much RAM that it actually uses some of the BACKTAB for storage. Tarmin tells the STIC to hide the top row of cards on the screen, and then uses those 20 locations for data.

 

 

I've often toyed with the idea of running an emulator/debugger and messing with various values, and seeing what happens. ie: start the score very close to overflow and play for a bit.

 

 

I guess this is the way to go if I want to explore these spurious character displays further. Load whatever game I'm exploring into a debugger, learn my way around the code and start hacking or experimenting. Both of the above ideas seem like good places to start. Any sort of overflow is a candidate for causing display anomalies, right? And any game that uses the BACKTAB for other than the intended purposes will likely have data hidden somewhere on the game screen, since the BACKTAB's purpose is to handle the background (or playfield) display. A reasonable assumption?

[freewheel]

Any sort of overflow is a candidate for causing display anomalies, right? And any game that uses the BACKTAB for other than the intended purposes will likely have data hidden somewhere on the game screen, since the BACKTAB's purpose is to handle the background (or playfield) display. A reasonable assumption?

 

In a nutshell, yes. Try overflowing any variable, not just ones that display on the screen. It's amazing what can happen if code does not do proper bounds checking (this, incidentally, is also the first step towards learning how to "crack" computer security at an application level).

 

BTW, you've given me an idea for one HELL of a complex INTV game. The limited graphics on the system sometimes make abstract concepts a bit hard to display - or hell, you have no choice BUT to think rather abstractly - but an intentionally "glitchy" game is something that would work very well in this environment.

[The Eyeball Mural]

BTW, you've given me an idea for one HELL of a complex INTV game. The limited graphics on the system sometimes make abstract concepts a bit hard to display - or hell, you have no choice BUT to think rather abstractly - but an intentionally "glitchy" game is something that would work very well in this environment.

 

This sounds intriguing, and fun. I'm not sure what exactly you have in mind, but I'll bet the underlying logic of the gameplay would be understandable by the player, even if it made for a different sort of challenge. At first it would seem random, but there would patterns and clues to recognize nonetheless.

[daeos]

Hey guys, I'm not much of one to be a Thread Necro, but I found this thread while searching for AD&D ToT source code. I used to play this game for days on end. One summer I spent a whole day to cycle through the levels. I still play this game on my phone and have my console nicely packed up safe and sound. Not sure if any of you are into meeting any of the developers, but you can find one of them at North West Vista College in San Antonio, Texas.

In my time spent playing the game I had discovered a way to cheat in the game, event posted it up on IGN a long time ago. Run out of arrows and using a strength book, let a monster beat you up. Kill it with a 1 use weapon or magic weapon. Once you rest, you will have obtained several points in strength. Sure saves on running around killing 1 monster at time.

If any of you are aware if the source has been made public domain, I sure would appreciate a pm.