Question for Keisan Game: Sansuu 1 Toshi

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

Immutable
Posts: 8
Joined: Fri Nov 15, 2013 5:45 am

Question for Keisan Game: Sansuu 1 Toshi

Post by Immutable »

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?
User avatar
Gilbert
Posts: 564
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Re: Question for Keisan Game: Sansuu 1 Toshi

Post by Gilbert »

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?
Immutable
Posts: 8
Joined: Fri Nov 15, 2013 5:45 am

Re: Question for Keisan Game: Sansuu 1 Toshi

Post by Immutable »

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
Screenshot
Screenshot
FGM-0.png (2.38 KiB) Viewed 7475 times
PPU Viewer with "culprit graphic" highlighted.
PPU Viewer with "culprit graphic" highlighted.
User avatar
Sumez
Posts: 919
Joined: Thu Sep 15, 2016 6:29 am
Location: Denmark (PAL)

Re: Question for Keisan Game: Sansuu 1 Toshi

Post by Sumez »

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?
Immutable
Posts: 8
Joined: Fri Nov 15, 2013 5:45 am

Re: Question for Keisan Game: Sansuu 1 Toshi

Post by Immutable »

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!
User avatar
Sumez
Posts: 919
Joined: Thu Sep 15, 2016 6:29 am
Location: Denmark (PAL)

Re: Question for Keisan Game: Sansuu 1 Toshi

Post by Sumez »

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 :)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Question for Keisan Game: Sansuu 1 Toshi

Post by tokumaru »

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.
Immutable
Posts: 8
Joined: Fri Nov 15, 2013 5:45 am

Re: Question for Keisan Game: Sansuu 1 Toshi

Post by Immutable »

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!
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Question for Keisan Game: Sansuu 1 Toshi

Post by tokumaru »

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.
Immutable
Posts: 8
Joined: Fri Nov 15, 2013 5:45 am

Re: Question for Keisan Game: Sansuu 1 Toshi

Post by Immutable »

I resolved the hack - but through the hex editor.

Thanks for your help, everyone! :)
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Question for Keisan Game: Sansuu 1 Toshi

Post by Dwedit »

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!
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Question for Keisan Game: Sansuu 1 Toshi

Post by tokumaru »

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.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Question for Keisan Game: Sansuu 1 Toshi

Post by koitsu »

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
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Question for Keisan Game: Sansuu 1 Toshi

Post by tokumaru »

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

Re: Question for Keisan Game: Sansuu 1 Toshi

Post by tokumaru »

OK, I cleaned up a little lua script I wrote a while ago to display sprite information in FCEUX:
nes-sprites.lua
(4.72 KiB) Downloaded 69 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.
Post Reply