Talk:PPU palettes
It says that the background palette hack can be used to display the unused palette data. Can the EXT pins also do this? --Zzo38 (talk) 22:30, 1 July 2013 (MDT)
- Yes, I think so. While rendering background pixels, the palette index that gets looked up is simply 0<exp_in3><exp_in2><exp_in1><exp_in0>. -Ulfalizer (talk) 03:58, 2 July 2013 (MDT)
- Interestingly, it looks like the background palette hack wouldn't work for output to the EXT pins though (bit 6 of $2000 set). The logic that causes the VRAM address to be used for the palette index while the background palette hack is active comes after the logic that outputs the index to the EXT pins. -Ulfalizer (talk) 04:15, 2 July 2013 (MDT)
Source of palette
Where did the palette added by Lidnariq in this edit come from? --Tepples (talk) 18:56, 25 December 2013 (MST)
- Screenshot from Nestopia running blargg's full_colors and nes_ntsc. Feel free to bikeshed. —Lidnariq (talk) 20:00, 25 December 2013 (MST)
Parsing the palette
The palette values from this table are read from left to right, then up -> down. Is this ok?
00 01 02 03 ... 0F
10 11 12 13 ... 1F
20 ...
(unsigned comment by Zepper)
- Almost. They appear to go from $00 to $0D, then the next line from $10 to $1D, etc. --Tepples (talk) 06:42, 28 December 2013 (MST)
Browser compatibility of Drag's palette generator
It appears that Firefox 29 implements built-in validation for <input type="number"> such that said elements are expected by default to contain integers. This affects the default hue and saturation settings, causing the boxes to be given glowing red borders and explanatory tooltips, and preventing the values from being changed to other reasonable non-integers. The default settings still work (in that they produce the same palette as in older versions of Firefox) as long as they are not changed.
Relevant documentation can be found on various Mozilla websites (not bothering to link any of it here due to lack of login). --150.135.211.242 22:30, 18 May 2014 (MDT)
