It is currently Tue Oct 24, 2017 12:54 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Mon Dec 26, 2016 4:22 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
On this page: https://wiki.nesdev.com/w/index.php/APU
"Writing to $4017 will restart the sequence almost immediately (2 or 3 CPU cycles delay)"


On this page: https://wiki.nesdev.com/w/index.php/APU_Frame_Counter
"If the write occurs during an APU cycle, the effects occur 3 CPU cycles after the $4017 write cycle, and if the write occurs between APU cycles, the effects occurs 4 CPU cycles after the write cycle."


So, is it 2/3? Or 3/4?

I assume it's 3/4, but clarification is appreciated.


On a side note -- this is a pretty good case against the amount of redundant info on the wiki -- particularly in the APU section. There's like 2 or 3 different places with register descriptions, and you kind of have to read all of them to get all the tidbits of info you need. All that that should probably be combined into one page -- and anything else that needs to touch on it should just have a link.


Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 6:11 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
Here's my notes on $4017. I requested help (_Q) that time.
Code:
        /* When writing to $4017, the frame counter reset
        and the quarter/half frame triggers happen simultaneously,
        but only on "odd" cycles (and only after the first "even" cycle
        after the write occurs) - thus, it happens either 2 or 3 cycles
        after the write (i.e. on the 2nd or 3rd cycle of the next instruction).
        After 2 or 3 clock cycles (depending on when the write is performed),
        the timer is reset.
        If the mode flag is set, then both "quarter frame" and "half frame"
        signals are also generated.
         */
        reg4017 = value;
        /* clear frameIRQ */
        if(value & 0x40)
           cpu_irqcancel(TIRQ_FRA);
 /* "and only after the first *even* cycle"
        ODD -> *0*, ]1[   -- takes 2 cycles
       EVEN -> 1, *0*, ]1[ -- takes 3 cycles
        */       
        apuCYC = even_odd ? (-2): (-3);
        break;


Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 6:31 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 284
IMHO the wiki's APU pages are garbage. You're better off looking at test ROMs and emulator source code.

I'd offer to help improve them, but I don't have the time, and I'd want to ensure I have verified test ROMs for everything, which would take even more time.


Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 7:01 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Zepper wrote:
the frame counter reset
and the quarter/half frame triggers happen simultaneously,
but only on "odd" cycles (and only after the first "even" cycle
after the write occurs)


Sooo... the wiki is wrong about this too, then, because it says the quarter/half clocks happen immediately.

Thanks Zepper.


Regarding the state of the APU wiki: The decision to use APU cycles for some areas and CPU cycles for other areas is also baffling. I'm hesitant to change things myself because I don't know if there's any consensus on the way the info is to be structured or what that consensus is.


Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 9:14 pm 
Offline
Formerly ~J-@D!~
User avatar

Joined: Sun Mar 12, 2006 12:36 am
Posts: 445
Location: Rive nord de Montréal
I'll attempt to predict what tepples will say: there's a discussion page on the wiki for that.


Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 9:25 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Let me cut in with a little extra because I don't want to sound like a complainer.

I love the wiki. It is infinitely better than a random mishmash of old docs and scattered forum posts. I know how much work it is to get a wiki up and running, keeping it maintained with constantly updating info, and trying to make everyone happy. So kudos to everyone involved.

I bring up issues here not because I'm trying to rag on anyone's hard work, but only because I'm trying to find clarification with some questions I have.


Top
 Profile  
 
PostPosted: Mon Dec 26, 2016 9:28 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
In addition, people who post to forums might not edit the wiki. But yes, I agree with Jarhmander that once we get an idea of the basic requirements of a reorganization, it might be a good idea to hash out the details on the wiki. If anything, it makes history of the talk pages and associated articles easier to correlate. That's one reason why I left talk page editing open to IP visitors.


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 5:31 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
Sorry for being harsh, but I need to give my $0.02 anyway...
I had an easy assumption that any new info should pass under the supervision of someone "in high degree", meaning people with hardware knowledgement for proper testing. Perhaps this is the reason for NOT editing the wiki. I already had a few disagreements editing the wiki, for language barrier (?) or just a different point of view. And no, I'm not in the mood for adventures in the visual6502.


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 10:35 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5736
Location: Canada
I created the APU article a few years ago because there was no summary of APU registers etc. and I wanted one central place to find that information, and branch out from there to articles about individual APU units where the "nitty gritty" details should appear. It was using the best information I had available to me at the time.

The individual APU unit articles are all older than this page, written by various people at various times, not in any consistent style, and some may still contain dubious information. All of them are in need of a cleanup.

Sometimes people add "nitty gritty" stuff to the APU summary article instead of the APU unit pages, and this does lead to divergence in some cases. It's really hard to arbitrate which stuff is too "fine" a detail to go on the summary page, but also I think people might be tempted to add there instead of some of the unit pages because of how inconsistent and disorganized they are.

Rahsennor wrote:
IMHO the wiki's APU pages are garbage. You're better off looking at test ROMs and emulator source code. I'd offer to help improve them, but I don't have the time, and I'd want to ensure I have verified test ROMs for everything, which would take even more time.

If you want the wiki to improve, you have to contribute to it. If you find something wrong with it, or are dissatisfied with something about it, fix it. Everybody has time they could spend on the wiki, but only a few people decide it's a worthwhile use of their time. Most people don't go back and try to improve the knowledge there after they've learned what they wanted to know. They just take from it and move on.

If you made use of knowledge from the wiki, it's because somebody decided to spend time on it. If you want it to be a good reference, make it one. When you add something to the wiki, the time you spent gets paid back to many, many people as they use it. There's a big multiplier on the value of these contributions that I don't think a lot of people really consider. If you gained something from the wiki, think about how a hundred people might do the same.

Also, when you forget things months or years later and need to remember it again, if you left behind a shitty mess that's exactly what you can look forward to using a second time-- in the long run it's even worth organizing this information just for your own selfish benefit.

Zepper wrote:
I had an easy assumption that any new info should pass under the supervision of someone "in high degree", meaning people with hardware knowledgement for proper testing.

I don't think the problem is due to the "degree" of the editors. A lot of people who do good hardware research here aren't interested in editing the wiki, and just because you know the truth of something doesn't mean you're good at teaching it to others.

Anybody with correct knowledge and an ability to communicate or organize that information should contribute. Our real problem is that there are so few contributors.

The best standard for adding information is the same in pretty much all academic situations, including wikipedia, and it's basically just: cite your sources.

If you add some note about the hardware because someone did some research and mentioned it in a forum thread, link to that thread. The wiki has a convenient <ref> tag to create footnotes, and they're perfect for showing people where the information comes from. This is very important to document, don't just add information you think is correct, leave a trail showing why you know this, so that in the future whenever someone needs to verify it can go to the source.

Imagine the OP's situation with good citations. The "3/4 cycles" would have a footnote linking to a thread, and the "2/3 cycles" would also have a footnote; the person who is confused by this divergence of information could click on each footnote and see where the information comes from, and it would be clear which one is better quality information (e.g. you might find one is several years out of date, or was based on an old emulator, etc.) and easy to update.

It doesn't matter if you personally did hardware tests, what matters is that we can check up on it. If you only know something because you found it buried in Nestopia's source code, and you can't find any other source, explain that in a footnote! If someone comes along to do the better research later, we can update it, and with a proper citation it'll be easy to understand at that point which knowledge is the old and out of date version.


And once again, when you find there is something wrong or inconsistent, like this information about $4017, once you've learned the truth, go back and fix it. Don't just complain about it!!!


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 12:39 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Quote:
And once again, when you find there is something wrong or inconsistent, like this information about $4017, once you've learned the truth, go back and fix it. Don't just complain about it!!!


I'd love to. Sign me up. I'd be happy with doing some work to clean up the APU pages and adding a page on DMA operation.

I just made an account for the wiki a minute ago, and it says I don't have permission to edit the APU Frame Counter page. I assume I need to get added by an admin or something.


The big question I have for the APU pages.... how married are you to guys to the idea of illustrating everything in APU cycles (or 'half' cycles, as frequently they have a ".5" tacked on the end) instead of CPU cycles? I get the logic of why you'd want to use APU cycles, but IMO it makes it super confusing.

EDIT:

The approach I would want to take here is have the main body of the page be an abstracted concept, and get the point across as clearly as possible --- and have the technical hardware stuff (ex: "it actually uses x.5 APU cycles instead of y CPU cycles") in an inlay in the page, preferably with a separate background color. Kind of like in textbooks where they do little cutaways with tangential information.


Last edited by Disch on Tue Dec 27, 2016 12:44 pm, edited 2 times in total.

Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 12:42 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
Disch wrote:
The big question I have for the APU pages.... how married are you to guys to the idea of illustrating everything in APU cycles (or 'half' cycles, as frequently they have a ".5" tacked on the end) instead of CPU cycles? I get the logic of why you'd want to use APU cycles, but IMO it makes it super confusing.

My opinion? NEVER. I don't see a strong reason for counting in APU cycles. Just leave in CPU cycles for my best, please.


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 12:51 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6304
Location: Seattle
I have this hunch that if you don't implement all the 2A03 peripherals on the 900kHz timebase, you'll never be able to accurately emulate the DPCM read glitches.

Now, whether the documentation should say what the hardware does or what makes sense to an emulator author is a different question... but I'm personally inclined to say that phrasing things so that the most obvious implementation only has a single ÷2 clock divider shared between everything would be the better plan.


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 1:01 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Disch wrote:
I just made an account for the wiki a minute ago, and it says I don't have permission to edit the APU Frame Counter page. I assume I need to get added by an admin or something.

Correct -- this model (manual approval) is to keep spammers from destroying the pages. Tepples or Memblers can take care of it.


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 1:17 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
Disch wrote:
I just made an account for the wiki a minute ago, and it says I don't have permission to edit the APU Frame Counter page. I assume I need to get added by an admin or something.

As described in Nesdev wiki:Users, the wiki offers three ways to gain mainspace editing privileges:
  1. Confirm that you can receive mail, which is a good idea anyway in case your password gets messed up
  2. Have an account for four days and make two edits to talk pages while logged in
  3. Be a regular on forums.nesdev.com or in #nesdev on EFnet and let a wiki administrator know that you've created an account, so that the admin can be reasonably certain of your identity and add you to the trusted group in Special:UserRights (which I'm doing right now)

Quote:
The approach I would want to take here is have the main body of the page be an abstracted concept, and get the point across as clearly as possible --- and have the technical hardware stuff (ex: "it actually uses x.5 APU cycles instead of y CPU cycles") in an inlay in the page, preferably with a separate background color. Kind of like in textbooks where they do little cutaways with tangential information.

One approach, similar to what I've seen on allthetropes.org, is to use a Cite.php note:
Code:
About 15 CPU cycles later,<ref>Internally, this is an LFSR that triggers after 7 APU cycles.</ref> the channel...


Top
 Profile  
 
PostPosted: Tue Dec 27, 2016 1:24 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
lidnariq wrote:
I have this hunch that if you don't implement all the 2A03 peripherals on the 900kHz timebase, you'll never be able to accurately emulate the DPCM read glitches.


Well there's two approaches. Either you use 900kHz and allow of half cycle granularity ... or you use 1.8MHz and keep track of even/odd cycles.

They're both exactly the same apart from semantics. I personally prefer the latter, but I can understand the argument made for the former.

Right now the wiki uses both in different places -- which I absolutely object to. We need to pick one and use it everywhere. My question is, which?

If it's up to me, I'm going 1.8MHz. But I don't really care... and if someone else has a strong preference for 900kHz then I'll go with that instead.

Quote:
Now, whether the documentation should say what the hardware does or what makes sense to an emulator author is a different question...


I don't see why it can't do both.

Abstract concepts provide the "big picture", then you can get into details of how that big picture works. Going straight for the hypertechnical explanation without first providing a general overview of what's going on is going to be confusing for most people -- and is going to intimidate people and shy them away from the wiki.

It's the visual2A03 problem... that thing is extremely daunting because of how ridiculously low level it is without any concern for providing an introductory layer. Now, that's works just fine for it, because it's a hypertechnical tool that's only going to be used by people with enough knowledge to interface with it. But a wiki? You gotta soften the information up first and make it easier to digest. A wiki should be available to anyone.

Quote:
but I'm personally inclined to say that phrasing things so that the most obvious implementation only has a single ÷2 clock divider shared between everything would be the better plan.


*everything except the Triangle and most steps of the frame sequencer ;P

Hence why I prefer the 1.8MHz clock.



@ tepples:

Wooop. Didn't see that page. Thanks.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 13 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group