Posted: Thu Jun 18, 2009 11:59 pm
That table is correct, but mostly redundant. I use the following table in my core:
This corresponds with the lookup table for fnum bit 9. You'll note that the lookup table for every other bit is simply a shift of this table. For fnum bit 10, shift the values up by 1. For fnum bit 8, shift the values down by 1. For fnum bit 7, shift the values down by 2, etc. Note that I say the table above corresponds with fnum bit 9, but in MAME, since they're giving the values for use with a 12-bit fnum calculation instead of an 11-bit calculation, the MAME table for fnum bit 9 will be shifted up by 1.
Looking back on my notes, I've realised there's some testing I still haven't completed for frequency modulation. I've talked about the upper six bits being relevant for frequency modulation, and the lower bits not having an effect. That's not entirely true however. According to my notes, I measured sign-extension taking effect in the negative portion of the frequency modulation wave, even when the only fnum bits set were below the upper six bits, all the way down to fnum bit 0, which suggests that the frequency modulation value may be calculated at full precision, then the lower bits discarded when it is combined with fnum, eg:
In this case, the lookup table I've given above would correspond with fnum bit 0, and you would shift up from that for each place above bit 0, then negate the value if we're in the negative half of the wave, and finally you'd shift down 9 places and add the result to fnum. I don't do this in my core currently however. Like MAME, I'm just grabbing the upper bits of fnum and calculating the frequency modulation value directly in the 11-bit target. If the real hardware calculates the frequency modulation adjustment at full precision based on all the bits of fnum however, this may not be accurate, since a carry could be generated from bit 8 of the frequency modulation value for example. I was going to perform a set of tests to confirm whether this was the case, and then make adjustments to my core as necessary, but I lost time to work on it, and I didn't end up completing the test. I'll try and find some time to carry out this test, so we know for sure how the frequency modulation value needs to be calculated. Personally, I think it's likely the value is calculated at full precision. MAME would also effectively generate a carry from bit 8 currently, due to the extra bit of precision they added to the pipeline. I'll have to do some math and see if I can construct a test where I can measure a carry taking place from bit 7 or lower.
Code: Select all
const unsigned int YM2612::phaseModIncrementTable[1 << pmsBitCount][1 << (phaseModIndexBitCount - 2)] = {
{0, 0, 0, 0, 0, 0, 0, 0}, //0
{0, 0, 0, 0, 1, 1, 1, 1}, //1
{0, 0, 0, 1, 1, 1, 2, 2}, //2
{0, 0, 1, 1, 2, 2, 3, 3}, //3
{0, 0, 1, 2, 2, 2, 3, 4}, //4
{0, 0, 2, 3, 4, 4, 5, 6}, //5
{0, 0, 4, 6, 8, 8,10,12}, //6
{0, 0, 8,12,16,16,20,24}}; //7
Looking back on my notes, I've realised there's some testing I still haven't completed for frequency modulation. I've talked about the upper six bits being relevant for frequency modulation, and the lower bits not having an effect. That's not entirely true however. According to my notes, I measured sign-extension taking effect in the negative portion of the frequency modulation wave, even when the only fnum bits set were below the upper six bits, all the way down to fnum bit 0, which suggests that the frequency modulation value may be calculated at full precision, then the lower bits discarded when it is combined with fnum, eg:
Code: Select all
// ---------------------------------------------
// | Fnum (11-bit) |
// |-------------------------------------------|
// |10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
// ---------------------------------------------
// ---------------------------------------------------------------------------------
// | Frequency Modulation Value (20-bit) |
// |-------------------------------------------------------------------------------|
// |19 |18 |17 |16 |15 |14 |13 |12 |11 |10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
// ---------------------------------------------------------------------------------
//10 | 4 | 3 | 2 | 1 | 0 |
// 9 | 4 | 3 | 2 | 1 | 0 |
// 8 | 4 | 3 | 2 | 1 | 0 |
// 7 | 4 | 3 | 2 | 1 | 0 |
// 6 | 4 | 3 | 2 | 1 | 0 |
// 5 | 4 | 3 | 2 | 1 | 0 |
// 4 | 4 | 3 | 2 | 1 | 0 |
// 3 | 4 | 3 | 2 | 1 | 0 |
// 2 | 4 | 3 | 2 | 1 | 0 |
// 1 | 4 | 3 | 2 | 1 | 0 |
// 0 | 4 | 3 | 2 | 1 | 0 |