Back when I was analysing the screen, I was using the STeem Emulator and regularly dumping memory from 0x25500 and 0x260B8, analysing the data in a spreadsheet to learn how the gameboard was represented. Part of the game is to pick up new good spores and drop them on good growth to create a new good portal, whilst stopping evil spores flying off and creating an evil portal when it lands on some evil growth. An experiment I did at the time was to try and add in a new portal into the gameboard by writing the corresponding values into that area of memory whilst debugging. The experiment failed – it wasn’t as simple as that.
Re-reading the Player’s Guide from Amiga Format, there was something that struck me.
10.
All portals produce a limited amount of growth. Once they have done this, they can continue sporing but stop growing. Look out for evil portals which have exhausted their growth capacity; they are far easier to knock out.
There had to be another mechanism for storing the portals, including how much growth was left, that wasn’t just in the gameboard. Something that had to be flexible enough to allow more portals to be added, and some to be removed after they had been covered by growth. After digging around using AiraForce, there are a number of data tables that get referenced. These are the next areas that I am going to try to analyse.
Observing the game running in both the instructions demo and the game have yielded the following possible clues.
| Table Memory Location | Possible role |
| 258E8 | Hold addresses to other parts of memory |
| 25ADC | (not sure yet) |
| 26942 | Portal Locations (as defined in the level data) |
| 26A6E | Portal Type (stores 0000 for evil, 0001 for good) |
| 26B9A | Growth remaining (counts down to zero) |
| 26DF2 | Columns in the gameboard the portals are in |
| 26F1E | Rows in the gameboard the portals are in |
| 339CE | (not sure yet) |
| 33A34 | Seems to be something to do with good portals |
| 348F6 | Seems to be something to do with evil portals |
| 4E83C | (not sure yet) |
This new information has given me a much clearer idea of how the game tracks portals beyond just their positions on the gameboard. My next steps will be to investigate how these tables are updated during gameplay, and what role do the unknown tables like 25ADC, 339CE, and 4E83C play in all of this?
I’ll continue experimenting with memory modifications, but with a more targeted approach now that I have some specific tables to focus on. If I can fully map out how portals are managed, I might even be able to figure out a way to add new ones dynamically—something that my original experiment failed to achieve.
More to come soon!
The Eye Of Infinity 