It is currently Sat Aug 18, 2018 11:32 am

 All times are UTC - 7 hours

 Page 1 of 1 [ 9 posts ]
 Print view Previous topic | Next topic
Author Message
 Post subject: APU PulsePosted: Wed Jun 28, 2017 3:23 pm

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1365
http://wiki.nesdev.com/w/index.php/APU_Pulse

I am trying to emulate the duty cycles.

Quote:
Duty Cycle Sequences

Duty Waveform sequence
0 0 1 0 0 0 0 0 0 (12.5%)
1 0 1 1 0 0 0 0 0 (25%)
2 0 1 1 1 1 0 0 0 (50%)
3 1 0 0 1 1 1 1 1 (25% negated)

The reason for these odd sequences is that the sequence counter is initialized to zero but counts downward rather than upward

This is my approach:

Code:
auto APU::Pulse::clock() -> uint8 {
if(!sweep.checkPeriod()) return 0;
if(lengthCounter == 0) return 0;

static const uint dutyTable[4][8] = {
{0, 1, 0, 0, 0, 0, 0, 0},  //12.5%
{0, 1, 1, 0, 0, 0, 0, 0},  //25.0%
{0, 1, 1, 1, 1, 0, 0, 0},  //50.0%
{1, 0, 0, 1, 1, 1, 1, 1},  //25.0% (inverted)
};
uint8 result = dutyTable[duty][dutyCounter] ? envelope.volume() : 0;
if(sweep.pulsePeriod < 0x008) result = 0;

if(--periodCounter == 0) {
periodCounter = (sweep.pulsePeriod + 1) * 2;
dutyCounter--;  //note this is a uint3 type. If the value is zero, dutyCounter-- becomes 7.
}

return result;
}

(\$4003, \$4007 writes set dutyCounter=7 currently.)

By counting backward, it will effectively output:
00000001
00000011
00001111
11111100

Which looks nice, but I'm not sure if that's the intention or not.

But if you really mean we should be outputting LITERALLY:
01000000
01100000
01111000
10011111

Then why mention the decrementing thing? It's just confusing. If the counter is supposed to decrement, then store the table as if you're decrementing the counter (like my first example) and say you should decrement. If the counter is supposed to increment, then store the table in that order (like the second table) and don't talk about decrementing. Really, it's not a great code simplification to turn a decrement into an increment, in return for making the table look like hot garbage. >_>

Any help would be appreciated. I'd try to emulate this by ear but I cannot tell the difference at all between either way.

Top

 Post subject: Re: APU PulsePosted: Wed Jun 28, 2017 4:38 pm

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3111
Location: Tampere, Finland
byuu wrote:
But if you really mean we should be outputting LITERALLY:
01000000
01100000
01111000
10011111

That's correct. (Blargg's original doc doesn't mention decrementing, somebody probably added it based on Visual 2A03.)

Quote:
Then why mention the decrementing thing?

I agree that it's worded in a confusing way. It should say something like "... sequence counter in the NES APU hardware is initialized to zero ...".

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

Top

 Post subject: Re: APU PulsePosted: Wed Jun 28, 2017 4:44 pm

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20415
Location: NE Indiana, USA (NTSC)
I think the page mentions decrementing in order to explain how the circuit produces the sequence internally. I have edited the page to clarify this, giving both the lookup table and the resulting output.

Top

 Post subject: Re: APU PulsePosted: Wed Jun 28, 2017 5:18 pm

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6598
The information of primary importance is the output sequence. That's what matters.

What it does internally is irrelevant to an emulator, or for working with the output sound (e.g. making music). Nothing depends on whether it's counting up or down. Maybe it's nice to know why that weird sequence exists, but it's far more important that it just get the output correct.

I'd probably suggest making a separate "internal details" section further down in the article and explain that stuff there... I dunno. I just feel like the more words and diagrams you spend on those internal details the more it's going to confuse the useful bit about the actual output. Like, right now we have two tables, one with bits that it doesn't output, which precedes the table with bits that it does?

Top

 Post subject: Re: APU PulsePosted: Wed Jun 28, 2017 5:33 pm
 Formerly Fx3

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3140
Location: Brazil
rainwarrior wrote:
The information of primary importance is the output sequence. That's what matters.

What it does internally is irrelevant to an emulator, or for working with the output sound (e.g. making music). Nothing depends on whether it's counting up or down. Maybe it's nice to know why that weird sequence exists, but it's far more important that it just get the output correct.

Agreed.

Top

 Post subject: Re: APU PulsePosted: Wed Jun 28, 2017 5:41 pm

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20415
Location: NE Indiana, USA (NTSC)
...and done. Everything about the decreasing counter has been moved down to the "Implementation details" section.

Top

 Post subject: Re: APU PulsePosted: Wed Jun 28, 2017 5:55 pm

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6598
Yeah, that's probably an improvement.

Top

 Post subject: Re: APU PulsePosted: Wed Jun 28, 2017 6:33 pm

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1365
Quote:
The information of primary importance is the output sequence. That's what matters.

Right, but the output sequence changes completely depending on whether you increment or decrement through the 8-entry duty modes. The table expects [well, did. Updated now :)] you to increment (without telling you to do so), but then adds a note that it looks weird because real hardware decrements. I'm not a very bright person, and took it to mean that -I- should be decrementing in emulation (as I'm trying to emulate how the hardware worked here), which indeed made the true output look really nice and clean. Which is apparently wrong.

Quote:
...and done. Everything about the decreasing counter has been moved down to the "Implementation details" section.

Thanks a bunch! That looks nicer :D

Top

 Post subject: Re: APU PulsePosted: Wed Jun 28, 2017 8:04 pm

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 483
byuu wrote:
I'd try to emulate this by ear but I cannot tell the difference at all between either way.
The apu_mixer\square test rom's sound output should vary based on whether or not this is implemented properly (though the test will also vary based on a lot of other factors).

I actually misinterpreted the information on the Wiki in the exact same way a while ago and also ended up creating a thread about it, so it's definitely nice that the wiki's wording was changed to make this more obvious.

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 1 of 1 [ 9 posts ]

 All times are UTC - 7 hours

#### Who is online

Users browsing this forum: Gilbert and 4 guests

 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum

Search for:
 Jump to:  Select a forum ------------------ NES / Famicom    NESdev    NESemdev    NES Graphics    NES Music    Homebrew Projects       2018 NESdev Competition       2017 NESdev Competition       2016 NESdev Competition       2014 NESdev Competition       2011 NESdev Competition    Newbie Help Center    NES Hardware and Flash Equipment       Reproduction    NESdev International       FCdev       NESdev China       NESdev Middle East Other    General Stuff    Membler Industries    Other Retro Dev       SNESdev       GBDev    Test Forum Site Issues    phpBB Issues    Web Issues    nesdevWiki