Errors with INIDISP

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
UnDisbeliever
Posts: 124
Joined: Mon Mar 02, 2015 1:11 am
Location: Australia (PAL)
Contact:

Re: Errors with INIDISP

Post by UnDisbeliever »

I've uploaded my latest test ROMs to github and posted an Imgur album of the tests on my 3-chip Super Famicom Console.

The tests for the INIDISP glitch are hdma-2100-*.sfc, hdma-21ff-*.sfc, inidisp_d7_glitch_test.sfc and inidisp_hammer_*.sfc.

The following tests do not glitch: hdma-2100-glitch-2ch-0a.sfc, hdma-21ff-glitch.sfc and inidisp_hammer_0f0f.sfc.

The hdma-21ff-2100-0f-glitch.sfc test glitches due to the fxpack firmware bug Near mentioned above.

You may need to reset your console a few times for the glitches to appear on the hdma-2100-*.sfc and hdma-21ff-*.sfc tests (they appear ~40% on the time on my console)

The hdma-2100-* and hdma-21ff-* tests require the "Reset patch for clock phase" setting off on an FXPAK.


I have been able to trigger a sprite glitch on my 3-chip console with:
  • A HDMA write that has bit 7 set, immediately followed by a HDMA write to INIDISP (hdma-21ff-2100-glitch.sfc)
  • A HDMA write to INIDISP on the first active HDMA channel, after the CPU has read/written a byte with the 7th bit set. (hdma-2100-glitch.sfc, the bit 7 is set by a bra spinloop)
  • ldx.w #$0f80 ; stx.w $20ff. Writes $80 to $20ff, $0f to $2100 (inidisp_d7_glitch_test.sfc)
  • lda.b #$0f ; sta.l $802100. The data bus $80 before the write to $2100 (inidisp_hammer_0f_long.sfc)

I have been able to trigger a brightness glitch on my 3-chip and 1-chip consoles with:
  • ldx.w #$0f00 ; stx.w $20ff. Writes $00 to $20ff, $0f to $2100 (inidisp_hammer_0f00.sfc)
  • lda.b #$0f ; sta.w $2100. The data bus $21 before the write to $2100 (inidisp_hammer_0f.sfc)

This glitch also affects the inverse. Accidentally activating the display for about a dot while in force-blank if the data-bus had bit 7 clear before the INIDISP write (on my 3-chip console).
  • ldx.w #$8f0f ; stx.w $20ff. Writes $0f to $20ff, $8f to $2100 (inidisp_hammer_0f8f.sfc)

EDIT: Fixed typos in the stx.w $20ff test descriptions.
Last edited by UnDisbeliever on Wed Feb 17, 2021 4:24 pm, edited 1 time in total.
d4s
Posts: 96
Joined: Mon Jul 14, 2008 4:02 pm

Re: Errors with INIDISP

Post by d4s »

Near wrote: Wed Feb 17, 2021 1:53 am Once that bug is fixed in a future firmware revision, the easy fix for this will be to HDMA to $21ff+$2100, and make sure both write the exact same value. That is how I intend to fix Bahamut Lagoon in revision 1.2.

Note that this bug works both ways. It can both erroneously turn the screen on *and* off on you, when you don't want that. It usually doesn't matter, but if the screen turns off during Hblank with active display, it disrupts OAM tiledata fetches. bsnes is accurate enough to reflect this in fact if I emulate this behavior.
Wow, this is absolutely incredible!
Thank you so much for not only identifying the problem but also providing a solution, Near and Undisbeliever!

I first noticed sprite glitches related to writes to $2100 via HDMA around 2006 when working on a Breath of Fire 2 translation patch.
Considering that commercial games also did this and exhibited the same issue (e.g. stage 1 "Green greens" in Kirby Super Deluxe), I unfortunately took this issue for granted and never even thought about the possibility of fixing this in software...

Initially, I wasn't sure if the issue you described was related to what I experienced, but I just implemented your suggestion (HDMA to B-Bus $ff, 2 registers write once) in one of my games that originally wrote to $2100 via HDMA and sure enough, that fixed the sprite glitches completely on all systems that I tested so far:
NTSC 3-Chip 1/1/1
NTSC 3-Chip 2/1/3
PAL 3-Chip 2/1/3

I noticed that the previously appearing sprite glitches were much more pronounced in 50Hz mode and barely noticeable in 60hz mode.

Seeing this issue resolved after so many years makes me so happy, thanks again!
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: Errors with INIDISP

Post by Near »

It's funny ... dissastisfaction with bugs in my previous fan translation of Der Langrisser on hardware but not emulators is what led to me getting into emulation.

All these years later with seemingly known 100% compatibility, I end up discovering not one, but two new unemulated hardware bugs in my next fan translation.

There's some kind of poetic justice and cosmic irony to that, I think ^-^;
Everything always comes full circle.
Initially, I wasn't sure if the issue you described was related to what I experienced, but I just implemented your suggestion (HDMA to B-Bus $ff, 2 registers write once) in one of my games that originally wrote to $2100 via HDMA and sure enough, that fixed the sprite glitches completely on all systems that I tested so far:
Just be sure to tell people they'll need fxpak firmware 1.10.4 or later (should be out soon) to see the fix. Right now fxpak users will still see the glitch.

I have tried many other things to fix this, but they either don't work or risk bringing in even more bugs. This is the only fix I know of so far to both the early $2100 latching on all hardware and the DMA failures on S-CPU A.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Errors with INIDISP

Post by 93143 »

If forced blank doesn't interrupt sprite sliver fetches on a 1CHIP, does that mean VRAM writes during HBlank won't work?

viewtopic.php?f=12&t=19896

Perhaps I should go over that test ROM to make sure it definitely can't produce a false positive. I'm super tired right now and likely to screw it up; maybe tomorrow or on the weekend...
Near
Founder of higan project
Posts: 1553
Joined: Mon Mar 27, 2006 5:23 pm

Re: Errors with INIDISP

Post by Near »

If forced blank doesn't interrupt sprite sliver fetches on a 1CHIP, does that mean VRAM writes during HBlank won't work?
If you mean VRAM writes during force blank and inside hblank ... that's a very good question! I assume they'll work anyway and just overdrive what the sprite fetches read back, maybe.

I haven't actually tested this theory. It's just that we can see on the 3CHIP that the background blanks for a pixel during active display, and sprites get disrupted during Hblank. Whereas on the 1CHIP, only the former happens. That tells me that it's both still latching $2100 too soon, *and* that it's not affecting sprites. There's really no telling exactly what's going on until we test this more thoroughly.

By all means, the more research the better! I'd like to have my emulators support these glitches, but it has to be thorough because I don't want to break games by being too overly aggressive.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Errors with INIDISP

Post by 93143 »

Okay, I modified the first test ROM slightly, so that the OBJ tile tables do not overlap the BG1 tiles. It still works on my SNES, via Super Everdrive. I do not know if my SNES is a 1CHIP or not.

hvdma.sfc
(32 KiB) Downloaded 116 times

Again, the blue background is 64x64 sprites, and the symbols are BG1, consisting of a single tile that gets rewritten halfway down the screen. On my SNES, the line after the transfer glitches, showing flickering white artifacts (white shouldn't be in CGRAM...), but the BG1 tile is rewritten successfully, and the glitching goes away if I turn off the sprite layer.

hvdma.png
hvdma.png (1.6 KiB) Viewed 6831 times

If you need more information, I can modify the test to try to get it.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Errors with INIDISP

Post by 93143 »

I added the ability to turn the layers on and off with the controller. Pressing L toggles BG1, and pressing R toggles the OBJ layer. This makes it easier to see the sprite glitches, allows you to verify that they go away when the sprites are disabled, and shows more clearly that there isn't garbage being written to the sprite tiles.

At least, that's the way it works on my SNES. Unfortunately I doubt my SNES is a 1CHIP (I don't have the tool to open it, but the serial number is a UN2), so these posts should not be taken as any sort of positive result beyond what we knew last year.

If you have a 1CHIP (or Jr.) and are willing to try this ROM, please do so.

hvdma.sfc
(32 KiB) Downloaded 118 times

Note that in this test, the last HDMA channel turns the screen back on. However, once the HDMA is started, no further bulk DMA transfers are done. In a practical scenario, it might be wise to pack in an OBSEL write, or follow the INIDISP channel with an audio I/O channel, to avoid triggering the S-CPU A bug.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Errors with INIDISP

Post by Pokun »

Tested it on my 1CHIP I mentioned earlier (non-Jr) in the thread using the SD2SNES. The glitch seems to be the same as you describe. The line after the modified line shows a glitch line on the sprite layer, and it goes away when I turn off sprites with the R-button but not with the L-button like expected. It's a black line with some places flickering in other colors like blue, pinkish and whitish.

Mesen-S also seems to have the glitch line, although without most of the color the artifacts. Other emulators like bsnes, snes9x and no$sns didn't show it when I tested.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Errors with INIDISP

Post by 93143 »

But the transfer seems to take? The BG tile is rewritten successfully, highlight and all, and the sprite data as shown on subsequent lines isn't corrupted?

If so, this is excellent news. Unless I've missed something with this test, it means I should be able to rely on this technique working on a 1CHIP. I see no reason to suppose it won't work on a Jr. too (they're basically 1CHIPs, right?), but as those are easy to identify without taking them apart, that's somewhat less critical.

Pokun wrote: Mon Feb 22, 2021 2:49 pmIt's a black line with some places flickering in other colors like blue, pinkish and whitish.

Mesen-S also seems to have the glitch line, although without most of the color the artifacts.
My glitch line is not very colourful. It's mostly black, with a few areas of flickering blazing white (not in the palette BTW).

...wait...

...yep. This is embarrassing...

I use a codebase originating from Neviksti's SNES Starter Kit for these tests, and I guess I just never proofread his ClearPalette routine:

Code: Select all

   SEP #$20

   STZ $2121
   LDX #$0100
ClearPaletteLoop:
   STZ $2122
   DEX
   BNE ClearPaletteLoop
It's leaving the top half of CGRAM uninitialized. Those are flashcart colours getting let through. Since I use a Super Everdrive, the colours I got were less interesting than the ones you got from your SD2SNES.

This version gives me 100% black glitching (unless some of the blue on that line is glitching too; it's hard to tell with a one-colour sprite layer):

hvdma.sfc
(32 KiB) Downloaded 112 times

It might be useful to deliberately load a bunch of colours into the sprite palettes and see what happens... but I might wait until I've arrived at a better understanding of what else needs looking at rather than continuing to upload a string of identically-named ROMs with minor changes...
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Errors with INIDISP

Post by Pokun »

93143 wrote: Mon Feb 22, 2021 6:17 pm But the transfer seems to take? The BG tile is rewritten successfully, highlight and all, and the sprite data as shown on subsequent lines isn't corrupted?
Yes the transfer seems to take place. The line before the glitch line has the second type of tile (the blue one) in the background layer, and it continues so for the rest of the screen down.

I will run the updated test program sometime soon when I can.
UnDisbeliever
Posts: 124
Joined: Mon Mar 02, 2015 1:11 am
Location: Australia (PAL)
Contact:

Re: Errors with INIDISP

Post by UnDisbeliever »

I've documented this glitch on my INIDISP register document.

While I was writing the document I noticed this glitch can also cause corrupted background tiles on my 3 Chip SFC console.
Black dots and corrupted tiles. 1-CHIP consoles do not show tile corruption.
Black dots and corrupted tiles. 1-CHIP consoles do not show tile corruption.
inidisp-hammer-0f8f-3chip-bg.jpeg (8.84 KiB) Viewed 750 times

Ikari has published a blog post about the glitch. It includes a timing diagram that nicley describes the hardware bug.

The FXPAK firmware bug that can cause this glitch has been fixed in Firmware v1.11.0 beta 1.




Ikari asked me to test if the SETINI register is also effected by this hardware bug, and it is. I was able to corrupt sprites by testing the OBJ Interlace bit of SETINI with a two-registers-write-once HDMA write of 0x02 to COLDATA ($2132) and 0x00 to SETINI ($2133). The glitched sprites appeared on both my 3-chip and 1-chip SFC consoles. (link to test source code)
Corrupted sprite graphics with a HDMA write to SETINI.
Corrupted sprite graphics with a HDMA write to SETINI.

I also tested and confirmed the Mode 7 EXTBG bit of SETINI is also effected by this hardware bug on both my 3-chip and 1-chip SFC consoles. (link to test source code)
Output of a test that constantly writes the value 0x40 to SETINI (enable Mode 7 EXTBG) while the previous value on the data-bus is 0x00.
Output of a test that constantly writes the value 0x40 to SETINI (enable Mode 7 EXTBG) while the previous value on the data-bus is 0x00.
Post Reply