Changes

Jump to navigation Jump to search
2,165 bytes added ,  00:12, 19 April 2018
Documented some timing and display registers
Line 148: Line 148:  
| Higher values are slower, 12bits.
 
| Higher values are slower, 12bits.
   −
Setting this value too low will make the screen not be able to sync any pixels other than a single one from the wrong location. The lowest the screen can handle is 0x1C1, with rare glitching.
+
Setting this value too low will make the screen not be able to sync any pixels other than a single one from the wrong location. The lowest the screen can handle is 0x1C2, at 0x1C1 the display loses a few scanlines worth of pixel clock (though not noticable).
 
|-
 
|-
 
| 0x04
 
| 0x04
Line 170: Line 170:  
|-
 
|-
 
| 0x10
 
| 0x10
| ???
+
| Vertical pixel interpolation(?)
| Some sort of delay in signal, probably in the pixel clock
+
| Some sort of delay in signal. Has dither-like effect.
 
|-
 
|-
 
| 0x14
 
| 0x14
| HBlank length(?)
+
| Horizontal data offset(?)
| ??? Seems to offset the screen to the left if this value is high enough, but can glitch out the syncing on the bottom screen
+
| ??? 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
 
| ???
 
| ???
| should be < REG#0x10
+
| ???
 
|-
 
|-
 
| 0x20
 
| 0x20
| HFrontPorch(?)
+
| Low: Horizontal pixel data offset(?)
| ??? the screen gets vertically offset with wrap-around
+
High: ???
horizontal timing gets messed up
+
| ??? 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
| HSync timer?
+
| Low: ???
|  
+
High: ???
 +
| The low 12bit halfword seems to affect:
 +
 
 +
- the total amount of scanlines displayed
 +
 
 +
- vertical pixel data offset if the GPU can't VSync properly
 +
 
 +
- VSync length
 
|-
 
|-
 
| 0x28
 
| 0x28
| VDispStart(?) or VFrontPorch
+
| VBlank timer(?)
|
+
| Seems to determine the vertical blanking interval.
 +
 
 +
 
 +
Setting this to lower than <code>VTotal - VDisp</code> will cut off the top <code>VTotal - VDisp - thisvalue</code> lines.
 +
 
 +
Setting this to higher than <code>VTotal - VDisp</code> will make the image be pushed downwards with the overscan color visible.
 +
 
 +
Setting this to higher than <code>HTotal</code> will make the GPU skip vertical pixel data synchronization (hence filling the screen with the rest of the pixel data past the given screen framebuffer size). Also will skip <code>thisvalue + somevalue - HTotal</code> lines into the "global" pixel buffer.
 
|-
 
|-
 
| 0x30
 
| 0x30
 
| VTotal
 
| VTotal
| Total amount of vertical scanlines
+
| Total amount of vertical scanlines in the pixel buffer, must be bigger than *an unknown blanking-like value*. If this value is less than VDisp then the last two scanlines will be repeated interlaced until VDisp is reached.
 
|-
 
|-
 
| 0x34
 
| 0x34
 
| VDisp(?)
 
| VDisp(?)
| Total amonut of vertical scanlines displayed (only for top screen it seems like)
+
| Total amonut of vertical scanlines displayed (only for top screen it seems like). If this value is less than VTotal then the rest of the scanlines will not be updated on the screen, so those will slowly fade out. Must be bigger than *an unknown blanking-like value*, otherwise an underflow will happen.
 +
|-
 +
| 0x38
 +
| Vertical data offset(?)
 +
| ??? Seems to offset the screen upwards if this value is high enough. If this value is higher or equal to *some value* (aka. if less than one scanline is displayed on the screen) then the screen will lose synchronization.
 
|-
 
|-
 
| 0x44
 
| 0x44
 
| ???
 
| ???
 
| similar functionality to 0x10
 
| similar functionality to 0x10
 +
|-
 +
| 0x48
 +
| ???
 +
| bit0 seems to disable HSync, bit8 seems to disable VSync, rest of the bits aren't writable.
 
|-
 
|-
 
| 0x4C
 
| 0x4C
Trusted
225

edits

Navigation menu