VA0/VA1 LCD Interface (Game Gear)

i enjoy reverse engineering as much as the next guy, and i love sharing my knowledge more during the creation of the game gear cleanscreen to bring modern screens to the game gear, i learned a lot, and despite the dangers of businesses sharing their knowledge, it is for the better of the community and scene to give back below are my personal findings and understandings of the game gear lcd interface of va0/1 boards, when t10 is pulled to 5v enabling full ntsc video output for sms games not just game gear the game gear interface is described below this allows reading in of the pixel data to a frame buffer the game gear produces signals with ntsc timing 525 lines at 30 fps the video resolution for game gear games is 160x144 or when using master system games or rare gg games, they output 256x192 as we want to output at a different resolution and frequency (vga 640x480 60hz or tft 320x240 parallel rgb) we need a frame buffer to store the full frame between changing frames our maximal resolution is 256x192 = 49152 pixels game gear produces 4bit x 3 colors = 12bit color (r4g4b4) pixel clock the pixel clock is a continuous pulse all the time, running at 32 215mhz this runs the console and the lcd interface timing, so we call the system clock the pixel clock all measurements and changes in values are checked on each rising edge of this clock hsync / vsync a new frame starts on the rising edge of vsync once this signal rises up, we want to start counting pixel clock pulses note on these captures in hsync/vsync section the pclk is inverted as it goes through a buffer for stable capture so where it is low, it will be high in relation to the other signals here is a complete capture of all the pins over many frames (many vsync rises) zoomed in to a single frame per vsync there are 262 hsync lines this is basically the 15 7khz frequency of the cga (and ntsc) monitors the active lines (there are 144 vertically) are the first 144 hsync pulses from the start of vsync rising quite clearly seen here by where the d2 and d3 start pulsing one note is the first hsync line actually starts before the vsync high pulse, but before actual pixel data starts bare this in mind when doing your line counting logic now we know where y0 (first line) begins, we need to look into each hsync pulse to find the start of pixel data counting pixel clock pulses, after 533 (the 534th is the first pixel) pulses from hsync rising, is the start of the first sub pixel data this then continues for 960 clock pulses as the sub pixel data is split into 6 pixel clocks per rgb pixel to see how to extract the rgb pixel from each of these sub pixels scroll down to the sub pixel data section in short, at the start point of 533 clock rises in after hsync rise, the next clock rise will have the red 4 bit value present on d0/1/2/3 then the next clock cycle is nothing, then green, then nothing, then blue, then nothing and following on with the next rgb cycle this happens for 160 pixels of 6 (r g b ) for a total of 960 clock pulses, forming all the pixels of the line note these timings for start position and data length change for sms games see video mode for details csync (unstable) the csync pulse is used to register the next set of rgb data about to be clocked out, as well as register the newline (vsync) note from selling thousands of the cleanscreen with csync instead of hsync/vsync i discovered not always, but in enough cases, the asics do not lock the csync to the pixel clock so it can be very hard to align pixel data to the csync as such i recommend hsync/vsync method csync is high for the majority then pulses low for a specific period (varies based on hsync or vsync), then goes high while pixel data is being read csync pulses low for 156 pixel clocks for each new line, and then has a short glitch pulse of 11/12 cycles, followed by 3 pulses that are longer (1884 cycles) signalling the start of a new image frame, finally one more glitch pulse of 11/12 cycles, and then after that the line pulses start again for the new frame the hsync pulses low are exactly 156 pixel clocks so csync is low for 156 clock pulses then it goes high and starts the sub pixel clock counting to read in the rgb data no data is ever sampled on the low pulse time of csync all data pins are low during this time here is the pixel clock count on a hsync pulse low and here is the full frame of csync pulses over a full screen of data, before the vsync (next image frame) csync pulses starts to signal the next frame there are 259 csync edges for horizontal data, so 259 lines technically it is ntsc 525 format (525 interlaced lines, so every other full frame is the other half of the 525 frames) that means each full frame is actually 525/2 so 263 lines in this case, and we can get 262/263 lines by including the last 2 longer pulses (signalling the next frame) as the start and end lines for many cycles are ignored anyway, this is irrelevant, so long as we time it correctly from the same starting point you see d2 pulsing before all other data lines is the blank lines that you just ignore that is 69 to the left edge, and 200 (from the start) to the right edge, however as we know the output is 144 lines, this only gives 131 lines, we are 13 short so we presume that 6 before and 7 after the other data pins start sending data are actual vertical lines that gives us a y line start of 63 and a y end line of 207, so 144 valid lines out of the total 263 lines that are clocked out for each frame the complete frame of an image generally looks like this, which as you can see is 60hz refresh rate sub pixel and data pins now we have the frame timings, we need to extract the horizontal line pixels once a hsync csync pulse occurs on the rising edge after its low pulse, we start to count the pixel clock cycles after that rising edge we count from 0, 1, 2, 3, 4 then 5 pulses at the first high pulse after csync went high, we clock out the d0, d1, d2 and d3 pins as the 4 bit information about the red color then we ignore a clock and on the 3rd clock we do the same but for green data finally we ignore one more and then on the 5th clock we extract the blue data after that the next clock is classed as zero and is ignored, and then the cycle starts over again the d0 to d3 are the bits from 0 being least significant to 3 being the most in this example below the first red has data of 1110, being (d3d2d1d0), which in binary is decimal 14, or hexadecimal e the possible range of the 4 bits is 16 possible levels of red from 0 to 15 the green is 0100 so decimal 4 finally the blue is 0000 so decimal 0 if we presume the colors are on a scale of 0 to 255 we can multiply the values by 16 to get a value we can represent this would make the final color red 244, green 64 and blue 0 the pixel clocks total from the rise of csync to the fall ready for the next line to around 1887 cycles given each rgb pixel set is 6 clocks (0 to 5), 1887 divide by 6 is approximately 314 pixels per line as we ignore the end and start windows it is ok that the final end clocks vary slightly as it is non information video mode (!gg / sms) the sms pin is pulled to 5v by default when a game gear game is inserted, it is sunk low to ground when a master system game is used through a converter (or some game gear games that output master system video) this pin is left floating and the video signals are then a different format (larger video resolution) game gear games output a resolution of 160 x 144 by default starting at y0 (hsync pulses) and x533 (pclk pulses), but when a master system game is inserted it changes the resolution to 256x192 start at y? (hsync pulses) and x? (pclk pulses) this new larger information is sent in the exact same format except now the x and y start and end values change