MetalSlime wrote:
I think it would be useful to have 3 (or more) main sections:
1.For developers
2.For emulator writers
3.For hardware people
??4.For ROM-hackers??
Each section would have its own set of articles for the various topics (for example, there would be 3 articles about the PPU registers, one for each group). The articles in each section would be targetted at that specific group, and there would be links to the other sections' corresponding articles (if they exist) at the bottom for reference. Naturally there would be a lot of overlap, but I don't think that's a bad thing.
For a small example, the UxROM mapper page. Developers would probably want some basic information about how it works and some example code to get it running, but probably don't care about the information in "Solder Pad Config" or "Hardware" or "Variants". Hardware people probably want more detailed information about how it works and don't care about example code. So they'd each get their own UxROM page (with links to each other at the bottom)
For a bigger example, try imagining what would happen if we added code examples to the current NES_PPU page. That thing would be a monster (the bad kind).
The reason I am requesting this is because I often find (as a developer) that the current nesdevwiki articles are a little too technical. There have been many times where I wanted to edit them and add in more developer-friendly explanations with examples, but I didn't because there didn't seem to be a good place to stick them without overinflating the articles or messing up the flow.
1.For developers
2.For emulator writers
3.For hardware people
??4.For ROM-hackers??
Each section would have its own set of articles for the various topics (for example, there would be 3 articles about the PPU registers, one for each group). The articles in each section would be targetted at that specific group, and there would be links to the other sections' corresponding articles (if they exist) at the bottom for reference. Naturally there would be a lot of overlap, but I don't think that's a bad thing.
For a small example, the UxROM mapper page. Developers would probably want some basic information about how it works and some example code to get it running, but probably don't care about the information in "Solder Pad Config" or "Hardware" or "Variants". Hardware people probably want more detailed information about how it works and don't care about example code. So they'd each get their own UxROM page (with links to each other at the bottom)
For a bigger example, try imagining what would happen if we added code examples to the current NES_PPU page. That thing would be a monster (the bad kind).
The reason I am requesting this is because I often find (as a developer) that the current nesdevwiki articles are a little too technical. There have been many times where I wanted to edit them and add in more developer-friendly explanations with examples, but I didn't because there didn't seem to be a good place to stick them without overinflating the articles or messing up the flow.
Yes, we should identify distinct audiences and ensure that each can find the information it is interested in, and little more. How that is achieved is an open question; separate sections might not be the best way.
Everyone: overall structure of the NES and how everything fits together.
Developers: basic operation of a component, the normal way to use it, and techniques for getting the most out of it.
Emulator authors: more detailed operation, without programming techniques cluttering things.
Hardware developers: pinouts, timing, cartridge board layouts, etc.
ROM hackers as an audience is an interesting idea. It is a different perspective on things, influenced more by NES software than hardware.
The overview gives a framework for all the other descriptions, so they don't have to repeat how things fit together. And the developer documentation will likewise allow the emulator-oriented documentation to avoid having to mention how the registers generally work; it can get on with describing each register in full detail.
This division also modularizes decisions about how to present the information. Those working on developer documentation can focus on how to make it most useful to developers, without worrying about emulator authors or presenting every last detail.
In coming up with ideas, the PPU seems the best component to focus on, since it is so central to everything and has so many aspects. There are registers, like most other components, but then there's rendering behavior and timing and a ton of programming techniques.