Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

LCD to Composite video help

Status
Not open for further replies.

NeX

Member
hello everyone, this is my first post on here so i am sorry if any of it is wrong in any way. I have been looking at this forum for a while and it has helped me a lot but now i need to join up to see if anyone can help me out.

what i am trying to do is take a portable unit (gameboy) and take the data that is normally sent to the LCD screen and convert it to a composite signal.

i have details of the LCD pin outs here:
https://www.devrs.com/gb/files/gameboy2.gif
and details about the rest of the unit here:
https://www.devrs.com/gb/files/gameboy1.gif

now i understand that this is not simple, i realise that the data has to be stored and converted before it can be displayed on a TV and i also realise that it has to be multiplied to fit the screen.

but i am very new to all of this, this is already out of my depth but i still want to have a go at making it, i am not asking anyone to spoon feed me the information, but i really have no idea where to start.

i need to work out first is:
how do i translate the data from the LCD, or rather how can i work out what kind of signal is being sent?
how do i gererate a composite signal?
what is needed to store, convert and multiply the signal?

i dont even know what to search for in Google, "generating a composite signal" comes up with a lot of test and AV stuff that is not in the direction i am trying to go and there is almost nothing on translating an LCD signal.

there is equipment that already exists which does exactly this job, but it is rare and expensive and also bulky (it does more than just convert the signal) because it is rare it is impossible to find any information about it so that is a dead end.

but i assume that one thing that might make it a bit easier is that i am only working with a black and white image.

anyway, any pointers would be a great help

thanks everyone
 
That is a lot of work. If you have a free couple of months, you might get something working.

Inside the LH5264 in the Gameboy is an image of the game. That changes all the time, as the game is played. The LH5264 has 65536 bits of data stored, and that allows about 2 bits per pixel of the screen, so 4 levels of grey.

The data lines between the processor and the screen include Data1 and Data0 and those might well correspond to the 2 bits per pixel. The clock line is likely to be what tells the screen controller to go to the next pixel. The horizontal and vertical sync lines are likely to be lines that tell the screen controller to go to the next line or to start again at the top of the screen.

You need to get a digital oscilloscope or logic analyser to monitor those lines and to work out what is happening. If you change what the Gameboy is doing, you can see what affect that has on the signal going to the screen controller. It will be a bit like code breaking, but you have the advantages of knowing what the answer is (what is on screen) and being able to try lots of small variations.

There is no clock line in a composite video signal. The horizontal and vertical sync pulses within a composite video signal have certain fixed timings. I doubt that the Gameboy has the same timing as a composite signal. It is likely that the frame rate on the Gameboy varies, and it might also only send data to parts of the screen that are changing.

I think that a dsPIC would be a start for the hardware you need. You need to check that it can output the data fast enough.

You should be able to find on the web all the details of what a composite video signal is, so that you can create one.
 
thanks very much driver300, you have already helped me understand a whole lot more. i have the time i can dedicate to this project and i really want to know how this all works so i am willing to put the effort in.

so just to clear things up, the LH5264 is the chip i need to be interfacing with, it is the video decoder, and i cant interface with anything further back in the system because i would still need that chip to turn it into a usable signal?

i will get myself a PC based oscilloscope and see what the data is from the outputs, but i was wondering what i am looking for? is it a spike on the screen of the oscilloscope? or a change in pattern?

i have the ability to speed up or slow down the refresh rate of the LCD on the gameboy, i happen to know that the refresh rate is a constant and it will continuously update the screen even if there is no change. i can slow down the refresh rate to a point where i can see it drawing pixel by pixel on the screen starting from the top and going left to right.

I will look into the dsPIC after this post, but i am assuming that it would be a simple processor that can store and convert the data?

all the information i have found on generating a composite signal seem to be about the software you use on a PIC, there is no hardware only way of creating a composite signal (that i can see) so i assume that once i find a chip that can handle the data processing from the gameboy i need to know what language i can program it in and look for examples of generating composite signals in that language.

thanks again for your help, this is already looking a lot more possible now
 
The LH5264 is described as the video RAM.

I guess that the games write to the RAM in any order, probably as the objects or characters move in the game. There is some other process that takes the data from the video RAM and puts it, pixel by pixel, on the screen.

In theory, you could look at the data being sent to the video RAM. It looks like a standard RAM IC, with address lines, data lines, Write/Read and Chip Enable. If you decoded the address, and stored what was on the data lines when the Write/Read and Chip Enable were in the correct state, you would get a picture of what is in the RAM. You could probably work out the relationship between which the RAM and the LCD screen by seeing what address is read before each pixel or group of pixels is sent.

Alternatively, as you can see each pixel in turn arriving (is that by slowing the clock?) then you should be able to see how the processor tells the LCD how to move to the next pixel or line or page. If you can work that out, you can capture the data as it come from the processor to the LCD.

On generating a composite signal, there are only a few voltage levels if all you want it a few grey levels and the sync pulses. You may be able to use a few outputs of dsPIC and a few resistors to give the correct voltages.
 
ok so the most easiest method so far of collecting the data would be to monitor the data 0 and 1 channels as well as the vertical and horizontal sync and clock, and then slow down the clock so that i can watch each pixel come in on the screen.

then i need to work out from the collected data is, what is a black,white,light grey or dark grey pixel, when to go to the next line, when to start from the top again and the refreash rate.

then i feed that info into dsPIC and through some clever programming i store the image, multiply it to fit the screen and then convert it to a composite signal.

then using various resistors i can create the composite signal in a grey scale (or any colour scale presumably?) and output it to the TV

is that right?

if so i think i know how to start going about this now
 
I suspect this is FAR harder than you imagine - probably easier to built your own GameBoy from scratch with video output instead of an LCD.

well this is what i want to know, just how much work is involved and what has to be done. i know i will need to learn a programming language like C++ or similar, but i dont know what is involved in processing the data.

i have considered starting from scratch, there are many ways of outputting the gameboy game in composite video and then it is easy enough to get a small LCD and use that as a screen for a portable, but i want to understand the technology inside the original console.
 
Glass LCD modules (as presumably used in the Gameboy) are fed from AC, and may well be multiplexed as well - you need to decypher all that and copy the data into memory. You then need to read that back out at a totally different speed and use it to generate a composite video signal. Both processes need to run concurrently as well.

It's not a trivial task, and not something I would even consider attempting.

There are always people on here asking for suggestions for a final year project for their degree courses, I would suggest this would be a suitable project for a final year of a degree?.
 
Glass LCD modules (as presumably used in the Gameboy) are fed from AC, and may well be multiplexed as well - you need to decypher all that and copy the data into memory. You then need to read that back out at a totally different speed and use it to generate a composite video signal. Both processes need to run concurrently as well.

It's not a trivial task, and not something I would even consider attempting.

There are always people on here asking for suggestions for a final year project for their degree courses, I would suggest this would be a suitable project for a final year of a degree?.

ok thats fair enough, if the kind of education needed to make this happen is a degree in electronics then i suppose i should give up for now. I dont know enough to be able to work out how to translate data at different speeds for example, i assume i would need a buffer but if it is being filled at a different speed than it is being emptied then i really dont know how that would work.

but thanks very much everyone for your help, at least i understand a little bit more in all of this
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top