1

ROM Hacking Discussion / Zelda 1 Bank Swapping?

« on: February 06, 2022, 09:23:15 pm »

So far I've managed to keep my hacks confined to the free space in whatever bank is being hacked so I haven't had to use any bank swapping. At this point I've largely filled up bank 5 of the Legend of Zelda but I could use more data space, possibly in bank 6. The problem seems to be that the relevant code to process that data is already in bank 5 and bank swapping doesn't really help unless I duplicate that code.

Here's my understanding, please correct as needed.

1) Bank 7 is the fixed bank and is always available in memory at C000-FFFF.
2) A bank swap makes the given bank available at 8000-BFFF.
3) Bank swapping is generally only used from the fixed bank.
4) Code and the data which it references are usually in the same bank (or in the fixed bank); e.g. bank 5 cannot access data from bank 6 unless that data is written somewhere to system RAM at 0000-1FFF.

I noticed something confusing in the Zelda code which makes me question my assumptions:

1) Why do banks 0, 1, 2, 5, and 6 all duplicate a portion of code that's already in bank 7 * (ISR reset, MMC1 control, and the bank swap routine)? I notice that they're always loaded into the same RAM location so the code can always be called reliably, but why not call the code in the fixed bank instead?
2) Why does said code perform a bank swap to bank 7? Does this result in the same code/data both in 8000-BFFF and C000-FFFF?

Code: [Select]

1FF90: A9 07 LDA #$07 ; A = 07
1FF92: 20 ACFF JSR $FFAC ; Switch to Bank A (7)3) Can the duplicate code in those banks be removed and the relevant calls be redirected to bank 7 instead?
4) Do banks beside the fixed bank typically use bank swapping?

* Duplicated code in banks 0, 1, 5, 6 and 7 (ROM locations 3F50, 7F50, 17F50, 1BF50, and 1FF50):

Code: [Select]

1FF50: 78 SEI
1FF51: D8 CLD
1FF52: A9 00 LDA #$00 ; A = 00
1FF54: 8D 0020 STA $2000
1FF57: A2 FF LDX #$FF ; X = FF
1FF59: 9A TXS

1FF5A: AD 0220 LDA $2002
1FF5D: 29 80 AND #$80 ; keep bits x... ....
1FF5F: F0 F9 BEQ $1FF5A

1FF61: AD 0220 LDA $2002
1FF64: 29 80 AND #$80 ; keep bits x... ....
1FF66: F0 F9 BEQ $1FF61

1FF68: 09 FF ORA #$FF ; set  bits xxxx xxxx
1FF6A: 8D 0080 STA $8000
1FF6D: 8D 00A0 STA $A000
1FF70: 8D 00C0 STA $C000
1FF73: 8D 00E0 STA $E000

1FF76: A9 0F LDA #$0F ; A = 0F
1FF78: 20 98FF JSR $FF98

1FF7B: A9 00 LDA #$00 ; A = 00
1FF7D: 8D 00A0 STA $A000
1FF80: 4A LSR
1FF81: 8D 00A0 STA $A000
1FF84: 4A LSR
1FF85: 8D 00A0 STA $A000
1FF88: 4A LSR
1FF89: 8D 00A0 STA $A000
1FF8C: 4A LSR
1FF8D: 8D 00A0 STA $A000

1FF90: A9 07 LDA #$07 ; A = 07
1FF92: 20 ACFF JSR $FFAC ; Switch to Bank A (7)

1FF95: 4C 40E4 JMP $E440

----

1FF98: 8D 0080 STA $8000
1FF9B: 4A LSR
1FF9C: 8D 0080 STA $8000
1FF9F: 4A LSR
1FFA0: 8D 0080 STA $8000
1FFA3: 4A LSR
1FFA4: 8D 0080 STA $8000
1FFA7: 4A LSR
1FFA8: 8D 0080 STA $8000

1FFAB: 60 RTS

----

Bank Switch (Switch to Bank A)

1FFAC: 8D 00E0 STA $E000
1FFAF: 4A LSR
1FFB0: 8D 00E0 STA $E000
1FFB3: 4A LSR
1FFB4: 8D 00E0 STA $E000
1FFB7: 4A LSR
1FFB8: 8D 00E0 STA $E000
1FFBB: 4A LSR
1FFBC: 8D 00E0 STA $E000

1FFBF: 60 RTS

2

ROM Hacking Discussion / Zelda 1 Bank 7

« on: January 17, 2022, 08:48:37 pm »

I was toying around with the idea of moving sounds around and ran across a note somewhere that DPCM sounds have to reside in the fixed bank. That got me thinking of how little space is available in bank 7 of The Legend of Zelda and that there must be a way to free up some space by modifying the sounds. That led me to the following notes in Trax's disassembly:

Code: [Select]

Related to Sound Effects that use the DMC (Sword, Link Hurt...)

1BEE: 00 4C 80 1D 20 28 4C Table for Sample Address (7 bytes)
1BF5: 75 C0 40 0A B0 90 D0 Table for Sample Length (7 bytes)
1BFC: 0F 0F 0D 0F 0E 0F 0E Table for Sample Frequency Index (7 bytes)
Looks simple enough so I did a little sleuthing and found the following calculations:

Code: [Select]

Address is calculated by: $C000 + x * $40 (+$10000 for ROM location)
Sample Length is calculated by: $10 * x + 1
That allowed me to flesh out the following table:

Code: [Select]

Sound Name   | Address Range | Length
--------------------------------------
Flying Sword | 1C000-1C750   | 751
Boss Hurt    | 1D300-1DF00   | C01
Dungeon Door | 1E000-1E400   | 401
Link Hurt    | 1C740-1C7E0   | A1
Boss Sound 1 | 1C800-1D300   | B01
Boss Sound 2 | 1CA00-1D300   | 901
Boss Sound 3 | 1D300-1DFFF   | D01
Now the first thing to note is that 1C7E1-1C7FF is actually unused even though there's data there. I verified that the sounds remain unaffected by blanking out that space. That's $1F (31 bytes) of unused space for free!

Now imho the boss sounds are not really that critical of a feature. At the very least we don't need three different sounds. Boss Sound 3 is the largest and also the strangest so why not reclaim that space for better use? One catch, if you look carefully Boss Hurt is using the same sound, just a smaller portion at a slightly different frequency. No matter, let's just point both of them to one of the other sounds and then modify the frequency of them all so they all still sound a little different.

Here's the modified table with the data for Boss Sound 3 no longer referenced:

Code: [Select]

1BEE: 00 20 80 1D 20 28 20
1BF5: 75 90 40 0A B0 90 B0
1BFC: 0F 0D 0D 0F 0C 0F 0E
Boom, that frees up $D01 bytes of data in the fixed bank for better use! (That's 3,329 bytes from 1D300-1DFFF.)

3

ROM Hacking Discussion / Legend of Zelda Bombable Armos

« on: July 16, 2021, 11:09:35 pm »

The Legend of Zelda (nes) contains code for a bombable Armos which mostly works. The only problem is that bombing the Armos reveals a cave entrance instead of stairs. After you exit the cave or re-enter the screen there are stairs in the location as expected.

I debugged for a while and located the code which writes the cave tiles. Changing the value at $10F09 (headered) to $70 will change the behavior as desired for the Armos but the problem is that this changes the tiles for bombable walls as well.

I was unable to locate anything in RAM that would allow a bit of logic to determine which tiles should be written: cave or stairs. One possibility is that the logic would be based on the tile code that is being replaced.

Anyone have the hacking chops to dig into this more?

An easy way to test this is to change $15E39 (headered) to $2B and $18611 to $00 which will add the bombable Armos to the starting screen and put some bombs in the starting cave.

Code: [Select]

-015e30  45 c5 4e 4e 4e 0e 45 db 5b 34 4e 4e 1a 1b db 5b
+015e30  45 c5 4e 4e 4e 0e 45 db 5b 2b 4e 4e 1a 1b db 5b
-018610  3f 01 7f 20 3f 5a 7f 02 7f 7f 03 7f 3f 3f 3f 3f
+018610  3f 00 7f 20 3f 5a 7f 02 7f 7f 03 7f 3f 3f 3f 3f

4

Personal Projects / Zelda 1 Map Generator

« on: October 03, 2020, 10:42:41 pm »

During the development of Zelda A New Light I needed a way to explore the column combos that are used to build screens. There's not a lot of information available about this part of the game, but there's just enough to get started (see 1, 2, 3, 4). Even then, there's no easy way to tell what combos are used in what screens and where the game code needs to be edited once you find what you're looking for. I originally wrote this as a command line tool to fill the gap and thought it would be interesting to integrate a GUI to make it more interesting. It is a browser based tool written in Javascript and HTML so it's easily hackable. This is primarily a development tool but it can also be used by players to generate a map of their favorite Zelda 1 hack.

Download it. Here are a few screenshots:

5

ROM Hacking Discussion / Zelda 1 level text

« on: September 19, 2020, 06:41:40 pm »

I'd like to change the text in the dungeons from "Level-1" to "Dungeon-1". In addition to the text change, the text also has to move over to the left one space so it fits well. This is probably an easy change for someone that knows what they're doing. I'm not having much luck.

6

ROM Hacking Discussion / Zelda 1 pushable rock palette

« on: September 19, 2020, 06:03:23 pm »

In Zelda 1 pushable rocks take on a different palette when they are being pushed. I'd like to remove that palette change altogether or at least use the same palette. The palette at 0x1A268 seems to be the right one but then black always remains transparent as the rock is being pushed. I was unable to locate the code that handles the move, that would probably help.

7

Personal Projects / The Legend of Zelda: A New Light

« on: May 10, 2020, 12:21:18 am »

This thread is for the discussion of The Legend of Zelda: A New Light. Thanks to everyone who's played it so far and to those that who have provided feedback! Please leave a positive review on the hack page if you liked it.

8

ROM Hacking Discussion / Zelda 1 overworld secret path

« on: April 18, 2020, 03:54:05 pm »

You know the one, from the green gambling tree to the secret 100 rupees (or blue ring in quest 2). Zelda Tech screen 11 to 14.

First how does it work? Second, how can I move the secret path to a different location? I tried debugging around LDA $EB/$EC (A5 EB) and CMP #$1F (C9 1F) but couldn't make out anything relevant.

Btw, I have a few other questions like this around Zelda 1. Is it ok to post a new thread here under Discussion for each question or is it better to start a new thread under Personal Projects and lump them all together there?

9

ROM Hacking Discussion / Zelda 1 map cursor help

« on: April 09, 2020, 09:36:12 pm »

I'm working on a small change for my Zelda 1 hack which uses two different map cursors, one for the overworld and a different one in dungeons. Why am I making this change? Because the hack also contains automap where a smaller cursor looks great - but the normal cursor looks better in the dungeon.

It has been mostly successful but has introduced a rendering artifact because I'm currently using tile $1C (which seemed unused but actually is). I can't find where the artifact gets written (Mesen shows it's a sprite). Here's a screenshot to clarify the problem:

And here's the patch. It can be applied on top of my hack or vanilla Zelda 1. The most relevant bits are at $7761 ROM / $7EE1 RAM. I can paste the commented code and related data locations if that's helpful.

Any pointers on how to get rid of this or how to use a different tile from the other pattern table will be appreciated!

April 11, 2020, 02:58:08 am - (Auto Merged - Double Posts are not allowed before 7 days.)After reading a doc about OAM on nesdev it was much easier than I thought to change to an unused tile (see part about bit 0 in Byte 1). For example, FCEUX PPU Viewer showed $5C for an empty tile in the right side pattern table so add $1 to make it $5D. Too easy. Here are the relevant RAM locations for anyone wanting to edit the cursors.

Code: (RAM locations for map cursors) [Select]

0250 Map cursor Y pos (dungeon subscreen)
0251 Map cursor tile (dungeon subscreen)
0252 Map cursor attributes (dungeon subscreen)
0253 Map cursor X pos (dungeon subscreen)

0254 Map cursor Y pos (also used to blink cursor)
0255 Map cursor tile
0256 Map cursor attributes
0257 Map cursor X pos
April 11, 2020, 08:06:29 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Sorry to keep replying to myself but I think this info might be useful to others at some point.

Based on the same OAM document it occurred to me that I could find the original rendering artifact as well. Before I had been searching for $1C $00 (the tile id plus the palette number) which didn't yield what I was looking for. But I had also noted that the sprite was behind the background. That was a clue that bit 5 of the attribute byte would be set. So add $20. Viola, $1C $20 has only one occurrence in RAM and it's what I'm looking for. Once I found that, another solution to my problem could be to add $80 to the attribute byte (bit 7 is flip vertical), making $1C $A0, to effectively hide the sprite behind the background. Fun stuff!

10

ROM Hacking Discussion / Zelda 1 sound effects

« on: March 28, 2020, 08:13:50 pm »

I've been looking through Trax's bank 0 disassembly and this line caught my eye:

Code: [Select]

185B: Table for ? (6E bytes)
Here's what I found so far (these are ROM locations):

Code: [Select]

186B    shield sound pointer
186C    boomerang stun pointer
186D    rod sound pointer
186E    pick up heart pointer
186F    dialog sound pointer
1870    bomb placement pointer
1871    low hearts pointer

1872    low hearts sound
1887    shield sound
1892    rod sound
18B1    dialog sound (also affects arrow chirp)
18B7 boomerang stun sound
18C7    pick up heart sound
18D2    bomb placement sound
So this is a table for some of the sound effects as listed above. For example, the table starts at $186B with the byte $1C. Add the offset to the table start address to get the sound location ($186B + $1C = $1887). The offset for bomb placement is $67 so the sound starts at $18D2 ($186B + $67 = $18D2).

I also found the following sounds using the technique outlined later in this thread. I'm not sure where the corresponding table is located.

Code: [Select]

1F09-1F0E    stairs sound
1FC2-1FCB    sword swoosh sound
1FCC-1FD0    boomerang swish sound
1FD1-1FE0    fire sound
1A4D-1A64    bomb explosion sound