This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

NMI-synchronized text box demo

by on (#64134)
OK it's done now I updated ROMs and sources of my window demo updated with Blargg's synchronization:
The "old" versions use simple sprite #0 hit, but the NTSC version glitches on real HW (altough it looked fine in both Nintendulator and Nestopia).

The source is a big pile of junk btw but it's there. Tested & glitchless on both NTSC and PAL, Nestopia seems pretty accurate at emulating both.
Although, even with Blargg's synchronization, I had to place 2 blank tiles before the end of the screen and 1 blank tile after it to get this glitch-less. Maybe I did something wrong ? With NTSC only 1 blank tile before the end was necessary, but I wanted it to be dual NTSC/PAL anyways.

by on (#64156)
I found the timing problems in Bregalad's demo. Here are just the fixed NTSC/PAL ROMs:


The apparent garbage is the character images used for the window. Not sure why he had them looking like that. In fine-tuning the timing, even adjusting the CPU delays by +/- 1 cycle resulted in slight glitching. So this NMI synchronization technique is critical to fitting within the window for this effect.

I also tried the NMI sync demos on Nestopia. The NTSC one's line was too far to the right by a couple of pixels, and the PAL one's was within the range a NES gives. I believe that Nestopia is handling the NMI sync code correctly, it's just emulating the $2001 grayscale bit with timing slightly off. Other PPU writes are probably emulated more accurately, so Nestopia is probably accurate enough for testing things that use this technique. I'll have to do more thorough testing when I'm back on my Linux machine tomorrow.

by on (#64187)
I'm going to apply this to to see if I can stabilize it in Nestopia. The demo is stable in PAL NES but shakes horizontally in the latest Nestopia. It was some pretty dirty trial&error though so I wasn't too surprised. Probably comes down to very small details. So yeah, we're still not quite there when it comes to emulation accuracy.

by on (#64188)
tokumaru wrote:
tepples wrote:
and it's not even really wasting if you defer computation of some of the written values until that line.

The code I use takes significantly less than a scanline:

   ;start setting the scroll before the horizontal blank (48 cycles)

But yeah, it makes sense to do these operations as the scanline is rendered, and have the final writes fall within HBlank. That way only a portion of the time will be wasted.

Hmm, I had no idea the first two writes could be done while rendering (or forgot). Then again it wouldn't help much with the rasterbars demo I mentioned in the previous post because I need to change the palette through $2006 also...

by on (#64199)

The apparent garbage is the character images used for the window. Not sure why he had them looking like that

Not sure why you had them looking like that. Your file was somehow corrupted.

I uploaded it with Blarg's correcgtions (# of cyces before sta $4014 in NMI) - but it doesn't make a big difference to me. I was hoping I could make the window bigger (with smaller margin for glitches) so I tried to make the window 30 tile wide, only 8 tiles blank at each edge for glitches. Unfortunately, I always get small glitches on the right, and I even get them on both sides on PAL. Is there a way I can know if I successfully did the full synchronization or not ?

by on (#64201)
OK, I figured if I wanted to "allow" the left 8 tiles to be glitched, I'd have to have my second $2006 write fall "during the first tile" and write the adress of the SECOND tile. But then the PPU scrolls from the second tile at the next scanline so I had to add a $2005 write in the cases where the palette wasn't rewritten to have normal scroll.

Yet I still can't get rid of the glitches. I've had setups without glitches on Nestopia, but with glitches on HW, and this for both NTSC and PAL.

I uploaded everything on :
Blargg, I uploaded the .chr file btw.

by on (#64226)
I eliminated glitching on NTSC, and it only occasionally occurs very slightly on the right side of PAL. The image is shifted left a bit, but I couldn't help that. ROMs + source (PAL image on right):

Image Image

Aside: interesting how PAL forces color to black in hblank area, but NTSC doesn't.

by on (#64282)
Yeah this is weird - the overscan area is never visible on PAL anyway, a few pixels are even cropped left & right (2 pixels I think, but some monitors crop more).

I'm relived that the "BG color overflows on the sides" effect is not due to the fact I have a top loader. Almost remember me the border of the C64 which can be tricked to show some graphics in.

And I guess it is not possible to have it centered then.

by on (#64283)
Well, you could always just make the text box 29 characters wide, rather than 30 like above. Since I had to offset them 4 pixels left, 29 characters is centered.

by on (#64284)
I wonder if this would be useful for a "semitransparent" text box overlay if you take the average color of the pixels behind each scanline before drawing the box.