HDMI and RGB mods for different consoles

Continued from this thread...

https://www.assemblergames.com/foru...cable-solution&p=804035&viewfull=1#post804035

Basically, I'm working on new PCBs for doing RGB and / or HDMI mods on many different consoles.
The short list in the previous thread shows which consoles might be best suited to the mods (especially the HDMI mod).

In the other thread, we were discussing work on the Game Gear, including getting the best possible picture on a modern replacement LCD...

@MonkeyBoyJoey...

I just checked the schematic for the Game Gear and realized that the signals I'm tapping for the RGB mod ARE going directly to the stock LCD (rather than it being a separate bus).

This means we'd still need the CPLD or FPGA to convert the signals to something a modern LCD (or controller) can accept.
(In other words, it's unlikely we'll find a modern LCD that can attach directly to the GG mobo without some format conversion.)

Might as well concentrate on getting the best possible signal into a modern LCD controller using the CPLD board, then figure out the scaling / zooming.

It would be better to just scale the standard RGB video signal to the LCD controller of course. That way, the output to the TV will always be scaled too.
That would also get around the problem of the stock LCD not working when the GG is forced to "zoom" mode for Master System games (using test pad T10).


A bit of background on SMS mode...

I haven't tested this myself yet, but with an SMS game (or "SMS in a GG cart", like Castle Of Illusion), the GG changes the video timings so the image will fit the smaller res of the stock LCD.

(bottom of Tim's page has a better explanation)...

http://etim.net.au/ggtv/ggtv.htm

To get the RGB output to display properly on a normal TV, you have to connect test pad T10 to 5V.
This will then disable the internal stock LCD though, due to the difference in the video timings.

If we're replacing the stock LCD with a modern one, the GG could likely be left with T10 permanently tied to 5V, so SMS games will always fill both the LCD and TV.

(If tying T10 to 5V causes problems with normal GG games, it would be simple enough to just check the "GG" signal on the cart slot to detect the type of cart.)

So, since I think many people would prefer a shiny new modern LCD, getting the zoom working on the CPLD / FPGA side would have the bonus of allowing simultaneous display on both the LCD and TV, and give a full-screen image at all times (selectable).

EDIT: The zoomed image would work for the HDMI board as well, but it would still need a scan doubler because some modern TVs don't accept 240p via their HDMI input. It would have to be output in 480p or 480i to make it work with most TVs.

OzOnE

 

Once this GG mod is done, all we would need is the metal stand that came with the TV Tuner and a mod that allows player 1 controllers, and then we could kick back, relax, and play GG Sonic 1 or GG Streets of Rage 2 on an HDTV and from the comfort of a rocking chair and a rocking ottoman.

Maybe we could get some LCD manufacturers over in China to create LCDs compatible with stock GGs or at least some that accept RGBS. Maybe we could get one that accepts the old 15KHz CGA signals so we could get the RGB coming out of the GG and also separate H and V Syncs for the best possible analog picture. Maybe we could get 31KHz VGA out of it but I'm just speculating here. Of course the easiest way may be to get an LCD that accepts DVI-D or HDMI and just use those.

(Sorry in advance for double posting)

I wonder if Sega had a prototype cartridge for the Genesis/Mega Drive that allowed GG games to play on it. If I were Sega, I would have designed it in a way to take advantage of both the on-board Master System hardware, the extra power of the Genesis/MD hardware, and anything else could have been added via the custom cartridge. That would have given it a competitive edge over the Super Game Boy as that needed extra hardware in the cartridge to play GB games on the SNES whereas this "Mega Gear Converter" would use the on-board hardware. That would have made the MGC cheaper than its Nintendo counterpart because it would have been basically a couple custom chips, custom software, and a GG cart slot on a Genesis/MD cart.

Use the edit button then
- Moderation

 

I have an xbox related project here you may be intrested in:
http://www.xbmc4xbox.org.uk/forum/viewtopic.php?f=13&t=3644

I have looked at making a y,pb,pr to hdmi adaptor for mounting nicely in an xbox console, I looked at using a analogue devices all in one chip but it i would have to make hundreds of them to make them at a resonable price far exceding the possible demand it woud mean en easy solution but cost became the issue as you can't compete with cheap chineese adaptors!!.

The other option was to use a upside down socket and pop it on top of the video encoder chip to collect the digital signals out of the video encoder into an fcpga creating hdmi on the output, but the work envolved in doing it to potentially only work on one console type and or version of that console.

I think the best solution is to make some standard signals available and use an off the shelf converter as I have done with my project.
I would be keen to see any info you have on component to hdmi if you have made or designed any thing.

Many of the chineese devices have custom or obscure chips with their makrings shaved off and many are in extruded cases and have no holes to mount them nicely inside a console without some sort of fabracation.

I did enquire with one of the chineese manufacture's and they said they could make a custom adaptor to fit the xbox but they would not look at it unless there was a minimum order of 1000, but their resulting price was very good per unit.

 

@MonkeyBoyJoey - I'm sure there are small LCD kits out there that would work with RGB input.
As you've seen though, it seems the ones with the smaller controller board often seem to have Composite only.

I'll keep looking for a small controller with VGA / RGB on, and I'll ask the manufacturers if they support 15KHz modes via that input.

I don't think we'll find LCDs directly compatible with the GG ribbon cable output tbh.
It's a fairly non-standard time-multiplexed 4-bit video bus, so I don't think the modern controllers could be made to work with it.

Conversion from the GG video bus to 12-bit parallel RGB is easy on the small CPLD though.
(This is essentially what's already being decoded and output to the DACs.)

I'm using simple discrete resistor DACs on the prototype board for RGB out to the TV, and a THS7374 opamp buffer.
Once I fixed a small bug (added a resistor down to Ground on the DACs), the image quality on the TV is superb.

I'm not sure if Sega had a GG player cart for the Genesis tbh. If anyone does know, please chime in.
Interestingly, the Genesis does support SMS mode already, so you could in theory play the SMS mode GG carts on the Genesis with a simple adapter.


@mrgreedy98

Nice project.

I don't envy you getting those boards made exactly the right size etc.
I'm having "fun" with that on the GG atm; printing out and cutting out random bits of paper etc. lol

The Xbox is still a great machine. I stuck Coinops 6 on mine last year.
I used an Xbox with XBMP / XBMC for many years for watching movies on the projector via Component as well.

I did think about simply sticking an analog-to-HDMI adapter in some machines, but I'm a stickler for quality, so I'm always chasing a pure digital connection if at all possible.

Some of the HDMI adapters can give a pretty decent image though, especially if the console / computer can output 480p (or higher) progressive modes.

I also gave thought to using a socket on top of the DACs (like some Amiga accelerator cards do). If it can be done cheaply, that might still be an option.

Funnily enough, I've just bought a cheap £10 VGA-to-HDMI adapter as well, just to see if my Avermedia H727 capture card would accept 15KHz 480i / 576i via the HDMI port so I can use a SCART adapter with it.
It doesn't seem to work, sadly.

http://www.ebay.co.uk/itm/251799150419

It could be simply because the capture card won't accept 480i / 576i via the HDMI input, but I think it does.
It's far more likely that the VGA adapter won't accept Composite Sync, so I'll try again soon with an LM1881 or something.

What's frustrating is that most of these cheap conversion chips can actually support most video modes and even do RGB <-> Component conversion, but the firmware often doesn't have that enabled.

I have one of those WII2HDMI adapters too, and it looks like it's obscure chip is almost the same as the one in this VGA to HDMI adapter, just in a different chip package.

The box works fine with the Dreamcast though, and the Avermedia software adjusts to 640x480 via HDMI fine.

I'm still on the lookout for a more "universal" cheap adapter which will upscale or scan-double from 240p / 288p.

I'm sure this stuff can be done without too much expense, we just have to find the right combination of converter.

I'll keep an eye on your Xbox project. It's looking good so far.

btw, I think soldering Kynar to the different DACs on the Xbox won't be too hard (for the HDMI mod).
That might mean doing a pre-modded service though.

IIRC, the Xbox uses standard bt.601 or bt.656 multiplexed video to the DACs.
Hopefully, the HDMI chip will accept that directly. It does cut down on the number of wires required to do the mod too.

I'll crack open an Xbox soon and do some testing.

OzOnE

 

Have you thought about how to handle weird pixel clock rates/weird number of pixels per lines/weird amount of lines?

N64 for instance has 773.5 (I believe) pixels per line for 480i/240p. I think some TVs will not like such a weird amount of pixels per line over HDMI. You could add SDRAM to your board, so you can triple/double buffer the image. In that case you will be dropping input frames from time to time, unless you are able to lock the input framerate and output framerate.

If you are able to somehow lock the input framerate with the output framerate then it is possible to only buffer a few lines from the input signal and output these. You just need to make sure your output is behind a few lines. I found this topic where they are discussing this approach. Still it seems you need a rather precise PLL setting. Also, the framerate of the console needs to be close enough to the HDMI spec (59.94 fps?).

I designed my own N64 to VGA adapter (and hope to make a HDMI version soon). For 240p input I was able to lock the input and output framerate by calculating the VGA clock. The clock has quite a lot of jitter, but I fed it into a PLL to smoothen it again. Not sure how good/stable this approach is. Also curious how HDMI will handle it. Anyways, I am now outputing a correct 640x480 VGA signal (800 pixels per line, 525 lines). What kind of sucks is that the PLL only accepts input from Clock pins, so I need to output the generated clock and feed it to a clock pin before it can go the the PLL.....

It seems Dreamcast and Gamecube have video output that certifies with CEA-861. Not sure how this applies for PS2 and PS1?

 

It's always a challenge when there are weird video timings.

You do have a fair bit of adjustment with the clock rates on HDMI though, assuming the TV will accept the base resolution to begin with (480i / 576i etc.)

I really should look again about adding SDRAM to the board, but I'm trying to keep it as small as possible.
I'd love to try routing a BGA FPGA to make the board smaller, but I've never tried a multi-layer board before.

The fact that the N64 often switches between 240p/288p and 480i/576i all the time is a pain as well.
As you know, quite often the main logo screen will be in 480i (KI Gold, Vigilanti 8 etc.), then it will switch to 240p in-game.

The switching means that the HDMI chip will re-sync as well, so you'll usually get a blue / blank screen on the TV for a second or two.

The output clock on the HDMI chip is essentially locked to the input pixel clock on the current design anyway, since it doesn't buffer any lines / frames or anything.

On my much older HDMI tests on the FPGA dev board, I was using the Altera IP core to buffer the frames into SDRAM and always output 640x480, or 720x480.
This was quite forgiving, as the mode changes on the N64 were pretty much seamless IIRC.

Warning: this video was pretty "rushed". lol

https://www.youtube.com/watch?v=NCbkDgCIKRQ

To get a more standard pixel clock, you could try feeding your own clock into the RCP and overclocking it very slightly?
This worked very well for me, and I was able to overclock it to roughly 70MHz.

The frame buffering meant the output timing to HDMI was kept the same, and there was no noticeable tearing that I recall.

IIRC, the N64 uses a non-square pixel mode, is that correct? The actual NTSC and PAL timings should be spot-on though.

I really need to try buffering some lines on the current HDMI board, as I want to try expanding the image for the Game Gear without using SDRAM if possible.

Doing line buffering is a good compromise really, as the smaller FPGAs often have enough internal BRAM to buffer at least three or four lines.

What kevtris is doing with the HDMI NES is interesting - he's locking to the input frame rate, then buffering some lines, then expanding horizontally to fit 720p or 1080p (with options for keeping the same aspect ratio, or stretching etc.)

This is only really practical on the NES because it generally sticks to 240p/288p of course.
Doing the same on the N64 would no doubt be a bit of a headache.

The Game Gear is a definite candidate for doing some line buffering tricks.

OzOnE
P.S. I imagine the PS1 and PS2 have standard and thus quite accurate video timings.
I only have a PS2 Slim, but if that will work via HDMI it will likely work for the PS1 and Dreamcast too.

 

With the various output resolution, SNES would be a great challenge

256x224
256x239
256x448
512x224
512x448

 

Yes, but what I am trying to say is that a lot of old systems have a weird amount of lines per frame and also a weird amount of pixels per line. Not every TV will accept this over HDMI I think.

Edit: SDRAM is not that expensive and you could omit it when not used. Routing is pretty lenient in my experience (single rate). In case you are low on FPGA pins, what you could do is only connect 12 of the 16 data lines of the SDRAM chip. 24 bits colors would not fit anyways, unless you use an SDRAM chip with 32 bits word size.

 

I think that's the difference between the framebuffer size and the actual video output timings.

ie. all those resolutions should still be displayed within the standard 240p / 288p video timings when output to the TV (AFAIK).

If some systems' output timings fall too far outside CEA-861 standards, we'll probably need to buffer full fields to get HDMI working.
Otherwise, we can hopefully just buffer some lines to "make it fit".

The FPGA I'm using on the HDMI board atm doesn't really have enough pins for SDRAM, so it might need a new board layout to support the weirder console video formats.

OzOnE
EDIT: I originally wrote more here, but then hit "Reply With Quote" again, and it wiped out my previous text.

 

No, that's the real output on the TV screen. You can «hear» it with a CRT, and it causes some slight jumps with a Framemeister.
The best way to test all the SNES mode is by using the ROM SNES TEST PROGRAM.

 

Ahh. I never knew that.

So it does output a slightly different number of lines in each mode too. Hmm.

Shows how forgiving most CRT TVs were / are. They can have a wide variance in input timings and still display OK.
The beauty of analog I suppose.

I only recently got hold of a SNES console again after many years without one.

I'll eventually need to test the video timings of every console I own, and it's sounding like doing an HDMI board with SDRAM may be necessary with some of these machines too.

OzOnE.

 

Does the SNES have a separate DAC? Or is it like with NES?

Maybe some TVs are more forgiving. If that is the case, then it might still be interesting to keep a direct mode. From what I have seen on forums it seems Sony TVs are very picky.

 

It's easy to synchronize input and output video. Yes, you need to use PLLs. For digital video you only need a fractional PLL. The display doesn't care that the frequency is slightly off because it too uses a PLL to lock to the incoming video. You *MUST* use proper SMPTE frame timing (thus approximate the pixel clock) though because displays typically don't have adaptive algorithms for other formats. (Don't use VGA/VESA timings.)

You can do the same with analog video too. You must first very-cleanly separate Hsync and use an integer-N PLL to generate your sample clock. With a second fractional PLL governed by the sample clock again you can create whatever output clock. With a low noise clamp, high-res ADC, a quadrature clock, knowledge of the console's gamma etc and some signal processing it's possible to reconstruct lossless digital video... Conceptually it's not even that difficult, so basically Micomsoft sucks.

 

The PPU in the SNES (one of the two chips) outputs analog RGB directly.
It then gets encoded into Composite and S-Video via a Rohm BA6592 chip.

After I said that the SNES would probably need a whole PPU core running on the FPGA, I'm thinking now that the colour bus between the PPU chips could be snooped instead...

The PPU does constantly read the VRAM to output the framebuffer, but hooking up to the VRAM would mean running a partial PPU core to decode certain stuff.
It would also need tons of wires to hook up to the VRAM, so I'd be interested to see what's actually transferred over the colour bus.

I was actually doing some experiments on the SNES the other week - I bought a working SNES and another one with a dodgy image.

There is most of a PPU core available here, but it's not entirely finished...

https://code.google.com/p/fpgasnes/source/browse/#svn/trunk/PPU%3Fstate%3Dclosed

(probably a good idea to grab a copy soon, as they are shutting down the Google Code service.)

I hooked up the FPGA to the IO bus on the broken SNES, and was able to get part of the image working on the FPGA side.
IIRC, the code for VRAM accesses in the core isn't quite complete either, but it was promising.

If the core was finished, it would form the basis for an HDMI SNES mod, as well as a full FPGA SNES core.

There are also some 65816 CPU cores out there that are not quite complete, and working code for the Audio DSP.
I've seen a few complete FPGA SNES projects online, but they are not open-source AFAIK.

It's a shame, because all of the component parts are there to finish the core.
It just needs somebody with the patience and skillz (not me. ) to write the rest of the code.

I did try finishing some 65816 code I found online too, but it's very complex and time consuming.
The SPC700 audio CPU alone apparently needs all 256 opcodes to work properly with all games!

Anywho, I'm getting off track as usual. lol

Yep, we can always leave a Direct Mode option available on the HDMI mod.

I would like to be able to bypass the need for a framebuffer too if possible.
That would make the board a bit cheaper, and keep the added frame lag to a minimum.

As you say though, we can always just leave the footprint for an SDRAM chip on the board, so it'll be ready for consoles that need it.

OzOnE

 

I actually have acces to a roland versa cad vinal printer and I just pop the eagle out using the cam printer but yes it is a pain to get right special the mix of metric and imperial and constantly changing the object snap and grid settings.

I would much rather see a native hdmi mod but the problem with me is I have no knowlege in programming of fcpga's and cpld's.

I would love for someone to come up with a device to do it we are comming to a point where analogue will be phased out of TV's and it is semi how i started of with my project.

A wii clip style socket would suit the xbox console and I think a small qsb with a lead or socket to a standard board with hdmi output and a set would be a great solution.

If a coding socket or small serial eeprom or dip switches was inlcuded on the qsb or board it could select the fcpga source image for the correct console type. a universal solution for all consoles perhaps?.

To make it usefull it has to be semi plug and play or it ends up in the too hard basket for people to install and you end up with a lot of soldering work and little free time, then shipping internationally becomes a issue pushing it out of the saleable price bracket if you are poping consoles around the world.

I dont envy you looks like you have a lot of work on your plate!!!

Cheers Jono

 

Hi, Jono,

Don't worry too much about digital video taking over these days - decent analog outputs are still very much in demand in the retro community, so your work is definitely valued.

In fact, as you know there are many retro gamers who still prefer to use a CRT with their machines, so Component and RGB is always welcome.

Yep, I'm definitely aiming for sticking a few DIP switches on the HDMI board to make it universal.
For most machines, the conversion code should be quite small, so I could probably fit the code for about 16 or more different formats into the config EEPROM.

(That's assuming the specific console doesn't require a big video core to be running, simply to extract the video data.)

atm, I'm stuck wondering if I should make the board slightly bigger to fit voltage level conversion / buffers on the board itself, or just have a separate small connection board for consoles that run on 5V?

I also think I'll leave SDRAM until the next version, because the FPGA has nowhere near enough spare pins anyway.
I don't send off for some PCBs soon, it might never get done. lol

True about the modding service too...
It has the advantage of being able to fully test the mod first, but I can see it taking tons of time.

For consoles like the GC, I want to do a small adapter board that fits over the Dig AV pins (similar to your Component / RGB design.)

OzOnE

 

I would think digital conversion on the qsb or adaptor as it will be different per console as bus and video formats differ you could make the main board more universal if it is smaller it will fit better inside smaller and portable consoles, but you end up redesining the basics for different consoles again.

I guess it all depends on what is the largest bus you wish to tap, there is also decoding config signals of the video encoders per console aswell and chip configure video modes.

maybe a hidensity plug on the end like a lvds cable on a laptop or double suded flexible ribbon cable or something to connect the two? then all meandering etc could be done on the qsb's taking into account hi speed signals and trace lenghts making a very simple main board.

There is merit in both methods I guess it depends on which consoles you want to support.

 

OK, so let's say we have a N64 240p signal that we want to synchronize with a 480p output signal. The N64 incoming frame exists of 263 * 773.5 = 203430.5 pixels. The 480p frame exists of 525 * 858 = 450450 pixels. In that case we need a pixel clock for the 480p output signal that is n64_pixelclock * 450450/203430.5. So we have an N value of 450450 and M value of 203430.5 for the PLL.

Not sure how to simplify the N and M value further. Do you have any idea? Also, what would then be a suitable PLL chip?

This method will still not work if the input framerate deviates too much from 60 Hz and the TV is very picky about it. In that case the system will need to be overclocked/downclocked a bit.

 

450450/203430.5 = 9900 / 4471

Find the greatest common divisor and simplify.

FPGA are starting to integrate fractional PLL, so that would be the best choice (Cyclone V for example). Besides that I'm not sure, I'm interested in DIY designs.

Perhaps older FPGA can be modulated too, depending on their loop filter. 9900 / 4471 = 2^2 * 3^2 * 5^2 * 11 / 17 / 263 <- tricky

Vsync will deviate by <0.2%. Even analog displays could handle 2%. HDMI should lock to all clocks >25 MHz so video shouldn't be a problem. Audio on the other hand.... I'm not sure. Every TV should have an audio PLL or asynchronous resampling, but that's a lot to assume.

 

Will this RGB to HDTV work on the Saturn? Maybe I should hold off on all the cables and converters, eh?