Hi there!
I've translated Zelda 1 & 2 for NES to my native language Swedish,
but I wish to do it again, but now use the PAL versions as a base.
I extracted the PAL versions from the PAL versions of the WAD:s
for Wii. I'm gonna use Mato-san's guide to improve the translation
of Zelda 1.
This is what I humbly wish for help with:
Zelda 1
Add a fifth row row of letters when you register your name
and add Swedish characters (ÅÄÖ). There's a fifth row in
the Japanese version so it should be possible to transfer
to the PAL version.
Zelda 2
Add the three Swedish characters Å, Ä and Ö when you
register your name.
Change the size of the text windows (aka. letterbox?) so
that more text can fit if it's possible?
I wish to make a certain patch with the changes in English
in case some other person wish to translate the PAL version
to her/his native language.
I've taken a beginners course in Ada, but I thought it was
hard to understand and I know that Assembler is even
harder.
I might even try to translate Zelda 1 and 2 for GBA afterwards
if it's not too difficult.
Thank you for reading!
Have a nice day!
It's an English to Swedish translation? (I'm Swedish too BTW.)
Ada is quite a difficult and large language I heard, used where reliability and maintenance is very important. Assembly isn't really hard to understand, it's actually very simple as it's mostly about copying data or doing arithmetic on it, but it requires understanding how the hardware works before anything useful can be done with it, which is what takes time.
Yes, English to Swedish.
Ada is used in the aviation industry because it's reliable.
I wish I knew assembly.
Pokun wrote:
It's an English to Swedish translation? (I'm Swedish too BTW.)
Ada is quite a difficult and large language I heard, used where reliability and maintenance is very important. Assembly isn't really hard to understand, it's actually very simple as it's mostly about copying data or doing arithmetic on it, but it requires understanding how the hardware works before anything useful can be done with it, which is what takes time.
This whole forum is about using assembly to produce new NES games from scratch. If you really wish to learn this art, there are several options. I learned it in my free time as a hobby, coming from a non-programmer background with only the will to learn.
Pokun wrote:
, but it requires understanding how the hardware works before anything useful can be done with it, which is what takes time.
Mattiac wrote:
I wish I knew assembly.
My really quick summary of most of the hardware. Though, DocWaluigean never posted again so maybe it was too much condensed info? I attempted to make these replys be correct. Hope this helps start your assembly journey.
(attempt to ignore my edits at the bottom)
I will take a shot at looking into the Japanese version vs the PAL version of Zelda 1. I am no expert when it comes to 6502 assembly but maybe something will stick out.
I took a quick look at the two games today and you are very right in that this seems doable. As a proof of concept I re-purposed an existing letter, '!', within the European menu to represent the Swedish A you listed.
If you would like to re-create this POC yourself:
1. Create a copy of the European version.
For sanity the SHA-1 of the European version begins with 0B27FEA...
2. Open up the copy of the European version in a hex editor.
For this session I used BeyondCompare and selected "Session->New Session->Hex Compare.
From there open up your original in the left screen and the copy you will modify in the right.
3. Change memory location 0x8a1f-0x8a27 from hex "1818181818001800" to hex "44386CC6C6FEC6C6".
NOTE: If the sha1 is different or you are unsure if we have the same game then search for hex "1818181818001800" because it may not be at 0x8a1f.
4. Reboot the game in an emulator and see if the exclamation tile changed in the register menu.
Memory-wise there are plenty of blank tiles following the standard alphabet where you are free to insert your Swedish letters. One thing to keep in mind is the standard letters are already almost maxing out the height of a tile. While adding new tiles is simple we might need to change some game code to get it to use two tiles to represent a letter.
While the extra Swedish letters are considered separate letters, they are technically no different from letters with diacritics. To avoid needing an extra tile row, you have to squish an "A" and an "O" a bit to get room for the dots on "Ä" and "Ö". For the ring on the "Å" you can get away with a slightly larger dot, Swedish people will understand it as an "Å" in text anyway.
Example 8x8 font
To edit the graphics is the very easy part except in Zelda 2 because there's no free tiles in the Zelda 2 CHR.
I need the extra row so it would look like an official translation.
Pokun wrote:
While the extra Swedish letters are considered separate letters, they are technically no different from letters with diacritics. To avoid needing an extra tile row, you have to squish an "A" and an "O" a bit to get room for the dots on "Ä" and "Ö". For the ring on the "Å" you can get away with a slightly larger dot, Swedish people will understand it as an "Å" in text anyway.
Example 8x8 font
Quote:
To edit the graphics is the very easy part except in Zelda 2 because there's no free tiles in the Zelda 2 CHR.
I need the extra row so it would look like an official translation.
Ah I didn't realized this was already identified as an easier part. I will look for the cursor logic next. Just putting them side by side it seems like the cursor has a wrap around max that we need to modify somewhere.
It's easy in Zelda 1, but very hard in Zelda 2. I also found the
table in Zelda 2, but I couldn't add another letter. It was a
few characters after 0. I got lots of letters and numbers
on the screen when I tried to overwrite them. I guess
I have to replace three English characters or find a
place for the graphics first and then try to create a
new table somewhere else and point to it instead.
xamboni wrote:
Quote:
To edit the graphics is the very easy part except in Zelda 2 because there's no free tiles in the Zelda 2 CHR.
I need the extra row so it would look like an official translation.
Ah I didn't realized this was already identified as an easier part. I will look for the cursor logic next. Just putting them side by side it seems like the cursor has a wrap around max that we need to modify somewhere.
Alright so I found the horizontal cursor reset comparison. If you think moving everything one tile over and then having an extra column will suit your needs in Zelda 1 let me know. I will keep hunting for the vertical reset. For some reason it is not as apparent.
I dont have my notes in front of me but if looking for the horizontal reset in the European game search for CMP $E0.
Oh, thank you! It sounds like progress. I do want a fifth row
after 0-9 and that's where I wish to put the Swedish
characters.
xamboni wrote:
Alright so I found the horizontal cursor reset comparison. If you think moving everything one tile over and then having an extra column will suit your needs in Zelda 1 let me know. I will keep hunting for the vertical reset. For some reason it is not as apparent.
I dont have my notes in front of me but if looking for the horizontal reset in the European game search for CMP $E0.
Quote:
Oh, thank you! It sounds like progress. I do want a fifth row
after 0-9 and that's where I wish to put the Swedish
characters.
Right I get you on that I will give it another go. Worst case though we change the box to be wider left and right by one column. Then we can move the A letter left and shift the rest of the letters back one space like a snake. You would then have 5 extra spaces for new letters to be used.
I plan on finding the vertical wrap though so probably a moot point. I should probably test the horizontal addition and see if it correctly takes what is in the new row and puts it in for the name.
It sounds like a possible solution. Thank you, Xamboni-san!
xamboni wrote:
Quote:
Oh, thank you! It sounds like progress. I do want a fifth row
after 0-9 and that's where I wish to put the Swedish
characters.
Right I get you on that I will give it another go. Worst case though we change the box to be wider left and right by one column. Then we can move the A letter left and shift the rest of the letters back one space like a snake. You would then have 5 extra spaces for new letters to be used.
I plan on finding the vertical wrap though so probably a moot point. I should probably test the horizontal addition and see if it correctly takes what is in the new row and puts it in for the name.
Ok I found the extra row test so I think the Zelda 1 problem is under control now. In the European version of the game the vertical cursor test is done at location 0x9e13. Note this is a static address rather than runtime memory.
The game will do a memory compare on the cursor's RAM location against this address. On each cursor move 0x10 is added to the RAM address holding the cursors location. This result after the add is compared to the contents of 0x9813. If you add 0x10 to 0x9813 you will see the cursor move down another row before it resets to the beginning.
My modified binary now has the byte sequence 0x23 0x30 0x10 0xd7 0x87 0xf0 0x77 0xb7 around the important locations. Let me know if you have any questions or if I made any mistakes. There are a ton of changes in my modified binary so I might have things a bit backwards here. Next time I sit down I'll work with a clean binary to test the changes.
edit: I should have mentioned the important byte in the above sequence is 0xd7. The original game vertical max is 0xc7.
Thank you so very much, Xamboni-san! ^_^
I feel a bit stupid because I'm not sure I understand, but should
I go to 0x9e13 and enter the byte sequence there? Will that add
the Swedish characters as well or do I have to add them to a
table somewhere else?
xamboni wrote:
Ok I found the extra row test so I think the Zelda 1 problem is under control now. In the European version of the game the vertical cursor test is done at location 0x9e13. Note this is a static address rather than runtime memory.
The game will do a memory compare on the cursor's RAM location against this address. On each cursor move 0x10 is added to the RAM address holding the cursors location. This result after the add is compared to the contents of 0x9813. If you add 0x10 to 0x9813 you will see the cursor move down another row before it resets to the beginning.
My modified binary now has the byte sequence 0x23 0x30 0x10 0xd7 0x87 0xf0 0x77 0xb7 around the important locations. Let me know if you have any questions or if I made any mistakes. There are a ton of changes in my modified binary so I might have things a bit backwards here. Next time I sit down I'll work with a clean binary to test the changes.
edit: I should have mentioned the important byte in the above sequence is 0xd7. The original game vertical max is 0xc7.
Quote:
I feel a bit stupid because I'm not sure I understand, but should
I go to 0x9e13 and enter the byte sequence there? Will that add
the Swedish characters as well or do I have to add them to a
table somewhere else?
No reason to feel stupid my man. I am sure I skipped a ton of steps in my explanation and as always I am still learning too.
Adding in the Swedish characters is probably the easier part of this so I didn't address it too much yet. In an earlier post I believe there was a picture showing the additional letters you want are doable so we can go over that later. First lets confirm the cursor now behaves the way you want.
You will need a hex editor in order to review the bytes I posted earlier. I pulled up a page on
wikipedia which shows a few options for you. BeyondCompare is available on multiple platforms and requires a license but you can use their trial period for a bit. HxD (Windows) and Bless (Linux) are two others that I can say will get the job done.
1. Make a copy of your European ROM.
2. Open up the copy inside of your hex editor of choice.
3. Confirm you are looking at a ton of game data and code (Hex bytes). The first 3 bytes are 0x4e 0x45 0x53 which spells NES in ascii characters.
4. Either search for the byte pattern I listed (233010c787f0) or navigate to address 0x9e13. If your hex editor shows addresses in decimal rather than hexadecimal then it is 40467.
5. Change the byte c7 to d7, save the file change, and load the game in an emulator. In BeyondCompare if you load the original game in the left pane and the copy in the right when doing a hex comparison (File->NewSession->HexCompare) then your change will be obvious.
6. See if the menu is behaving the way you want.
Sorry for the typo in my last post. 0x9813 should be 0x9e13.
Wow, it's really cool that a tiny change like that can
cause a big difference. Now it's like I wished for.
The cursor didn't move to the bottom when I moved
it to the top character and pressed up, but I guess
you will figure that out as well.
Thank you a lot, Xamboni-san!
Have a nice day!
xamboni wrote:
Quote:
I feel a bit stupid because I'm not sure I understand, but should
I go to 0x9e13 and enter the byte sequence there? Will that add
the Swedish characters as well or do I have to add them to a
table somewhere else?
No reason to feel stupid my man. I am sure I skipped a ton of steps in my explanation and as always I am still learning too.
Adding in the Swedish characters is probably the easier part of this so I didn't address it too much yet. In an earlier post I believe there was a picture showing the additional letters you want are doable so we can go over that later. First lets confirm the cursor now behaves the way you want.
You will need a hex editor in order to review the bytes I posted earlier. I pulled up a page on
wikipedia which shows a few options for you. BeyondCompare is available on multiple platforms and requires a license but you can use their trial period for a bit. HxD (Windows) and Bless (Linux) are two others that I can say will get the job done.
1. Make a copy of your European ROM.
2. Open up the copy inside of your hex editor of choice.
3. Confirm you are looking at a ton of game data and code (Hex bytes). The first 3 bytes are 0x4e 0x45 0x53 which spells NES in ascii characters.
4. Either search for the byte pattern I listed (233010c787f0) or navigate to address 0x9e13. If your hex editor shows addresses in decimal rather than hexadecimal then it is 40467.
5. Change the byte c7 to d7, save the file change, and load the game in an emulator. In BeyondCompare if you load the original game in the left pane and the copy in the right when doing a hex comparison (File->NewSession->HexCompare) then your change will be obvious.
6. See if the menu is behaving the way you want.
Sorry for the typo in my last post. 0x9813 should be 0x9e13.
Quote:
The cursor didn't move to the bottom when I moved
it to the top character and pressed up, but I guess
you will figure that out as well.
Hmmmmm mine was working both ways as intended. Maybe I made two changes that fixed both ways and didnt realize it from my notes. I'll boot it up soon-ish and see what is going on.
Well when you are right you are right. The second change must have slipped my mind. I made two changes to account for going up as well.
0x9e13: 0xc7 -> 0xd7
0x9e17: 0xb7 -> 0xc7
I looked into the other parts of the equation here and it seems we might be looking at a bit more difficulty. I added a new row of letters into the games background code locations. Unfortunately this throws off some pointers for the initial Zelda splash screen so we will have to fix that math. Also when the cursor selects a location it does not use what is there per se. We will have to identify that dereference and fix it up. As a first test I moved the cursor to the new row and instead of the zero I put there it loaded an 'x' into my name.
If you would like to play around with the backgrounds on the enter name menu look at address 0x1a1fe. You will see a clear pattern of number bytes (0x0#) and black bytes (0x24) alternating. For example that particular row begins with the numbers 0-9. In hex we see 0x00 0x24 0x01 0x24 0x02 0x24...
You can add another row by adding the bytes 0x23 0x26 0x13 0x00 0x24 0x01... at location 0x1a211. This breaks the game due to relative offsets found throughout the code. As an easy way of fixing this I removed bytes starting at 0x1ad80. Those bytes are filler 0xff's so they are probably not used for anything. If you add in the byte pattern I listed about (0x23 0x26... ) you need to remove the exact same amount of 0xff's from the padding section.
Let me know if you have any questions. As long as you keep the byte count the same you can modify things as much as you want to get it cosmetically looking like swedish letters in the final row.
There are two offsets where one can change to replace ! with Å for example. I know where, but I have my notes at home and I will return tomorrow. Unless I borrow my friends computer here.
xamboni wrote:
I looked into the other parts of the equation here and it seems we might be looking at a bit more difficulty. I added a new row of letters into the games background code locations. Unfortunately this throws off some pointers for the initial Zelda splash screen so we will have to fix that math. Also when the cursor selects a location it does not use what is there per se. We will have to identify that dereference and fix it up. As a first test I moved the cursor to the new row and instead of the zero I put there it loaded an 'x' into my name.
If you would like to play around with the backgrounds on the enter name menu look at address 0x1a1fe. You will see a clear pattern of number bytes (0x0#) and black bytes (0x24) alternating. For example that particular row begins with the numbers 0-9. In hex we see 0x00 0x24 0x01 0x24 0x02 0x24...
You can add another row by adding the bytes 0x23 0x26 0x13 0x00 0x24 0x01... at location 0x1a211. This breaks the game due to relative offsets found throughout the code. As an easy way of fixing this I removed bytes starting at 0x1ad80. Those bytes are filler 0xff's so they are probably not used for anything. If you add in the byte pattern I listed about (0x23 0x26... ) you need to remove the exact same amount of 0xff's from the padding section.
Let me know if you have any questions. As long as you keep the byte count the same you can modify things as much as you want to get it cosmetically looking like swedish letters in the final row.
Quote:
There are two offsets where one can change to replace ! with Å for example. I know where, but I have my notes at home and I will return tomorrow. Unless I borrow my friends computer here.
Not quite sure what you mean but if you get something working let me know what changes you made and I will test them out.
I had to change at offset 1A1B0-1A210
and offset 09DC0-09DE0 in order to
replace ! with an Å for example.
Only the graphics would change if
I only changed at one offset, so
I had to change at both places
because it would otherwise look
like Å on the screen but it would
print ! if I typed it on the name
registration screen. I used HxD.
I just don't know how to add more
characters in the mix...
Have a great day, Xamboni-san!
xamboni wrote:
Quote:
There are two offsets where one can change to replace ! with Å for example. I know where, but I have my notes at home and I will return tomorrow. Unless I borrow my friends computer here.
Not quite sure what you mean but if you get something working let me know what changes you made and I will test them out.
Quote:
I just don't know how to add more
characters in the mix...
You can add more characters into the mix by using the image editor program "yychr". I believe I got the tool from smwcentral.net but I am sure it hosted elsewhere also. Once you have that program throw the game into a debugger. For this I used fceux in Windows. In Linux fceux does not have many debugging features.
Once in the debugger go to the name registration screen and hit "pause|break" on your keyboard. This should halt the game. From there bring up the PPU memory viewer. I think this is something like Tools->HexViewer->PpuMemory. In that window's file menu there is an option to "Dump PPU Memory" which creates a binary file containing the tiles loaded into the PPU at that moment. This binary file can be fed directly into yychr which displays the tile set and allows you to make changes. In yychr do File->LoadFile->Select your binary dump file. If the graphics look messed up there is a drop down box in the lower left which scrolls through the different gaming systems. There is probably an entry named NES 4-bit or something. Once you are looking at the actual letters click around to change them how you would like. You can see several spaces after the standard letters where adding your new letters can happen.
I typed this from memory so some of it might be a little inaccurate. Let me know if you have any questions.
xamboni wrote:
Once you have that program throw the game into a debugger. For this I used fceux in Windows. In Linux fceux does not have many debugging features.
However, if your Linux box uses an x86 or x86-64 processor, you can use FCEUX for Windows in Wine with no problem.
xamboni wrote:
Once in the debugger go to the name registration screen and hit "pause|break" on your keyboard.
Or if your laptop's keyboard lacks a Pause button, you can click "Step" in the debugging window, or press
\ (backslash) for frame advance with the game window focused.
Thank you, Xamboni-san, but I meant that I already
know how to easily add Swedish characters to the
tileset, but I don't know how I can add them in the
right places in the ROM that has some kind of list
and table over the characters in the registration
screen.
xamboni wrote:
Quote:
I just don't know how to add more
characters in the mix...
You can add more characters into the mix by using the image editor program "yychr". I believe I got the tool from smwcentral.net but I am sure it hosted elsewhere also. Once you have that program throw the game into a debugger. For this I used fceux in Windows. In Linux fceux does not have many debugging features.
Once in the debugger go to the name registration screen and hit "pause|break" on your keyboard. This should halt the game. From there bring up the PPU memory viewer. I think this is something like Tools->HexViewer->PpuMemory. In that window's file menu there is an option to "Dump PPU Memory" which creates a binary file containing the tiles loaded into the PPU at that moment. This binary file can be fed directly into yychr which displays the tile set and allows you to make changes. In yychr do File->LoadFile->Select your binary dump file. If the graphics look messed up there is a drop down box in the lower left which scrolls through the different gaming systems. There is probably an entry named NES 4-bit or something. Once you are looking at the actual letters click around to change them how you would like. You can see several spaces after the standard letters where adding your new letters can happen.
I typed this from memory so some of it might be a little inaccurate. Let me know if you have any questions.
Quote:
Thank you, Xamboni-san, but I meant that I already
know how to easily add Swedish characters to the
tileset, but I don't know how I can add them in the
right places in the ROM that has some kind of list
and table over the characters in the registration
screen.
Sorry for misunderstanding. I worked a bit more on the background layout. I can now add another row and fix the borders around it cosmetically. I will work on the mysterious dereference that drives what character is chosen.
Great progress! I was thinking that the Japanese version
must have a much bigger table of characters selectable
at the registration screen or perhaps it has a table for
the Japanese characters and another table for the
English characters?
Have a very nice weekend, Xamboni-san!
xamboni wrote:
Quote:
Thank you, Xamboni-san, but I meant that I already
know how to easily add Swedish characters to the
tileset, but I don't know how I can add them in the
right places in the ROM that has some kind of list
and table over the characters in the registration
screen.
Sorry for misunderstanding. I worked a bit more on the background layout. I can now add another row and fix the borders around it cosmetically. I will work on the mysterious dereference that drives what character is chosen.
Ok I finished finding the dereference table. This was a major "shame on me" for not seeing the pattern sooner. The value table for what the cursor selects is just above the boundary logic tests we previously fixed. Bonus points here in that we don't have to disturb memory further as we can relocate the table safely to filler space. Below all addresses are "static" in that these are the raw ROM addresses rather than anything at runtime.
Notes:
Static address 0x9dc3 is a small table that begins "0x0a 0x0b 0x0c" which directly corresponds to the letters displayed on the screen.
Static address 0xa161 is the table dereference load instruction. Specifically the assembly is "LDA $9db3,Y" where Y is the cursor location. The cursor location is added to the table base address and voila, the correct digit is chosen.
Changes:
We can easily move this table to filler space by modifying the address bytes at 0xa162 (static address). As a test I changed the value 0xb39d at location 0xa162 to the value 0x909c. Addresses are stored little endian for this architecture so that is why the bytes are flipped around.
Now the cursor will be looking for the table at 0x9c90. At 0x9c90 in a hex editor I erased a bunch of 0xff's and replaced it with 0x0a-0x2c, 0x00-0x09, 0x24 (this is the blank spot at the end of the letters, (what you want here for additions).
At this point the cursor moves how you want, the menu is cosmetically fixed with additions, and the values saved are correct. We broke the main menu when we added in a new row of letters so that will need to be fixed at some point.
There's no shame because The Force is strong with your ROM
hacking skills, Xamboni-san! Thank you so much! I will try it
out if I can understand.
Have the best weekend ever!
xamboni wrote:
Ok I finished finding the dereference table. This was a major "shame on me" for not seeing the pattern sooner. The value table for what the cursor selects is just above the boundary logic tests we previously fixed. Bonus points here in that we don't have to disturb memory further as we can relocate the table safely to filler space. Below all addresses are "static" in that these are the raw ROM addresses rather than anything at runtime.
Notes:
Static address 0x9dc3 is a small table that begins "0x0a 0x0b 0x0c" which directly corresponds to the letters displayed on the screen.
Static address 0xa161 is the table dereference load instruction. Specifically the assembly is "LDA $9db3,Y" where Y is the cursor location. The cursor location is added to the table base address and voila, the correct digit is chosen.
Changes:
We can easily move this table to filler space by modifying the address bytes at 0xa162 (static address). As a test I changed the value 0xb39d at location 0xa162 to the value 0x909c. Addresses are stored little endian for this architecture so that is why the bytes are flipped around.
Now the cursor will be looking for the table at 0x9c90. At 0x9c90 in a hex editor I erased a bunch of 0xff's and replaced it with 0x0a-0x2c, 0x00-0x09, 0x24 (this is the blank spot at the end of the letters, (what you want here for additions).
At this point the cursor moves how you want, the menu is cosmetically fixed with additions, and the values saved are correct. We broke the main menu when we added in a new row of letters so that will need to be fixed at some point.
On my previous post I am not sure why the table addresses differ between 0x9db3 and 0x9dc3. I dont have my Windows boot in front of me. I am sure you will find the table easy enough by searching though.
The difference between 0x9DB3 and 0x9DC3 is 16 bytes, the size of one iNES header. In the MMC1's most common PRG ROM mapping mode, file offsets 0x000010-0x00400F, 0x004010-0x00800F, 0x008010-0x00C00F, ... get mapped to $8000-$BFFF.
Quote:
The difference between 0x9DB3 and 0x9DC3 is 16 bytes, the size of one iNES header. In the MMC1's most common PRG ROM mapping mode, file offsets 0x000010-0x00400F, 0x004010-0x00800F, 0x008010-0x00C00F, ... get mapped to $8000-$BFFF.
Thanks for the sanity! Really cool how things fall into place with computers.
I tried to convert the addresses to decimal, but I still can't find the
offsets to try your changes, Xamboni-san... I feel stupid again.
xamboni wrote:
Ok I finished finding the dereference table. This was a major "shame on me" for not seeing the pattern sooner. The value table for what the cursor selects is just above the boundary logic tests we previously fixed. Bonus points here in that we don't have to disturb memory further as we can relocate the table safely to filler space. Below all addresses are "static" in that these are the raw ROM addresses rather than anything at runtime.
Notes:
Static address 0x9dc3 is a small table that begins "0x0a 0x0b 0x0c" which directly corresponds to the letters displayed on the screen.
Static address 0xa161 is the table dereference load instruction. Specifically the assembly is "LDA $9db3,Y" where Y is the cursor location. The cursor location is added to the table base address and voila, the correct digit is chosen.
Changes:
We can easily move this table to filler space by modifying the address bytes at 0xa162 (static address). As a test I changed the value 0xb39d at location 0xa162 to the value 0x909c. Addresses are stored little endian for this architecture so that is why the bytes are flipped around.
Now the cursor will be looking for the table at 0x9c90. At 0x9c90 in a hex editor I erased a bunch of 0xff's and replaced it with 0x0a-0x2c, 0x00-0x09, 0x24 (this is the blank spot at the end of the letters, (what you want here for additions).
At this point the cursor moves how you want, the menu is cosmetically fixed with additions, and the values saved are correct. We broke the main menu when we added in a new row of letters so that will need to be fixed at some point.
Quote:
I tried to convert the addresses to decimal, but I still can't find the
offsets to try your changes, Xamboni-san... I feel stupid again.
Can you let me know what program you are using so I can try to look at things as well?
The translation to decimal should be 0x9dc3 = 40387. If you are using a program that lets you search for a pattern you can try "0a 0b 0c 0d 0e 0f 10 11 12..." to try and locate the table.
I use HxD and Hex Workshop.
Have a splendid evening, Xamboni-san!
xamboni wrote:
Quote:
I tried to convert the addresses to decimal, but I still can't find the
offsets to try your changes, Xamboni-san... I feel stupid again.
Can you let me know what program you are using so I can try to look at things as well?
The translation to decimal should be 0x9dc3 = 40387. If you are using a program that lets you search for a pattern you can try "0a 0b 0c 0d 0e 0f 10 11 12..." to try and locate the table.
Quote:
I use HxD and Hex Workshop.
Have a splendid evening, Xamboni-san!
Unfortunately I found I can't load those programs easily in Linux. However this led me to find a much better hex compare program called Okteta in Linux. I've been looking for something like this for a very long time as BeyondCompare is beyond broken in Linux.
The only thing I can guess on us having different offsets would be us using different ROMs. I ran some hashing on my ROM so you can compare against it. Make sure you use a clean ROM with no changes in it before running your hashes.
Size: 0x20000 or 131072 bytes
Md5: ef37683ffd049760d0783b364ef0e18f
Sha1: 0b27feac1814b85ed973525e2c2cad55ba618a55
Sha256: 1025adb1c46b3e461aa5ca281a8c5c37a7a95360ed8499b14a141639f72e853b
I'm not sure how to easily run these in Windows. I remember having an entry for checksums when right clicking files though.
Mattiac wrote:
I use HxD and Hex Workshop.
Have a splendid evening, Xamboni-san!
xamboni wrote:
Quote:
I tried to convert the addresses to decimal, but I still can't find the
offsets to try your changes, Xamboni-san... I feel stupid again.
Can you let me know what program you are using so I can try to look at things as well?
The translation to decimal should be 0x9dc3 = 40387. If you are using a program that lets you search for a pattern you can try "0a 0b 0c 0d 0e 0f 10 11 12..." to try and locate the table.
umm... converting to hex to decimal is quite easy with Windows Calculator. Calculator in Windows 10 is extra nice.
After opening Calculator in Windows 10 (it always comes with Windows so no need to download the app): click the three horizontal lines in the upper left, click Programmer, then click the bold "HEX" and hex's A-F keys should work; also Calculator will now calculate with base 16 logic.
Simply enter your hexidecimal number and afterwards your translated decimal value will be beside the bold "DEC".
If you are using an older version of Windows: its Calculator also provides Hex to Dec translation, but it isn't as easy or attractive.
p.s. If using Windows 10's Calculator be sure to play with the Bit toggling keypad in Programmer: click the dotted graphic to the left of "QWORD".
To exit Bit toggling keypad: click the dotted graphic to the left of the Bit toggling keypad graphic you just clicked to enter this mode.
I'm sorry for my late reply, Xamboni-san, but I had problems with my printer that took up some time to fix.
You gave me the address 0x9e13 and that corresponded to the address 00009E10 in my ROM where I changed C7 to D7. Earlier I mean.
I use the PAL version of Zelda 1 that I extracted from the WAD files from Wii. What version do you have?
I thought that the offsets would be the same in every file because I thought it was a simple list from 1-100 or maybe 1-50 if it's a smaller file. I guess I thought wrong...
Do you like fighting games (Street Fighter for example), Xamboni-san?
I wish to thank Unregistered-san for taking time and inform me! I use Windows 7 64-bit Enterprise SP1.
xamboni wrote:
Quote:
I use HxD and Hex Workshop.
Have a splendid evening, Xamboni-san!
Unfortunately I found I can't load those programs easily in Linux. However this led me to find a much better hex compare program called Okteta in Linux. I've been looking for something like this for a very long time as BeyondCompare is beyond broken in Linux.
The only thing I can guess on us having different offsets would be us using different ROMs. I ran some hashing on my ROM so you can compare against it. Make sure you use a clean ROM with no changes in it before running your hashes.
Size: 0x20000 or 131072 bytes
Md5: ef37683ffd049760d0783b364ef0e18f
Sha1: 0b27feac1814b85ed973525e2c2cad55ba618a55
Sha256: 1025adb1c46b3e461aa5ca281a8c5c37a7a95360ed8499b14a141639f72e853b
I'm not sure how to easily run these in Windows. I remember having an entry for checksums when right clicking files though.
Mattiac wrote:
I wish to thank Unregistered-san for taking time and inform me! I use Windows 7 64-bit Enterprise SP1.
You're welcome.
Load Calculator in Windows 7, it's in the Accessories folder, and to convert Hex to Decimal just click the open white circle next to (to the left of) "Hex". Then enter your Hex value; finally, click the open white circle next to (to the left of) "Dec". The Decimal equivalent should now be displayed on your Calculator's screen.
Calculator can also be switched into binary mode "Bin" or octal mode "Oct", but octal isn't used (not used generally, but I don't know if it's even possible/beneficial to use octal) on the nes.
FYI: Near the top of asm6's README.TXT it lists symbols for specifying Hexidecimal and Binary numbers, but Octal numbers are ignored.
Mattiac wrote:
I'm sorry for my late reply, Xamboni-san, but I had problems with my printer that took up some time to fix.
You gave me the address 0x9e13 and that corresponded to the address 00009E10 in my ROM where I changed C7 to D7. Earlier I mean.
I use the PAL version of Zelda 1 that I extracted from the WAD files from Wii. What version do you have?
I thought that the offsets would be the same in every file because I thought it was a simple list from 1-100 or maybe 1-50 if it's a smaller file. I guess I thought wrong...
Do you like fighting games (Street Fighter for example), Xamboni-san?
I wish to thank Unregistered-san for taking time and inform me! I use Windows 7 64-bit Enterprise SP1.
I'll need a hash of your PAL version so I can confirm it against mine. I am not sure how to get a copy of a WAD for the Wii but I will check into it. Did you follow any steps to dump it from the WAD that I can look into?
I got a ROM SHA-1 using the tool ROM Hasher:
903CB43E70762F0F05E6C40AA8FAFF31DE20590D
http://www.romhacking.net/utilities/1002/The size of my ROM is 131 088 bytes and the
size on disk is 135 168 bytes according to
Windows 7.
There was a webpage with some good information
about extracting a ROM from a WAD file, but I
can't find it now, but there's also this
useful guide:
http://www.youtube.com/watch?v=vFsOjFrdicIMaybe it was this webpage:
https://gbatemp.net/threads/where-are-n ... ds.209930/Have a relaxing weekend, Xamboni-san!
xamboni wrote:
Mattiac wrote:
I'm sorry for my late reply, Xamboni-san, but I had problems with my printer that took up some time to fix.
You gave me the address 0x9e13 and that corresponded to the address 00009E10 in my ROM where I changed C7 to D7. Earlier I mean.
I use the PAL version of Zelda 1 that I extracted from the WAD files from Wii. What version do you have?
I thought that the offsets would be the same in every file because I thought it was a simple list from 1-100 or maybe 1-50 if it's a smaller file. I guess I thought wrong...
Do you like fighting games (Street Fighter for example), Xamboni-san?
I wish to thank Unregistered-san for taking time and inform me! I use Windows 7 64-bit Enterprise SP1.
I'll need a hash of your PAL version so I can confirm it against mine. I am not sure how to get a copy of a WAD for the Wii but I will check into it. Did you follow any steps to dump it from the WAD that I can look into?
Seems like we might be at a breaking point. I am not sure how to get my hands on a European WAD of this game. Let me know if you have any ideas on that problem. Unfortunately if I can't take a look I probably cannot help. If you want to test out my ideas you could probably do that on your end with the European ROM of the game in an emulator.
Open to any ideas.
I've sent you a private message and I think that might offer a solution... Have you read it, Xamboni-san?
xamboni wrote:
Seems like we might be at a breaking point. I am not sure how to get my hands on a European WAD of this game. Let me know if you have any ideas on that problem. Unfortunately if I can't take a look I probably cannot help. If you want to test out my ideas you could probably do that on your end with the European ROM of the game in an emulator.
Open to any ideas.
Quote:
I've sent you a private message and I think that might offer a solution... Have you read it, Xamboni-san?
Thanks for the message. I went and had a look at the ROM hasher tool you mentioned earlier and I think I see what is going on here. The good news is we are dealing with the same file. Unfortunately ROM hasher cuts the ROM header off before running the SHA1 of the file when it prints the second line of output. If you look just above it at the file SHA1 you can confirm we have the same file on both ends.
I will respond to your PM with a solid patch so we can get you off the ground testing the output.
I forgot to add that I also checked the SHA1 with
a webpage and then I got a different checksum:
http://www.fileformat.info/tool/hash.htmMD5 ef37683ffd049760d0783b364ef0e18f
SHA-1 0b27feac1814b85ed973525e2c2cad55ba618a55
SHA-256 1025adb1c46b3e461aa5ca281a8c5c37a7a95360ed8499b14a141639f72e853b
xamboni wrote:
Quote:
I've sent you a private message and I think that might offer a solution... Have you read it, Xamboni-san?
Thanks for the message. I went and had a look at the ROM hasher tool you mentioned earlier and I think I see what is going on here. The good news is we are dealing with the same file. Unfortunately ROM hasher cuts the ROM header off before running the SHA1 of the file when it prints the second line of output. If you look just above it at the file SHA1 you can confirm we have the same file on both ends.
I will respond to your PM with a solid patch so we can get you off the ground testing the output.
Excellent, Xamboni-san! THANK YOU!
xamboni wrote:
I sent you my patch.