It is currently Sun Aug 25, 2019 8:39 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 49 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Sat Jul 20, 2019 9:08 am 
Offline

Joined: Sun Jun 16, 2019 7:00 am
Posts: 19
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.


Top
 Profile  
 
PostPosted: Thu Jul 25, 2019 10:18 pm 
Offline

Joined: Sat Apr 27, 2019 11:56 am
Posts: 33
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.


Top
 Profile  
 
PostPosted: Fri Jul 26, 2019 1:08 pm 
Offline

Joined: Sun Jun 16, 2019 7:00 am
Posts: 19
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.


Top
 Profile  
 
PostPosted: Tue Jul 30, 2019 8:32 am 
Offline

Joined: Sat Apr 27, 2019 11:56 am
Posts: 33
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.


Top
 Profile  
 
PostPosted: Tue Jul 30, 2019 9:27 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21564
Location: NE Indiana, USA (NTSC)
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.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Tue Jul 30, 2019 8:06 pm 
Offline

Joined: Sat Apr 27, 2019 11:56 am
Posts: 33
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.


Top
 Profile  
 
PostPosted: Sun Aug 04, 2019 1:08 pm 
Offline

Joined: Sun Jun 16, 2019 7:00 am
Posts: 19
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.


Top
 Profile  
 
PostPosted: Mon Aug 05, 2019 10:03 am 
Offline

Joined: Sat Apr 27, 2019 11:56 am
Posts: 33
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.


Top
 Profile  
 
PostPosted: Tue Aug 06, 2019 11:08 am 
Offline

Joined: Sun Jun 16, 2019 7:00 am
Posts: 19
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.


Top
 Profile  
 
PostPosted: Wed Aug 07, 2019 8:31 pm 
Offline

Joined: Sat Apr 27, 2019 11:56 am
Posts: 33
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.


Top
 Profile  
 
PostPosted: Fri Aug 09, 2019 3:45 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1034
Location: cypress, texas
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.


Top
 Profile  
 
PostPosted: Mon Aug 12, 2019 1:08 pm 
Offline

Joined: Sun Jun 16, 2019 7:00 am
Posts: 19
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.


Top
 Profile  
 
PostPosted: Mon Aug 12, 2019 3:57 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1034
Location: cypress, texas
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. :)


Top
 Profile  
 
PostPosted: Wed Aug 14, 2019 8:55 am 
Offline

Joined: Sat Apr 27, 2019 11:56 am
Posts: 33
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?


Top
 Profile  
 
PostPosted: Fri Aug 16, 2019 7:08 am 
Offline

Joined: Sun Jun 16, 2019 7:00 am
Posts: 19
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=vFsOjFrdicI

Maybe 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?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 49 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group