APU crosstalk 16-bit bug

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.
Post Reply
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

APU crosstalk 16-bit bug

Post by jeffythedragonslayer »

What is the APU crosstalk 16-bit bug mentioned here?

https://wiki.superfamicom.org/open-problems
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: APU crosstalk 16-bit bug

Post by rainwarrior »

I believe that's described here: SPC700 Communication Ports
Hardware Quirk! When writing in 16-bit values to 2140 / 2141, a noise pulse (or some technical thingy) may write data to 2143 too! Always write to 2140 / 2141 with 8-bit writes if this is undesired.
I think this is something that's kind of erratic and not really known how to emulate accurately. I think games just avoid doing it, so emulating it might be a little bit moot?
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

Re: APU crosstalk 16-bit bug

Post by jeffythedragonslayer »

Oh, that one. It sounds like emulating it would be in higans' design goals, right? But I'd want a development focused emulator to throw an exception when doing something undefined behaviory like that so I don't wind up writing code like zsnes-only romhacks.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: APU crosstalk 16-bit bug

Post by 93143 »

jeffythedragonslayer wrote: Fri May 20, 2022 9:58 pmBut I'd want a development focused emulator to throw an exception when doing something undefined behaviory like that
That might be hard, considering a lot of emulation is just guessing what the system does accurately enough to run games. The S-PPU in particular has not been reverse-engineered from a decap, so the actual hardware algorithm is not known; this is why switching BG modes mid-scanline isn't properly emulated (it works in higan as of v095, but the garbage pattern isn't correct, and - importantly - I don't think it emulates the glitch pixels that can show through sprites placed on top of the split). It might be easy to miss a corner case where the behaviour is not understood but the issue simply hasn't come up yet.

Having the emulator barf on specific "don't do this" actions might be good as an optional feature. But ultimately there's no substitute for testing on real hardware, ideally hooked up to a CRT TV. Not only are you guaranteed to get correct behaviour (at least if you have access to all revisions of the hardware...), but you can actually use "undefined" behaviour if you can figure out what it does.

For the specific case you're talking about, it's perfectly fine to write to $2140 using 16-bit mode in certain cases, not only if you don't care about the value of $2143 but if you're about to overwrite it before it can be read. HDMA audio streaming probably causes the glitch, but it doesn't matter because if your pickup loop is working properly there's no way for the SPC700 to ever see the glitched value.
User avatar
jeffythedragonslayer
Posts: 344
Joined: Thu Dec 09, 2021 12:29 pm

Re: APU crosstalk 16-bit bug

Post by jeffythedragonslayer »

So #2 is definitely blocked by needing the PPU reverse engineered from a 50x (and preferably 100x according to Near,) die scan. I suspect #3, #7, #9, and #10 are as well to varying degrees. That makes this APU crosstalk bug sound like no big deal.

I don't have a logic analyzer yet or CRT currently. My snes is hooked up to an LCD monitor but it beats accidentally scribbling over VRAM in snes9x. :lol:
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: APU crosstalk 16-bit bug

Post by 93143 »

jeffythedragonslayer wrote: Sat May 21, 2022 2:16 am So #2 is definitely blocked by needing the PPU reverse engineered from a 50x (and preferably 100x according to Near,) die scan.
I don't know about definitely. If one could get a logic analyzer between the two chips, it might be enough. I'm not a hardware guy, so I'm not sure.

As for the others, they seem to me to be at least partly susceptible to experiment.
My snes is hooked up to an LCD monitor but it beats accidentally scribbling over VRAM in snes9x. :lol:
It does.

I'm using the Super FX for my game, so at some point I'll need a custom devcart with a real chip, but for now a flash cart will have to do...
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: APU crosstalk 16-bit bug

Post by creaothceann »

jeffythedragonslayer wrote: Sat May 21, 2022 2:16 am So #2 is definitely blocked by needing the PPU reverse engineered from a 50x (and preferably 100x according to Near,) die scan.
Not just one scan, you'd need to scan all the layers one by one, then create a vector representation, then decode the circuits, and finally work out what the effects and side effects are.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: APU crosstalk 16-bit bug

Post by lidnariq »

And even with Visual2C02, it's still taken us a while to find the weird edge cases in the NES. Just a complete description of the logic isn't yet sufficient.
Kingizor
Posts: 24
Joined: Sat Jun 18, 2011 10:50 am

Re: APU crosstalk 16-bit bug

Post by Kingizor »

I'm reasonably sure I tested all of this at some point.

According to my vague recollection and notes (do not trust either), I apparently wrote the APU ports from the CPU side with many different types of writes; 8-bit CPU, 16-bit CPU, and various kinds of stacked DMA from successive channels to different ports, and I didn't encounter a single sign of the $2143 glitch, or similar.

While those writes are fairly regular, I don't see any persistent loops in my source code, if for example the glitch was rare enough that it only happened very rarely, or that it might only happen with frequent writes of a particular kind, etc, then it wouldn't have shown up for me.

However, I'm not aware of anyone describing it or encountering it first-hand either though and that's a big problem. The primary source for it seems to be under "Sound Programming Caution #10" in the APU section of book 1 which provides a description of the conditions and a diagram. Fullsnes only paraphrases this whereas anomie's documentation doesn't mention it at all, so it would seem neither they nor anyone in their radius up to that point was able to trigger it either.

I'm inclined to say it can't happen under normal circumstances, or if it can then only on an early hardware revision or development hardware with a suitably overloaded culprit cartridge? When the bus is overloaded you'd probably expect strange things to happen anyway so this glitch as a symptom wouldn't really be noteworthy on its own. Otherwise, it would seem that all discussion of it stems from that single source.

Although perhaps my test ROM was borked all along and it's actually fairly trivial to trigger? Perhaps everyone else has written their own test ROMs that do trigger it reliably and it's just me that's wrong, how embarrassing? :oops: We can't just have people saying it happens but no-one has ever made or seen it happen, so if someone has done it I'd certainly like to hear all the scary details.

The interloping reads/writes between CPU/APU is somewhat related and it's comparatively very easy to trigger, but even then it doesn't happen too often. With CPU writing and APU reading, I recorded it happening a bit less than once every 16 writes, and around one in a thousand in the other direction. The numbers varied a lot between runs so consistency is out of the question. An emulator should have some degree of randomness there and independent verification would be even better yet!

There was some ever so quiet talk of yet another supposed quirk with the APU ports that's been on my mind ever since I heard of it and I still haven't gotten around to investigating it. I need to do that some day as well, I feel stressed just thinking about it. I only tested those other two things because my boat wasn't sailing and it turned out to be nothing to do with either of them.
PPU
Exciting stories and shocking revelations for another day, or not, I'm feeling a bit too worked up as it is, not to mention all these mysterious contradictory elaborations I'm apparently waiting on first.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: APU crosstalk 16-bit bug

Post by calima »

I don't think I've seen the 2143 thing ever, but I did change to 8-bit writes as the doc advised early on. The read-write mismatch was very easy to trigger, GSS hanged quickly. The Japanese sound weirdness is still unsolved, and I haven't seen anybody else mention it, anywhere on the internet.
Post Reply