nesdev.com

I was looking at Akumajou Densetsu earlier and I noticed that after every write to the sound registers at 8000-8002 / 9000-9002 / A000-A002, it follows up with an immediate jsr to a NOP routine that ends up burning 32 cycles.

I didn't see anything equivalent in Madara or Esper Dream 2, but they both seem to have more than that delay between writes just by some actual functional code in between.

I've seen homebrew NSFs play fine on hardware (e.g. TNS devices) that have shorter periods between writes (Famitracker seems to go about 14 cycles between?) and haven't spotted a problem with them.

I'm just curious if there's really supposed to be a "speed limit" on VRC6 writes like there is on VRC7. At least with the VRC7 I know why, but seeing intentional delays like this in AD makes me wonder if it has any real write speed problems, or maybe at some early point in the design such a problem was presumed? Anyhow, just kind of strange, really, I might try and do some write speed tests later on when I get back to working on NSFPlay.

Other than the OPL series, the only sound IC I know of that requires an incomprehensibly long delay between writes also is the SN76489...

Maybe they were planning to use a Yamaha chip like they did later, but changed it late in development? I could see some poor programmer in crunch mode not realizing the JSRs didn't do anything useful.

When using the SN76489 derivative in the Megadrive VDP, I didn't include any delays when writing to multiple registers, but it seemed fine. Is this a problem with the standalone chip only?

I can't really do anything more than quote the datasheet?

The SN76494 and SN76494A require approximately 4 clock cycles to load the data into the control register. The SN76496 and SN76496A require approximately 32 clock cycles. The open-collector READY output is used to synchronize the microprocessor to this transfer and is pulled to the false state (low) immediately following the falling edge of C̅E̅ (or W̅E̅ when data transfer is initiated by W̅E̅). READY will go high upon completion of the data transfer cycle.

(emphasis mine, just to ease comprehension)

The 76494 has a maximum clock of 500kHz and the SN76496 has a maximum clock of 4MHz: the only difference is the latter has a global divide-by-8 on its clock input.

This requirement is that the data bus be stable for the whole time; while this design clearly intended to stall the CPU during a write, an external latch also works.

This delay is pretty incomprehensible to me. I don't see, even given late 1970s technology, why latching the values takes more than a single cycle.

Really, the only way to know is write a test ROM or something, maybe something that can be used with hotswapping, so that it doesn't require the damagement of a working VRC6 cartridge.

Did someone ever make a test ROM for this? I'm asking because I'm trying to narrow down which expansion audio chips require a delay, for the purpose of developing specialized audio drivers for the next Famicompo Pico.

It's on my to-do list to test out (which might happen in the near future now that Lizard is finished), but from what I already know I'd be very surprised if there's any kind of speed limit on it.

Famitracker's driver has never had delays in its VRC6 code. I don't think PPMCK did either (but I can't find its source right now). I've done a bunch of hotswap tests with it and never noticed anything like that, and I know one or two people who have done relatively high frequency writes to it and had the expected behaviour.

So... my strong guess is that this is a leftover useless delay.


TBH I'm not exactly sure what I would do to test this if there's nothing obviously wrong with current emulation in this respect.