Mid-Frame Scrolling

[jstout]

I was working on learning mid-frame scrolling (test rom was a Top Status Bar with an IRQ to scroll the bottom). I read the documentation and got it to work but Nestopia and FCEUX had a conflict with each other on the $2005 writes. Since Nestopia is generally more accurate and the same as the wiki I figure it is correctly written. Is there anything that could be possibly missing code-wise that could cause FCEUX to have the $2005 writes switched or is it just an emulator issue? I tried reading and not reading $2002 before and placing the code in Forced Blank and not but nothing seemed to make the two emulators match.

; NN = NAMETABLE
; YYYYY = SCROLL TILE DOWN
; XXXXX = SCROLL TILE RIGHT
; yyy = SCROLL PIXEL DOWN
; xxx = SCROLL PIXEL RIGHT

Working in Nestopia 1.39:

Code: Select all

	LDA XSCROLL+1		; %----NN--
	AND #%00000001
	ASL
	ASL
	STA $2006
	LDA YSCROLL+0		; %YY---yyy
	STA $2005
	LDA XSCROLL+0		; %-----xxx
	STA $2005
	LDA YSCROLL+0		; %YYY-----
	AND #%00111000
	ASL
	ASL
	STA TEMP_SCROLL
	LDA XSCROLL+0		; %---XXXXX
	LSR
	LSR
	LSR
	ORA TEMP_SCROLL
	STA $2006

Working in FCEUX 2.2.1:

Code: Select all

	LDA XSCROLL+1		; %----NN--
	AND #%00000001
	ASL
	ASL
	STA $2006
	LDA XSCROLL+0		; %-----xxx
	STA $2005
	LDA YSCROLL+0		; %YY---yyy
	STA $2005
	LDA YSCROLL+0		; %YYY-----
	AND #%00111000
	ASL
	ASL
	STA TEMP_SCROLL
	LDA XSCROLL+0		; %---XXXXX
	LSR
	LSR
	LSR
	ORA TEMP_SCROLL
	STA $2006

[tepples]

What works on the NES is tokumaru's code fragment.

[tokumaru]

The timing is as important as the operations you are performing. If you do some things too soon the PPU will screw up your scroll values, too late and you'll get a glitchy scanline. If you look at my code, I wrote some notes about the timing. You can do a lot of stuff ahead of time, at any point before the HBlank, and only the last couple of writes have to fall within HBlank. That's just 8 cycles in a a window of ~28 cycles, so it isn't so hard to get right.

[tepples]

only the last couple of writes have to fall within HBlank. That's just 8 cycles in a a window of ~28 cycles, so it isn't so hard to get right.

Better yet, it's actually 5 cycles: the write from stx $2005, three cycles to fetch sta $2006, and the write from sta $2006.

[tokumaru]

Yeah, I thought about considering only the last cycle of the $2005 write, but figured that 5 cycles would sound confusing. =)

What I'm not really sure is the ~28 figure though, because at the very start of HBlank the VRAM pointer is automatically updated, and by the end the tiles for the next scanline are already being fetched, so you definitely want the new scroll values to be set by them. My advice is: try to make those timing sensitive writes closer to the beginning of HBlank, right after the VRAM pointer auto updates.

[jstout]

Thanks, I tried the code tokumaru posted and ended up with the same exact thing happening. I understand what HBlank is but maybe I'm not correctly figuring out when it occurs. The test rom below scrolls smoothly vertically on Nestopia and Nintendulator with no glitching but is still not right in FCEUX as its trying to do the $2005 writes in a backwards order (so I'm hoping its the emulator).

Test Rom

[3gengames]

FCEUX sucks with the scroll timings, go off of Nestopia for stuff like that.

[koitsu]

Does your code work on the actual NES/Famicom? If so, then you're done/no further effort is required. Writing code that "caters to emulator oddities" is the wrong way to go about it.

[jstout]

Does your code work on the actual NES/Famicom? If so, then you're done/no further effort is required. Writing code that "caters to emulator oddities" is the wrong way to go about it.

I have no idea. I have no way to test on the real machine.

[tokumaru]

I'll say this again: IF A PIECE OF CODE WORKS ONLY ON HARDWARE, MOST OF THE TIME IT HAS NO EXCUSE FOR FAILING ON EMULATORS. PLEASE DON'T GO "IT WORKS ON HARDWARE, SO FUCK FCEUX/NINTENDULATOR/NESTOPIA/ETC", BECAUSE YOU COULD BE RELYING ON SOME EDGE CASE THAT COULD CAUSE PROBLEMS UNDER CERTAIN CONDITIONS.

Unless you are doing something unusual (I wouldn't put mid-screen scroll changes in that category - in fact, FCEUX in particular is pretty forgiving in this area), you should take a look into it if your code is failing on popular emulators.

[Shiru]

On the other hand, it leads to stall in emu dev scene. Like, if there are no games that shows certain bugs in emulators, the bugs will never get fixed. I'm personally pretty sure that if some code works on the HW, it shouldn't be fixed for emulators, the emulators should be fixed instead.

That may be not very actual on the NES scene, as the system is relatively simple, and emulators are well developed, but on the SNES scene it could be very difficult to satisfy all popular emulators. Happens very often, a game works properly in one, shows glitches in another, when you fix it to work in both, it starts to glitch on the third, and that's a vicious circle.

[tokumaru]

koitsu, I have to disagree with you. When you are experimenting undocumented behavior, like manipulating registers at odd times, using open bus values, etc. then yes, what the hardware does should be the definitive answer (even though different revisions might behave differently). But when you're working with behavior that has been documented for years (loopy's skinny doc), and has been implemented in every NES emulator made in the past 10+ years, a failure on emulators could mean that something is wrong, even if it appears to work 100% on hardware.

I wouldn't call that "catering to emulator oddities", because these emulators were made to work with this kind of code. They were supposed to handle this correctly, and if they aren't, that might be a sign that your code isn't as safe as it could be. Just because you didn't see any errors during the 1 minute you tested your code on your own console, that doesn't mean that inside a game engine running for several hours on a console on the other side of the planet the same code wouldn't cause problems because it wasn't safe enough.

[koitsu]

koitsu, I have to disagree with you. When you are experimenting undocumented behavior, like manipulating registers at odd times, using open bus values, etc. then yes, what the hardware does should be the definitive answer (even though different revisions might behave differently). But when you're working with behavior that has been documented for years (loopy's skinny doc), and has been implemented in every NES emulator made in the past 10+ years, a failure on emulators could mean that something is wrong, even if it appears to work 100% on hardware.

I wouldn't call that "catering to emulator oddities", because these emulators were made to work with this kind of code. They were supposed to handle this correctly, and if they aren't, that might be a sign that your code isn't as safe as it could be. Just because you didn't see any errors during the 1 minute you tested your code on your own console, that doesn't mean that inside a game engine running for several hours on a console on the other side of the planet the same code wouldn't cause problems because it wasn't safe enough.

None of this has any relevancy to this specific issue at hand -- he's using your code (now/at this point), which we know works on actual hardware (right?), yet doesn't work on one emulator. Thus I do think it's safe to say in this case "fuck FCEUX". :-) I bet it doesn't work on Nesticle either -- oh shit, what do we do!? Maybe the guy should provide the full source code (test ROM = a good start, but the code matters more in this case).

[tokumaru]

Happens very often, a game works properly in one, shows glitches in another, when you fix it to work in both, it starts to glitch on the third, and that's a vicious circle.

Like I said, you have to consider the kind of work you're doing. Reading the controller, for example. It's a very basic thing that every emulator must be able to do in order to play games, so if input is broken in your game alone you must be doing something funky. Unless you have a very specific reason for doing it in a funky way, I think you should change it. I see no point in breaking things on purpose.

For complex tasks however, sure, you shouldn't give up features or effects in your game just because emulators can't handle them.

he's using your code (now/at this point), which we know works on actual hardware (right?), yet doesn't work on one emulator.

It works correctly when run at the correct time. I'm pretty sure I tested it in FCEUX... (will try again when I get the chance, just to be sure) Maybe he's not getting the timing right.

I bet it doesn't work on Nesticle either -- oh shit, what do we do!?

That was very constructive! Nesticle was last updated well over 10 years ago though, so my point still stands.

Maybe the guy should provide the full source code (test ROM = a good start, but the code matters more in this case).

A test ROM would be great for us to check the timing out.

[jstout]

I had the link to the rom above and here is a direct attachment to it again. I can provide the source if needed but its just a rom for testing that I keep adding features to make sure I can do various things myself.

skeleton.nes

(24.02 KiB) Downloaded 130 times