Don't Repeat Yourself failure
Ok, it's crazy to have two completely different pages explaining the MMC5 mapper, one on iNES mapper 5 and the other on MMC5. I think the info should be present on a single page (like it is for all other mappers).
Well in fact it seems it's Zeromus who added Dish's notes on all iNES mapper pages. This would be nice if the info wasn't already present on the wiki - having twice the same info isn't very logical is it ? I don't know what to do but something should probably be changed...Bregalad 00:36, 23 March 2012 (PDT)
- Disch' format is much better for reading. Funny, I was really thinking to discuss about such thing. :) --Zepper 14:44, 23 March 2012 (PDT)
- Problem solved. @Zepper : If there is a particular point that should be improved about how the mappers are presented on the wiki, then please change it (or at least say more precisely what is much better).Bregalad (talk) 06:02, 20 April 2015 (MDT)
- Rather than just deleting them, I've been trying to review the disch notes and compare them to the existing article, integrating anything that it was adding before removing it. It's more time consuming than just deleting them, but the whole point of zeromus pasting them here was that they might improve the articles. Sometimes they add nothing, for sure, but it's worth reviewing before deleting, I think. In the process you might find other things here and there to improve in the mapper articles too. This review process is healthy for the wiki content. We don't need to be in a hurry to scour the disch notes from the wiki. - Rainwarrior (talk) 20:38, 20 April 2015 (MDT)
- They have been here for more than three years, so how much time should have been waited for their removal in your opinion? 10 years? As I said they are still available, so you can just download them, and do the review work using your local copy of Dish notes. No point to have them pasted here, period. I absolutely agree that such a review work is benefical, and if there is a particular part you'd want me to review, just ask.Bregalad (talk) 03:13, 21 April 2015 (MDT)
- I did not just remove it but link to the original place. That's a different thing. Please explain me why Rainwarrior cannot download dish's document on his hard drive and work with that copy. (answer : he can, and that makes a lot more sense). Anyways I'm sick of editing this wiki for a while. Bregalad (talk) 06:04, 21 April 2015 (MDT)
- There are several reasons why I would not do it that way:
- - If I download the document and begin integrating it into the Wiki, it can no longer be a collaborative process. If I do that, I have to do every single one myself (nobody can help, sensibly, without being redundant), and there is really no good way to know which have been done already.
- - Several of the Disch notes sections have had edits in the time since being pasted here, and all of these deserve an overview before being removed.
- - I believe zeromus' addition of the Disch notes to the Wiki was overall a good thing, filling in content where it was missing at the temporary expense of redundancy.
- - Simply reverting someone's changes without reviewing them treats them in bad faith.
- "if there is a particular part you'd want me to review, just ask." Please review every deletion you make. That's what I am asking, and that was the project I had begun, myself. If you don't want to do this, please just leave it there. I will get to it eventually! I had started working on this carefully (but slowly). It will probably take me a few months if I do it alone, but I really don't appreciate someone coming in with sweeping deletions and making it difficult for me to try and attempt to finally make good on zeromus' good-faith effort to have the wiki improved by Disch's notes. - Rainwarrior (talk) 10:48, 21 April 2015 (MDT)
Oh because those HAVE HAD EDITS ?! :O
Now everything makes even less sense. I give up! This wiki is a huge mess anyway and will always be. Collaborative work just doesn't work. My only regrets is to have worked so hard for the hardware page and the FDS page, when they are doomed to be in the little of this huge disorganized mess with no head and no tail. Any change I make is systematically criticized, even if I asked in the forums if it was ok to do it, and nobody reacts which I belive is "I'm ok with that", but after the change everytime screams like "Begalad you're doing it all wrong, revert those changes!" It's the fourth time there is an issue like that where changes I made in a lame attempt to make this wiki a slightly better place are refuted only AFTER I made them.
By the way a great thing would be to report those edits to RHDN, so that at least a clean and up to date version of Dish' doccument lies somewhere (and that is on RHDN, not here).18.104.22.168 12:47, 21 April 2015 (MDT)
- If consensus for large scale editing has been established in a topic on the forum, it would be a good idea to include the URL of this topic in the edit summary of each edit so that we know what you're doing. --Tepples (talk) 12:56, 21 April 2015 (MDT)
- I can't complain about your changes before you make them, unless you tell us what your intentions are first. If you want to make large scale changes unannounced, yes, people will complain after the fact. When else would they complain? I think we want the same thing in the end (no more redundant Disch notes), but I am unhappy with the way you are doing it. I began several days ago a long term effort to do it carefully to make sure we aren't losing information as the Disch notes are removed, but suddenly you have come in to just bulldoze it to the ground, and this does bother me. This isn't collaboration, this is in effect just you having an edit war with zeromus with a 2 year delay. I don't know what argument you had about the FDS article, or what, but it's not at all relevant to the current discussion. - Rainwarrior (talk) 13:13, 21 April 2015 (MDT)
- Yeah, it really suck because we're making efforts and we get in the way of eachother. That's just how this wiki works and is doomed to work. As for the thread it's here, but it was in an abandoned state after one day. If I say "should we do that" and nobody react I assume nobody cares if I to do it. Well wrong assumption I guess. I was absolutely sure the Dish docs were untouched that is why I acted this way. However the edits from the are not lost because they're in the history logs. I'll track for them, and update new Dish docs to RHDN to apologize for this behaviour (so I don't have to deal with the wiki anymore but still repair what I have broken). I hope this is okay for everyone. It will take a few days, though.Bregalad (talk) 13:28, 21 April 2015 (MDT)
- I reacted, and I started working on the problem. I didn't want to just revert your deletions because it would basically be an edit war if we don't talk about it first. Undoing a single revision I can explain in the comment summary, but doing many is kind of hostile. I know you spent a good amount of time (in good faith) making the edits, though zeromus also spent a good amount of time putting that stuff up in the first place. Both of you wanted to improve the wiki, and I'm trying to mediate this by keeping anything of value that was there. You don't need to revert anything yourself, at this point; I have been reviewing the changes, and keeping a list of deletions at User:Rainwarrior, and I'll eventually get through them one by one as part of the ongoing project I started. I want to keep all the document links you added, for eaxmple, because those are good. As for updating RHDN, you can do that if you like, but I'm only concerned about the wiki. - Rainwarrior (talk) 13:42, 21 April 2015 (MDT)
What is the logic in the ASIC that causes it to write zero if the PPU is not rendering? --Zzo38 01:51, 22 September 2012 (MDT)
Another question about the ExRAM is, what happens when you try to read/write ExRAM nametables through the PPU registers, and if extended attribute mode is selected, what happens when reading/writing attribute tables using the PPU registers (when it isn't rendering the picture, and in any potentially random order)? --Zzo38 (talk) 22:23, 24 February 2014 (MST)
Even more extended PRG RAM
Parsimony of silicon strongly implies that the higher address lines (corresponding to the 0x78 bits of the register) are still driven for the registers from $5114 to $5116 even when RAM is selected, meaning >64KiB PRG-RAM would be usable when mapped to $8000-$DFFF. It's conceivable that these same bits of the register at $5113 (controlling PRG-RAM bank) are implemented, since they have to feed a multiplexer anyway. Something to test, maybe. —Lidnariq (talk) 23:34, 20 January 2014 (MST)
The PRG bankswitching section was much better before the recent edits by Ben Bolt. In particular, I do not see why non-existing registers $5112 etc... are even mentioned at all. The current page is a huge mess and I don't see any new info that wasn't there before, except that it's now much less readable and non understandable.Bregalad (talk) 00:40, 26 November 2018 (MST)
Also, this is not related to recent edits, but the info in this wiki clearly contradict Dish notes.
Mode 1 - Select a 16KB PRG ROM bank at $C000-$FFFF (pass through CPU A13 to PRG A13 instead of using bit 0) Mode 0 - Select a 32KB PRG ROM bank at $8000-$FFFF (pass through CPU A13 and A14 to PRG A13 and A14 instead of using bits 0 and 1)
Before the recent edits it said:
Mode 0 - Select a 32KB PRG ROM bank at $8000-$FFFF (ignore bottom 2 bits) Mode 1 - Select a 16KB PRG ROM bank at $C000-$FFFF (ignore bottom bit)
which is equivalent, but simpler to understand in a sowftware viewpoint.
Dish however says:
Note that unlike most other mappers, these CHR pages are in *actual* sizes. IE: when in 4k mode, registers contain 4k page numbers. But when in 2k mode, register contain 2k page numbers.
Which is the oposite ! This was already contradictory before the recent edits but I didn't notice. So who's right, who's wrong ? At least Castlevania III uses 16k banks with MMC5 so this should be easy to figure out. Bregalad (talk) 08:50, 26 November 2018 (MST)
- You'll note that the former comment is about PRG bankswitching, and Disch's comment is about CHR bankswitching. Both are true. —Lidnariq (talk) 13:29, 26 November 2018 (MST)
- Ah Okaaay... so the MMC5 did the shifting trick for it's CHR pages but not PRG pages where bigger sizes are used like usual by ignoring lower bits... that's very tricky indeed. This should probably be mentionned after the PRG bankswitching part is fixed up.Bregalad (talk) 13:56, 26 November 2018 (MST)