Variations in Note Counter Values

[segaloco]

So I've been curious about something for a while. In the RP2A02 datasheet as produced by Ricoh is a table of counter values for producing notes, which I have reproduced in my standard system headers (all sharps, x instead of # for simplicity):

Code: Select all

		.enum	apu_chromatic_scale
			A1	= $7F2
			Ax1	= $780
			B1	= $714
			C2	= $6AE
			Cx2	= $64E
			D2	= $5F4
			Dx2	= $59E
			E2	= $54D
			F2	= $501
			Fx2	= $4B9
			G2	= $475
			Gx2	= $435
			A2	= $3F9
			Ax2	= $3C0
			B2	= $38A
			C3	= $357
			Cx3	= $327
			D3	= $2FA
			Dx3	= $2CF
			E3	= $2A7
			F3	= $281
			Fx3	= $25D
			G3	= $236
			Gx3	= $216
			A3	= $1FC
			Ax3	= $1EC
			B3	= $1C5
			C4	= $1AC
			Cx4	= $194
			D4	= $17D
			Dx4	= $168
			E4	= $153
			F4	= $140
			Fx4	= $12E
			G4	= $11D
			Gx4	= $10D
			A4	= $0FE
			Ax4	= $0F0
			B4	= $0E2
			C5	= $0D6
			Cx5	= $0CA
			D5	= $0BE
			Dx5	= $0B4
			E5	= $0AA
			F5	= $0A0
			Fx5	= $097
			G5	= $08F
			Gx5	= $087
			A5	= $07F
			Ax5	= $078
			B5	= $071
			C6	= $06B
			Cx6	= $065
			D6	= $05F
			Dx6	= $05A
			E6	= $055
			F6	= $050
			Fx6	= $04C
			G6	= $047
			Gx6	= $043
			A6	= $040
			Ax6	= $03C
			B6	= $039
			C7	= $035
			Cx7	= $032
			D7	= $030
			Dx7	= $02D
			E7	= $02A
			F7	= $028
			Fx7	= $026
			G7	= $024
			Gx7	= $022
			A7	= $020
			Ax7	= $01E
			B7	= $01C
			C8	= $01B
			Cx8	= $019
			D8	= $018
			Dx8	= $016
			E8	= $015
			F8	= $014
			Fx8	= $013
			G8	= $012
			Gx8	= $011
			A8	= $010
			Ax8	= $00F
			B8	= $00E
			C9	= $00D
			D9	= $00C
			Dx9	= $00B
			F9	= $00A
			G9	= $009
			A9	= $008
			B9	= $007
			D10	= $006
			F10	= $005
			A10	= $004
			D11	= $003
			A11	= $002
			A12	= $001
			none	= $000
		.endenum

However, I've found that even within Nintendo, there is quite a bit of variability in which values are actually chosen for the notes. Linked are a couple note tables from Donkey Kong and Super Mario Bros., and the Legend of Zelda:

https://gitlab.com/segaloco/fc_dk/-/blo ... nd/notes.s
https://gitlab.com/segaloco/smb/-/blob/ ... pu/notes.s
https://gitlab.com/segaloco/zel/-/blob/ ... pu/notes.s

I assume these all derive from the same original tables, because the same notes tend to have the same counter offsets. The A#3 in particular is 13 ticks down from the reference value. The same offset I actually observe in the published reference value and the resulting calculated value produced by the note extraction algorithms in Super Mario Bros. 3, which use a 12-word table and octave shifts to calculate the notes.

This does beg the question of whether the published values were just inaccurate, if there was some motivation to have a set of values that differed slightly from the published specs, etc.

Something I intend to revisit once I'm done with this stuff is the PAL situation with timer values between a few titles to see if the PAL versions of these tables look similar. This could then be useful for deriving more accurate PAL-ization of note values based on an aggregate of the values used in real titles by folks close to the source.

Any thoughts on why the situation is so bizarre? One thing this does have me wondering is if even the earlier titles used some sort of shift table with the octaves because of the numbers I have calculated, the reference values in older titles do seem to match pretty well with what you get from doing the shifts on the semitone table in SMB3. Maybe they simply had a set of macros before and have been using the same semitone reference all along, which would explain some of the differences. If the shift is based on the actual mathematical operation, then maybe the way in the games is more accurate than the datasheet.

[Dacicus]

IIRC, the title music for The Legend of Zelda has a vibrato effect on some of the long notes. Maybe that might explain some of the differences.

[segaloco]

There is a pitch bend mechanism in SMB3, I haven't checked too deep into the Zelda variant of the engine to see if it's in there too. I don't think it is but I postponed my Zelda disasm until I wrap up the SMB3 stuff.

[Pokun]

Those counter values seems to match the chromatic scale table found in the early handwritten official devdocs we have exactly, if they were miscalculated the mistake might have been done by some engineer early on.

Most values are only off by one compared to the modern values though so it doesn't seem like it would be noticeable, as long as they are correct relatively.

I've seen dissemblies of games like Super Mario Land which shows that Nintendo had some calculation errors for the note pitches on the Game Boy APU too.

[segaloco]

Is that different than the Japanese documents from Ricoh? I'm referring to the hand-written datasheet in Japanese from the early 80s. My main chromatic scale in my system-level APU header comes from that document. You'll notice then I use those note values in the note tables for the games, with whatever factor applied to the reference values. If there is some other official table, I should compare my tables with that...

[Drag]

Michiya Hirasawa wrote a sound engine for the Gameboy which saw a lot of use, but has a typo or something in its pitch table, because you'll occasionally hear a note (midi note C#5) that's very flat from where it's supposed to be. That, its bass waveform, and its drums are very distinctive and how you can identify that this is the music engine being used.

You can hear it all over Mickey's Dangerous Chase, but particularly stage 1's music.

What's interesting is that it never got fixed; there are games in 2000 with this engine that still have the same characteristic.

I don't think it's on purpose, maybe a typo when entering the pitch data into the source code or something.

[segaloco]

Well and I haven't actually gotten my guitar tuner out with these values to see how accurate they really are. Do any of you know if the current community-derived values are mathematically or observationally computed, and if the latter, via oscilloscope or simple chromatic tuner?

[lidnariq]

Mathematically derived, from 12TET A440.

If someone wants to compose with the triangle at the very top of its range, it'd be better to compose for A436, but we don't usually.

Tepples also previously asked about composing for Just Intonation, but I don't think we have any playback engines that make it easy to customize the period by scale degree. (You could swap out the tuning table after build, but that's not "easy")

[Pokun]

Is that different than the Japanese documents from Ricoh? I'm referring to the hand-written datasheet in Japanese from the early 80s.

I think we are talking about the same table. I meant this one:

[segaloco]

Yep thats the one, my sys/apu.i header table derives from that.

[Pokun]

OK, you just skipped the duplicates. I first thought it was taken from disassembles.

you'll occasionally hear a note (midi note C#5) that's very flat from where it's supposed to be. That, its bass waveform, and its drums are very distinctive and how you can identify that this is the music engine being used.

You can hear it all over Mickey's Dangerous Chase, but particularly stage 1's music.

What sound should I listen to exactly to identify Hirasawa's sound engine?

[Drag]

It's written in the quote: the out-of-tune C#5 (C# on other octaves is in-tune, just the one on that octave is not), the waveform used for the wave channel (bonus, it varies the volume for key on/key off), and the drum sounds, which are similar between all of the games I checked that use that engine. Really it's the out-of-tune C#5 that's the dead giveaway.