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

Read Raster Position?

Read Raster Position?
by on (#52487)
Can you do it on the NES?

by on (#52488)
Nope.

Only through mappers can you find a semi-automated way to count scanlines. Perhaps others here will helpfully list mappers that DO have scanline interrupts.

by on (#52492)
Ways to read some approximation of raster position:
  • Read $2002 for whether sprite 0 has overlapped the background since the top of this frame. Super Mario Bros. uses this.
  • Read $2004 for sprite overflow.
  • Read $2004 to access internal OAM bus. Micro Machines uses this.
  • If you're not using the DPCM channel for audio, you can use its (primitive) timer IRQ, possibly in connection with sprite 0. Fire Hawk uses this.
  • MMC3 IRQ triggers after a given number of bursts of fetches from $1000-$1FFF. Ordinarily, the pattern tables are arranged to give one such burst per scanline from sprite pattern fetches. Super Mario Bros. 3 uses this.
  • Numerous mappers that are more common in Japanese games, such as FDS, Sunsoft's FME-7, and some Konami VRCs, have timers that count CPU cycles. These would need to be adjusted for a PAL NES.
  • MMC5 watches the entire PPU's operation for a fairly reliable scanline counter. (IMHO, MMC5 is an attempt to introduce Game Boy features to the NES.)

by on (#52495)
:) Astounding knowledge as always Tepples.

I thought of quite a neat idea for the "play head" in my tracker and did a quick bit of rough timing code to prove it looks good. My idea was to have a 8 pixel high raster effect that changes the emphasis bits. The position of the raster bar would be the current step of the sequence.

The problem is, once I have other stuff in my NMI (DMA routine for screen refreshing etc.) the timing is not as predictable and therefore not as easy to push the raster bar down the screen using loop delays.

Any clever ideas?

by on (#52497)
A sprite 0 hit would probably work best for timing a raster bar. You can put it at any position, as long as you draw opaque pixels of sprite 0 in front of or behind opaque pixels of the background. Wait for a sprite 0 hit, overwrite the PPU tint bits, wait a few more hundred cycles, and change them back. One thing you do have to watch when doing sprite 0 is how much processing you do above and below sprite 0: you should finish processing before sprite 0 hit happens, and then you should finish processing before vertical blanking happens. If the Y position of sprite 0 will vary considerably, you'll need to schedule various subroutines to be called above or below the split depending on the position and how long they usually take.

by on (#52501)
Sprite zero hit actually has two functions:
Bit turns on when you when you hit Sprite 0.
Bit turns off when vblank ends.
So as long as sprite zero will hit, you can also find out when Vblank has started.

by on (#52502)
tepples wrote:
[*]MMC5 watches the entire PPU's operation for a fairly reliable scanline counter. (IMHO, MMC5 is an attempt to introduce Game Boy features to the NES.)


what do you mean exactly by introducing gameboy features.
What exactly ? :) (my megaman 3 rom hack uses the mmc5 mapper) well i was just curious what you meant about gameboy specific things.

by on (#52508)
neilbaldwin wrote:
:) Astounding knowledge as always Tepples.

Agreed. Where did it all come from? 8) Please, oh please, tell us your story, Mr. Tepples. [disappointing...there's no emot for 'in awe'].
neilbaldwin wrote:
The problem is, once I have other stuff in my NMI (DMA routine for screen refreshing etc.) the timing is not as predictable and therefore not as easy to push the raster bar down the screen using loop delays.

Any clever ideas?

In a typical tracker the raster bar effect is stationary in the middle of the screen and the sequences glide upward as the song is playing. Perhaps make the raster bar stationary [use MMC3 IRQ, sprite 0, whatever] and use $2005/$2006 writes to scroll the sequences?

by on (#52519)
kuja killer: The MMC5 feature that most made me think of the Game Boy was the vertical split screen. It keeps the right side of the screen stationary while vertically scrolling the rest, as seen in Quarth and DDR for Game Boy.

NESICIDE wrote:
neilbaldwin wrote:
:) Astounding knowledge as always Tepples.

Agreed. Where did it all come from? 8)

For one thing, reading every English doc on the front page and then writing some test case programs. Since the wiki was started, I've been incorporating new findings (such as the double clock glitch when reading the controller and playing samples) into the wiki, and that means reading pretty much every page that anyone put on the wiki.

A problem with MMC3 is the lack of a 72-pin counterpart to HVC-TNROM, the only MMC3 board with CHR RAM and PRG RAM. So if your program's on-screen text is primarily in any language other than Japanese, you have to choose between CHR ROM and PRG RAM or CHR RAM and no PRG RAM. That, along with the availability of SNROM-clone boards (with MMC1 mapper) from RetroZone, is a reason that I haven't tried to find clever MMC3 tricks lately.

by on (#52528)
NESICIDE wrote:
In a typical tracker the raster bar effect is stationary in the middle of the screen and the sequences glide upward as the song is playing. Perhaps make the raster bar stationary [use MMC3 IRQ, sprite 0, whatever] and use $2005/$2006 writes to scroll the sequences?


Doh!

:)