nesdev.org

What is the right way to set up IRQ to preform a forced blank 16 lines at the bottom of the screen and use it for extra v-blank time? I can't seem to figure out how to use register $4200 properly to do this kind of stuff.

The main thing to know is that you have to acknowledge/clear the interrupt before returning. Here is code from my NSF player, this is for horizontal IRQ, but I guess there is a similar way for vertical control.

What this code does, is every scanline (at a horizontal position near hblank) it replaces the background palette with random data grabbed from data being decompressed. That slowed the loading down, but I thought it looked pretty funny (better than just having everything freeze, a few of those loads were really long).

More related to what you'd be doing, I guess you would use the IRQ routine much you would normally use the NMI routine. Only difference being that you turn the screen off, since it's not vblank yet. I guess then you could ignore NMI when you're using the IRQ like that.

For scanline location detection, see registers $4200, $4209, and $420A.

Regarding forced VBlank, looks like Memblers already took care of that for ya. :-)

Does the Super NES PPU have the same OAM refresh glitch as the NES PPU, in which programs have to disable rendering at the right point on the scanline or risk getting a random pair of sprites' data replaced by the data for sprites 0 and 1?

Off the top of my head, dunno -- I never got around to tinkering with sprites in all my years (on either NES or SNES). I would hope that Nintendo would have been aware of whatever mistakes were made in the NES and improved/addressed those. :-)

Disch might have some ideas...

I can get it to work, but only for one emulator at a time. Once I get it to work on one emulator, it doesn't work on the others.

Why care about any other emulator than BSNES? Of course the main concern should be whether it works on an actual SNES or not. But while you're developing on a PC I don't see any reason to care about how your code behaves in zSNES/Snes9x/whatever.

Snes9x has video capture built in.

mic_ wrote:Why care about any other emulator than BSNES?

For end users who play on a device less powerful than a recent desktop PC and more common than the SNES PowerPak. Or does bsnes work well on a GP2X, Wiz, Droid, 10" laptop, modded PSP, or modded Wii?

psycopathicteen wrote:Snes9x has video capture built in.

Maybe you could use BSNES + fraps or some similar program? Or run your program on a real SNES that you hook up to a video capture device (which is what I do if I want to grab a video of something I've written).

For end users who play on a device less powerful than a recent desktop PC and more common than the SNES PowerPak. Or does bsnes work well on a GP2X, Wiz, Droid, 10" laptop, modded PSP, or modded Wii?

It probably doesn't. But this is SNESdev, not SNES9Xdev or zSNESdev.
If you write a game that works on a real SNES but not e.g. in Snes9x, then Snes9x should be fixed; you should adjust your game to work on inaccurate emulators.

mic_ wrote:Maybe you could use BSNES + fraps or some similar program?

Is it worth $37? And can its capture be synchronized to the emulator's output?

Or run your program on a real SNES that you hook up to a video capture device (which is what I do if I want to grab a video of something I've written).

Super NES video with the interlace bit turned off is a non-standard 240p signal, and both video capture devices that I own have had a problem with it. One (an Aiptek camcorder with a composite input) works with 480i video from my Wii, but with 240p video, it stops recording after five seconds, throws an error message, and ends up with a horribly out-of-sync clip. The other (a Philips DVD recorder) works with NES video but for some reason rapidly flickers between color and black-and-white when trying to receive Super NES video. Good luck finding an online electronics store whose sales staff know whether or not the devices that the store sells are compatible with the non-standard video output of any given pre-Dreamcast console.

If you write a game that works on a real SNES but not e.g. in Snes9x, then Snes9x should be fixed

In theory, I agree. In practice, good luck getting the maintainers of Snes9x to attend to your test case collection before your video is due. It's been eight months since the most recent version of Snes9x. But it's worth a shot; I made a whole bunch of test cases for VisualBoyAdvance while trying to get TOD working on GBA.

mic_ wrote: ; you should adjust your game to work on inaccurate emulators.

You mean shouldn't?

It did seem when I was developing, that zSNES and SNES9x would run anything. But I used an SNES clone for initial and periodic testing, which seemed to be fairly close to the actual hardware (except for a couple oddities with the controller ports). On that, nothing would work right until I had initialized probably every single register in the system.

Snes9X and ZSNES have poor support for NMI and IRQ. Try F-1 Grand Prix and Sink or Swim. Whereas I spent two weeks researching an edge case where if an IRQ triggers on the edge of a two-cycle opcode with an I/O cycle, it gets converted to a bus read without PC increment. A timing difference of two 21-millionths of a second, and even then only on SlowROM code.

The only other emulator I could recommend for IRQs would be Super Sleuth, which does an exceptional job.

For end users who play on a device less powerful than a recent desktop PC and more common than the SNES PowerPak. Or does bsnes work well on a GP2X, Wiz, Droid, 10" laptop, modded PSP, or modded Wii?

10" laptop

As for the rest, give the Snes9X devs incentive to improve.

byuu wrote:10" laptop

Wow, I'm glad you posted that, I didn't realize I was so behind in bsnes releases. I also have a MSI Wind and was getting only ~45 FPS with v034, but now with v068 a steady 60! Thanks for the netbook friendly profile, it's very forward thinking.

I wouldn't say v068 official is entirely 1.6GHz Atom ready. Some of the crazier PPU-heavy games can stall it a bit.

The next release will be an extra ~10% faster, and if you combine that with the MSI Wind turbo function (1.91GHz dynamic overclock), 60fps should be doable in just about any non-SA1/SFX game.

And no problem. It's sort of been my goal all along. Rather than go top-down (start with fast code, then fix bugs), I went bottom-up (start with correct code, then make it faster.) Still a work in progress, so hopefully I can keep making it faster.