Games with black bars on top and bottom

You can talk about almost anything that you want to on this board.

Moderator: Moderators

User avatar
DRW
Posts: 2225
Joined: Sat Sep 07, 2013 2:59 pm

Re: Games with black bars on top and bottom

Post by DRW »

Fiskbit wrote: Mon Jul 11, 2022 6:47 pm Pre-E NTSC PPUs are found almost exclusively in square-button Famicoms, which were the first 2 million units. There aren't known to be any in any model other than the RF Famicom. They're not exactly rare, but there are around 54 million NTSC consoles.

The PPUs with $2001 write issues are just the first 200,000 or so Famicoms.
So, I can be sure that those glitch issues only appear on the old Famicoms whose controllers don't even look like the later, more famous model?

Other models don't have different behavior? Can I be definitely sure that, for example, the first batch of American NES consoles that were sold in winter of 1985 will not produce any strange behavior that differs from the behavior of, let's say, a 1989 NES?

Fiskbit wrote: Mon Jul 11, 2022 6:47 pmlidnariq just identified that there is a workaround: If you know what the values of the rendering bits are, you can OR the high byte of the PPU mask address with those bits. So, if rendering is on and you're writing to $2001, you can write to $3E01, instead, to avoid the unexpected rendering toggle.
Is this an officially supported operation, though, or just some chance discovery? I've never heard of the address $3E01 in regards to NES programming and I'd rather not use stuff that's too obscure.


By the way, what do you think of my attempt? Disabling the background at a certain scanline and placing sprites on the black border to simulate a status bar, but without the hassle of actually implementing a proper status bar in a vertically scrolling game. Is this something any game actually did?
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Games with black bars on top and bottom

Post by rainwarrior »

DRW wrote: Tue Jul 12, 2022 1:43 pmBy the way, what do you think of my attempt? Disabling the background at a certain scanline and placing sprites on the black border to simulate a status bar, but without the hassle of actually implementing a proper status bar in a vertically scrolling game. Is this something any game actually did?
I've seen it in one game, but I can't remember the name of it at the moment. I think it was a racing game. The bottom half of the field was BG off with just a few sprites to make a very sparse looking HUD.
User avatar
DRW
Posts: 2225
Joined: Sat Sep 07, 2013 2:59 pm

Re: Games with black bars on top and bottom

Post by DRW »

Are you sure you don't mean "Road Fighter"? In this game, they simply leave the right side of the screen black and use sprites for a status bar.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Games with black bars on top and bottom

Post by rainwarrior »

It was Rollerblade Racer:
rollerblade_racer.png
rollerblade_racer.png (6.93 KiB) Viewed 970 times
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Games with black bars on top and bottom

Post by lidnariq »

DRW wrote: Tue Jul 12, 2022 1:43 pm Is this an officially supported operation, though, or just some chance discovery? I've never heard of the address $3E01 in regards to NES programming and I'd rather not use stuff that's too obscure.
No commercial games use it.

We discovered the cause and workaround in the past 9 years. You, in fact, already asked about it: viewtopic.php?t=13046

All NESes and Famicoms support accessing mirrors.

We have discovered similar problems in almost all of the PPU registers, but some were fixed by PPU revisions (this one), and others effectively don't matter.
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Games with black bars on top and bottom

Post by Fiskbit »

DRW wrote: Tue Jul 12, 2022 1:43 pm So, I can be sure that those glitch issues only appear on the old Famicoms whose controllers don't even look like the later, more famous model?

Other models don't have different behavior? Can I be definitely sure that, for example, the first batch of American NES consoles that were sold in winter of 1985 will not produce any strange behavior that differs from the behavior of, let's say, a 1989 NES?

Is this an officially supported operation, though, or just some chance discovery? I've never heard of the address $3E01 in regards to NES programming and I'd rather not use stuff that's too obscure.
The $2001 write glitches I'm describing occur only on the RP2C02A and presumably RP2C02 letterless. These PPUs exist onlyin the first couple hundred thousand RF Famicoms, which were sold with square button controllers. You will not find them in any other console. The North American market only got E, G, and H PPUs, and the vast majority of these are G (only around 1 million E's and probably a very small number of H's).

The $2001 write workaround where you use PPU register mirrors that correspond with your data to avoid glitches will work on official hardware with no negative side effects, and probably on most clones and most (all?) reasonable emulators. It was just discovered in this thread, but as lidnariq says, other PPU register bits have the same bug and the workaround for them has been known for years. As far as we know, this is new knowledge that Nintendo and contemporary developers did not know about and thus did not intentionally use.

Glitches from turning rendering off at approximately dots 1-64 or 257-320 occur only on E, G, and H PPUs. Glitches from urning rendering off at approximately dots 65-256 and back on mid-screen on some alignments occur on all NTSC PPUs (and probably RGB PPUs, as well). PAL is untested.
Dwedit wrote: Tue Jul 12, 2022 11:14 am Final Fantasy 1 is known to use timed PPUMASK writes to do the light beam effect when you get a crystal. What would the failure condition look like on a square button Famicom? Is there no failure condition because there is no forced blanking?
I'm going to guess here because I don't like this game and am not going to play far enough to trigger this effect, but assuming it's doing normal $2001 writes, then the greyscale part will work fine, but rendering will turn off briefly after both edges, messing up the background afterward on each scanline. Sprites on the next scanline will presumably be disrupted, and it may cause sprite issues on the remainder of the screen depending on the CPU/PPU alignment because at least some of the writes occur in the approximately 65-256ish dot range where rendering disable can cause poorly-understood sprite issues. I'm not sure exactly how wide the rendering disable region is; that's something that would need to be tested. However, it doesn't have to be wide to meaningfully disrupt a whole sliver.

CutterCross' CrossPaint demo has $2001 writes all down the edge of the canvas in hblank, and on revision A, those cause flickering bad slivers all along that edge unless changed to $3E01. I think he had a report of this happening on a revision B console, as well (which would bring the affected number of PPUs up to about 1.2 million), but I don't think I ever saw evidence of this issue on my B's. I still need to test CrossPaint on one. I don't have B, C, D, or D-0 PPUs in consoles with composite output, which makes testing them pretty annoying.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Games with black bars on top and bottom

Post by Dwedit »

The FF1 beam effect can be seen in a video at https://youtu.be/c4EQ5wyVfBc?t=4096
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Games with black bars on top and bottom

Post by Fiskbit »

Thanks, though I should've been more clear: I've seen the effect before, but I don't intend to play there on a rev A PPU myself to see the actual result. I also wouldn't be able to test a hack that makes it easy to access because on-cart VRAM on the Everdrive N8 Pro doesn't work properly on rev A PPUs (writes receive a corrupted value).
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: Games with black bars on top and bottom

Post by Drag »

Really quick, is there a centralized place we've documented all of these misc PPU glitches? Glitches with turning rendering off, palette corruption, and times where you need to use a mirror of a PPU register?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Games with black bars on top and bottom

Post by lidnariq »

We're about to make a page on the wiki for this - I realized there was no central place for it yesterday.
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: Games with black bars on top and bottom

Post by Drag »

lidnariq wrote: Wed Jul 13, 2022 10:32 am We're about to make a page on the wiki for this - I realized there was no central place for it yesterday.
Excellent, thank you, because was interested in familiarizing myself with all of this recent info, but there's no way I'd be able to effectively search the forums and find it all.
User avatar
DRW
Posts: 2225
Joined: Sat Sep 07, 2013 2:59 pm

Re: Games with black bars on top and bottom

Post by DRW »

rainwarrior wrote: Tue Jul 12, 2022 2:05 pm It was Rollerblade Racer:
rollerblade_racer.png
So, I'm not the only one with this idea.

How did they manage to let the sprites disappear under the status bar? (They are off by two pixels, though.)
I myself use the eight sprites per scanline trick. But it looks like this is not what they did here.

lidnariq wrote: Tue Jul 12, 2022 2:47 pm We discovered the cause and workaround in the past 9 years. You, in fact, already asked about it: viewtopic.php?t=13046
Interesting. I never connected those two things.

Fiskbit wrote: Tue Jul 12, 2022 6:28 pm The $2001 write glitches I'm describing occur only on the RP2C02A and presumably RP2C02 letterless. These PPUs exist onlyin the first couple hundred thousand RF Famicoms, which were sold with square button controllers. You will not find them in any other console. The North American market only got E, G, and H PPUs, and the vast majority of these are G (only around 1 million E's and probably a very small number of H's).
Thanks. Good to know.

Fiskbit wrote: Tue Jul 12, 2022 6:28 pm Glitches from turning rendering off at approximately dots 1-64 or 257-320 occur only on E, G, and H PPUs. Glitches from urning rendering off at approximately dots 65-256 and back on mid-screen on some alignments occur on all NTSC PPUs (and probably RGB PPUs, as well). PAL is untested.
If my IRQ function starts with the following:

Code: Select all

Irq:

    PHA

    LDA PpuMaskBufferValue
    STA $2001
at what dot is the PPUMASK write done?

For information:

PpuMaskBufferValue has either the value $00011110 when I do the IRQ for a mid-frame name table change.
This is for dialog boxes that are rendered on the opposite name table, so I don't have to delete parts of my actual gameplay screen.
I.e. the value is identical to what is currently in PPUMASK anyway. Hence, I wouldn't need the write at all. But to save the time of a CMP, BEQ/BNE, I simply always write the value.

Or PpuMaskBufferValue has the value $00010110 when I disable the background rendering to use the black border as a status bar.
(Rendering only gets turned on again in NMI.)

Drag wrote: Wed Jul 13, 2022 9:57 am Really quick, is there a centralized place we've documented all of these misc PPU glitches? Glitches with turning rendering off, palette corruption, and times where you need to use a mirror of a PPU register?
This is something that I'd like to know as well. I'm especially interested in different behavior between revisions that aren't readily distinguishable. I.e whether, for example, one standard front loader US NES might have a different behavior from another standard front loader US NES, simply because they were manufactured in different years and have different revisions of the PPU or anything else.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Games with black bars on top and bottom

Post by rainwarrior »

DRW wrote: Wed Jul 13, 2022 1:10 pm
rainwarrior wrote: Tue Jul 12, 2022 2:05 pmRollerblade Racer
How did they manage to let the sprites disappear under the status bar? (They are off by two pixels, though.)
They have two IRQs, one that happens at the top of the HUD area and one that happens 8 lines later.

It looks like for the top 8 lines (well, off by 2 as you mentioned), they try to switch to a blank CHR page in the ROM to cut off sprites.

It actually writes the same value ($10) to $2001 after both IRQs. I wonder if they had tried at first to disable both BG + Sprites for 8 lines and ran into corruption problems?
User avatar
DRW
Posts: 2225
Joined: Sat Sep 07, 2013 2:59 pm

Re: Games with black bars on top and bottom

Post by DRW »

Interesting. I still prefer my eight sprites method, though. Since my two player characters can have up to four energy points anyway, and I use 8x16 sprites, I don't even need to waste any blank sprites: The energy points are hearts. And they are drawn in the lower half of the sprite. This way, I place eight sprites at the top of the status bar. Therefore, any character that walks into the status bar automatically doesn't get drawn inside the status bar while he's still visible on the playfield. And visually, the hearts appear in the second "tile row" of the status bar.
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
User avatar
DRW
Posts: 2225
Joined: Sat Sep 07, 2013 2:59 pm

Re: Games with black bars on top and bottom

Post by DRW »

I'll post my IRC code here. Can you please check whether everything is alright, regarding mid-frame glitch stuff etc.?

Code: Select all

	; Scanline counter interrupt request (IRQ)
	;
	; If enabled, this interrupt gets called when the screen output has reached a
	; previously defined scanline.
	; This way, mid-frame changes can be done.
	;
	; In this game, we only have one scanline split per frame at most.
	; If we ever needed more than this one scanline split, we would have to devise a
	; more complicated method than what is done here.
	;
	; The current method is adjusted for lags in NMI when it comes to the status bar.
	; But it isn't adjusted for lags for dialog boxes.
	; (The graphics bank that gets switched out mid-frame wouldn't be reset.)
	; But the code in the game logic that gets called whenever a dialog box is shown
	; is so short that it never lags.
	; (The regular gameplay action is stopped during dialog boxes.)
	; So we don't do more here than we need to.

.segment "CODE"

Irq:

	PHA

	; The deactivation of the background needs to be
	; done pretty fast, so that there are no graphical
	; glitches.
	; That's why we do this first, even before pushing X
	; and Y to the stack.
	LDA NextIrqTypeAndPpuMaskValue
	STA PpuMask

	; IRQ gets immediately disabled again.
	STA $E000

	TXA
	PHA
	TYA
	PHA

	; Check whether we do the status bar or the dialog
	; box.
	LDA NextIrqTypeAndPpuMaskValue
	CMP #IrqTypeDialogBox
	BEQ @dialogBox

	; We change the upper sprite graphics bank, so that
	; the tiles for the status bar are loaded.
	LDA #SpritesBankStatusBarIdA
	JSR SwitchSpritesBankA_NoX

	JMP @end

@dialogBox:

	; We take the current name table and XOR it to get
	; the opposite name table.
	; Since we're mid-frame, using the NameTable buffer
	; variable would usually be bad because it's a value
	; that can be changed by the game logic.
	; But since the name table is never changed while
	; dialog boxes are shown, we can be sure that the
	; NameTable variable still equals the actual name
	; table.
	; If this wasn't the case, we would have to save the
	; real name table value to a separate variable
	; whenever PpuCtrl is written.
	LDA NameTable
	EOR #OppositeNameTableXorValue

	; We set the name table by taking our new opposite
	; name table and OR-connect it with the default PPU
	; control register value.
	; In the PPU control register, the name table is set
	; at the lowest two bits, so the OR works and no bit
	; shifting is necessary.
	; Unlike mid-frame scrolling, a mid-frame name table
	; switch only gets executed at the start of the next
	; scanline, so we don't need to time it.
	ORA #PpuCtrlDefaultValue
	STA PpuCtrl

	; However, since we're still in the scanline above
	; the first dialog box scanline and we want to
	; change a graphics bank next, we have to wait a
	; while, so that the graphics aren't changed while
	; we're still above the dialog box.
	LDX #16
@waitLoop:
	DEX
	BNE @waitLoop

	; Before we change the graphics bank, we deactivate
	; the sprites, so that characters below the dialog
	; box aren't rendered.
	LDA #PpuMaskNoSpritesValue
	STA PpuMask

	; We change the upper background graphics bank, so
	; that the tiles for the dialog box are loaded.
	; We made sure that the graphics for the first row
	; of the dialog box (i.e. the dialog box border) are
	; stored in the lower background bank.
	; This way, there are no graphical glitches.
	; Because no matter when the bank switch exactly
	; happens, as long as it's still within the first
	; eight dialog box scanlines, the currently rendered
	; graphics are exclusively from the lower background
	; bank which doesn't get changed here.
	LDA #BackgroundBankTextIdE
	JSR SwitchBackgroundBankE_NoX

@end:

	PLA
	TAY
	PLA
	TAX
	PLA

	RTI
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Post Reply