Does writing 16-bits to $2140/$2141 really mess up $2143?

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
psycopathicteen
Posts: 2904
Joined: Wed May 19, 2010 6:12 pm

Does writing 16-bits to $2140/$2141 really mess up $2143?

Post by psycopathicteen » Sun May 12, 2019 4:51 pm

It says so on superfamicom, and I've been ignoring it, because it sounds like nonsense, but I've been scratching my head about it today.

Is it only a problem with $40/$41 or does something similar happen with $42/$43, or $41/$42, or writing to all 4 registers at once? Does writing to $43 afterward fix the problem?

User avatar
dougeff
Posts: 2614
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: Does writing 16-bits to $2140/$2141 really mess up $2143

Post by dougeff » Sun May 12, 2019 6:16 pm

Fullsnes mentions it. Some hardware bug.
nesdoug.com -- blog/tutorial on programming for the NES

User avatar
koitsu
Posts: 4215
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Does writing 16-bits to $2140/$2141 really mess up $2143

Post by koitsu » Sun May 12, 2019 6:53 pm

Comments in passing, which should be considered anecdotal despite being able to provide reference material for all of them:

1. OP cited material is here: https://wiki.superfamicom.org/spc700-reference#toc-16

2. Official documentation circa 1994 does not mention this problem (either in description/behaviour, Programming Cautions, or subsequent Errata documents)

3. Official SPC700 loader routine v1.1 circa 1994 uses 16-bit writes to both $2140-2141 and $2142-2143

4. Anomie's spc700.txt does not mention this problem, but does have this when describing SPC700 $F4-F7 (which correlate with $2140-2143), but I cannot tell if this is describing potentially the problem. I suspect not, as a 16-bit write to $2140 should write the lower 8 bits of A to $2140, followed by the upper 8 bits to $2141; I can't see how this description would end up writing something to SPC700 $F7:
If the SPC700 writes to an output port while the S-CPU is reading it,
the S-CPU will read the logical OR of the old and new values. The
exact cycles during which the 'read' actually occurs is not known,
although a good guess would be some portion of the final 3 master
cycles of the 6-cycle S-CPU memory access. Possibly the same thing
happens the other way around, but the details are unknown.
5. nocash's fullsnes document "Uploader" routine says Word[2142h]=dest_addr which looks to me like a 16-bit write to $2142-2143. I can't tell if this is harmless or harmful (I suspect harmless?), because the same document says (emphasis mine) for $2140-2143:
Caution: These registers should be written only in 8bit mode (there is a hardware glitch that can cause a 16bit write to [2140h..2141h] to destroy [2143h], this might happen only in some situations, like when the cartridge contains too many ROM chips which apply too much load on the bus).
If this is a real bug, then the fullsnes document should be a bit more clear. Example rephrasing and punctuation clean up:

Caution: There is a hardware glitch that can cause a 16bit write to [2140h..2141h] to destroy [2143h]. This may happen in some situations, such as when the cartridge contains too many ROM chips thus applying too much load on the bus. To alleviate this problem, only use 8-bit writes to 2140h..2141h.

In general, sounds to me like more analysis may be needed at the hardware level, especially if it's reproducible. "Too many ROM chips that apply too much bus load" sounds kinda like voodoo. But as I've said time and time again, I'm not a hardware guy.

nocash
Posts: 1086
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Does writing 16-bits to $2140/$2141 really mess up $2143

Post by nocash » Sun May 12, 2019 8:59 pm

That glitch is described in book1.pdf section 9.10.
The description versus example isn't really clear if they were talking about the data bus or address bus.

If it's specifically related to address B bus, then the problem would probably only occur for cartridges that do connect to B bus, ie. it would only occur only with a few coprocessor carts (or with stuff attached to expansion port). As far as I remember, some coprocessor carts have capacitors on B bus A0 or A1 or so, that might have been intended to fix the problem?

User avatar
koitsu
Posts: 4215
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Does writing 16-bits to $2140/$2141 really mess up $2143

Post by koitsu » Mon May 13, 2019 12:59 am

nocash wrote:That glitch is described in book1.pdf section 9.10.
The description versus example isn't really clear if they were talking about the data bus or address bus.
In this case, once again I'm actually thrilled to be proven wrong (and that it IS officially documented). Paper copy I have is missing pages 3-9-5 through 3-9-7, but they're there in the PDF. Argh! As always, thanks for catching this one! (I still maintain the phrasing in fullsnes should be changed to mention that it pertains to just $2140-2141 for some reason).

nocash
Posts: 1086
Joined: Fri Feb 24, 2012 12:09 pm
Contact:

Re: Does writing 16-bits to $2140/$2141 really mess up $2143

Post by nocash » Mon May 13, 2019 6:32 am

The phrasing in the pdf is a bit unclear, too. So it's hard to clarify what they meant. I assume 16bit writes to addr means (addr+0)=LowByte, (addr+1)=HighByte. Then problems with words at 2140, 2141 would translate to problems with all three bytes at 2140, 2141, 2142 possibly smashing the fourth byte at 2143.

Despite of that, the upload function (at the end of book1.pdf) does use 16bit writes. On the other hand, the problem is described to occur "when all CPU data simultaneously changes from high to low". I think that means something like writing "[2140]=00FF", maybe that isn't an issue in the uploader. And especially, the APU uploader doesn't really need 2143 to be kept intact (during the main part of the upload).

The cartridges where I had spotted the capactitors are S-DD1 boards (though others have those capacitors, too). S-DD1 doesn't really have "many ROM chips" (but has the S-DD1 chip, which might cause "equivalent" problems).
And, S-DD1 doesn't have any chips wired to B bus, so the capacitor is apparently related to B-bus problems in the console.

Code: Select all

S-DD1 PCBs
  SHVC-1N0N-01  CartSlotPin59 not connected (no C12 capacitor on PA1 pin)
  SHVC-1N0N-10  Strange revision (capacitor C12 between PA1 and GND)
  SNSP-1N0N-10  PAL version (S-DD1.Pin82 wired to ... VCC?) (also with C12)
  SHVC-LN3B-01  Version with additional SRAM for Star Ocean
The 1N0N board contains only two chips (100pin D-DD1 and 44pin ROM).
The LN3B-board contains five chips (two 44pin ROMs, S-DD1, 8Kx8bit SRAM, and a MM1026AF battery controller).

Post Reply