It is currently Fri Dec 15, 2017 7:20 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sun Oct 16, 2016 12:33 pm 
Offline

Joined: Fri Nov 15, 2013 5:45 am
Posts: 8
I am unable to remove the "1" character in the title screen of "Keisan Game: Sansuu 1 Toshi".

I have attempted to identify the assembler code by viewing the Name Table Viewer (in FCEUX). Unfortunately, it does not appear.

Is there an easy way to find and identify the "1" title graphic in the assembler code?


Top
 Profile  
 
PostPosted: Sun Oct 16, 2016 6:01 pm 
Offline
User avatar

Joined: Sun Dec 12, 2010 10:27 pm
Posts: 298
Location: Hong Kong
I haven't checked that out, but if it doesn't appear in the name table, it is possible that the '1' character is formed by sprites, so you may check that. I think you can also view the sprite table in Fceux?


Top
 Profile  
 
PostPosted: Sun Oct 16, 2016 7:19 pm 
Offline

Joined: Fri Nov 15, 2013 5:45 am
Posts: 8
I was able to find the assembler code on the PPU Viewer table. Removing the graphic "1" would ruin the gameplay... so I assume that there is another code for the placement of that graphic.

By the way, here is a screenshot of the translated game and the PPU Viewer table.

Again, my objective for this project is to remove the "1" for the title "Grade 1 Math Games".


Attachments:
File comment: Screenshot
FGM-0.png
FGM-0.png [ 2.38 KiB | Viewed 2026 times ]
File comment: PPU Viewer with "culprit graphic" highlighted.
1.PNG
1.PNG [ 18.93 KiB | Viewed 2026 times ]
Top
 Profile  
 
PostPosted: Sun Oct 16, 2016 10:54 pm 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 466
Location: Denmark (PAL)
The PPU viewer window doesn't display assembler codes.

You will have to open the debugger and find the place where the game adds the sprites that form the character.

It probably pushes its sprites using the OAM DMA with a write to $4014 (though for a math game it's probably not necessary). Set a breakpoint for writes to that address and make note of the number it writes. For example if it writes $02, its sprite buffer will be in the $0200-$02ff area of memory. Try editing this memory just before the DMA write to see different results on the next frame.

If the game doesn't use DMA, you're gonna have to look for writes to the OAMADDR and OAMADDR ($2003 and $2004) registers. I'm pretty sure all of these are labeled in Fceux.

Ps. You're gonna have to understand these assembler codes before editing them, but I'm guessing getting into that is the core of your project?


Top
 Profile  
 
PostPosted: Mon Oct 17, 2016 6:55 am 
Offline

Joined: Fri Nov 15, 2013 5:45 am
Posts: 8
I was hoping to do some simple edits in the assembler code, but I'll look into the debugger program. I am unfamiliar with using this program, but I'll give it a shot and let you know if I make any progress.

Thanks for the advice!


Top
 Profile  
 
PostPosted: Mon Oct 17, 2016 7:15 am 
Offline
User avatar

Joined: Thu Sep 15, 2016 6:29 am
Posts: 466
Location: Denmark (PAL)
It should definitely be possible with a couple of simple edits to the assembler code.

But "assembler code" is what you see in the debugger, it's not the graphics data :)


Top
 Profile  
 
PostPosted: Mon Oct 17, 2016 7:32 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
A quick debug of this game shows that the "1" is indeed a sprite, which is covering some garbage background tiles. To properly get rid of it you'll have to hide the 4 sprites that make up the number (give them a Y coordinate of 239 or higher), and also patch the background data to use the blank tiles instead of the garbage tiles in that space. The steps for this are the following:

1- Open the name table viewer, put the cursor over the garbage tiles and take note of their addresses and IDs;

2- Open the CPU debugger and create breakpoints for writes at the PPU addresses you wrote down;

3- Reset the game and wait for the breakpoints to trigger. When they do, check if the values being written are the ones you wrote down previously. If so, look at the previous instructions in the disassembly to see where the value are being read from, and take note of the addresses;

4- Change the tile IDs in those addresses to the ID of the blank tile using an hex editor (FCEUX has a built in hex editor you can use). The background should be fine now.

As for the sprites, this games uses $0200-$02FF as the OAM buffer, so this is where all sprite attributes can be found. Create a breakpoint for writes in this memory range to find out where the Y coordinates for those 4 sprites are coming from, and then patch the code or data to change it to 239 or more.


Top
 Profile  
 
PostPosted: Mon Oct 17, 2016 8:59 am 
Offline

Joined: Fri Nov 15, 2013 5:45 am
Posts: 8
Yes, I was able to remove the background garbage tiles easily, but my main problem was removing the sprites in the foreground, which were not accessible in the Table Viewer. Again, I'll try to locate the register(?) values of the buffer and see if I can relocate that "1" graphic. Thanks!


Top
 Profile  
 
PostPosted: Mon Oct 17, 2016 12:35 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Immutable wrote:
Again, I'll try to locate the register(?) values of the buffer and see if I can relocate that "1" graphic.

I hope I'm not being rude, but you do seem to be throwing around expressions you apparently don't know the meaning of, such as "assembler code", and that's a bit confusing. Let me try to clear this up:

"Assembly (not -er) code" is the source code of a program, which an assembler (now it's -er, because this is a program that assembles) will turn into binary code. The binary code is what goes in the ROM, but a debugger might disassemble it on the fly to show you a more readable version of the program.

"Registers" are small pieces of memory inside a computer chip necessary for it to perform its tasks. The CPU has A, X, Y, S, P and PC, the PPU has two address registers plus a bunch of other stuff, mappers use registers to keep track of the banks that are mapped in, to count scanlines, and so on. We also use the term "register" to refer to the memory-mapped ports the CPU uses to communicate with other hardware, even if they don't necessarily have a matching internal register.

Sprite attributes are not registers, and neither is the memory at $0200-$02FF. $0200-$02FF is just a buffer, a temporary place where the sprite attributes are stored before they're sent to the PPU. A DMA will copy those attributes to memory inside the PPU, where they'll be processed as the screen renders so the PPU knows where to draw the sprites.

Unfortunately, FCEUX doesn't help much when it comes to debugging sprites. But you can open the game in Nintendulator for example, and its PPU debugger will show you all the sprites that are currently in use. From that you can tell what part of the OAM buffer is used for the sprite in question, so you can set your breakpoints accordingly. Fortunately, in this game, it looks like the sprites always occupy the same slots, so it should be easy to find the the code that populates them. Other games might cycle OAM slots every frame, making the source of a particular sprite's data harder to locate.


Top
 Profile  
 
PostPosted: Mon Oct 17, 2016 4:17 pm 
Offline

Joined: Fri Nov 15, 2013 5:45 am
Posts: 8
I resolved the hack - but through the hex editor.

Thanks for your help, everyone! :)


Top
 Profile  
 
PostPosted: Mon Oct 17, 2016 8:16 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3968
Oddly enough, PocketNES + NO$GBA does a great job at finding sprites. NO$NES might also have a similar feature.
I think Nintendulator also has an OAM viewer?

Edit: yeah, use Nintendulator for finding information about sprites on the screen.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Mon Oct 17, 2016 9:23 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Nintendulator is OK for this, but it still doesn't give you any visual indication of what sprite is used where in the screen, you have to deduce this from the sprite's attributes and appearance. I vaguely remember an emulator (not even sure it was an NES one) having red lines connecting the sprites in the OAM preview to their on-screen versions.


Top
 Profile  
 
PostPosted: Mon Oct 17, 2016 9:36 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
tokumaru wrote:
Nintendulator is OK for this, but it still doesn't give you any visual indication of what sprite is used where in the screen, you have to deduce this from the sprite's attributes and appearance. I vaguely remember an emulator (not even sure it was an NES one) having red lines connecting the sprites in the OAM preview to their on-screen versions.

NO$NES will display OAM details, and draws red lines to sprites depicting where they are when mousing over them. Proof attached.


Attachments:
screenshot.png
screenshot.png [ 45.67 KiB | Viewed 1889 times ]
Top
 Profile  
 
PostPosted: Tue Oct 18, 2016 12:49 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Cool, that's probably the one I was thinking of then.


Top
 Profile  
 
PostPosted: Tue Oct 18, 2016 9:26 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
OK, I cleaned up a little lua script I wrote a while ago to display sprite information in FCEUX:
Attachment:
nes-sprites.lua [4.72 KiB]
Downloaded 50 times

It detects the sprite height and the OAM page automatically (this is a little hacky, but appears to work just fine), and draws boxes around every sprite on the screen. You can hover the cursor over a box to get more information about a sprite. It only works for sprites transferred by $4014 DMA, from position $00 (which is what the vast majority - if not all - commercial games do), $2003 and $2004 are completely ignored. There might be bugs, I didn't test this thoroughly.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 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