3dbrew

Changes

GPU/External Registers (edit)

Revision as of 22:26, 11 February 2022

832 bytes removed ,  22:26, 11 February 2022
Get rid of misleading and wrong information, and add more researched PDC info (unfinished)
Line 145: Line 145:  
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:
 +
0x10 --> 0x14 --> 0x18 --> 0x60 low --> 0x04 --> 0x60 high --> 0x08 --> 0x0C.
 +
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 no particular order):
 +
- HSync (triggers a line to the LCD to move to the next line)
 +
- Back porch (area between HSync and border being displayed)
 +
- 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)
 +
- Front porch (unknown where it happens)
 +
- Unknown synchronization/blanking (unknown where it happens)
    
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
Line 159: Line 173:  
|-
 
|-
 
| 0x04
 
| 0x04
−
| ?
+
| HParam5
−
| Seems to determine the horizontal blanking interval.
+
|  
−
 
  −
 
  −
Setting this to lower than <code>HTotal - HDisp</code> will make the screen not catch up with the scanlines, some will be skipped, some will be misaligned.
  −
 
  −
Setting this to higher than <code>HTotal - HDisp</code> will make the displayed image misaligned to the right.
  −
 
  −
Setting this to higher than <code>HTotal</code> seems to make the horizontal synchronization never happen.
   
|-
 
|-
 
| 0x08
 
| 0x08
−
| ?
+
| HParam7
−
| must be >= REG#0x00
+
|  
 
|-
 
|-
 
| 0x0C
 
| 0x0C
−
| ?
+
| HParam8
−
| must be >= REG#0x08
+
|  
 
|-
 
|-
 
| 0x10
 
| 0x10
−
| Window X start (LgyFb)
+
| HParam1
−
| Offsets the viewing window on the display's physical X co-ordinate relative to its front porch end.
+
|  
−
 
  −
Outside of LgyFb changing this value only seems to cause weird pixel interpolation and blurryness.
   
|-
 
|-
 
| 0x14
 
| 0x14
−
| Window X end (LgyFb)
+
| HParam2
−
| Window X start + window width - 1 is written here to set the end display scan pixel offset.
+
|  
−
 
  −
Outside of LgyFb it seems to offset the screen to the left if this value is high enough, but can glitch out the syncing on the bottom screen. High enough values will make the screen skip too many "pixels". If this value is higher or equal to *some value* (aka. if less than one pixel per line is displayed on the screen) then the screen will lose synchronization.
   
|-
 
|-
 
| 0x18
 
| 0x18
−
| Window Y start (LgyFb)
+
| HParam3
−
| Offsets the viewing window on the display's physical Y co-ordinate relative to the first visible scanline.
+
|  
 
|-
 
|-
 
| 0x1C
 
| 0x1C
Line 205: Line 208:  
|-
 
|-
 
| 0x20
 
| 0x20
−
| Low: Window Y end (LgyFb)
+
| low u16: ???
−
High: ???
+
high u16: ???
−
| Low: Window Y start + window height - 1 is written here to set the last display scanline relative to the first visible scanline.
+
| ???
−
 
  −
High: This is cleared to zero when displaying LgyFb. Outside of LgyFb this doesn't really seem to do anything useful.
  −
 
  −
 
  −
??? 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
Line 275: Line 273:  
| 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
 
| ???
 
| ???
−
| low u16: timing data(?)
+
| low u16: HParam4
−
high u16: framebuffer total width (amount of pixels blitted regardless of framebuffer width)
+
high u16: HParam6
 
|-
 
|-
 
| 0x64
 
| 0x64
Line 297: Line 295:  
|-
 
|-
 
| 0x70
 
| 0x70
−
| Framebuffer format
+
| Framebuffer format and other settings
−
| Bit0-15: framebuffer format, bit16-31: unknown
+
| Bit 0-2: framebuffer format
 +
Bit 3: null (unwritable)
 +
Bit 4-7: unknown
 +
Bit 8-9: DMA size
 +
Bit 10-15: null (unwritable)
 +
Bit 16-31: unknown
 +
 
 +
DMA sizes (in bytes):
 +
0 - 64
 +
1 - 128
 +
2 - 256
 +
3 - ???
 
|-
 
|-
 
| 0x74
 
| 0x74
MarcusD
Trusted
225

edits

Retrieved from "https://www.3dbrew.org/wiki/Special:MobileDiff/21814"