edit text ppu

[Bavi_H]

I did as you wrote but it didn't show the [] tiles

In the PPU Viewer, right click on the left or right area of the Pattern Tables to change the color palette.

In this case, several of the color palettes are all black so nothing shows up. Once you change to a palette that isn't all black, you will see the tiles.

[TheBoxGamePL]

I give up

[Bavi_H]

The palettes are shown at the bottom of the PPU Viewer. Each time you right click on one of the Pattern Tables, it will change to the next palette.

In your picture, you need to right click 3 times on each Pattern Table to get to a palette that is not all the same color.

[TheBoxGamePL]

Thanks

[TheBoxGamePL]

BINGO and what now

[TheBoxGamePL]

I made all the tables that were there and searched for it but I didn't find words like complete game over

[Bavi_H]

Another small tip: In the PPU Viewer window, you check the box "Sprites 8x16 mode". That will arrange the tiles into 8x16 pixel groups and make the letters easier to see.

These steps so far were a workaround for the lack of a Sprite Viewer. The results so far have helped show the game is using sprites to put the letters on the screen.

As a reminder, as tepples said, because the game uses sprites to display the letters, this means it can only put 8 letters in the same horizontal row:

If you see the "GAME OVER" letters [are made out of sprites], you won't be able to make "END OF GAME" [...] because the text is written with sprites, and only 8 sprites can be displayed on the same scanline.

What are the next steps? Now that we have compensated for the lack of a Sprite Viewer, I think the rest of tepples's post is a good overview of the kind of steps that will be needed next:

Methods that game engines use to draw sprites differ more than how they draw text to the nametable. You'll probably need to do a lot more reverse engineering of the program code, working backward from the output (sprites on screen) to the input (metasprite tables in ROM). First you'll need to figure out where in RAM the game stores its 256-byte "shadow OAM" (display list where the CPU builds sprite positions). Put a write breakpoint on $4014; any value written is the high byte of the starting address of shadow OAM. For example, many games write $02, which causes the CPU to copy 512 bytes from $0200-$02FF to object attribute memory (OAM) on the PPU. Then by correlating PPU Viewer, Sprite Viewer, and Hex Editor, you can find where in RAM it writes the sprites. By putting a write breakpoint on addresses in shadow OAM, you can find what code is writing to shadow OAM and what table it's reading in ROM.

If you want to learn how to set a breakpoint, the FCEUX manual might be helpful. In FCEUX, you can go to the Help menu and select the Help command to bring up the help manual. In the manual you can open the book for "Debug", click on the page "Debugger", then scroll down to the section for "Breakpoints".

(You can also read the manual online: FCEUX Help, but be aware the online manual is for the most recent version.)

[TheBoxGamePL]

What next

[TheBoxGamePL]

the problem is that I don't know how to create a table whether
40=A
41=A

or just
40=A
41=B

[segaloco]

So reading over more of the thread, I think what folks have been trying to say (that I missed myself, duh, the words are 2x CHR tall) is that this is not a typical case of text encoding. What I was describing was the much more typical text scenario where text is a series of individual tiles per character and the encoding is just a linear array of the character IDs in order, like ASCII but mapped to where the tiles are in CHR.

In this case, it sounds like the text is actually being assembled from OBJ CHR rather than BG CHR so all bets are off regarding a text encoding. In fact, unless they have the CHR to assemble 2x2 or whatever size of every letter, then it's unlikely any of that text is encoded /as text/ anywhere in the code. In other words, you're not going to find the word "CONTINUE" in any sort of encoding because it's probably not looking at text and then assembling the letters dynamically, there's probably a specific routine that clobbers the words together in OAM, like "jsr render_continue" or "jsr render_game_over". You'd need to go looking through the code for areas where the tile IDs of OAM entries are being set to the indices of the OBJ CHR tiles that make up the word. Sorry I misled with the encoding stuff, that is true for the majority of text in NES titles but this is a situation where it's not.

Long story short, you're probably not going to simply find those strings to edit, you're dealing with a finite number of "letter pieces" which are explicitly intended to be put together into those exact words. You'd need to create new letter pieces and edit the OAM assembly functions to create new text, not nearly as trivial as editing text made up of individual BG CHR entries.