[bri]

Hello,
NES Tetris has a DAS counter value between 0 to 15 which is stored in memory at 0x46.  I want to modify the game to show the current value of this counter visually on the screen (either in numeric form, or with a visual status bar). 

I'm looking for some advice on the best way to go about this.  I have read a lot on 6502 assembly and I believe I can write the code to do this, however I have a couple of questions:

1 - How do I insert new assembly code in to an existing ROM?  Does the whole rom have to be disassembled, the new code added, and then assembled again?  Or is there a easier way to add in new asm code?

2 - How do I find the best location to put the new code for this? 

Thanks in advance.

[Dr. Floppy]

1 - How do I insert new assembly code in to an existing ROM?  Does the whole rom have to be disassembled, the new code added, and then assembled again?

No. That's actually the least efficient process! All you need to do is write your new code and insert it somewhere in the NMI Routine. Which brings us to:

2 - How do I find the best location to put the new code for this?

Writes to PPU-RAM (onscreen visuals) must be done during the V-blank interval between frames. This is best done by tapping into the NMI Routine, the starting address of which is stored at CPU Address $[FFFA-B].

Where (precisely) onscreen do you want these numerical tiles to appear?

[bri]

Thanks for the info!!

Are there any tutorials on how to assemble new code and then insert it?  I've looked online but can't find very much info on this.  Do I write the new assembly and then use a cross assembler, and then take that and insert it in to the NMI routine? 

I would put it down at the bottom center of the screen. 

[Dr. Floppy]

Are there any tutorials on how to assemble new code and then insert it?  I've looked online but can't find very much info on this.  Do I write the new assembly and then use a cross assembler, and then take that and insert it in to the NMI routine?

 

I can walk you through the process. At least 75% of it is merely designing a new routine to do (1) what you want, (2) when you want it. The rest is examining the NMI Routine for a decent insertion point, then manually typing in the new code via Hex Editor. No assemblers, disassemblers, capdapplers and/or schmendlers will be necessary! 

Concept Time: NES games are displayed by an electron gun firing a beam against a picture tube which draws the onscreen image left-to-right, top-to-bottom. Once all 240 lines are drawn, a special signal is sent to the NES which informs it that the electron gun is resetting itself for the next framedraw. This is called V-Blank, and it's a very special moment in time. (If you want to use "scanline" as a unit of time, V-Blanks last about 23 such units.) The NES outputs 60 frames per second.

NES games operate by following a Main Program Loop. During framedraw, the MPL runs a series of checks to determine what's happening in-game at that precise moment, and what needs to be done to keep it happening according to the in-universe "rules". Once it gets thru this checklist, it goes into a sort of hover pattern until the framedraw is complete and that special V-Blank signal is sent.

When that happens, the NES activates something called the Non-Maskable Interrupt (NMI), which is a fancy way of saying "Ultra-special checklist of important shit to do between frames". Onscreen images can only be updated by writing to the NES' Picture Processing Unit (PPU), and that can only happen during V-blank. Thus, NMI Routines are designed to take advantage of this critical period. If designed correctly, they'll end with time to spare and the MPL will begin its checklist prior to the electron gun starting the next framedraw. (This is why most games put their music/sound handlers at or near the very beginning of MPL.)

I know this is a lot to digest at once, but by doing so you'll find the forthcoming procedure to make a lot more sense.

[Trax]

For what Bri is looking for, I wouldn't use the NMI routine. I'm not saying that inserting stuff in the NMI call is bad, but you still have to make sure that your new code happens after the other code that is executed to update the hud, which is the specific part that we want to alter...

It's also possible that some part of the CPU RAM is transfered to the PPU or the Sprite RAM through a DMA call. This means that anything happening after this call may not have any effect on screen...

I'd try to find the code where the hud is updated, create a bridge (near the end if possible), then insert the new code to display whatever you want to display on screen...

[Dr. Floppy]

HUD?

Writes to PPU-RAM must occur during V-blank. Adding the desired information to the Sprite OAM at $200 (which can occur during framedraw if intended for the subsequent frame) is probably the best way to go about this.