Intro Code not working in nintendulator

[griever]

Not so long ago I wrote some intro stuff for translated games. As there was no room in NMI procedure or ROM itself (it's packed to rim) I wrote whole stuff on VBLANK Loop - yup, I know it's horrible! But I guess there was no other way... Intro itself makes simple parallax effect along with some text scrolling. And it works on FCEU and VirtuaNES (guess they are not so accurate) But it doesn't on Nestopia and (which is much worse) Nintendulator. Sure, I've traced error: It's in SPR 0 waiting stuff - waiting never ends(I've commented this place in source).

[Bregalad]

As there was no room in NMI procedure or ROM itself (it's packed to rim) I wrote whole stuff on VBLANK Loop - yup, I know it's horrible!

I'm not exactly sure what you are talking about here, for me NMI is the interrup that happen on VBlank, so that's pretty much the same.

VirtuaNES and FCEU are pretty much accurate in fact (at least compared to Nesticle), but Nestopia and Nintendulator are the 2 most accurate emulators ever, so if a programm have the same result on both of them, we can be pretty sure it will be the same result as the hardware too I know a lot of people here will blame me for saying such thraison infamities (emulators suxx harware rules etc...) especially Bananmos and Quietust who aren't arround right now so I guess I'm safe) but that's the way I see things.

VirtuaNES happen to be wrong with midframe scrolling change when $2006 is affected, the timing is off, and all scrolling changes are delayed by a scanline and the screen is often a pixel too low, having disastrous effects on some demo where the vertical scrolling is changed every scanline, but then it's the other way arround : The ROM works in other emus and fail in VirtuaNES.
VirtuaNES doesn't support mid-scanline $2001 writes (they only take effect at HBlank), and there is probably a few other things innacurate when it comes to precise sound timings and such stuff.

I don't remember what exactly fails in FCEU, I just remember midframe $2001 writes fails, and MMC5 emulation has a couple of things wrong if I remember correctly.

So it's hard to guess what kind of glitch a programm that works on averagly accurate emulators but fails to very accurate emulators has, probably it's due to timing issues. If you set the scrolling close from HBlank, it's possible VirtuaNES (wich emualte this very badly) set the scrolling after HBlank as well as FCEU, making the sprite hit, and that accurate emulator take the scrolling effects immediately and the screen is one pixel higher and the sprite doesn't hit. Just a guess, tough. I recommend make your sprite zero visible (by palette swapping it) so that you see this yourself.

EDIT :
Sorry I didn't see source was included. I checked it, and I guess there is 2 thing that may be wrong. You write $1a to $2001, meaning that one of BG or sprites is clipped and the other not (I don't remember wich one). And you place your hitting pixel at the leftmost of the tile, wich is positionned at 48, 1. If either the background or the sprites are clipped for the leftmost 8 pixels, I'm pretty sure the hit won't happen, making your programm freeze.
The other thing wich is wrong is that you do sprite DMA only once at startup (is that this that you said was horrible ?). On the real console high chances are that temporary OAM will fade between the time where you do sprite-DMA and where you turn on the screen, but I don't think so. As long as you do not wait more than one frame with screen off and no sprite DMA there shouldn't be any problem.

Finally I strongly recommand to clear unused sprites with $ff, so that it avoid to have 63 times the tile 0 positionned at 0,0, but you effectively have 63 unused sprites.

[griever]

I'm not exactly sure what you are talking about here, for me NMI is the interrup that happen on VBlank, so that's pretty much the same.

I was talkin something like this: I write 0 in 2000's D7 - So I'm not using NMI on VBLANK, cause GAME uses this and I didn't want to hack game's NMI Routines.

You write $1a to $2001, meaning that one of BG or sprites is clipped and the other not

Yup, changed this to #$1E but nothing happened

And you place your hitting pixel at the leftmost of the tile, wich is positionned at 48, 1.

JIC I've also placed 0 sprite in 48,48 and nothing.

The other thing wich is wrong is that you do sprite DMA only once at startup

Check out string #330 in source:

Code: Select all

	
........................
            lda #$0
	sta $2003
	LDA #2
	STA $4014


; OK - MAIN PART JOYSTICK STUFF
	
	lda #$00
	sta $4016
............................

and it's all part of my main loop called 'get_key'

Finally I strongly recommand to clear unused sprites with $ff, so that it avoid to have 63 times the tile 0 positionned at 0,0, but you effectively have 63 unused sprites.

Sure thing - at first I've filled Sprite Tile Indexes and nothing, and then I tried to fill with #$FF all SPR Buffer in RAM - Nah, as usual just static picture and infinite vblank waiting!

[griever]

Ahhh, I've found It! Eventually Bregalad was right: dma transfer happened every frame, BUT I was really doing it AFTER spr 0 check! Sorry everyone and thanks Bregalad ^_^