Any research done on writing to oam durring active display?

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Any research done on writing to oam durring active displ

Post by Drew Sebastino »

93143 wrote: If (a) the internal/PPU-side OAM address auto-increments after a CPU-side write during HBlank
If it doesn't, you're only writing to sprite 0's X position? :lol: I kind of wonder why you wouldn't think it would though. What would be the point in changing the behavior?
93143 wrote:(b) the PPU caches the data it reads from OAM during active display, rather than reading it again during HBlank
You're talking about those potentially unused 84 "dot cycles"? As nice as it would be, I don't see this happening. How could "step 1" In the Fullsnes document take 256 cycles, while steps 2 and 3 do not take a single one?
byuu wrote:Uniracers is the only game that does it, and I suspect they got really lucky that it worked at all
They sent the data for changing sprite 1 and 2's position in HiOAM just as it was being scanned by coincidence?
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Any research done on writing to oam durring active displ

Post by 93143 »

Well, I tried it, and no joy. At least, not with the scanline basically full of sprites... It seems the PPU does in fact read OAM during HBlank, because on real hardware the writes are ending up all over the place. In higan, they all go to the highest HiOAM address actually used on the scanline (NOT the top of HiOAM like I thought), which implies the same thing if you think about it in context.

(Take this result with a grain of salt - I didn't do too much double-checking, so I may have screwed something up.)

I'd try to check for address incrementing, but it's late. Maybe tomorrow I'll try on a scanline without any sprites and see what it does...
Espozo wrote:If it doesn't, you're only writing to sprite 0's X position?
No, it wouldn't even get that far, not even if sprite 125 or higher was on that particular scanline. It would repeatedly write to the last HiOAM byte the PPU looked at (assuming sprite rendering was finished - if not, it would go wherever the PPU was reading at the moment).
As nice as it would be, I don't see this happening.
Well, it doesn't. It would have been nice if the PPU had turned out to internally cache the OAM data for the 32 sprites on the scanline, rather than having to read it again during HBlank, but I guess the designers figured there was no point adding extra circuitry just so that OAM could sit idle for 85 dot-cycles per line...
They sent the data for changing sprite 1 and 2's position in HiOAM just as it was being scanned by coincidence?
More probably they sent the data after sprite rendering was finished, and the internal address had been left at that byte by the PPU.

byuu wrote:The only viable trick with OAM mid-frame is a trick that some games use to make an entire background from sprites alone: you can change the tiledata address at the halfway point, but leave all the sprite attribute data alone.

It's not very useful. Yet several games do this for no reason: Megalomania OP, Winter Games main menu, etc.

You might find a use in making a static 256x224 background while using Mode7 as a giant single rotating sprite.
Are you serious? Actual games do that?

I thought it was just that one demo, and it didn't even do it right (used HDMA rather than a mid-line IRQ, thus interrupting rendering and causing glitches)... I was so proud of figuring out the right way to do it, too...

My (glacially proceeding) shmup port uses this trick for a Super FX layer on top of a Mode 7 background, which is why I was investigating it.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Any research done on writing to oam durring active displ

Post by tepples »

93143 wrote:
byuu wrote:You might find a use in making a static 256x224 background while using Mode7 as a giant single rotating sprite.
Are you serious? Actual games do that?
A static background plane behind a mode 7 main playfield is seen in On the Ball/Cameltry. And about half the bosses in Super Mario World, from when mode 7 was a brand new gimmick, likewise are drawn as a mode 7 layer with sprites for terrain.
My (glacially proceeding) shmup port uses this trick for a Super FX layer on top of a Mode 7 background, which is why I was investigating it.
The same technique used in the title screen of Yoshi's Island, correct?
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Any research done on writing to oam durring active displ

Post by 93143 »

Yeah, but what I believe he's talking about is specifically changing OBSEL partway down the screen, so as to access more than 16 KB of sprite data. I'm pretty sure none of the games you mention do that.
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: Any research done on writing to oam durring active displ

Post by Near »

I named two games that do it already. Give those a try and see for yourself.

Both of them had single-line errors in my scanline renderer at one point in time because the timing of when OBSEL is cached is really important with this trick.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Any research done on writing to oam durring active displ

Post by 93143 »

byuu wrote:I named two games that do it already.
I know; I was referring to the games tepples named. I looked up the ones you mentioned on YouTube, but it's hard to tell a sprite layer from a BG layer when Mode 7 isn't involved. I believe you, so I don't think I'll bother pirating them to check.

I suppose it could be interesting to see how they do it - whether they make the change during HBlank or active display...
Post Reply