And the more we work on a particular page and we are expert to a subject, the less it is possible to see how the page is appealing to a newcomer. Since we already spent time contributing to the page, some elements becomes obvious to us when they actually aren't. In order to simulate a newcomer who has to read the page and gather information from it without the biases of a subject matter expert, I find artificial intelligence could be a good candidate to clean up some wiki pages.
I made a random attempt to ask Chat GPT what could be improved on one wiki page :
And Chat GPT's answer :Hello,
What follows is a technical documentation intended for firmware developers. Could you point if there is some explainations that are unclear and should be cleared up ? Thanks.
=============================
PPU palettes
The NES has a limited selection of color outputs. A 6-bit value in the palette memory area corresponds to one of 64 outputs. The emphasis bits of the PPUMASK register ($2001) provide an additional color modifier.
For more information on how the colors are generated on an NTSC NES, see: NTSC video. For additional information on how the colors are generated on a PAL NES, see: PAL video.
=============================
Memory Map
The palette for the background runs from VRAM $3F00 to $3F0F; the palette for the sprites runs from $3F10 to $3F1F. Each color takes up one byte.
Address Purpose
$3F00 Universal background color
$3F01-$3F03 Background palette 0
$3F05-$3F07 Background palette 1
$3F09-$3F0B Background palette 2
$3F0D-$3F0F Background palette 3
$3F10 Mirror of universal background color
$3F11-$3F13 Sprite palette 0
$3F15-$3F17 Sprite palette 1
$3F19-$3F1B Sprite palette 2
$3F1D-$3F1F Sprite palette 3
Each palette has three colors. Each 16x16 pixel area of the background can use the backdrop color and the three colors from one of the four background palettes. The choice of palette for each 16x16 pixel area is controlled by bits in the attribute table at the end of each nametable. Each sprite can use the three colors from one of the sprite palettes. The choice of palette is in attribute 2 of each sprite (see PPU OAM).
Addresses $3F04/$3F08/$3F0C can contain unique data, though these values are not used by the PPU when normally rendering (since the pattern values that would otherwise select those cells select the backdrop color instead). They can still be shown using the background palette hack, explained below.
Addresses $3F10/$3F14/$3F18/$3F1C are mirrors of $3F00/$3F04/$3F08/$3F0C. Note that this goes for writing as well as reading. A symptom of not having implemented this correctly in an emulator is the sky being black in Super Mario Bros., which writes the backdrop color through $3F10.
Thus, indices into the palette are formed as follows:
43210
|||||
|||++- Pixel value from tile data
|++--- Palette number from attribute table or OAM
+----- Background/Sprite select
As in some second-generation game consoles, values in the NES palette are based on hue and brightness:
76543210
||||||||
||||++++- Hue (phase, determines NTSC/PAL chroma)
||++----- Value (voltage, determines NTSC/PAL luma)
++------- Unimplemented, reads back as 0
Hue $0 is light gray, $1-$C are blue to red to green to cyan, $D is dark gray, and $E-$F are mirrors of $1D (black).
It works this way because of the way colors are represented in a composite NTSC or PAL signal, with the phase of a color subcarrier controlling the hue. For details regarding signal generation and color decoding, see NTSC video.
The canonical code for "black" is $0F or $1D.
The 2C03 RGB PPU used in the PlayChoice-10 and 2C05-99 in the Famicom Titler renders hue $D as black, not dark gray. The 2C04 PPUs used in many Vs. System arcade games have completely different palettes as a copy protection measure.
I am fully aware it comes with its challenges and limitations, but it sounds like using AI to improve wiki pages' clarity might work.The technical documentation appears to be clear and concise. However, I'll point out a few aspects that could potentially be clarified or expanded:
Palette Memory Range:
It might be helpful to explicitly state that the palette memory range is from $3F00 to $3F1F, as this information is scattered in the document.
Attribute Table Control:
Clarify how the bits in the attribute table control the choice of palette for each 16x16 pixel area. Provide a brief explanation or refer to the specific bits in the attribute table.
Background Palette Hack:
The term "background palette hack" is mentioned without explanation. It might be beneficial to provide a brief description or reference to where readers can find more information about it.
Color Representation:
The section regarding hue and brightness values is clear, but it might be helpful to explain how these values translate into actual colors (e.g., what specific colors correspond to certain hue and brightness values).
Canonical Code for "Black":
The document mentions that the canonical code for "black" is $0F or $1D. Providing a brief explanation of why there are two codes for black could be useful.
2C03 RGB PPU and 2C05-99:
It might be beneficial to explain the significance of the 2C03 RGB PPU used in the PlayChoice-10 and the 2C05-99 in the Famicom Titler. A brief note on how they differ from standard NES palettes could be helpful.
Copy Protection Measure:
Regarding the 2C04 PPUs in Vs. System arcade games having different palettes as a copy protection measure, it might be useful to briefly explain how this copy protection works or its implications for emulation.
Consistent Terminology:
Ensure consistent terminology, such as using "background" consistently (sometimes referred to as "universal background") to avoid potential confusion.
Remember that the clarity of documentation can depend on the audience's familiarity with the subject matter, so consider the level of detail that your intended audience may need.
