SMB1 (again) - Sprite 0 removed, But Flickering is there

[Hamtaro126]

EveryTime I remove all of the sprite 0 stuff (including detection) It seems that it's making the status bar flicker. Everything I have tried does not work!

EDIT: Disch's IRQ routine does not work, And Tried to use the IRQ from the MMC3 version of SMB2J by loopy. But it cannot work unless it is seperated properly. Can anyone help me seperate SMB2J-MMC3 IRQ Stuff from Loopy's SMB2J-MMC3 source code for use in my Hack?

Link: SMB2J MMC3 Source
http://home.comcast.net/~olimar/NES/smb2jsrc.zip

[Disch]

EDIT: Disch's IRQ routine does not work, And Tried to use the IRQ from the MMC3 version of SMB2J by loopy. But it cannot work unless it is seperated properly.

Umm... what IRQ routine? I don't recall writing anything for SMB.. and if you're just taking arbitrary examples and inserting them, then it's no wonder it's not working.

Anyway, it's probably harder to work in something written for another game than it would be to just write a custom routine yourself. I don't see how this SMB2J-MMC3 source is supposed to be of any use to you.

What I would do is probably something like...

- set up the IRQ counter as soon as NMI happens, and SEI
- replace wait-for-sprite 0 hit routine with CLI
- remove the split screen code that follows the wait-for-sprite 0 stuff, and put it in the IRQ handler

This should be relatively easy especially considering you can always use doppelganger's disassembly. The hardest part will be finding free space for all this new code. SMB doesn't exactly have a lot of free space available.

The important thing is you have to understand the code you're writing/copying. If you're just copy/pasting stuff without understanding it and hoping it will work, you'll almost certainly run into problems all the time.

[MottZilla]

You should use WRAM if you need more space for code. Just copy code there for a seperate bank at reset. Replace whatever code you have to write over though. Just an idea. I agree with Disch you should just write your own hack. You could use Loopy's as a reference but don't take it and try to copy paste it.

And finally, when is all this flickering occuring? I'm guessing you made a hack that has a ton of enemys on screen at once? That's the only thing I can think of since I never remember any status bar flicker on SMB but I recall hearing it could happen if you have alot of enemys on screen.

[Bregalad]

Well, adding something that just reset the IRQ counter in the NMI handler, remove the sprite zero hit waiting routine at all and make the IRQ handler points to modified sprite zero hit waiting routine is all you have to do to get it working. Then replace the sprite zero waiting per resister saving/restoring and IRQ acknownledging and you'll be fine.

[Hamtaro126]

EDIT: Disch's IRQ routine does not work, And Tried to use the IRQ from the MMC3 version of SMB2J by loopy. But it cannot work unless it is seperated properly.

Umm... what IRQ routine? I don't recall writing anything for SMB.. and if you're just taking arbitrary examples and inserting them, then it's no wonder it's not working.

Anyway, it's probably harder to work in something written for another game than it would be to just write a custom routine yourself. I don't see how this SMB2J-MMC3 source is supposed to be of any use to you.

What I would do is probably something like...

- set up the IRQ counter as soon as NMI happens, and SEI
- replace wait-for-sprite 0 hit routine with CLI
- remove the split screen code that follows the wait-for-sprite 0 stuff, and put it in the IRQ handler

This should be relatively easy especially considering you can always use doppelganger's disassembly. The hardest part will be finding free space for all this new code. SMB doesn't exactly have a lot of free space available.

The important thing is you have to understand the code you're writing/copying. If you're just copy/pasting stuff without understanding it and hoping it will work, you'll almost certainly run into problems all the time.

Bregalad and Disch: You both are right on that,

Disch: I can do your instructions to make it working, unless it won't work,

Mottzilla: It is not the enemies. Just a reaction to removing the sprite zero code, I can put Disch's Idea into play. and By The Way, It is only affecting to the range where the status bar was handling sprite 0.

[tokumaru]

Disch, I'm too lazy to look for it right know, but recently you posted a MMC3 IRQ example where you mixed up 2 registers. That might be what he's talking about.

EDIT: Here it is. You said $E000 enables IRQs and $E001 disables them, but it's the other way around. If he finished the setup with a $E000 write, there'd be no IRQ.

[Disch]

osht, you're right.

Whooooops! :oops:

Wow I totally don't remember posting that. My memory sucks.

[doynax]

- set up the IRQ counter as soon as NMI happens, and SEI

Be careful. Returning from the NMI will restore the previous flags so you'll need something like:

Code: Select all

PLA
ORA #$04
PHA

Assuming that you haven't actually pushed anything yet (i.e. saved the registers on the stack), otherwise you'll have to play with the stack pointer..

Or perhaps a simple PLP/SEI/PHP sequence would do, but this is presumably done because of spurious IRQs triggered for some reason so perhaps that might happen here too.

[Disch]

I was under the impression that SMB ran its entire game from inside the NMI handler. Though I shouldn't assume that I guess -- you know what they say about when you assume.

[Bregalad]

I don't think any SEI is needed exept between reset and the run of the code. Just acknownlge an IRQ when it's triggering, disable the counter and you'll be fine.

[doynax]

I was under the impression that SMB ran its entire game from inside the NMI handler. Though I shouldn't assume that I guess -- you know what they say about when you assume.

Heh, that should teach me I suppose..