Question for Keisan Game: Sansuu 1 Toshi

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?

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?

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".

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?

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!

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

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.

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!

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.

I resolved the hack - but through the hex editor.

Thanks for your help, everyone!

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.

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.

Cool, that's probably the one I was thinking of then.

OK, I cleaned up a little lua script I wrote a while ago to display sprite information in FCEUX:

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.

The mouse-over feature you added to that is really neat.


I actually added the "value to be written" to FCEUX's Lua callbacks, and wrote a simpler script to visualize sprites.

It was after the last stable release, but you can get bleeding edge versions at EmuCR: FCEUX SVN r3320


There was also a brief thread about a year ago discussing Lua scripts for visualizing sprites, just in case it's useful for reference: thread

Cool! I'm not exactly proud of the way I'm detecting the written value.


That was probably when I tried to write my own implementation of the script, but it remained unfinished until last night!