News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - bogaabogaa

Pages: [1] 2 3 4 5 6
1
Personal Projects / Re: Zelda 1 Redux / The Legend of Zelda Redux
« on: April 01, 2020, 01:16:11 pm »
I did load a lot of empty bytes to my SRAM page so CPU $7f2d-7ffe is free SRAM. This is at PRG $779d. I also made my patch.txt more readable now. If you have question about it just ask. Documenting things is not my strong side yet.

2
Personal Projects / Re: Zelda 1 Redux / The Legend of Zelda Redux
« on: April 01, 2020, 10:56:39 am »
The heart counter is saved to your save table in SRAM.

CPU $677-67b seems to be free space that will go into the save table. I told the 3Dude to test it fully. I told him to test $67f too but he did not report that one false yet.
I do look at the ROM for a bit over two weeks now so I am not that familiar with the game.

3
Personal Projects / Re: Zelda 1 Redux / The Legend of Zelda Redux
« on: April 01, 2020, 10:17:39 am »
I did see on git that you are working to add a arrow counter. I will quote myself were I added a patch that does basically the same. I did make the the full heart container to a fragmented one. That one needed a entry in SRAM and the HUD table. To make it happen I had to be expand the table in SRAM and on the update table at CPU $302. Read the patch file for the DavePatcher. It will explain formats and what I put on what place. It might need slight changes for Revision 0.

Spider Patch file: https://www.dropbox.com/s/xi97vva2zst4b3t/patch.txt?dl=0
IPS for PRG1: https://www.dropbox.com/s/lt2fwksggbfr82o/QuaterHeartContainers.ips?dl=0

If you do testing it is good if you can do multiple things in a play-through to save time overall. I guess making list of the enemy health and damage tables is one of them. When you look for not used values use breakpoints. In the picture you see some of free values in SRAM. There will be writes when saving and loading but only $00 values. 



I am interested to see when you can finish describing a table. I don't know how to beat the game and it is always a big time factor to properly test things.


*NEW

Here is a patch with quarter heart and HUD indicator.
https://www.dropbox.com/s/lt2fwksggbfr82o/QuaterHeartContainers.ips?dl=0

As promised I will share a SpiderPatch here too!
https://www.dropbox.com/s/xi97vva2zst4b3t/patch.txt?dl=0

The benefits of the Spider Patch are that you can edit things. I can add a bunch of things you can enable or disable.

Get the patcher here: http://spiderdave.com/programs.php
There is a link to the git. Then download the folder from there.
It looks like this:


You will need to look at the config file and tell it where to find the ROM to patch and where to put and how to name it after.
Then open and run a patch file to mod your ROM.

The patch file has a simple format. First you might add "offset 10" this will skip the header and I can write PRG addresses now.
Here how to put values after a new offset: put "offset" "values" "more values till end of line"
If you like to describe something use a / "everything after a slash will be ignored by the patcher. Comment here till end of line!

If you like to disable something just comment it out with slashes.

My example might be confusing since I explained my research. This might be useful to understand it when doing further changes.
Look at the examples of SpiderDave they explain a lot more.

When I make further changes I can just update this link with the Spider Patch.

4
Is it possible to hide that many heart pieces? May be Half a heart would fit the hack better. You just need to change were it compares to the number 04 and every things else works automatically.

It is funny how you "find" sources of information all over the place after a while. Like here a partial described disassembly of the PRG0 ROM (http://www.bwass.org/romhack/zelda1).

By now I could add some stuff to it. Sometimes I wonder why people investing a lot of time researching a old dump when there is a revision (PRG1)

 

5

What tool did I use to edit the shop?
I used ZeldaTech.

ZeldaTech is compatible with Prg0 and Prg1


Ohh thanks you totally send me PRG0 and I did not think anyone would use old versions of the ROM. ::) my bad.. Just keep in mind that my patches are made for prg1!

Also is there a reason to quote people when there are only a view talk? I can not think of many reasons to do that. It feels to me it makes it harder to read through some posts.

6
I noticed something that could complicate things with my patch. The ROM you send me did had different offsets for some stuff my patch depends on it. I did try to save the original ROM with the snarfblam tools (ZeldaTech and DungeonMaster) I saved rigth away but the offsets did remain. What tools did you use? Do you have a idea how that happen? Might be that the tool changes offsets after some changes though..

7
ROM Hacking Discussion / Re: Zelda 1 sound effects
« on: March 31, 2020, 05:12:13 am »
I guess you talk of the PRG ROM offset. Also impotent seems the ROM dump you are working. Like legend of Zelda US PRG1..

Music pointer seem to be described here: http://datacrystal.romhacking.net/wiki/The_Legend_of_Zelda:Music_Pointers

Also you seem to have found a table with some values representing sound effects. If you change them some actions have different sounds. Not sure if all actions are represented in that table. I am sure you could list and name sound effects from value $00-$ff with some try and error. May be make your findings public.

8
If you do testing it is good if you can do multiple things in a play-through to save time overall. I guess making list of the enemy health and damage tables is one of them. When you look for not used values use breakpoints. In the picture you see some of free values in SRAM. There will be writes when saving and loading but only $00 values. 



I am interested to see when you can finish describing a table. I don't know how to beat the game and it is always a big time factor to properly test things.


*NEW

Here is a patch with quarter heart and HUD indicator.
https://www.dropbox.com/s/lt2fwksggbfr82o/QuaterHeartContainers.ips?dl=0

As promised I will share a SpiderPatch here too!
https://www.dropbox.com/s/xi97vva2zst4b3t/patch.txt?dl=0

The benefits of the Spider Patch are that you can edit things. I can add a bunch of things you can enable or disable.

Get the patcher here: http://spiderdave.com/programs.php
There is a link to the git. Then download the folder from there.
It looks like this:


You will need to look at the config file and tell it where to find the ROM to patch and where to put and how to name it after.
Then open and run a patch file to mod your ROM.

The patch file has a simple format. First you might add "offset 10" this will skip the header and I can write PRG addresses now.
Here how to put values after a new offset: put "offset" "values" "more values till end of line"
If you like to describe something use a / "everything after a slash will be ignored by the patcher. Comment here till end of line!

If you like to disable something just comment it out with slashes.

My example might be confusing since I explained my research. This might be useful to understand it when doing further changes.
Look at the examples of SpiderDave they explain a lot more.

When I make further changes I can just update this link with the Spider Patch.

9
With testing I do mean looking at it in a playthrough. Could be that this memory is used in lvl 9 to keep track of something special may be it is ok how it is. The RAM map did clear a lot up but there is still a lot to be discovered.

About Hud changes. It is kinda easy to do changes to it that are stationary.
PRG $1a2d3 Hud Tilemap Starts out with attributes. Tile mapping start at $1a2e4 

Format:
$20=offset from top
$FF=end of table
..there are more special Values. Tiles have nametable values as you find them in the PPU.

to put the heart down you write Heart=$65 to $1a312

After we need to find out how we could do a counter. So far I did look into how to game handles Hud updates. Turns out that at CPU $300 is a table that will be loaded into the PPU via registers $2006-2007. The format of this tables and how to use them is puzzling. I did see that there is space to expand the table. I was hopping I could look at the ruby routines and more or less copy them.. well there goes more research how things are handled. You know the table at CPU $6c97 will get drawn and places with special values will get updated (I guess). This routine will store impotent values to $00-0f.. before updating. It is hard to make out what all it has to do and why. But you need to know that if you like to extend on existing routines. I feel like it would be easier to write my own routine to update that value. Probably try this next.

It is interesting to look at a game how it does the things. I did see that SRAM is used as a other bank to save routines and at the end there is almost no space to add your own things.
If you like to expand it you can write overwrite $7f with $80 at PRG $4d31. This will load a extra 256 byte. There seems to be a impotent value on the bottom of the bank so put $a5 at PRG $786f too.

There goes a lot of text to explain little things. I know of a tool called DavePatcher. Probably will do some little things and add it to that format. Really easy to understand format and a great way to apply changes to a ROM. I had in mind to do that with some games I did look into. It is great to put a value and explain with a view words what it does. Might take me a while but I plan to post a other patch here and explain the patcher a bit. 


10
Ok this is the value I showed you. I did describe that the first four bit are for container and the second 4 is health. You added more health. After 4 times the value did overflow and added a container. This is a bug and the game code will usually prevent that form happening. (4 bit can make characters from 0-f) 0000 - 1111)

So I make a example how to add code with what I know. In this picture you see that I used mesen to write some horrible long code to get something working very quick. First I like to find out if it works. You see some old notes below so you know where I pasted the code into the PRG ROM after. This code does not work over save sessions since most of the SRAM will be overwritten when reseting the game. I would need to find free space in the save format at the beginning of SRAM. I will also need to find out how this is handled for different save files. So $7eff would need to go to the correct save file to be carried and this is a lot of research again for something I don't see much gained. May be it will make the experience worse since it feels like you never get stronger.
I rater research some interesting tables so you can make enemies shoot or what not.


I post a ips anyway if you like to work with the new code..

* I updated the patch. According to this RAM MAP (http://datacrystal.romhacking.net/wiki/The_Legend_of_Zelda:RAM_map) $677 seems not used. But sure it needs testing.
https://www.dropbox.com/s/9tr504v9w84b70x/QuaterHeartZelda.ips?dl=0

** I did bug fixing and added overflow protection so you can have to many hearts without problem. Should work if the SRAM address is really not used for anything..
https://www.dropbox.com/s/zkhy5fqud8irhnx/QuaterHeartZelda2.ips?dl=0

11
It is a learning experience for me too. I did read about the xkas version that can do 6502 assembly but I think ASM6 would be the better choice overall. I think it comes down that I don't understand how to allocate banks. It seems you use ORG to set where the banks is mapped in the cpu bus. Like org $8000 or org $c000. Not sure how to add the different banks at all yet..

All this is simpler on the SNES since the CPU bus has a large range to include everything. You use ORG to set the location where you like to put your code. You need to know that the RAM is mirrored to each bank and you are ready to go to do some damage. The assembler makes coding easy and might help beginners to get into.

On the Nes it seems you need to have a way better understanding of things before you get rolling with ASM6. I think you should not care yet. I started out finding some pointer tables and changing them in a hex editor. I did find data for the enemy assembly and learned how sprites are put together. Tasks like this seem to be easier and  might be the thing that will add to a hack quiet a lot. Use Mesen to write code since that one has a assembler. Or write it by hand and translate it to hex as a exercise.. Mesen will help you to find the proper bank in the ROM as you can just right click and go to the location. This is how I did most changes so far. In the process you will gain more knowledge how it works.

Tell me how you did change the heart-container to give a heart after 4 times. I will make you a example.

12
If I would know what you did to collect 4 containers to get one container I might know a better way to hijack the code. The problem is probably that one value is saved to RAM but should go to SRAM to keep the value between save sessions.

Here a example how I would hijack the code with my current knowledge.



On the bottom right you see that SRAM is mapped to CPU bus $6000-$8000. This is impotent since the CPU can only access the CPU bus. It talks to PPU over registers that are mapped to the CPU bus.. just to get a idea how this works.

I made a breakpoint and you see how I stepped code where you heart-container will add one up and health will get refilled. On the left bottom you see a assembler with some code I documented. There I made a jump to a location where I can put code. I could INC (increase) a value in SRAM and then compare that number to #$04. Then when it is equal I would reset that counter and add the heart-container. Else skip that part.

Learning to code will not happen over night. You will find the best documentation for the NES on wiki.nesdev.com.
You will study opcodes and how to use them. Probably follow tutorials on different pages and experimenting a lot.

Here a good list of opcodes and the hex equivalent.


If you really feel lost and you liked to learn to code for a 6502 you can also join my discord. There are channels for questions about it.

**NEW**

I probably did not explain it properly and did think I could write you a ASM file that would explain it better.. but..

I did try to create a ASM file with ASM6. I could not get it to include the code to a existing Zelda.bin. It will overwrite it or put it on the end of the file. I tryed for a view hours to get this to work but failed with any attempt. I find it very easy to do this sort of thing on the SNES and tools like asar or xkas. I think it would be the best way to learn to code and write small patches with it. It is easy to apply and change after. I could not find any ASM6 patches and I am glad if anyone could show me one. I found only large scale projects so if anyone knows where to find a example patch I would like to learn how to use it properly on the NES too!

I did not explain that you need to allocate the code at PRG $6c7d (pointer) PRG $7751 (new code) You can write out the code as hex in the memory editor or use the build in assembler in a debugger.

13
I started to find some enemies you can go about as I described before. It is a bit easier since this table is not located in SRAM. Not sure if all enemies are located on the same spot but they might. Finding things like this requires a bit of ASM knowledge or a lot of patience when you try and error your way through. It might be a bit overwhelming when looking at a debugger the first time. But in the end a CPU does follow instructions like jumping, copy or do some logic. In the end it is a simple machine and with the debugger you can make a point where it triggers a pause (break point) Then you can step slowly to see what happen.


Enemy Health Table PRG ROM

$1fb52 RedRockThrower/Blue?
$1fb56 ZoraShooter

$1fb51 BumerangDude   Level-1
$1fb5b Bat       Level-1
$1fb60 Skellet       Level-1
$1fb6c DragonBoss   Level-1


Format: First half byte ?? second half byte full damage point

14
This looks like a ambition project. I like your work. I don't know how much the info really helps you so far.

You don't require ASM knowledge to change how much damage a enemy does. Here a example.

I suggest that you use Mesen since this editor does a very good job explaining the NES in the debugger and is a excellent emulator overall. It has info you can learn all over it.
In this picture I like to find out how much damage this red enemy does. I make a save state on that screen. I open the debugger/memory editor and move to tab SRAM and the offset you see on the picture. When I load the save state previews color highlights go away. Then I run into the enemy and a number will get blue. Green colored things are op codes this are instruction processed by the CPU. Blue color shows data. In this case probably all enemy damage is stored in that table.


As you noticed we use SRAM to find out how much damage a enemy does. This table is located on the PRG ROM. So you start to do a document about that table that might look like this.

************************
PRG ROM

$72bb Enemy Damage Table
..
..
$72c2 Red Enemy
..

Format: First half byte is sub damage point second half byte full damage point
*************************

If you wonder what PRG ROM is. The NES file will contain a header, PRG ROM and CHR ROM. In a nes file this is combined. The nes header (ines header) is $10 byte length and will tell a emulator where everything goes. So when you open the Nes file in a hex editor you will need to subtract the header from the offset to get the correct PRG ROM offset. But you have also the option to save the ROM within the memory tool or generate a IPS of the change.

15
ROM Hacking Discussion / Re: I need yychr help!
« on: March 23, 2020, 07:51:21 pm »
Let me guess what you did so far. You did extract the Alttp GFX with zCompress to view the graphics. Since expanding the ROM will not decompress graphics. Or did you find other tools for it? You can change palettes of the shield with HyruleMagic editor if you are not comfortable with a debugger and hex editor. You can also load palettes from a zsnes savestate. yychr is not capable to load palettes of a ROM. You can do things like this with tile molester but should not be needed for your project. Just use the original color you find in your save state.
When I am not mistaken you probably edit graphics and will need to compress and insert them back to the alttp ROM. For this you just follow the readme of zCompress tool. To test your changes you load the ROM in a emulator to test and view the changes.



Note: Editing links spite is much easier this graphics are not compressed and there are amazing tool that help you to make a new sprite. You can find tutorials on youtube for it. There are tones of sprites on the randomizer page.

Since I had everything open I just made the shield a bit smaller. This patch will need to be used with a original unheadered US ROM. It will add a header and the smaller shild. https://www.dropbox.com/s/x64jwkpvfotuzvf/AlttpSmallMirrorShild.ips?dl=0


16
If you look at the RAM value $66f and $670 you will find the values for heart container and health. First 4 bit are for container the second 4 bit health. For example the value $52 will leave you with 6 hearts and half health.

In Ram at $670 you actually have "half" container and health what is used to show half hearts. When you pick up a big heart container it will do a ADC #$11 to the $66f Ram value. You can not go smaller then $1 so you would need to write costume routines for it to work. It would be easy to double it if you change the value $11 to $22 at $6c7c in the PRG ROM. Also keep in mind that this routines are copied to SRAM when you start up the game. It might not work if you use old saves-states to test it.

If you try to balance the game it might be easier and more interesting for you to look for enemy health tables. They are much easier to change. Also I did never hack Legend of Zelda. There might be good resources for the game so you don't need to find things yourself. What is your plan when I may ask. Would you like to do a balance hack?

17
ROM Hacking Discussion / Re: Super Castlevania 4 Maker
« on: August 08, 2019, 12:36:10 pm »
A forum thread is not a good way to organize hacking resources. I have a discord and work on a wiki.


18
Personal Projects / Re: Super Mario Kart Super Circuit Demake
« on: August 02, 2019, 06:06:55 pm »
This is great! I love those tracks, and would love to play them 2 player, but nobody else I know has a GBA, and I don't have a link cable.

I did read that this is a Super Mario Kart hack for the SNES. This game has 2 player mode to play on the same screen. If you don't mind to play on a emulator. I recommend the newest BSNES by Byuu. He just added HD mode7 Support so this hack can look very sharp when it comes out ;P

Emulator: https://www.byuu.org/

19
The RAM address of the blog should line up but I haven't tested that yet. CV3 J was the VRC6 mapper and CV3 U had mmc5. You will not find much that will line up.

I did use TileMolester to do graphics and I added most of the palettes. I think revamp does have some that are off at last for the mmc5 version. I guess it will be worse for the VRC6 as you can't even edit stairs without breaking the ROM. It would be nice if you can share your notes when you go after addresses. I might do a ROM map thingy and debugger resources if I get to it.

Here a example how I did add things for the MMC5 ROM. Did take some time but I like to edit palettes when I place new graphics and it was easy to add and edit the once not found in revamp.
I also share it but it will not help you since you are hacking VRC6.



But if you do end up doing bookmarks it is easy to share the XML so other have a easier time.

20
Here is a Blog with a RAM and Some ROM map of CV3 J
http://gmvania.blogspot.com/2012/08/bookmark-this-blog-entry-last-update.html


I work mostly on the US version and the ROMs are a bit different. But may be this addresses help you to find what you are looking for.

Some related addresses for CV3 US

0x3BEBA 40 => 60 (Leather Whip damage)
0x3BEC2 60 => C0 (Chain whip damage)
0x3AF7A 40 => 60 (Dagger damage)

0x3BEB0 40 => 60 (grant attack damage)
0x3AF7F 40 => C0 (Grant Dagger damage)
0x3AF80 60 => 80 (Grant Axe damage)

0x3AF7D 02 => 60 (Syfa Ice book damage on Bosses)


0x3BAC8 01 => 02 (Cross heart cost)
0x3BACA 01 => 02 (Holy Water heart cost)
0x3BAD1 05 => 03 (Clock heart cost)

0x3AF81 20 => 40 (Alucard Fireball)
0x3A84F A9 3C => A9 78 (Alucard bat timer for heart drain)

0x2E3D0 C9 0A => C9 14 (number of enemies or candles killed with subweapons before they drop a double)

related ram addresses
player health: 3C
boss health: 3D
subweapon: 85

partner subweapon: 86

Pages: [1] 2 3 4 5 6