23
edits
Changes
→LCD Source Framebuffer Setup: Correct typo in mathematical calculation.
! Name
! Name
! Comments
! Comments
|-
| 0x1EF00000
| 0x10400000
| 4
| Hardware ID
| Bit2: new model
|-
|-
| 0x1EF00004
| 0x1EF00004
| 4
| 4
| VRAM bank control
| VRAM bank control
| Bits 8-11 = bank[i] disabled; other bits are unused
| Bits 8-11 = bank[i] disabled; other bits are unused.
|-
|-
| 0x1EF00034
| 0x1EF00034
| 4
| 4
| GPU Busy
| GPU Busy
| Bit31 = cmd-list busy, bit27 = PSC0 busy, bit26 = PSC1 busy.
| Bit26 = PSC0, bit27 = PSC1, Bit30 = PPF, Bit31 = P3D
|-
|-
| 0x1EF00050
| 0x1EF00050
To make sense of these values, the 3DS must be held in a way, so that the bottom screen is in the left hand, and the top screen is in the right hand, and that way the first pixel will be in the top-left corner, as it should be. If the 3DS is held normally, the first pixel is in the bottom-left corner.
To make sense of these values, the 3DS must be held in a way, so that the bottom screen is in the left hand, and the top screen is in the right hand, and that way the first pixel will be in the top-left corner, as it should be. If the 3DS is held normally, the first pixel is in the bottom-left corner.
All pixel and scanline timing values are 12bits, unless noted. This also applies to those fields where two u16 are combined into one register. Each u16 field is only 12bits in size.
All pixel and scanline timing values are 12bits, unless noted. This also applies to those fields where two u16 are combined into one register. Each u16 field is only 12bits in size. timin
The horizontal timing parameter order is as follows (values may overflow through HTotal register value):
0x10 < 0x14 <= 0x60.LO <= 0x04 <= 0x60.HI <= 0x08 <= 0x0C <= 0x10
0x18 <= 0x60.LO
Timing starts from HCount == 0, then each absolute value in the beforementioned register chain triggers when HCount == register, latching the primitive display controller into a new mode.
There is an inherent latch order, where if two simultenaous events occur, one event wins over another.
Known latched modes (in order):
- HSync (triggers a line to the LCD to move to the next line)
- Back porch (area between HSync and border being displayed, no pixels pushed, min 16 pixel clocks, otherwise the screen gets glitchy)
- Left border start (no image data is being displayed, just a configurable solid color)
- Image start (pixel data is being DMA'd from video memory or main RAM)
- Right border start/Image end (border color is being displayed after the main image)
- Unknown synchronization (supposed to be probably right border end, but this mode seems to be broken or not do anything)
- Front porch (no pixels pushed, 68 clock min, otherwise the screen doesn't sync properly, and really glitches out)
{| class="wikitable" border="1"
{| class="wikitable" border="1"
|-
|-
| 0x04
| 0x04
| ?
| HStart
| Seems to determine the horizontal blanking interval.
| Determines when the image is going to be displayed in the visible region (register 0x60).
|-
|-
| 0x08
| 0x08
| ?
| HBR
| must be >= REG#0x00
| Right border start(?). Does nothing.
While this register seems to have no impact on the image whatsoever, it still has to be set to a valid value.
|
|-
|-
| 0x0C
| 0x0C
| ?
| HPF
| must be >= REG#0x08
| Front porch. The image is blanked during this period, and no pixels are pushed to the LCD.
Unknown why, but a single dot of red is displayed before entering this mode.
|-
|-
| 0x10
| 0x10
| Window X start (LgyFb)
| HSync
| Offsets the viewing window on the display's physical X co-ordinate relative to its front porch end.
| Triggers a HSync pulse.
Based on behavior, this needs to last at least a pixel clock for the LCD to register the sync.
|-
|-
| 0x14
| 0x14
| Window X end (LgyFb)
| HPB
| Window X start + window width - 1 is written here to set the end display scan pixel offset.
| Back porch? Has to be at least one bigger than HSync, otherwise HSync never triggers.
The display is blank, and the LCD displays nothing in this period (doesn't push pixels).
|-
|-
| 0x18
| 0x18
| Window Y start (LgyFb)
| HBL
| Offsets the viewing window on the display's physical Y co-ordinate relative to the first visible scanline.
| Left border trigger treshold. Enables pushing pixels to the display.
If this value is smaller than the back porch, then the back porch period will be zero, and the border will be immediately displayed upon entering the back porch period.
Can be lower than HSync, as the back porch is what takes the controller out of HSync.
Must be <= HDisp start (reg 0x60 low u16), otherwise no pixels will be pushed due to a glitched state.
|-
|-
| 0x1C
| 0x1C
|-
|-
| 0x20
| 0x20
| Low: Window Y end (LgyFb)
| low u16: ???
high u16: ???
| Low: Window Y start + window height - 1 is written here to set the last display scanline relative to the first visible scanline.
| ???
??? extra pixels get inserted in the first displayed scanline and thus the image gets shifted to the right. Seems to make horizontal syncing a bit glitchy. If a HSync occurs, the pixel data is suspended until the first pixel is supposed to be displayed, then the pixel stream will continue where it left off until a delayed HSync gets processed relative to the pixel data.
|-
|-
| 0x24
| 0x24
VClock = PClock / (HTotal + 1) / (VTotal + 1)
VClock = PClock / (HTotal + 1) / (VTotal + 1)
Setting this to 494 lowers framerate to about 50.040660858 Hz ((268111856 / 24) / (250 + 1) / (494 + 1)).
Setting this to 494 lowers framerate to about 50.040660858 Hz ((268111856 / 24) / (450 + 1) / (494 + 1)).
|-
|-
| 0x28
| 0x28
| 0x5C
| 0x5C
| ???
| ???
| low u16: framebuffer width
| low u16: Image width (including some offset?)
high u16: framebuffer height??? (seems to be unused)
high u16: Image height??? (seems to be unused)
|-
|-
| 0x60
| 0x60
| ???
| HDisp
| low u16: timing data(?)
| low u16: Image start (border --> pixel data)
high u16: framebuffer total width (amount of pixels blitted regardless of framebuffer width)
high u16: Image end (pixel data --> border)
|-
|-
| 0x64
| 0x64
|-
|-
| 0x70
| 0x70
| Framebuffer format
| Framebuffer format and other settings
| Bit0-15: framebuffer format, bit16-31: unknown
| See [[#Framebuffer_format|framebuffer format]]
|-
|-
| 0x74
| 0x74
|-
|-
| 2-0
| 2-0
| Color format
| [[#Framebuffer_color_formats|Color format]]
|-
|-
| 5-4
| 5-4
| Framebuffer scanline output mode (interlace config)
| Framebuffer scanline output mode (framebuffer interleave config)
0 - A (output image as normal)
0 - A (output image as normal)
1 - AA (output a single line twice, aka framebuffer A is interlaced with itself)
1 - AA (output a single line twice, so framebuffer A is interleaved with itself)
2 - AB (interlace framebuffer A and framebuffer B)
2 - AB (interleave framebuffer A and framebuffer B)
3 - BA (same as above, but the line from framebuffer B is outputted first)
3 - BA (same as above, but the line from framebuffer B is outputted first)
|-
|-
| 9-8
| 9-8
| Value 1 = unknown: get rid of rainbow strip on top of screen, 3 = unknown: black screen.
| DMA size
0 - 4 words (32 bytes)
1 - 8 words (64 bytes)
2 - 16 words (128 bytes)
3 - ???
FCRAM doesn't support DMA size 3, as it can only burst up to 16 words (128 bytes), and will show a black screen instead.
|-
|-
| 15-10
| 31-16
| Unused?
| Unknown
|}
|}