New VRC7 patch set

[Lord Nightmare]

How difficult do you think it would be to adopt Nukey's method for the original YM2413? That chip's patch set has yet to be dumped. It seems like, according to the wiki, that grounding the debug pin on the VRC7 seems to turn some of it's other pins into the bus control lines available on the YM2413. If that is the case, then the YM2413's test mode should be just as easy to access as the VRC7's.

I don't think it will be as easy.
The YM2413 has far fewer pins than the VRC7 does (just 18 pins total), so I don't believe there is a pin that the debug mode could easily 'hide' behind. However, the YM2413 application manual ( http://www.smspower.org/uploads/Develop ... 2413am.pdf pdf page 6, document page 3) DOES state that there is a debug/test mode involving pins D0 and D1 becoming outputs, if /CS is low(active), /WE is high(inactive) and A0 is low. If, in this mode, D2 thru D7 are still inputs, that means D2-D7 can select between 64 different pairs of bits to be 'visible' on D0 and D1, for 128 bits of internal state visible. The test mode of the VRC7 (described at https://pastebin.com/2gAwGmFT ) gives 40 bits of internal state. Each patch is 64 bits, but the two operators for each channel, modulator and carrier, happen one after the other, so you see only half the data (some of it common for modulator/carrier) for each patch at a time, sequentially for all the channels. (what the exact order is of this data vs the channel number, I'm not sure.)
So 128 bits, if D2-D7 really work that way, is more than enough data to hold not only all 40 bits of the 'current patch state', but also other fun stuff like the current phase count, current envelope count, bits having to do with the envelope position and key-on, etc. Even if it turns out only 64 bits are available, that's still enough for 40 patch bits plus 24 other bits.

Also, for this debug/test mode on the YM2413/OPLL, does changing A0 have any effect? The document seems ti imply that if /CS is low, /WE is high and A0 is high, the data bus is high impedance/disconnected, but this could use testing as well.

LN

[nukeykt]

Some info about VRC7's test register(0x0f):

Code: Select all

Test register:
Bit 0: EG output mute
Bit 1: Set next noise bit to 1, Reset/Halt LFO(both tremolo and vibrato)
Bit 2: PG halt/reset
Bit 3: Update tremolo and vibrato every sample(i.e tremolo is 64 times faster and vibrato is 1024 times faster than normal), custom EG timer value input via D2 pin

This info was gathered by analyzing VRC7 die shot and i haven't tested it on hardware so this info might be incorrect. I don't know if this info also can be applied for YM2413.

Also VRC7 has it's own way to test DAC. You need to set VRC7 to debug mode, connect pin 2 to ground and pin 47 to +5v(or vice versa, not 100% sure). Then you just need to write 8 bit sample to VRC7(any port, A0 is ignored)

[rainwarrior]

So I wrote a simple hotswap test (test_vrc7) to verify that theory.

I've attached a recording of the test ROM. It plays a 3 second reference tone, then a series of 8 tones where it's on for 1 second, sets a $0F bit for 1 second, then clears the $0F bit for 1 second, then release. After that it plays 3 tones after toggling bit 1, then 3 tones without doing that to show that it can reset LFO. The test is done twice, once with instrument 10 (demonstrates tremolo), and again with instrument 12 (demonstrates vibrato).

So the observed effects from the recording:

• bit 0 - tone goes very noisy/buzzy (feedback?) and is maybe stuck at full volume (envelope appears to have continued on through this period though, when it resumes it has already fallen to where it should be)
• bit 1 - LFO immediately stops, seems like it's resetting immediately to 0 and not just halting
• bit 2 - Tone goes silent, envelope seems to have continued through.
• bit 3 - With instrument 10 it makes a mild rapid buzz and with instrument 12 it seems like the vibrato is halted (but if it's 1024x speed it's maybe just so fast it sounds flat). By the envelope curve of instrument 10 it looks like the envelope is paused while this bit is set, and does not resume until it is cleared? (Instrument 12 has a flat envelope after 1s so this effect isn't noticeable in the second test.)
• bit 4-7 no effect

Also, toggling bit 1 does indeed seem to reset both LFOs, which is great! Finally a technique that works for that.

Edit: so compared to your description... what does the "next noise bit" mean? And was this maybe attached to bit 0 rather than bit 1 of this $0F register, explaining the buzzy/feedback-style noise? The other 3 seem to correspond to your description validly, though I guess I don't know what the bit 3 function of D2 you described to clock the EG is... but it does seem that EG is effectively halted by it for this test so that seems to corroborate?

[rainwarrior]

Updated my patch_vrc7 hotswap test ROM with a few extra attempts to get the LFOs synchronized, etc. with this new information.

Made a reference recording using the new patch set, in case anyone wants to see/hear how perfect it is. (I'm still kinda shocked by finally having this data!)

http://rainwarrior.ca/projects/nes/patc ... keykt.flac (39MB FLAC)

[nukeykt]

Edit: so compared to your description... what does the "next noise bit" mean? And was this maybe attached to bit 0 rather than bit 1 of this $0F register, explaining the buzzy/feedback-style noise? The other 3 seem to correspond to your description validly, though I guess I don't know what the bit 3 function of D2 you described to clock the EG is... but it does seem that EG is effectively halted by it for this test so that seems to corroborate?

I was a bit unclear/wrong with bit 0. it just disables EG output and zero attenuation value is sent to operator unit(i.e operator outputs at full volume).
In bit 1 description i meant rhythm mode's noise generator(23 bit LSFR) which doesn't affect melodic channels.
Bit 3 allows to serially input EG timer value, but you need to write it at the rate of MCLK/4, so if don't write anything to it, or write with wrong timing EG will basically stuck.

[rainwarrior]

Oh, the noisiness with bit 0 set is just the modulator being forced to full strength isn't it. Ah, okay.

[tepples]

j0CC-FamiTracker 0.6.1 (released 2018-09-29) uses earballed patches allegedly from this topic (t=9141): vrc7tone.h (0.6.1)

j0CC-FamiTracker 0.6.2 (released 2019-06-15) uses Nuke.YTK's dump (p=236280): vrc7tone.h (0.6.2)

The attached module starts a note on one preset then switches to another after one frame. The hi-hat sounds very different between the two.

Thwaite_0300_VRC7.0cc

(2.86 KiB) Downloaded 98 times

In the 0.6.1 patch set, the hi-hat sounds like a tink

Thwaite_0300_VRC7_j061.ogg

(58.25 KiB) Downloaded 100 times

In the 0.6.2 patch set, the hi-hat sounds more properly noisy

Thwaite_0300_VRC7_j062.ogg

(57.02 KiB) Downloaded 102 times

Who has the hardware to play a VRC7 NSF to settle this?

Thwaite_0300_VRC7.nsf

(8.16 KiB) Downloaded 107 times

EDIT: The 0.6.1 patches are not by plgDavid. They may be Rainwarrior's set.

[rainwarrior]

Who has the hardware to play a VRC7 NSF to settle this?

I don't have an easy setup for playing arbitrary NSFs through carts (wish I had a TNS thingie) but in my post directly above is a recording of a hotswap test demonstrating every preset patch in several pitches against nukeykt's dump. I have complete confidence in its accuracy. The sounds match up perfectly.

Take 2 copies of that FLAC, offset one of them by 242189 samples, and compare. I haven't been able to spot anything in there that isn't a perfect match.

[tepples]

Another reason I brought this up is that plgDavid seems to believe that use of the ripped patches infringes Konami's or Yamaha's copyright in the patches. If true, this means a legal clone would need to use earballed patches, and VRC7 composers would need to make their compositions compatible with earballed patches as well.

[lidnariq]

Current jurisprudence in the US is pretty clear that numbers as small as those needed to configure an OPLL patch are much too small to qualify for copyright, and even the set of a specific set of 15 would be very hard to argue qualify for the separate set of protections granted to aggregate works (like phone books).

[plgDavid]

Current jurisprudence in the US is pretty clear that numbers as small as those needed to configure an OPLL patch are much too small to qualify for copyright, and even the set of a specific set of 15 would be very hard to argue qualify for the separate set of protections granted to aggregate works (like phone books).

By pretty clear, you have a pointer to that? Also the rest of the world might see things differently. Note I'm very glad that NukeyTK has found a way to dump these, but for us (we have our small company to lose), we always play with caution.
Cheers

[lidnariq]

I mean, if your objective is to not get sued, there's no point in arguing, regardless of what case law says. People get sued over things that wouldn't make any sense, but the defendant still has to show up in court and waste their time.

But to directly answer your question, a really quick search finds this case:
https://caselaw.findlaw.com/us-3rd-circuit/1169734.html
and this writeup:
https://ptslaw.com/wp-content/uploads/2 ... _Parts.pdf
wherein the plaintiff

Southco manufactures various products, including rivets, latches, handles and fasteners. It had developed a numbering identification system using nine digits, where each digit or group of digits signified a relevant characteristic of the respective product.

which sounds awfully similar to a description of the parameters of an OPL patch to me.

The writeup continues that

Four years and two reversals later, the Third Circuit finally held that the product numbers weren’t entitled to copyright protection. It based its holding on two separate grounds: (1) the product numbers lacked originality, and (2) the product numbers constituted the equivalent of a short phrase, something which has long been held non-protectable by copyright.

[plgDavid]

Southco manufactures various products, including rivets, latches, handles and fasteners. It had developed a numbering identification system using nine digits, where each digit or group of digits signified a relevant characteristic of the respective product.

which sounds awfully similar to a description of the parameters of an OPL patch to me.

Except that OPLL patches are creations, bytes specifically chosen for their musical qualities, which is different than a random numbering system, but I like the parallel. Thanks for the legal links.

[rainwarrior]

I think the Blu Ray AACS encryption keys might be a closer analogy? Notably the claims made against the sharing of these seemed to be entirely about it being a way to circumvent anti-piracy measures, something protected by the DMCA, and not actually about any copyright claim on the encryption keys.


Of course, this is a very different situation. The most important difference I'd point out is that Konami is not making or selling the VRC7 or any games made with it, or even emulation of them. There is almost nothing at stake for them in this situation. Maybe a very unlikely possibility is that they'd release an emulated Lagrange Point?

Even in that situation, what would they get from this? The VRC7 patches are dumped now, they can't take that information back. At best they'd be pushing back a few emulator releases from perfect sound emulation to almost perfect sound emulation? Would there be much point to that? It certainly wouldn't give them any real competitive advantage.

Even if this was a danger, you could just treat it the same way things like BIOS dumps are treated and tell users that if they want more accurate patches they should download nukeykt.vrc7 from someone who is willing to take the risk of hosting it.


Personally I think that would be a nuisance, and a completely unnecessary prophylactic measure against a copyright claim that will never be made, but everybody's got their own level of comfort with this I guess.