10

From GBATEK, writes to a certain I/O port for power management may damage hardware:

4000304h - NDS9 - POWCNT1 - Graphics Power Control Register (R/W)
  0     Enable Flag for both LCDs (0=Disable) (Prohibited, see notes)
  1     2D Graphics Engine A      (0=Disable) (Ports 008h-05Fh, Pal 5000000h)
  2     3D Rendering Engine       (0=Disable) (Ports 320h-3FFh)
  3     3D Geometry Engine        (0=Disable) (Ports 400h-6FFh)
  4-8   Not used
  9     2D Graphics Engine B      (0=Disable) (Ports 1008h-105Fh, Pal 5000400h)
  10-14 Not used
  15    Display Swap (0=Send Display A to Lower Screen, 1=To Upper Screen)
  16-31 Not used
Use SwapBuffers command once after enabling Rendering/Geometry Engine.
Improper use of Bit0 may damage the hardware?

Emphasis mine. The document does not go into detail and provides no concrete information. How could improper use of the enable flag for LCDs cause hardware damage? Under what circumstances would it cause damage, and what types of damage to the hardware would it cause?

As pointed out in a comment, this may be similar to a related issue on the Game Boy:

Stopping LCD operation (Bit 7 from 1 to 0) may be performed during V-Blank ONLY, disabeling the display outside of the V-Blank period may damage the hardware. This appears to be a serious issue, Nintendo is reported to reject any games that do not follow this rule.

I've posted this after writing a meta question about the NDS and receiving the answer that it may finally count as retro.

11
  • 6
    An LCD does not like to be driven by DC, perhaps this bit switches off the AC generation. Feb 9, 2021 at 19:48
  • 3
    I wrote an email to the author of that document. He said that he wrote that because Nintendo states that that bit is "prohibited". He hasn't done any empirical testing but says that one could try to randomly toggle it on and off and see if it causes any damage or just temporary glitches.
    – forest
    Feb 21, 2021 at 23:45
  • 2
    Did some testing. If I toggle the bit fast enough (about 100 times in a second), it causes the system to crash. I think it also might lock up the ARM7 or something? Not sure, but the inputs sometimes fail (sometimes the touch screen, sometimes keys), and IPC to the ARM7 began to time out in the cases where it didn't cause the system to crash (black upper screen, magenta lower screen). No sign of hardware damage though, at least yet. My guess is it does not cause damage.
    – forest
    Feb 28, 2021 at 0:51
  • 3
    Another reply from the author of that document: For trying to destroy something, I would try to disable LCD somewhere midframe outside of hblank/vblank, and keep it frozen on OFF state for a whole minute... maybe that could burn the currently drawn pixel? Though I hope that the LCD manufacturer and Nintendo did add some safeguards against that. This might be interesting to test.
    – forest
    Mar 7, 2021 at 8:16
  • 3
    There's a similar warning for the Game Boy. bgb.bircd.org/pandocs.htm#lcdcontrolregister In the Game Boy Programming Manual, incorrectly disabling the display outside of Vblank causes a dark line to appear on the screen and is listed as a 'PROGRAMMING CAUTION'.
    – knol
    Nov 22, 2021 at 17:33

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.