TenPinSolitaire
(hex table mostly done) |
(minor update) |
||
Line 19: | Line 19: | ||
Notes |
Notes |
||
− | * Many values seem to be stored in 16bit segments - given the PalmIIIxe that I have runs on a 16bit dragonball CPU, this makes sense. Word. :) |
+ | * Many values seem to be stored in 16bit segments - given the [PalmPilot|Palm IIIxe] that I have runs on a 16bit dragonball CPU, this makes sense. Word. :) |
+ | * The memory dump given in the example below is of a completed game as follows: |
||
+ | ''todo'' |
||
Bytes 00-19 - 10 words containing 1bit toggles of the visibility of the 10 pins |
Bytes 00-19 - 10 words containing 1bit toggles of the visibility of the 10 pins |
Revision as of 16:24, 20 December 2003
My PalmPilot has this nifty and addictive game called TenPin Solitaire.
It runs like this: you are presented with:
- 10 pins, with numbers 0-9 on them.
- 10 cards numbered 0-9, in three stacks (with 5, 3 and 2 cards in the stacks).
On your first 'bowl', you get the 10 cards. The aim is to select pins (up to three, must be adjacent, may not select from back row on the first selection set) that add up to a card value (mod 10: so 7+7 = 14 = select card 4). The selected pins and card vanish. Repeat. For the second bowl, the top card on each stack is removed, revealing (hopefully) new values beneath to continue.
The pin and card values appear to be chosen randomly. There is no guarantee made that a strike or spare is possible every turn.
Now, being the happy little hacker wannabe that I am, I found recently that I have a hex editor on my pilot - and of course, the TenPin db is a nice little 240byte memory dump of the current game state and highscore table.
Now if we assume that the aim of the game is to get the highest possible score, then is the method really relevant? *grins*
Anyways, here is my analysis of the memory dump...
Notes
- Many values seem to be stored in 16bit segments - given the [PalmPilot|Palm IIIxe] that I have runs on a 16bit dragonball CPU, this makes sense. Word. :)
- The memory dump given in the example below is of a completed game as follows:
todo
Bytes 00-19 - 10 words containing 1bit toggles of the visibility of the 10 pins
000: 00 01 00 01 00 01 00 01 008: 00 01 00 01 00 01 00 01 016: 00 01 00 01
Bytes 20-39 - 10 words containing the values on pins - left to right, back row first
00 00 00 00 024: 00 00 00 00 00 00 00 00 032: 00 00 00 00 00 00 00 00
Bytes 40-59 - 10 words containing the values on cards - back to front, left row first
040: 00 00 00 00 00 00 00 00 048: 00 00 00 00 00 00 00 00 056: 00 00 00 00
Bytes 60-65 - 3 words containing the count of cards on each of the three stacks of cards
00 00 00 00 064: 00 00
Bytes 66-83 - unknown, though I have some guesses
00 00 00 00 00 00 072: 00 00 00 00 00 00 00 00 080: 00 00 00 00
Bytes 84-155 - 3 words containing frame information, repeated 12(why?) times.
First word - pins struck on first ball Second word - pins struck on second ball Third word - score added on this frame 00 00 00 00 088: 00 00 00 00 00 00 00 00 096: 00 00 00 00 00 00 00 00 104: 00 00 00 00 00 00 00 00 112: 00 00 00 00 00 00 00 00 120: 00 00 00 00 00 00 00 00 128: 00 00 00 00 00 00 00 00 136: 00 00 00 00 00 00 00 00 144: 00 00 00 00 00 00 00 00 152: 00 00 00 00
Bytes 156-215 - High score table - names: 10 bytes for names, 6 fields
00 00 00 00 160: 00 00 00 00 00 00 00 00 168: 00 00 00 00 00 00 00 00 176: 00 00 00 00 00 00 00 00 184: 00 00 00 00 00 00 00 00 192: 00 00 00 00 00 00 00 00 200: 00 00 00 00 00 00 00 00 208: 00 00 00 00 00 00 00 00
Bytes 216-239 - High score table - scores: 4bytes for score value, 6 fields.
216: 00 00 00 00 00 00 00 00 224: 00 00 00 00 00 00 00 00 232: 00 00 00 00 00 00 00 00
Links:
- TenPin Solitaire
- FileZ (hex editor)