GBA HDMI Adapter + RGB output (WIP)

[Woozle]

I thought I would share a side project I've been working on. It's a GBA to HDMI project using a Nexys Video FPGA board. Right now the implementation is not the best (line tripling into a buffer), there are odd artifacts during vertical scrolling (I think due to vsyncs), and a image column is misplaced (seems to be extra clock edge coming from GBA that I need to ignore somehow) but the controls are responsive and it's fun to mess around with. I plan to eventually have the FPGA read a SNES pad and give the button inputs to the GBA, then I can make a PCB for the FPGA and put everything into a neat enclosure.

This project was just made to practice the image scaling for a another project I'm working on with a group, a SCART, Component, S-video line doubler (hopefully other scaling filters too) that I plan on sharing here as well when we get a prototype going.

All of this is for fun and I plan on sharing as much as I can when the code gets better (it's a little sloppy currently). Any suggestions or things to watch out for are welcome.

http://i.imgur.com/q7UOvP6.jpg

http://i.imgur.com/EIsqqiO.jpg

PS if anyone else would like to give it a try... the GBA is 15-bit RGB video and all the pixel data, pixel clock, and timing signals are clearly marked on the PCB silkscreen

[bobrocks95]

I think the biggest question is how you're handling the GBA's odd refresh rate. I doubt many HDTVs like a 59.7275 Hz refresh. This is probably related to the vertical scrolling stuff you're seeing.

[Woozle]

Right now I'm not doing anything specific to address it, since I'm still trying to get the hang of general scaling and video output. The HDMI output operates at typical 640x480p.

Do you have any ideas on how to handle the odd refresh rate? I was under the impression that there is currently not a good solution (hope I'm wrong) and that you basically either get frame tear or stuttering.

I prefer playing on this vs my Gameboy player (both with component and HDMI for the gamecube) overall, but the vertical artifact/tear is frustrating.

[bobrocks95]

If you're using HDMI, as far as I know you're at the mercy of standard VESA timings and can't stray very far from them. Maybe someone like Extrems could offer some hypothetical where you modify the front and back porches to make it look close to a VESA timing, but I have no clue there.

For the Gameboy Player Nintendo made it drop a frame every couple of seconds to keep things aligned, which makes it look stuttery.

For the Gameboy Interface Extrems used frame blending with a 2 or 3 frame framebuffer to hit a constant 60Hz, but it looks blurry in motion. For the low-lag versions Extrems lowered the refresh rate to closer to the GBA's, but afaik people weren't able to get it working over HDMI- considering how new Gamecube HDMI output is this is probably a very small group of people to test anyway.

[lev11]

All 3 versions of GBI work over gcvideo HDMI on my Samsung TV. Maybe some TVs are more sensitive than others.

[bobrocks95]

That's good to hear, I was just speculating.

Now that I think about it though Woozle, if you're getting picture without any sort of framerate conversion that means your TV is accepting the odd refresh rate, doesn't it? Perhaps it's the generation of the signal by the FPGA not being locked directly to the GBA's output just causing a discrepancy. Unless you're just pumping out 60Hz.

[Greenalink]

For the Gameboy Interface Extrems used frame blending with a 2 or 3 frame framebuffer to hit a constant 60Hz, but it looks blurry in motion. For the low-lag versions Extrems lowered the refresh rate to closer to the GBA's, but afaik people weren't able to get it working over HDMI- considering how new Gamecube HDMI output is this is probably a very small group of people to test anyway.

HDMI Gamecube worked fine with GBI, if using Ultra Low Latency (ULL)
https://www.youtube.com/watch?v=Z_JqxL4vbTQ

[mikejmoffitt]

It's possible your project isn't experiencing tearing, and the monitor may be buffering to a fixed rate. I'd try at least one more monitor to be sure.

Cool to see line tripling used, that's perfect for this resolution and won't introduce latency.

[yxkalle]

Just overclock the gba a tiny bit with an on-board fpga pll. Problem solved.

[Woozle]

@bobrocks95 I'm pumping out 60Hz from the fpga. I'm writing to the buffer inside the fpga at the GBAs refresh rate and pulling from it at 60Hz. "Tearing" happens on TV and monitor.

I think I'm going to try line tripling -> half-scale -> output over VGA (first need to make a VGA DAC). That way I could try 240p on my pvm. I'll also try to have the fpga refresh the video output at the same rate of the GBA and see how my various TVs handle it.

@yxkalle Do you know how the GBA derives the pixel clock from the crystal oscillator? I suppose I could take a gba motherboard and see how the pixel clock is affected by different oscillator frequencies.

Any recommendations on how to approach scan lines with line tripling?

[Fudoh]

Any recommendations on how to approach scan lines with line tripling?

2:1 - the Framemaster with 240p input and 720p output does the same.

I'm pumping out 60Hz from the fpga. I'm writing to the buffer inside the fpga at the GBAs refresh rate and pulling from it at 60Hz. "Tearing" happens on TV and monitor.

you definitely have to lock your output refresh rate to the input. The GBA is close enough to NTSC specs to not cause any bigger compatibility problems. If the display can't handle it natively it will convert it to 59.94Hz or 60Hz which will cause a little stutter - but that's still better than the tearing you get right now.

[meneerbeer]

I think some scalers dim one of the lines and display the other two at full brightness.

It might be possible to reclock the GameBoy, so the output image is 60Hz. Perhaps you can get it precise enough so you do not need to buffer the complete image.

[Woozle]

@fudoh thanks, I'll try that out.

@meneerbeer I'll probably just have it subtract a value 0-255 from any pixel in a row that needs to be dimmed. For a gameboy to VGA project I just blacked out the odd lines entirely, looked ok.

[meneerbeer]

How many pixels per line does the GBA have and how many lines? Not sure if there are also blanking regions, but those are also needed if I want to check if you can lock input framerate to output framerate.

[bobrocks95]

Just overclock the gba a tiny bit with an on-board fpga pll. Problem solved.

Wouldn't this distort audio output a little bit as well? Seems like a last-plan solution to me, might even break game logic somewhere.

@bobrocks95 I'm pumping out 60Hz from the fpga. I'm writing to the buffer inside the fpga at the GBAs refresh rate and pulling from it at 60Hz. "Tearing" happens on TV and monitor.

I think I'm going to try line tripling -> half-scale -> output over VGA (first need to make a VGA DAC). That way I could try 240p on my pvm. I'll also try to have the fpga refresh the video output at the same rate of the GBA and see how my various TVs handle it.

Since now two people have posted to say that the ULL version of Extrem's Gameboy Interface was working over HDMI, and that runs at 59.7276 Hz, odds are 59.7275 Hz will work as well, if you can divide the FPGA clock to exactly that.

you definitely have to lock your output refresh rate to the input. The GBA is close enough to NTSC specs to not cause any bigger compatibility problems. If the display can't handle it natively it will convert it to 59.94Hz or 60Hz which will cause a little stutter - but that's still better than the tearing you get right now.

I didn't know modern displays would do a framerate conversion like that- I'm guessing that's just if the input refresh rate is very close to NTSC but slightly off?

[Fudoh]

I didn't know modern displays would do a framerate conversion like that- I'm guessing that's just if the input refresh rate is very close to NTSC but slightly off?

It's a common problem. The GBA refreshes at 59.7x Hz. That's CONSIDERABLY closer to NTSC specs than a Neo Geo MVS (59.15Hz). Almost all LCDs will display MVS (through a line doubler) just fine, but they will introduce little stutter due to the framerate conversion.

It's basically the same than what the GBA player on the Cube does internally, but with a 59.7x refresh rate I would really just leave it to the display since there's a good chance that a display will be able to show this without any conversion.

[Unseen]

The GBA is close enough to NTSC specs to not cause any bigger compatibility problems.

Only partially... The vertical frequency is reasonably close to 60Hz, but the horizontal is about 13.6kHz.

How many pixels per line does the GBA have and how many lines?

240x160, square pixels

Wouldn't this distort audio output a little bit as well? Seems like a last-plan solution to me, might even break game logic somewhere.

It would result in a slight pitch shift of the audio, but since everything in the GBA runs from a single clock the game should not be able to detect the change. There might be problems if you link such a modified system to a standard GBA, but games already need to handle slight clock variations between linked GBAs - the only question is how much variation they can accept.

[Woozle]

I might just try to generate different HDMI video timings from my FPGA and see how off-spec my TV lets me get.

An issue I'm having is how to use the GBA pixel clock for generating timing signals down the path within the FPGA. The GBA pixel clock is ANDed with a clock enable signal so that it is inactive during the video blanking period. That makes it not very useful for triggering the counters which generate the HSYNC and VSYNC signals for HDMI, at least it seems that way. Maybe there is another place on the GBA from which I can access the pixel clock without any clock enable?

Another idea I had is to just clock the FPGA using the GBA's oscillator and generate the video timing from that. The oscillator outputs a sine wave, but I'm not sure how I would use that as a clock signal...I'm thinking connecting the oscillator to some sort of comparator circuit to give me a square wave, anyone have experience with that?

[meneerbeer]

How many pixels per line does the GBA have and how many lines?

240x160, square pixels

In that case, if you derive the HDMI pixel clock for a 640x480 output signal from the GBA pixel clock, you need to multiply the GBA pixel clock by (800x525)/(240x160)=420000/38400=175/16. I think you can do this using a single PLL (sometimes the numbers are too big when doing these calculations, this seems to be the case for 720x480).

I could have made a mistake here with the calculation, but I have successfully done this before. Basically, if you perform this pixel clock generation you get matching input and output framerates. Obviously, this means the HDMI output framerate will not be spec compliant, which most TVs do not care about. I got my own TV running at 61Hz once.

You can keep the framebuffer in this case. All you need to make sure is that the HDMI controller's reads from it are slightly behind the writes (for minimal lag). However, with this pixel clock generation scheme, buffering only a few lines is also sufficient.

[Unseen]

Another idea I had is to just clock the FPGA using the GBA's oscillator and generate the video timing from that. The oscillator outputs a sine wave, but I'm not sure how I would use that as a clock signal...I'm thinking connecting the oscillator to some sort of comparator circuit to give me a square wave, anyone have experience with that?

I would use a single inverter from a 74HC14 from that. It will introduce a few nanoseconds delay, but that shouldn't be a problem - if it does, you should be able to compensate for it by setting up timing constraints relative to the clock for all input signals.

You only need to make sure that the FPGA's PLL is specified to work with such a low frequency - I don't remember the values for all Spartan families, but at least some of the older ones needed a minimum of 18MHz for the DLL (e.g. CLK0/CLK90/.../CLK2X outputs) and less than that for the PLL (CLKFX... outputs).

[Woozle]

How many pixels per line does the GBA have and how many lines?

240x160, square pixels

In that case, if you derive the HDMI pixel clock for a 640x480 output signal from the GBA pixel clock, you need to multiply the GBA pixel clock by (800x525)/(240x160)=420000/38400=175/16. I think you can do this using a single PLL (sometimes the numbers are too big when doing these calculations, this seems to be the case for 720x480).

I could have made a mistake here with the calculation, but I have successfully done this before. Basically, if you perform this pixel clock generation you get matching input and output framerates. Obviously, this means the HDMI output framerate will not be spec compliant, which most TVs do not care about. I got my own TV running at 61Hz once.

You can keep the framebuffer in this case. All you need to make sure is that the HDMI controller's reads from it are slightly behind the writes (for minimal lag). However, with this pixel clock generation scheme, buffering only a few lines is also sufficient.

I don't see how that would work given that the GBA pixel clock shuts between picture lines. Wouldn't that make it unusable for clock generation with a PLL? That's why I wanted to use the GBA's oscillator instead.

[Woozle]

Another idea I had is to just clock the FPGA using the GBA's oscillator and generate the video timing from that. The oscillator outputs a sine wave, but I'm not sure how I would use that as a clock signal...I'm thinking connecting the oscillator to some sort of comparator circuit to give me a square wave, anyone have experience with that?

I would use a single inverter from a 74HC14 from that. It will introduce a few nanoseconds delay, but that shouldn't be a problem - if it does, you should be able to compensate for it by setting up timing constraints relative to the clock for all input signals.

You only need to make sure that the FPGA's PLL is specified to work with such a low frequency - I don't remember the values for all Spartan families, but at least some of the older ones needed a minimum of 18MHz for the DLL (e.g. CLK0/CLK90/.../CLK2X outputs) and less than that for the PLL (CLKFX... outputs).

That's another issue. Xilinx Artix-7 PLLs need 8MHz minimum input frequency. I was going to try to mess around and see what they output if I go below that (would they even activate?).

I've been able to get by without using a PLL so far...but the GBA pixel clock was only triggering a few logic elements (write to buffer). Would a PLL matter more now that I'm trying to use the GBA clock to drive multiple sets of logic in the FPGA (meaning routing could cause clock skew between elements receiving the pixel clock) ?

For GBA to RGB (for PVM) I'm thinking about two methods,
-scale 4x horizontally (240 -> 960) then only use every third pixel (960 -> 320), scale 3x vertically (160 -> 480) and drop every other row (480 ->240)
-scale 3x horizontally then drop every other row (240 -> 720 -> 360) as well as cropping the left and right 20 pixel columns. Scale 3x vertically (160 -> 480) and drop every other row.

Both would give an output of 320x240. The first method would mess up the aspect ratio and the second would crop the image. I did a little comparison of a GBA frame in paints scaled these ways and it looked good enough.

Edit: I forgot the gba clock is 16Mhz and would work fine with PLL, 1st sentence was assuming gba had 4mhz clock (brain fart).

[meneerbeer]

I don't see how that would work given that the GBA pixel clock shuts between picture lines. Wouldn't that make it unusable for clock generation with a PLL? That's why I wanted to use the GBA's oscillator instead.

Yes, you should then use the GBA's oscillator. In that case it is a matter of figuring out the ratio between the pixel clock and GBA oscillator and take that into account during the calculation.

You could also clock the GBA through the FPGA probably. The Neo Geo HDMI mod does that. I am not sure how clean the input clock signal of the gameboy needs to be.

[Woozle]

I think all I need to do is to use the 16Mhz gba oscillator to drive two counters which generate the vsync and hsync signals for the TV. I can input the 16Mhz to a PLL and generate whatever pixel clock I desire for pulling pixels from frame buffer to TV.

Currently the tv timing signals are generate by a 25Mhz clock driving two timers, I wouldn't think a 16Mhz source clock would be all that different.

[BONKERS]

Another idea I had is to just clock the FPGA using the GBA's oscillator and generate the video timing from that. The oscillator outputs a sine wave, but I'm not sure how I would use that as a clock signal...I'm thinking connecting the oscillator to some sort of comparator circuit to give me a square wave, anyone have experience with that?

I would use a single inverter from a 74HC14 from that. It will introduce a few nanoseconds delay, but that shouldn't be a problem - if it does, you should be able to compensate for it by setting up timing constraints relative to the clock for all input signals.

You only need to make sure that the FPGA's PLL is specified to work with such a low frequency - I don't remember the values for all Spartan families, but at least some of the older ones needed a minimum of 18MHz for the DLL (e.g. CLK0/CLK90/.../CLK2X outputs) and less than that for the PLL (CLKFX... outputs).

That's another issue. Xilinx Artix-7 PLLs need 8MHz minimum input frequency. I was going to try to mess around and see what they output if I go below that (would they even activate?).

I've been able to get by without using a PLL so far...but the GBA pixel clock was only triggering a few logic elements (write to buffer). Would a PLL matter more now that I'm trying to use the GBA clock to drive multiple sets of logic in the FPGA (meaning routing could cause clock skew between elements receiving the pixel clock) ?

For GBA to RGB (for PVM) I'm thinking about two methods,
-scale 4x horizontally (240 -> 960) then only use every third pixel (960 -> 320), scale 3x vertically (160 -> 480) and drop every other row (480 ->240)
-scale 3x horizontally then drop every other row (240 -> 720 -> 360) as well as cropping the left and right 20 pixel columns. Scale 3x vertically (160 -> 480) and drop every other row.

Both would give an output of 320x240. The first method would mess up the aspect ratio and the second would crop the image. I did a little comparison of a GBA frame in paints scaled these ways and it looked good enough.

Wouldn't the 2nd option cause non uniform pixels though?
Here's what just line trippling and then downscaling it by 2 in each direction looks like
(Right click>View Image. Forum seems to scale it)
Or does cutting out every other line fix that? (Do you do this before or after downscaling?)

[meneerbeer]

I think all I need to do is to use the 16Mhz gba oscillator to drive two counters which generate the vsync and hsync signals for the TV. I can input the 16Mhz to a PLL and generate whatever pixel clock I desire for pulling pixels from frame buffer to TV.

So you are using two clocks in this case? A 16 MHz clock to generate the sync signals and a ~25 MHz clock as pixel clock. I do not think that will result in a compliant HDMI signal.

[Woozle]

For 480p I suppose I could just use the 16Mhz to generate a 25Mhz clock and just use the 25Mhz for both video timing and pixel clock.

I wouldn't think there would be a huge issue using 16 for timing and 25 for pixel clock. If a PLL is used to generate them they would have some phase relation...the 16mhz just determines active video region and essentially gates the 25mhz pixel clock. Maybe I'm not seeing it, what do you think would cause issues?

[Woozle]

The second option would be scaling by 1.5x. an alternative is to not scale the GbA image and display it with borders on a 240p crt. It seems like you either have a border or non-integer scaling, not ideal.

[Guspaz]

If you're specifically displaying on a PVM, you should have enough control over the image to scale it up by substantially increasing the overscan. The use of the underscan button (which is really just an alternate preset for geometry settings) would let you toggle back and forth between "overscanned for GBA" and "normal". Heck, the underscan button could be the zoomed-in option, despite that being the opposite of what it's supposed to nominally do.

[Fudoh]

The second option would be scaling by 1.5x

there's a reason why the GB player on the Cube offers a windowboxed output. In order to get 1.5x to look halfway decent you need a proper scaling engine, which is hard to implement and uses a lot of FPGA gates. 1.5x scaling using a next neighbour scaling looks terrible, especially once the screen starts scrolling.