Graphical Glitch in Final Fantasy III (USA) (Rev 1)

[ConHuevosGuey]

When riding the mine cart in Final Fantasy III (USA) (Rev 1) , I noticed some red lines at the top right of the screen that are not normally there when playing on a real SNES. At first I thought maybe it was something that's perhaps cropped out on a TV but I wasn't able to remove it with any of the Mister cropping options. I verified on a real SNES and BSNES that it does not appear there and only seems to happen with the mister. I made a recording of the minor issue, attached is a video of it, it's the flat red line at the top right of the screen during the mine cart section. I also included a save file right at that spot, it's in slot 2, the 8:22 Time save.

Final Fantasy III (USA) (Rev 1) save.zip

2025-08-15.01-16-25_encoded.mp4

[littlegamer87]

I recognize this. This is also visible on a freshly generated rom for ALTTP randomizer in the main menu, but only if no save file exists. The artifact looks the same. I thought this was a rom issue but now I am not so sure anymore.

2025-08-15.09-28-10.mp4

[ConHuevosGuey]

Interesting. That does appear to be a very similar same glitch.

[littlegamer87]

It gets more interesting now I have a real hw capture of the rando rom. A white bar is visible on top of the screen that is not moving and has a different position horizontally. It looks smaller too. That bar is also gone if a save file exists.

bsnes does not replicate this

[paulb-nl]

Both are caused by disabling Forced Blank in the middle of the line.

Final fantasy also does not show a glitch at the top on my SNES.
The ALTTP randomizer glitch looks similar to MiSTer on my SNES but it is a different color and position and does not flicker. If a save file exists then it disables Forced Blank in VBlank so there is no glitch.

SNES:

[littlegamer87]

That bar is not in the same spot if I align both captures on top of each other. Is this some edge case depending on SNES model? Does rando seed matter? Should we try and figure out the difference?

[paulb-nl]

Which flash cart was used for the other capture? I used an Everdrive. SD2SNES can use IRQ hooks which can delay things.

[littlegamer87]

Fxpak pro, on an NTSC USA SNES

[paulb-nl]

I have investigated the Force Blank behavior of original hardware. With PR #429 The glitch reported in FF3 is fixed.

The glitch in ALTTP is more complicated. On the MiSTer core this was a background layer glitch which is now gone with the latest changes. On original hardware it is a sprite layer glitch which needs investigation.
We can make a separate issue for that.

[littlegamer87]

Hi @paulb-nl , I think I noticed a ppu regression after looking into that Contra MSU issue

When launching the game and scrolling between soundtrack options, rows of pixel appear for one frame at the bottom half of the screen. These rows are not there on stable. I assume you can run MSU on hw or do I have to contact my friend to check?

[paulb-nl]

I was looking into that yesterday. I don't have an SD2SNES but I patched the rom to show the soundtrack options without MSU so i could run it on my Everdrive. Just change $F0 to $80 at rom address $298025.

On original hardware there are some white rows of pixels when scrolling to the US boxart. This matches the core behavior. There are some more rows of pixels when scrolling to the other pictures on the core which are not visible on hardware.

I made a test rom with the contra arcade poster and the same PPU settings to see what happens when disabling Force blank on different cycles. It shows the same blue/green row of pixels on hardware and the core but they differ at the start with the same horizontal IRQ. On hardware the row of pixels is not visible but on core it starts out visible. This makes me believe that the PPU implementation is correct but the write that Contra MSU rom does to disable Force blank happens at a different cycle on hardware.

Here is the test if someone wants to try it:
contra_test_fb.zip

Here is a video of original hardware:
https://github.com/user-attachments/assets/e76ddea4-e2fa-4c7b-816c-0bbb139a77fd

Video of the test rom on hardware:
https://github.com/user-attachments/assets/5d6f5e0e-fbfe-43b8-93ad-bd0bb8c91bbf

[srg320]

The glitch in ALTTP is more complicated. On the MiSTer core this was a background layer glitch which is now gone with the latest changes. On original hardware it is a sprite layer glitch which needs investigation.

Do you have a test program for testing sprite rendering with Forced Blank switching?

I looked at line 5 using LA, where Forced Blank is deactivated. If I figured out the sprite tile fetch address correctly, it's line 5 of the tile at address 0x8E60. Why this specific tile is displayed is not yet clear.

[paulb-nl]

Yes I have been debugging it. It is a very strange and complex issue.

Here is the test rom with the ALTTP scene. The background is purple to make transparent sprite tile pixels visible. The IRQ can be changed with Up/Down, L/R. X/B and Start+X/B changes the OAM DMA size which affects the internal OAM address.
alttp_oam_copy2.zip

The issue appears after disabling Force Blank when the internal OAM address is in High OAM (512+). For example after copying 544 bytes the address will be at 544 which will select sprite 8. Pressing B will decrease the OAM DMA size and that affects which sprite is shown.

Sprite 8 has Y position $F0 and tile number $53. The strange thing is that it will display the single tile row as Y position $00 with tile number $73. That is address 0x8E60 that you mentioned.

It is the same for other sprites. Here are the notes about which sprites (not checked all sprites) show which tiles:

Sprite
0: Ypos $02 vs $42 Tile $A8 
1: Ypos $00 vs $F0 Tile $61 vs $41
2: Ypos $00 vs $F0 Tile $62 vs $42
3: Ypos $00 vs $F0 Tile $63 vs $43
4: Ypos $00 vs $F0 Tile $64 vs $44
5: Ypos $00 vs $F0 Tile $70 vs $50
6: Ypos $00 vs $F0 Tile $71 vs $51
7: Ypos $00 vs $F0 Tile $72 vs $52
8: Ypos $00 vs $F0 Tile $73 vs $53
9: Ypos $00 vs $F0 Tile $74 vs $54

[srg320]

I took measurements using LA for different sprites and put the results in a table of sprite tile fetch addresses (addresses in word units).
alttp_oam_fetch_table.xlsx

Tile data fetching is always performed when Force Blank is disabled. Even when there are no sprites on the line. Addresses are repeated on all 34 available slots for reading tiles.

The addresses for a specific sprite is not changed regardless of where Force Blank is disabled. But when Force Blank is enabled, reading does not occur, the signal VRD_N inactive, and the address remains unchanged from the background fetch.

Analyzing the addresses, it seems that the internal tile coordinate counters continue to count in a circle (8 tiles/64 rows vertically). But for some reason, the counter starts with a value shifted by 2 tiles/16 rows the first time. Then it starts from 0 (this can be seen on lines 48 and 112). These counters are only set when a visible sprite appears on that line.

UPD.
I found out that the vertical tile offset in addresses depends on the sprite Y position and is equal to 256-Y. It seems that the visible part of the sprite is what “overlaps” the visible part of the screen, if the vertical size of the sprite is considered to be equal to 64 regardless of the settings.
For example, for sprite 8:
Y=0xF0, TILE=0x53 + ((0x100-0xF0)/8)<<4=0x73
Y=0xF8, TILE=0x53 + ((0x100-0xF8)/8)<<4=0x63

[srg320]

I modified the test ROM slightly, shifting the Y positions of some sprites. I made sprites 4 and 9,10 partially or completely visible.
As a result, sprite 4 is not displayed on the line with the “buggy” sprite 8, which is expected. However, sprites 9 and 10 are unexpectedly not displayed on the same line as the “buggy” sprite 8. For these sprites, the tiles are not read at all, even with incorrect addresses. It seems that they do not fall into the Range, only sprite 8 does.

It seems that Force Blank affects the entire line, both the Range and Time periods.

alttp_oam_copy2_1.zip

[paulb-nl]

It does show sprite 9 & 10 on the same line as sprite 8 if you press L to trigger the IRQ earlier.

I think the sprite in range evaluation continues during Force Blank with the last OAM address so the in-range table is filled with sprite 8 in this case. That is why disabling Force Blank earlier shows sprite 9 & 10 because the table is not filled yet.

I need to make a test rom for this behavior.

I have seen this behavior in the transistor simulation of PPU1 https://www.qmtpro.com/~nes/chipimages/visual5c77/

However not all behavior is working in the simulator. For example the sprite fetching is broken because it does not read the in-range table correctly.