Great work, I'm loving that shop design! But one caveat to hackers. That big run of zeroed out bytes at the end of bank 06 is actually part of the data area for the standard (local) maps. Out of the box, the last map (Titan's Tunnel) ends at bank 06 address $AC99. If an edit to any map increases the size of that map's RLE-compressed form, then saving the map will push all bytes after it back to make room. That means it will relocate your routine. If you're coding in assembly and using labels, then the assembler will adjust for this. ROM hackers using hex editors will need to account for this manually. When a routine grows, any bytes at the end of that big buffer are truncated (since they hit the end-of-bank boundary at $BFFF) I initially got it wrong and put code at the end of the buffer; actually, any code you add should go right after the Titan's Tunnel end of map marker. Happy hacking!
What you didn't say here "HI, this is a 101 for any hack at all really on any device, decide thing you care about, observe values associated with thing, change them in known ways, find where this happens, find some space or code you can amend to perform the new functionality. weld this in, with custom functions if you must". I think that is pretty much the first thing you should say to any would-be hacker. Also relatively certain that was the write up in precis from YiFan Li hacking his Sony. ;) Good video. Had depths beyond it's first blush.
Which - for your edification - included writing his own custom loader using the existing loader functions - by doing exactly what was described above. laterally. Finding memcopy, blah blah you get the picture. But yeah. His set of tweets IIRC read just like part 1 of this series ;) N.B. to the wise.
Wow this is a super thorough explanation of NES rom hacking. Great job man. Makes me wonder about fixing the spell bugs and making it so your attack goes to the next live monster instead of deadspace hacks would be too difficult. With 4kb you might even be able to make a routine for weapon and armor stats menu, such as what items cast what spells. Kinda like a tool tip in battle pop up when using weapons and armor from the menu like Thor Hammer or White/Black Shirt.
Yeah! There's all sorts of cools stuff you can do. I really want to go and just start fixing the game, but I'm pretty focused on the channel right now so I haven't gotten around to making all those fixes xD
I did the retargeting of ineffective attacks to make a point to people that it was not a limitation of the NES but rather a design choice. Then everyone in the forum just said no one thought it couldn't be done even though it was literally the first thing they were talking about.
It was pretty easy, I used a disassembled version of FF instead of going through the debugger, I'll post the code. I think I had to clear out 12 bytes? I don't remember. There was a lot of useless code in the C bank, though. Original: BCC :+ ; if set... attack the enemy LDX btl_charcmdbuf+2, Y ; X = enemy target LDA @playerid ; A = attacker JMP PlayerAttackEnemy_Physical ; Do the attack!
: LSR A ; shift out bit 3 ('drink' bit) Modified: BCC @DrinkLabel ; if set... attack the enemy XXXChangeXXX begin big change LDX btl_charcmdbuf+2, Y ; X = enemy target LDA btl_enemyIDs, X CMP #$FF BNE @TargetOK LDX #$08 @NewTargetLoop: LDA btl_enemyIDs, X CMP #$FF BNE @TargetOK DEX BNE @NewTargetLoop @TargetOK: LDA @playerid ; A = attacker JMP PlayerAttackEnemy_Physical ; Do the attack!
@DrinkLabel: ; XXXChangeXXX end big change LSR A ; shift out bit 3 ('drink' bit) I don't like that I repeat the same code twice, but whatever, it was just a proof of concept. It doesn't work for magic.
This takes me back to writing 16bit C code. I think this limited my game to 64k. Smaller procedures let me keep over 20k free, i would swap memory to load different pc speaker music for battles, town, etc.
@@NesHacker i faked scrolling by putting locking the screen for a few ticks, drawing the background over 1 tile, then using a blur kind of effect on all but the sprites, which were moving in real time. It gave my rpgs a kind of gameboy look. Because the scrolling backgrounds had a tiny streak to them lol. The music was the worst to get to play with correct timing. There would be a batch file allowing you to adjust tick wait states as my programs were basically coded to work on my machine only unless you helped it
@@NesHacker oh i made some crazy hypercard games too on my mac iici. Hypercard really made me more confident in programming...but then as i was getting into C/C++ coding they added classes and objects, went all clunky and visual....making everything i knew almost useless. And that is why i don't care about progamming in say windows. But i have wanted to get a 6502 system and have fun. Is there a board with a 6502 and a z80?
does the money update part also checks for the boundary for the players gil if it is enough or not? or is there another subroutine that takes care of the case when the player doesn't have enough gil to buy the items he wants?
You are a genius, I really enjoy the quality of your videos both from an editing perspective and a pedagogical perspective. Will be waiting for more videos on the NES
Seems like an "easier" method would be to find the subroutine and move the whole thing to your 4k of space and re-write it in it entirety there (finding the calls to it elsewhere in the program and just changing them). Thus freeing up space in the first bank and you could modify other subroutines there.
Yeah the only issue with an approach like that is that subroutines are “ill defined” at best in assembly since you can jump into them at any point. It’s even more fuzzy when you consider indirect jumps, where the address for a jump can be calculated and put in RAM at runtime (there are some cases where this isn’t even knowable without simulating all possible configurations of a program). That said, this probably doesn’t occur with these routines, but I was mostly just be cautious by changing as little as possible of the initial program, just in case there were some “jump shenanigans” afoot.
@@NesHacker It seems like the memory organization would tend to encourage whole related sections of code to be in the same place, and the memory segmentation would limit spaghetti to an extent. But yeah you do never know, and aside from assuming the programmer was organizing things in a sane way there's always a risk.
Fascinating series, thanks! Excuse me while I go binge the rest of your channel..! :) Did you ever post the repo link anywhere? I'd love to dig into it some...
Yes! That would be great! I want to see this shop code in it's entirety. LOVE THE CHANNEL!!! I thought I was the only one obsessed with Final Fantasy 1 LOL
8:32 Why not pass the arguments into say A and X or A and Y? That should require three fewer bytes at the call site, making it easier to insert a call to a hack routine. But I guess that wasn't really needed? So instead you opted to make the caller place the arguments where they would be needed later on?
Great work, I'm loving that shop design!
But one caveat to hackers.
That big run of zeroed out bytes at the end of bank 06 is actually part of the data area for the standard (local) maps.
Out of the box, the last map (Titan's Tunnel) ends at bank 06 address $AC99.
If an edit to any map increases the size of that map's RLE-compressed form, then saving the map will push all bytes after it back to make room.
That means it will relocate your routine.
If you're coding in assembly and using labels, then the assembler will adjust for this.
ROM hackers using hex editors will need to account for this manually.
When a routine grows, any bytes at the end of that big buffer are truncated (since they hit the end-of-bank boundary at $BFFF)
I initially got it wrong and put code at the end of the buffer; actually, any code you add should go right after the Titan's Tunnel end of map marker.
Happy hacking!
Now that's what I call taking ROM hacking to a whole new level!
Glad you enjoyed it :)
More 6502, I can't get enough!
Lucky for you the next two videos I have in the works feature a ton of 6502 ;)
@@NesHacker yes! Thank you!
What you didn't say here "HI, this is a 101 for any hack at all really on any device, decide thing you care about, observe values associated with thing, change them in known ways, find where this happens, find some space or code you can amend to perform the new functionality. weld this in, with custom functions if you must". I think that is pretty much the first thing you should say to any would-be hacker. Also relatively certain that was the write up in precis from YiFan Li hacking his Sony. ;) Good video. Had depths beyond it's first blush.
Which - for your edification - included writing his own custom loader using the existing loader functions - by doing exactly what was described above. laterally. Finding memcopy, blah blah you get the picture. But yeah. His set of tweets IIRC read just like part 1 of this series ;) N.B. to the wise.
Wow this is a super thorough explanation of NES rom hacking. Great job man. Makes me wonder about fixing the spell bugs and making it so your attack goes to the next live monster instead of deadspace hacks would be too difficult. With 4kb you might even be able to make a routine for weapon and armor stats menu, such as what items cast what spells. Kinda like a tool tip in battle pop up when using weapons and armor from the menu like Thor Hammer or White/Black Shirt.
Yeah! There's all sorts of cools stuff you can do. I really want to go and just start fixing the game, but I'm pretty focused on the channel right now so I haven't gotten around to making all those fixes xD
I did the retargeting of ineffective attacks to make a point to people that it was not a limitation of the NES but rather a design choice. Then everyone in the forum just said no one thought it couldn't be done even though it was literally the first thing they were talking about.
It was pretty easy, I used a disassembled version of FF instead of going through the debugger, I'll post the code. I think I had to clear out 12 bytes? I don't remember. There was a lot of useless code in the C bank, though.
Original:
BCC :+ ; if set... attack the enemy
LDX btl_charcmdbuf+2, Y ; X = enemy target
LDA @playerid ; A = attacker
JMP PlayerAttackEnemy_Physical ; Do the attack!
: LSR A ; shift out bit 3 ('drink' bit)
Modified:
BCC @DrinkLabel ; if set... attack the enemy XXXChangeXXX begin big change
LDX btl_charcmdbuf+2, Y ; X = enemy target
LDA btl_enemyIDs, X
CMP #$FF
BNE @TargetOK
LDX #$08
@NewTargetLoop:
LDA btl_enemyIDs, X
CMP #$FF
BNE @TargetOK
DEX
BNE @NewTargetLoop
@TargetOK:
LDA @playerid ; A = attacker
JMP PlayerAttackEnemy_Physical ; Do the attack!
@DrinkLabel: ; XXXChangeXXX end big change
LSR A ; shift out bit 3 ('drink' bit)
I don't like that I repeat the same code twice, but whatever, it was just a proof of concept. It doesn't work for magic.
This takes me back to writing 16bit C code. I think this limited my game to 64k. Smaller procedures let me keep over 20k free, i would swap memory to load different pc speaker music for battles, town, etc.
That’s so great, I remember writing RPGs back in the day as a kid and having a great time.
@@NesHacker i faked scrolling by putting locking the screen for a few ticks, drawing the background over 1 tile, then using a blur kind of effect on all but the sprites, which were moving in real time. It gave my rpgs a kind of gameboy look. Because the scrolling backgrounds had a tiny streak to them lol.
The music was the worst to get to play with correct timing. There would be a batch file allowing you to adjust tick wait states as my programs were basically coded to work on my machine only unless you helped it
@@NesHacker oh i made some crazy hypercard games too on my mac iici. Hypercard really made me more confident in programming...but then as i was getting into C/C++ coding they added classes and objects, went all clunky and visual....making everything i knew almost useless. And that is why i don't care about progamming in say windows. But i have wanted to get a 6502 system and have fun. Is there a board with a 6502 and a z80?
Wait, is that Morphy on your shirt?
The one and only. I got the shirt from agadmator’s chess channel shop :)
Where is the github link?
does the money update part also checks for the boundary for the players gil if it is enough or not? or is there another subroutine that takes care of the case when the player doesn't have enough gil to buy the items he wants?
You are a genius, I really enjoy the quality of your videos both from an editing perspective and a pedagogical perspective. Will be waiting for more videos on the NES
Thanks :D, should have a new video out this week *crosses fingers*
Seems like an "easier" method would be to find the subroutine and move the whole thing to your 4k of space and re-write it in it entirety there (finding the calls to it elsewhere in the program and just changing them). Thus freeing up space in the first bank and you could modify other subroutines there.
Yeah the only issue with an approach like that is that subroutines are “ill defined” at best in assembly since you can jump into them at any point. It’s even more fuzzy when you consider indirect jumps, where the address for a jump can be calculated and put in RAM at runtime (there are some cases where this isn’t even knowable without simulating all possible configurations of a program). That said, this probably doesn’t occur with these routines, but I was mostly just be cautious by changing as little as possible of the initial program, just in case there were some “jump shenanigans” afoot.
@@NesHacker It seems like the memory organization would tend to encourage whole related sections of code to be in the same place, and the memory segmentation would limit spaghetti to an extent. But yeah you do never know, and aside from assuming the programmer was organizing things in a sane way there's always a risk.
enjoyed watching this
Glad to hear it, it was a lot of fun to make! :)
Fascinating series, thanks! Excuse me while I go binge the rest of your channel..! :)
Did you ever post the repo link anywhere? I'd love to dig into it some...
Yes! That would be great! I want to see this shop code in it's entirety.
LOVE THE CHANNEL!!!
I thought I was the only one obsessed with Final Fantasy 1 LOL
Ah, rem me on translating roms, decades before. Good times
ROM translators are the true unsung heroes of the NES community in my humble opinion 😃
@@NesHacker Absolutely true! :)
8:32 Why not pass the arguments into say A and X or A and Y? That should require three fewer bytes at the call site, making it easier to insert a call to a hack routine. But I guess that wasn't really needed? So instead you opted to make the caller place the arguments where they would be needed later on?
Nice video! Why update the graphics only if they have changed, though? It only saves cycles when nothing is happening anyway?
The better shops ROM hack might help a little, but this game needs maany more improvements 😂
Hahah, so true…
That's really the only improvement I want for the game, it's so boring since you need to buy so many potions. The rest is fine.
Amazing videos! I'm loving to learn those techniques!
Thx alot, ths is exactly what i needed to start understanding stuffs :3
Where can I download this hack?