MMC3 clocking and palettes, what are the details?

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: MMC3 clocking and palettes, what are the details?

Post by Fiskbit »

While secondary OAM probably doesn't decay over the course of a normal vblank, just as primary OAM doesn't, Burai Fighter turns off rendering early, probably enough for decay to start. However, decay is a slow analog process; it doesn't result in all values immediately changing to some target value. Over this small a window, I would expect that any secondary OAM corruption would likely be a few bit flips, probably toward 0, but I would not at all expect secondary OAM to corrupt here entirely to 0.

Without any decay, Mesen thinks secondary OAM on the prerender line should be F0 FF FF FF FF ... FF. I don't understand the OAM evaluation process well enough to explain exactly why. It thinks the counter value is 0 on this scanline, and then when sprites begin being fetched, A12 clocks and the counter is reloaded with $C9. This seems plausible; you probably should be clocking once from sprite fetches on this scanline.

Aside from the special vert(v)=vert(t) behavior on dots 280-304 and the lack of any OAM clearing or evaluation, the prerender line is just like any other rendering scanline. Unless scanline 239 gave you weird secondary OAM results, I wouldn't expect sprites to be causing more than the 1 usual clock here.
Alyosha_TAS
Posts: 173
Joined: Wed Jun 15, 2016 11:49 am

Re: MMC3 clocking and palettes, what are the details?

Post by Alyosha_TAS »

Hmmm, well I'll take another look then, maybe I'm misunderstanding the results about which access is causing the clocks.
Post Reply