HDMI and RGB mods for different consoles

The Saturn doesn't have a discrete DAC, so digital video won't happen until someone reimplements most of the VDP2 chip. That won't happen anytime soon, and such a mod wouldn't even be practical so just go with a (HDMI) upscan converter. The Saturn has very compliant video, so it should play nice with just about any unit.

 

It isn't RGB to HDMI conversion. It bypasses the DAC which creates the RGB signals. This allows for a direct true digital DVI-D connection, which is compatible with HDMI. It will be better than any RGB cable as it isn't analog, it's true digital. This would also be better than VGA.

 

So it requires some mad soldering skillz direct to the chip?

 

Pretty much.

For some consoles, it is easy as soldering to the graphics chip (not the DAC) and then to a custom connector that go to an external box holding the necessary components. For internal mounting, all you would need to do is solder to the components and mount an HDMI port or a DVI-D port.

Other consoles with a combined DAC and graphics chip, such as the NES, require a method similar to Kevtris's NESHD mod.

 

What kind of upscalers understand 240p DVI or HDMI? XRGB mini is rather expensive for that (mine broke AFAIK).
I'm not sure I'd trust TVs to be very compatible with it...

 

It would probably require line doubling to 480p first. Then it could display on an HDTV, PC monitor, or an upscaler. The bare minimum HDMI is supposed to support is 480p, but I've heard of 480i and 240p working on some HDTVs/monitors.

 

The "NESHD" technically relies on some digital expansion video pins for part of the pixel data, and actually quantizes the analog video signal for the last bit (in addition to emulating/snooping palettes).

For all the other consoles with integrated DACs this method isn't possible. You either have to reimplement the PPU/VDP (as with Saturn) entirely, or much easier: you can lock onto the analog video, then re-quantize the RGB back to digital form. It's generally possible to reconstruct lossless video this way with enough ADC resolution, as long as the DAC's LSB isn't in the noise floor.

DVI doesn't support <480p, period.

HDMI supports 480i, but it requires pixel duplication to get an adequate pixel clock.
240p, not being a standardized format, can't really be expected to work over any digital interconnect since they follow hard-specified timing parameters.

 

The DVDO Edge does, although I don't like the ringing artifacts that it introduces with 240p.

"Bare minimum" doesn't mean that 480p is the lowest resolution though. It just means that the display must support 480p, but may support higher or lower resolutions in addition to that.

GCVideo sends 480i (and 240p) with pixel doubling and no HDMI signalling at all and it works pretty well on my monitors/scalers. Some detect it as 1440x480 (which it is), others just claim it's a 480i signal.

240p is a standard format, at least for digital video: CEA-861 formats 8, 9, 12 and 13. They even went so far as to specify two possible variants that differ in the number of blanking lines and defined formats 12 and 13 (2880x240) specifically with pixel repetition factors up to 10 to allow pixel-exact output from sources that generate less than 720 pixels per line. I'm not sure when these formats were added to CEA-861, but they have a lower format number than the now-common 1920x1080p24/50/60.

(Un?)fortunately just being a standard format does not mean that support for it is required.

 

http://oi59.tinypic.com/296husp.jpg

http://oi58.tinypic.com/359le38.jpg

Please note: The first two vids have a slight blue mist and blue / yellow ghosting to due a dodgy wire.
My capture card also only captures at up to 18 Mbps, so the quality looks much better in person...

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

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

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

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

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

OzOnE.

 

Wow those games look amazing via HDMI! I only have Sonic Adventure 2 for my Dreamcast but I do use a cheap VGA box. The HDMI mod looks much better. It seem cleaner and more colorful via HDMI but it could be do to my cheap VGA box.

 

Cool! So, what is the signal format on the Dreamcast's internal video bus? =)

 

Hey Ozone, awesome project!

I read in another thread you commenting about digital audio on consoles since the PS1. Since HDMI also carries audio would be possible to a digital audio output from those consoles?
This would give way better sound, I suppose.

Also, are scanlines possible to add?

Hope all the best to your project.

 

@MonkeyBoyJoey - I have the VGA box hooked up to a monitor as well, and although VGA can look very good, HDMI is definitely a few notches above that.

I'm still messing with the encoding settings for YouTube too - it obviously looks much better in person.
It seems that I'll have to encode it at 1920x1080p to get the best quality without the weird pixel resampling, even though it will be encoding the bars at either side of the main image.


@Unseen - I thought someone would ask about the the data format. lol
I thought it would be fairly simple, and it turned out to be in the end...

I knew the System Architecture Manual made reference to this as well, and managed to find it ..

"From HOLLY, the 24bit RGB image information (each RGB 8bit) is sent in units of 12 bit to the Digital-Video-Encoder(video DAC/encoder). The original 24 bit image data is divided into 12bit(RGB [11:0]) of MSB (RGB [11:0] = R [7:0], G
[/7:4]) and 12 bit of LSB (RGB [11:0] = G [3:0], B [7:0]). Then it is sent to the 54 Hz clock (which is double the 27Hz VGA
pixel-clock) in a synchronised manner where it alternates between MSB and LSB. For details refer to a separate
specification design document.


MSB (RGB [11:0] = R [7:0], G [7:4])
LSB (RGB [11:0] = G [3:0], B [7:0])."


So, it simply outputs the upper 12 bits, then the lower 12 bits in sequence, and I just reset that two-state machine when "Hsync_n" is Low, so it starts on the MSB first on each line.

//...........RED............................GREEN..................................BLUE
//.[11:10:9:8:7:6:5:4].......[3:2:1:0]....[11:10:9:8].......[7:6:5:4:3:2:1:0]
//...|-------------MSB----------------|......|------------LSB-------------------|


I had some big problems when I first soldered the Kynar to the DAC though - I bridged two of the pins on the DAC with solder, and quickly removed the bridge with solder-wick, but I must have removed a bit too much solder. Then, when I moved the wires, it lifted pin 5 (bit 5) off the pad which then disconnected it from the HOLLY chip. lol

So, I had the strange "blue mist" and weird colours at first, as you can probably see in the first two videos.
I wasted about a day thinking that I was clocking on the wrong clock edges or something, but I tried all combinations of that and it looked clearly wrong every other way.

Of course, this was mainly noticeable on the Blue channel, because bit 5 on the bus is also only used for bit 1 for the Red channel.

Unfortunately, the JTAG on this FPGA seems to have "given up the ghost", so I couldn't yet see where the problem was, or view the data via SigTap.

Anywho, I removed all the wires, resoldered the DAC pins, then re-soldered everything, and it's fine.


@Fandangos - I'm already transmitting digital audio directly from the audio DAC pins on the DC.
This is I2S audio as well (four wires), so should in theory be very slightly better quality than S/PDIF.

You can hook up SPDIF directly to the HDMI chip as well, but I2S is used on pretty much every console since the SNES.

btw, scanlines are easy on FPGA. It's one of the first things I tried.
http://pastebin.com/3J7RPN80

That does work OK, but then the capture card scales it to my monitor's res, and the scanlines look bad (not to mention the tearing, because two of my monitors are only 1440x900, and the main one is 1680x1050.)

But, it's easy to just do multiple lines of scanlines, or even match them to the monitor's / capture res.

Normally, you'd connect the HDMI (or VGA) directly to a monitor though, and most of them will scale nicely without destroying the scanlines.
To get the best possible image, the FPGA would really need to convert to the native res before adding the scanlines.


I've been e-mailed [RDC] from the gc-forever forum again, and he seem enthusiastic about tweaking the final design and getting a small run of new boards made.
I did almost finish my own board design, but it's using much bigger parts, and his reflow soldering is pretty much perfect (I don't have a reflow oven).

At first, I was hoping to use Hirose type 1mm connectors / cables, as you often see on LCD panels.
This would make things more convenient because the cables have thin separate wires.

But, when [RDC] compared the layouts, it's actually just as good to use 1.5mm x 1mm solder pads on the board tbh.
That would give us around 37 pads in the space of the 30-pin connector too.

Since in many consoles we would have to solder to the DAC anyway, we might as well save the cost of the connectors / cables, and simply solder Kynar to the main board as well.

We're also looking at doing a separate QSB and / or TransX board for doing voltage-level conversion on 5V machines...

I did a quick spreadsheet to note down which are the best target machines, and which have direct access to the digital video bus.
It turns out that there are far more "5-Volt" machines than you would first think, as most of them are mid-90s or earlier.

It's only really things like the N64, GC, Wii, Dreamcast, PS1, PS2, and Xbox 1 which use 3V3 logic for the video DAC.
Almost all the other machines use 5-Volt (and there are at least 22 I have listed already!)

We might be able to squeeze the voltage transceivers on the QSB itself, or just have a generic small TransX board which makes it easier to solder too from the DAC.

It will also have the HDMI port on a separate shielded FPC, so the main board can be put almost anywhere inside the console / computer.
That means you won't need to find the space directly behind the HDMI connector to fit the main board.

Also, as Calpis said above, for machines like the Saturn which only output analog RGB directly, you would need to run a large chunk of the VDU / PPU / GPU on the FPGA to re-create true digital video.

For many of the 8-bit machines (ZX Speccy, Beeb, C64, Amstrad), there are already some ULA / PPU cores which are working very well.

Thanks to the coding skillz of other clever people like Grégory Estrade, we also have a decent video core for the Genesis and PC Engine.
There's also a mostly finished open-source SNES PPU core online, but nothing as yet for the Sega Saturn nor Atari Lynx that I know of.

Then there are a few machines which shouldn't in theory even need the FPGA at all, but the chips are getting cheaper every few months, so we might as well keep it for an on-screen menu and possible line expansion to 720p / 1080p etc.

Machines which use a generic 24-bit video bus include the NeoGeo MVS/AES/CD, Atari Jaguar, Amiga 500,1200,CD32 etc., and Pana 3DO, and countless arcade boards.

(Of course, the NAOMI 1 and 2 use a very similar (if not the same) DAC to the Dreamcast.)

Anyway, I'd better stop typing for a while. lol

OzOnE

 

But it's the lowest the display is guaranteed to lock to.

Interesting, I've never seen these in practice or listed as supported by any equipment specs.

It would be remarkable if displays could switch between 240p and 480i seamlessly as with analog, but I suspect next to none are equipped for that.

IMO band-limited 704 pixels is preferable.

As far as I can tell these IPs are more or less high-level implementations informed by software emulators, so they aren't nearly accurate enough to interface with, much less replace, the original ASICs.

 

True to an extent, but I've messed with the Genesis VDP code quite a lot when trying to implement the 2-player split-screen modes, and I think it could actually be made to work as a VDP replacement with a bit of work.

Most of them are coded to quite a low level tbh, and match the "intent" and timing of the originals fairly well.

I know the original does a lot of bus arbitration and other stuff too, but the actual video core seems quite accurate, even down to the way it has slight glitches when there are too many sprites along a line etc. (like the original hardware).

I also hooked up a SNES PPU bus to the FPGA recently, to test the partial core for the PPU, and it seemed quite far along.
I got a fair bit of the image on the screen when using the SNES as the "Master", but it needs more of the VRAM code to be finished.

I do like your idea of quantizing the analog RGB signals though - I'm looking to do something similar for the Atari 2600, since there are only so many finite colours it can display anyway. So, I was going to run a PLL in-sync with the colour burst, then window-match the colour signal to a hard-coded palette.

Quantizing RGB could work quite well too, especially since many older machines don't have too huge a palette to begin with.

OzOnE.

 

@OzOnE

Does it means, you could make a version for PS1 that will enable a HDMI out?

Thanks.

 

Quick question about the TG-16/PC Engine.

I noticed in a pinout diagram that the expansion port (for the CD drive) has direct access to the video bus. Does this mean a TurboDVI add-on could be made that attaches to the expansion port to provide true digital DVI-D/HDMI?

Maybe make it in an inline form so the CD drive would still work?

Can you add digital audio output to the Dreamcast boards using audio over HDMI and/or a TOSLINK connector in the future release?

Just throwing around ideas here.

Anyway, keep up the great work on the N64 and Dreamcast! Looking forward to them both!

 

Yes, it does. But I believe the PS1 uses a 24 bit parallel RGB interface, meaning you will have to solder quite a lot of wires on very small IC pins.

I think it already has audio over HDMI.

 

Yes. It requires a lot of I/O though because it must also snoop the CPU bus to keep a local copy of palette memory. By that point you have all of the hardware to make a well-featured expansion device with emulated digital audio, Hucards and CD system. It's probably possible to turn a vanilla PCE into a SuperGrafx over the expansion port...

 

Thanks for the information. It matches what I suspected based on the schematics, the main missing bit was how to determine if the current word is the first or second half of a pixel.

If you need to use non-integer vertical scaling this can result in uneven scanlines though - the XRGB Mini appears to add scanlines on top of the scaled image and with a 1080p output from a 240p source it looks rather ugly.

There are also a few handhelds that would qualify for the 3.3V category.

As far as I know there is no satisfactory C64 VIC core available in source code form. The one from FPGA-64 comes with a "no distribution" license and even its most current, not-available-in-source version in the Turbo Chameleon 64 still has issues with a few Demos.