GBA to TV adapter

Started by emuman100, January 30, 2005, 09:03:34 AM

Previous topic - Next topic

emuman100

Hello,

If anyone has the "GBA Transverter", I want to build myself one of them. The format the GBA output's to it's LCD is 15 bit RGB. The other signals include Hsync, Vsync, Hpage, and a power saving signal. most GBA to Tv adapters contain a D/A converter of course and a frame buffer. To match the frequency of TV, the frame is stored in the frame buffer, which is then sent to the D/A converter. The D/A converter then outputs RGB and is sent to an RGB encoder. The RGB encoder used is a CXA2075. It's a good quality part, but uses a lot of power, and get's really hot. Reason I wanted to build a GBA to TV adapter is because the ones out now are cheap made in China garbage. They work, but they get hot, and there is noise on the video. GBA games are a shame to waste on an LCD if you can play on a TV or monitor. I'm not interested in the GB Player for the gamecube because I want to make the unit portable. I want to make it small, have RGB, S-video, and composite video output, and a much better scaler than the one on the current unit. The "GBA Transverter" has ICs with reconizable part numbers in normal packages, the other units out there do not. They have "glop-tops".

I'd imagine the frame buffer is just some RAM that stores the whole frame, then the frame is read and sent to the D/A converter at the right frequency. Anyone know where I'd start?

Rockard

No, but I want to wish you good luck on the project! =)
I want to do somehting like this myself, I find the various mods available expensive and crappy. I want rgb-output using a non-scale output with a frequency that fills the screen somewhat.

I haven't researched that much in this, just searched around a bit.

Anyway, looking forward to your progress =).

Aidan

Yup, the frame buffer is nothing but a bit of RAM. However, you probably want at least two frames worth of storage, so you're not trying to display the frame you're trying to capture.

The first step is to capture the display information into a frame buffer. We know that GBA displays 308x228, even though it's resolution is actually 240x160 (3:2 aspect). Horizontal lines are drawn at 13.62KHz, and vertical at 59.737Hz.

The next step is to scale the data so it fits your output format, which is 480 lines of video. As the GBA has a different aspect ratio,  you will have to suffer some blank area of the screen. For a 16:9 screen, you will have vertical areas on the left and right that are blank, for a 4:3 screen, you will have letterboxing.

Once you have scaled the data to the correct aspect, and added the padding for the areas that will not be displayed, you can start pushing that data back out to the encoder at the correct frequencies. However, as a TV displays interlaced signals, the first pass will display the even lines, and the second pass will display the odd lines.

An NTSC 16:9 screen will have ~720 horizontal 'pixels' (technically there is no horizontal resolution, but digital circuits have to have some quanta!), and 525 vertical lines. Of these, you can probably expect around 650 horizontal pixels and 480 vertical lines to be visible. You still have to generate the nonvisible pixels, but be aware they probably won't be visible, so you can set them to black.

You'll have to figure out how you want to do scaling - you can use the simplest method, which simply doubles pixels and lines, or you can go for something much more sophisticated, such as the classic interpolation followed by decimation. The more sophisticated you go, the more processing power you will need to do the conversions.
[ Not an authoritive source of information. ]

Rockard

Aidan: Why not output using a lowresolution noninterlace mode instead?
Seems unnecessary to output at an interlacemode when the gba don't use that high resolution anyway. Then you can skip the scaling/interpolating stuff, that just makes the output ugly and bloated... blergh

Hojo_Norem

#4
QuoteAidan: Why not output using a lowresolution noninterlace mode instead?
Seems unnecessary to output at an interlacemode when the gba don't use that high resolution anyway. Then you can skip the scaling/interpolating stuff, that just makes the output ugly and bloated... blergh
And would introduce interpolation artifacts like I do with my GBPlayer.  If I recall correctly from a lengthy thread on comp.sys.cbm, the C64 outputs progressive (abeit low res progressive) and the info there might be of some use.  

EDIT:
The name of the thread is "DTV Compatibility woes..." and the relevent stuff starts on the second post.  
Formerly 'butter_pat_head'

Aidan

#5
QuoteAidan: Why not output using a lowresolution noninterlace mode instead?
Cuz a TV only supports interlace. ;) Even if you don't want interlace, you still have to output two fields 25/29.97 times a second to keep the TV happy, even if they're the same picture.
[ Not an authoritive source of information. ]

Hojo_Norem

#6
Quote
QuoteAidan: Why not output using a lowresolution noninterlace mode instead?
Cuz a TV only supports interlace. ;) Even if you don't want interlace, you still have to output two fields 25/29.97 times a second to keep the TV happy, even if they're the same picture.
But a lot of games run at the full 50/60Hz framerate of the screen they are displaying on.  Meaning that they could display a different picture on each field, which means quite a lot of modern games which run at full speed will usually exhibit interlace artifacts to some degree, like my GBPlayer when its set to sharp mode.

Now lower res machines normally output progressive and TVs have no problem displaying the image from such machines, and they do so without exhibiting interlace problems.

Quote
>The C64 has to output interlaced video because that is what an NTSC or
>PAL TV expects. What the C64 does is to send the same output to both the
>odd and even scan-lines.

To have true interlacing in NTSC you need to have
1) 262 lines for the first field
2) half a line to make the offset of 0.5 lines for interlace
3) 262 lines for the second field
4) half a line to undo the offset of 0.5 lines
with the correct timing of vertical and horizontal syncs.

C64 does not generate true interlace. It only generates 262-line
fields/frames at 60Hz (NTSC). There are no half-lines that generate
offset between the fields. Thus every field is drawn exactly in
the same place, thus fields=frames.

If the display device does not support non-interlace, you may get
50 Hz interlaced and the output looks horrible.

>The C64 does work on a HDTV. The TV detects the incoming signal as 480i
>mode (NTSC). If the C64 did output a non-interlaced signal (which it
>does not) then the mode would be set to 480p which is progressive.

C64 does not output a HDTV-standard 480 lines progressive, it outputs
240 lines progressive.

Yes I know this relates to the C64, but at the end of the day a video signal is avideo signal, no matter what ageing or not designed for the machine that is outputting it! ^_^
Formerly 'butter_pat_head'

Aidan

Basically, the TV is expecting to see two fields at a rate of 29.97 or 25Hz. Whatever you do, you have to provide those two fields, regardless of progressive/interlaced. There is no issue with simply displaying the 160 lines in each field. However, that only gets you 320 lines, instead of the 480 lines the TV is expecting per frame. Without any kind of stretching, you're only displaying an image that's 66% of the screen. Its even worse on PAL! Assuming that the lack of half line means the TV will display progressive is a dangerous assumption, given all the interesting tricks that display electronics now perform.

In terms of technicalities, converting the output from the GBA into real NTSC with the correct timing requires retiming of the whole signal, as neither the GBA's horizontal or vertical output matches NTSC (or PAL).

[ Not an authoritive source of information. ]

Hojo_Norem

#8
QuoteBasically, the TV is expecting to see two fields at a rate of 29.97 or 25Hz. Whatever you do, you have to provide those two fields, regardless of progressive/interlaced. There is no issue with simply displaying the 160 lines in each field. However, that only gets you 320 lines, instead of the 480 lines the TV is expecting per frame. Without any kind of stretching, you're only displaying an image that's 66% of the screen. Its even worse on PAL! Assuming that the lack of half line means the TV will display progressive is a dangerous assumption, given all the interesting tricks that display electronics now perform.

In terms of technicalities, converting the output from the GBA into real NTSC with the correct timing requires retiming of the whole signal, as neither the GBA's horizontal or vertical output matches NTSC (or PAL).
I can understand where you are coming from.  The GBA simply dosent ouput a resolution which can easily be scaled to a TV's aspect ratio.  im just saying that any standard TV sould do non-interlace (can't realy call it progressive I suppose, or maybe low-res progressive, its basically the same thing, I think ^_^)

Some of the jiggerypokery that goes on inside modern sets these days (that is the plasma, lcd, tv card and 100Hz tube screens, Im pretty sure the standard 50/60Hz tube sets are practically unchanged in basic operation principals) that some indeed do get a little confuzed with the non-interlace signals that classic machines output and re-interlace them, creating interlace artifacts.

As for your third point, thats fair enough.  As I recall the GBA runs at 60Hz while Not The Same Colour twice runs at about 59.something or other.  Same reason you get judder sometimes while using the GBPlayer.

I suppose at the end of the day there isn't any relitively simple way of displaying a GBA image on a TV, besides buying a Gamecube and GBPlayer (which at the end of the day probably would work out cheaper to some degree ^_^) as some amout of scanrate manipultion and pixel scaling will be needed, weather the output will be interlace or non-interlace.
Formerly 'butter_pat_head'

RGB32E

The term Nintendo uses for non-interlaced (a bit of a misnomer) is "double-strike".  As both odd and even fields scan over the same screen position.