Willow Hack - Almost There

The main part of this hack - setting aside some SRAM to save to and load from, the actual routines for accomplishing this, and the basic interface to select from 3 slots where to save or load - is complete.

I still need to write a routine that displays Willow's stats for each save game, and do something better than SELECT+B in order to access the save menu. There is also a bug where the background music isn't restored after leaving the save menu.

I also did a few kludges to make things work, such as shamelessly copy/pasting some code from other parts of the code without knowing exactly what the function calls did. Seems to work fine though.

I also need to check if I've overwritten any code that shouldn't be. Fortunately (I noticed) the assembler does export symbols from the source. This means that any labels I've used in the source code are noted down along with their memory locations in the ROM. By placing labels at the end of functions and data tables, I can compare with the original disassembly and find out if I've overrun any code.

I also noticed and rooted out a little bug where the stack head kept moving up after selecting continue. Turns out the original code forced a stack reset which I failed to include (yes, copy/paste). Although there seemed to be no ill effects right off, it might have caused problems after the player continued 20 or so times.

However aside from the savegame text and a few bugs, there are a few things I want to add before I call this patch finished and release it into the world.

I want to add the name of the area into the save game, just so the player knows more-or-less where he left off, and a percent complete value would be nice. I suppose the calculation for percent completed would be computed from the items Willow has acquired. Then there's a minor hack to the saver/loader routines which should use a checksum to verify if the savegame is valid or corrupt.

One last thing, I'd like to add my name into the credits on the PRESS START screen, but the data is tightly packed with no free memory right after it, so my last hack will entail either moving that bit of data into some place more agreeable, or add and extend the "string" writing code to allow jumping to another location in memory. Right now I've just shamelessly replaced the TM & © "LUCASFILM" with "ENDERSOFT".

For now, here's what the selection screen will look like. The data is actually a mock-up - no values are read from SRAM - but the screen is actually running off the emulator (i.e. no Photoshop tricks)

Willow Hack News

I'm in the middle of unraveling the code to draw the backgrounds used for the START and PASSWORD screens.

Interestingly, it uses the same routines for drawing the in-game backgrounds. This is the background you see when walking through the game as Willow.

Now this routine uses two variables to specify what background is loaded to be scrolled into the screen while Willow walks to the edge of the visible screen.

• Each variable seems to change independent of each other
• One variable changes if Willow walks out the top/bottom of the screen, I designate this as mapY.
• The other variable changes if Willow walks out left/right of the screen, I designate this as mapX.
• The variables don't seem to be a direct index, as useful values seem to be in the 1A-1F range.

The "coordinates" for the START screen is (1A,1E). I'm not sure where the password screen is stored yet. When switching to the password screen, no backgrounds are drawn (i.e. the code for drawing backgrounds is not called). Instead, the code merely switches the active nametable implying that the password screen is already drawn into memory.

So far I've determined that these values decode into a memory address where the code picks up another byte that decodes into another address, which is where the char which will be copied to the nametable is stored. I still haven't fully decoded the routine, but it's another step towards finalization.

I think it uses some form of compression in order to save space, as the routine seems to read from certain locations multiple times, instead of simple packed data. It is probably RLE, which would be ideal given the repetative nature of the backgrounds.

Meanwhile, I think I should focus on what can be done, which is implementing the load/save screens - sans backgrounds - and adding support for multiple saves.

I just feel so close to understanding how it works that I don't want to let it by.

Willow Hack PoC complete!

My Proof-of-concept hack is done, and I now have a Willow ROM that allows saving current progress by pressing SELECT-B and resuming the saved game by selecting PASS WORD in the opening screen or CONTINUE after losing all your HP.

So far the hack works well on FCEUltra. I tried on NesterJ for the PSP but it crashed every time I tried to save my progress. Maybe it doesn't have support for battery backed RAM?

On a side note I called in sick, because I'm feeling really lousy, but apparently not enough to stop me from sitting in front of my PC for 6 hours straight.

Right now I'd like to change the intro screen text to "CONTINUE" instead of "PASS WORD", but I really should be getting some rest.

Once I figure out how the screens are set up and how text is drawn I'd like to put int a real save game selection screen, with allowance for 3 save games, showing info about each save game.

UPDATE: Just tested it on NesterJ version 1.20 beta, and it works perfectly! The version that the hack wasn't working with was 1.1 RM.

Download the patch and source here

Willow Hack News

I'm using a cross assembler for the SNES, but since the 65816 processor mostly extends the 6502, getting it to work for this project was easy.

Well, mostly.

I spent most of the morning trying to get the assembler to produce a valid IPS file, but I'm glad I did.

The samples I downloaded for compiling SNES patches from asm files had scripts for checking addresses when creating patch files.

I was getting symbol not found errors when trying to subtract a hex address from a variable, but had no problems adding (or any other operation, I suppose).

The error went away when I decided to use base 10 to represent the value I was trying to subtract.

So, instead of



@STEP2 = @STEP1 - $C000


It was



@STEP2 = @STEP1 - 49152


I decided to hijack the password routine and copy a bit of code from the "new game" routine. For now I just loaded up the SRAM with some default values.

It almost worked.

I had a black screen with Willow in it. Switching to inventory and back brought the screen colors to life but the palette seems messed up, though I think I have some idea of how to fix this.

With the code analysis practically complete and most critical variables identified, I can now focus on writing code. The assembler/patcher toolchain makes things much easier as all I have to do is edit the assembly code and re-run my compiler script.

Already I'm halfway to my goal of a Proof-of-concept hack, with a full hack not too far off.

Although state-saves have all but made this hack useless, it's been a fun ride. Maybe I'll put a little how-to together, for the sake of posterity.

Useless Hacks Update

I have managed to isolate most of the code that takes up the password entry, testing and stats loading for the NES game Willow. I've also identified where stats are saved in memory, how Willow's map and screen position is stored, and the all-important events and inventory flags.

Coding a replacement function that will load data from SRAM should be pretty easy, and free up a lot of ROM space in the process.

I have yet to figure out how the screens are loaded, so I can load my own custom save game screen, but that's not really part of the Proof of Concept hack.

Just to make things interesting I'll change the PASS WORD text into LOAD GAME.

That's the easy part.

Saving for my PoC requires me to tap into the main game joystick routine and save everything to RAM once a combinaion (SELECT+B) is pressed. However in a real hack it'd be nice to have save points.

Adding code to a NES ROM is a bit more problematic because of it's memory restrictions and the memory mappers designed to handle this.

You can't just add code to another bank if the original bank doesn't have any space to give up. Since only one bank is mapped at any time, you'd have to push some registers or save in RAM and switch banks to run code from another bank.

I hope to do the loading code tomorrow, that is, if Patapon doesn't distract me long enough.

NES Hacks: Coin Tricks

Here in the Philippines, we had the Japanese version of the Nintendo console, known as the Family Computer (aka Famicon), instead of the dull-grey clunky unit with excessively large cartridges known as the Nintendo Entertainment System.

The Famicon design featured joysticks that were permanently connected to the console and had a port at the front which was used for the optional light gun. This port was usually covered by a red plastic cap when not in use.

There was something mysterious about that port. It has little pins in it, and wat I remember is that my uncles and cousins would take a 10 centavo coin and run it across the ports pins with Contra plugged into the game slot and the unit turned on. After a few tries they would get a level select screen.

It's a wonder how anybody figured out how to do this trick, let alone that it worked at all. The regular way to do this utilizes a variation of the Konami Code.

It would be real nice if someone could come up with a solid explanation of why it works. Unless someone already has, and I haven't found the right keywords to google it.