Background info:

If I ever suspected I'd need to come back to Adventure II's code the way I have, I'd have never compressed and re-coded so many memory-saving schemes into the original 32K 5200 version! One of the things I was proudest of in 5200 Adventure II was that I fit so much into 32K.

As has been stated in the forums many times, the game had to use bank switching for the Atari XE version because the Atari 8bits can't address 32K memory, they instead address in 16K . And you can break up those into varying 4K banks which you load as needed.

So for example, many of the game's screens are stored in the 8K bank from $8000-$9FFF. Other stuff is stored in the next 4K bank $A000-$AFFF. Because XE carts and AtariMax carts use differing bank-switching schemes, Tep392 put in logic to do it both ways when I compile the game.

The Abend

I made a little change last week, something that has long been on my to-do list. I was testing the game's Vast levels, and the game crashed ("Abended") trying to load some screens. Oh No!!!!!!!!

As I tested more, slowly relearning variable and memory addresses that I had forgotten since 2007 , I saw that not only Fire Castle screens, but also some Vast Ice Castle screens were also crashing the game. Oh No!!!!!!!!!

For a few days I was really all thumbs, not being able to understand why my stupid little tweak had caused the problem. But I got busy with work and had to put it aside during the week. Thankfully this worked to my advantage. It's interesting how your brain works - give a problem the day off, and you'll likely come up with a fix tomorrow or the next day.

The Cause of the problem found!

I spent 2 hours this morning using the process of elimination to find clues to the game crashes. I found that there were actually 3 screens that would cause a crash. What did they have in common? And what was different about them compared to all the other (similar) internal castle maps??

After investigating more,and writing down the internal hex numbers for these screens, I spotted the clue that all 3 screens used the same "map" data and were in the same bank! When I looked at the source file for that memory bank, this map screen is at the end of the bank. Clearly it was now corrupted and any attempt to use this screen caused a crash. Then my mind put all the clues together.

Since 2013, I have slightly added changes and fresh details to a few Kingdom1 screens. Then in early December 2015, I made the final Kingdom 1 screen changes, to 4 different screens. These map changes - and not the more recent 'tweak' that I mistakenly thought was the problem - caused the problem. They weren't being compressed quite as efficiently as before, and thus incrementally used more and more bytes. I had pushed a bank over its limit. I had exceeded the 4K memory available from $8000-$BFFF. The only thing affected was the last thing in the bank - that screen map which caused the crashes! It only happened in Vast castle mazes, so I didn't notice it because I usually don't test using the huge Vast variations.

So, every time I visited a certain Fire Castle screen, or one of 2 Ice Castle screens (I change the colors though, so they don't look identical), the program would try to load the glitched map. Every time I tried to load one of those 3 screens, using the compressed include file "Y3.INC" - it crashed the game.

Happy times!

I moved some memory around and solved the problem! Happy Day! Because, I HATE HATE HATE trying to fix bugs! Especially when the game is 99% finished!

And now I leave to go see Star Wars VII: The Force Awakens! Happy Happy , Joy Joy !

(_)3