Atari 2600 RGB mod

[Atari 2600 RGB mod]

Has anyone installed one yet? Curious to see how well it works going through a xrgb-mini. I've been checking the US order page daily hoping for the opportunity to order.

 

I don't think anyone's got one yet. They take forever to arrive from Australia to the US (2-4 weeks) and apparently there's been an issue and new shipments were sent on 8/14. Once the US distributor is up and running I would expect much faster delivery times. My NESRGB came from the US distributor and showed up in less than a week.

 

Tim has said this uses the same RGB output section as the NESRGB. The NESRGB works perfectly with the XRGB-mini I would expect the same here.

[Atari 2600 RGB mod]

Someone above was discussing what would occur if you transcoded component from the RGB signal produced from this mod. Chroma subsampling would take place when you go from RGB to YPrBR colorspace.

 

 

True, most component signals are filtered to reduce chroma bandwidth. There's no interconnect reason for that however. The Pb and Pr cables are the same as the Y cable and full bandwidth chroma is legal in analog component video. Once you go to S-Video or composite then bandwidth reduction is necessary.

 

From what I can see of the photos of Tim's circuit he's got a bunch of resistors presumably to do weighting and scaling of the RGB signals and dual Op Amps to do a subtraction for each chroma signal. He's got video driver caps on each signal and a single power smoothing cap. I don't see any low pass filters on Pb and Pr. I think they are likely full bandwidth. So it's really up to your TV. It may filter component at the input or it may not depending on how it's built.

 

However RGB is not immune to all this. The RGB signal is almost always converted to YPbPr and back even on analog sets. The YPbPr space is a much easier space for signal processing, especially in analog. If brightness, contrast, color and tint effect your RGB input your set has almost certainly converted to YPbPr for that processing. If your set chroma filters YPbPr it probably internally chroma filters the RGB to YPbPr conversion too.

 

Even if chroma filtering occurs you are unlikely to tell. DVDs and Blu-rays halve chroma horizontally and vertically and they look great. At most a low pass filter on component will halve the horizontal chroma but keep the full vertical chroma resolution.

 

Ultimately we're talking about an Atari here with 160x192 pixels and a 128 color palette. None of the subtleties of colorspace conversion or chroma filtering should be visible at all.

[Atari 2600 RGB mod]

anyone install one of these yet?

 

My guess is that unless you live next door to Tim nobody has one of these in hand yet.

 

Mine is apparently in the mail. I ordered the first day of availability and it shipped August 4th. I don't know when it will reach me in the US.

[Atari 2600 RGB mod]

I haven't used Tim's RGB to component converter, but it should only need to apply a conversion matrix to the signal. The result should be quite good. You will not be able to tell a difference between RGB and YUV.

 

Mathematically RGB to YUV and back to RGB is not a lossless transform. That's largely academic though. Our entire video system is built on YUV. Blu-rays look pretty darn good and they start with a YUV encoding on disc and are likely transformed from YUV to RGB and back several times before the video is display as RGB on a modern HDTV.

 

A couple caveats however :

 

1. Tim's component converter outputs 240p just like the RGB signal. Most modern digital TVs that accept SD only really know how to deal with 480i and 480p. Many won't show a 240p signal at all and those that do often mangle it. The OP was going to use a CRT so it's likely compatible with 240p but for anyone hoping this will let them hook up to their LCD or Plasma there is a good chance it won't work.

 

2. There are two different YPbPr to RGB transforms. One for SD (Rec 601) and one for HD (Rec 709). Unlike RGB this leads to an opportunity for the source or display side to use mismatched transforms. When the transforms are mismatched the signal can be noticeably inferior to RGB. A correctly implemented TV should detect the signal type (SD or HD) and apply the appropriate transform. Unfortunately many HDTVs, particularly early models, get this wrong and apply just one of the transforms to all signal types. Some up-converting DVD players also got this wrong on the source side. The resulting picture when mismatched transforms are used looks mostly correct, but there are color shifts. Most noticeably green will either be too neon or too muted. If the OP's CRT TV is SD it almost certainly uses Rec 601 so there shouldn't be an issue.

 

[Atari 2600 RGB mod]

Yes, if it were a simple on/off switch between the two original pal and ntsc palettes I would have put it in place of the useless channel switch. But as it's automatic and I don't have pal60 games anyway, I won't install any switch. People with a lot of Pal60 games would probably have preferred the option of a manual two position switch, as it would give a tactile feedback of what palette you are using. A push button may be confusing sometimes.

I would have liked if there was an audio in pad, so it could mix the AtariVox internally. The two audio pins do confuse me though, especially since I expected to have the video and audio through the mini din8.

 

Also why do we have to replace the regulator? And the extra capacitor is an oversight of the original design or does it need to be put as it is?

 

I wonder if there's a momentary switch that could replace the channel switch? Something that springs back like the reset and select switches but in the form factor of the channel switch. That would be a nice stealth way to externalize the palette switch on 4 switch units. I Googled a bit and didn't see anything, but that doesn't mean they don't exist.

 

On the NESRGB people were soldering to one of the resistors in the audio section to mix in expansion audio. In later revs Tim added a thru-hole to make mixing in audio easier than soldering a wire onto a surface mount resistor. In the photos for the 2600RGB there is a loan thru-hole over by the audio section. Maybe that's also for mixing in audio? I guess we'll have to see. Worst case I'm sure you can find a solder point to mix into the audio section.

 

And yeah what's up with the extra cap for the regulator? You would think it would be on the regulator board already. Maybe a last minute addition?

[Atari 2600 RGB mod]

 

I am a little worried about the use of a push button for palette selection here. The NESRGB used a multi-position switch to set the palette mode so the switch position dictated the palette. With a push button the 2600RGB will need to remember what palette it's on since it can't just query the switch position. Is this selection remembered after the console loses power? Does it have two independent memories, one for the current PAL palette and one for the NTSC?

 

Hopefully there's some non-volatile RAM in the mod that saves this info.

 

Looking at his photos he's got an 24LC64 8K programable ROM on the board. No such EEPROM was present on the NESRGB. He states that it contains palette data and can be updated by a user with an EEPROM programmer. It is certainly possible that he uses a few bits in the EEPROM for the 2600RGB to remember palette selection across power loss. We'll see.

[Atari 2600 RGB mod]

Tim, I see you have the instructions up now (although only 4-switch. I'll need the 6) and I'm curious, is there an easy way to do this without wiring anything to your joystick connections? I'd really rather leave those alone and I have no intentions of adding any buttons to them. Thanks!

 

 

Darn, I have to wait another week and a half for the six switch kit. I guess it's been almost 38 years, I'll live.

 

Tim has said that the joystick features are optional. I don't intend to install them either.

 

But he didn't call out in the guide how he expects you to wire things up if you don't use the joystick mod. Hopefully he will update the guide with that info.

 

From looking at the wiring diagram I think you can simply skip all the wiring between the Extra pads and the left controller port. Instead you wire a push button switch between P and GND on the main pads.

 

I am a little worried about the use of a push button for palette selection here. The NESRGB used a multi-position switch to set the palette mode so the switch position dictated the palette. With a push button the 2600RGB will need to remember what palette it's on since it can't just query the switch position. Is this selection remembered after the console loses power? Does it have two independent memories, one for the current PAL palette and one for the NTSC?

 

Hopefully there's some non-volatile RAM in the mod that saves this info. It would be annoying to have to pick your palette every time you plugged your Atari in. Personally I'm not sure I want to even externalize the switch. I'd like to just pick the most faithful NTSC and PAL palettes once and leave the switch double stick taped to the inside of the console. That's what I did with my NES. No extra holes in my console. I suppose on the 2600 it does give you the pause feature so it might be worth externalizing. I'll have to think about it.

[Atari 2600 RGB mod]

Ah, so it gets input from both sides? CPU and TIA? That would make sense.

 

I think so, at least that's how the NESRGB works.

[Atari 2600 RGB mod]

I doubt he's emulating much of the TIA at all. He didn't replicate the PPU on the NES either. He's almost certainly still using the TIA for the actual video generation. What I think he is doing is two things :

 

1. Capturing all palette updates from the game. The game thinks it's talking to the TIA, but i's not.

2. He's feeding the TIA a custom palette e.g.

000 = BALL

001 = MISSLE1

010 = MISSLE 2

ETC.

 

He's driven by the output timing of the TIA and can determine exactly what's being displayed from the custom palette. He can determine what color it is supposed to be because he's intercepted the game's palette update register writes.

 

Again, I don't know this is exactly how it works, but he pulls off something similar on the NESRGB and it works well. Admittedly he did have a couple firmware updates to fix a couple bugs. The biggest game compatibility one was something where he wasn't fully masking of address bits to capture all PPU palette updates. Otherwise the NESRGB has been very compatible.

 

We'll see. Maybe this won't be that compatible but in principle I think it could be. The NESRGB does work well for me so I am taking a little bit on faith. I will try to order one and see how it works. I'm refreshing the website now. It's been the 31st in Australia for almost a full day now!

[Atari 2600 RGB mod]

I wonder how this works technically. Is there some kind of frame buffer involved? Or is it still racing the beam?

 

I highly doubt this is frame buffered. I installed Tim's NESRGB mod in my Nintendo and it definitely doesn't use a frame buffer. Tim claims "The video timing is unchanged". Certainly it is unchanged on the Nintendo.

 

The way the NESRGB works has been explained. It sits between the CPU and PPU (NES graphics chip). It intercepts palette writes destined for the PPU and remembers them. The NES PPU can be configured in a master mode to send information about the palette index it is currently displaying on 4 expansion pins as the video signal progresses across the scan line. To know exactly what palette index is being used you actually need a 5th bit indicating background or sprite that is not externalized from the PPU. This is where the NESRGB pulls a rabbit out of a hat; not only does it intercept palette writes and remember them but it changes them to color the sprites full white and background full black. A simple level test on the PPU's composite output allows the fifth bit to be extracted and the exact palette index for every pixel of the scan line to be determined. The sync signals are extracted directly from the PPU and as the beam races along the NESRGB generates a perfect RGB signal.

 

I have no inside knowledge about how Tim pulled off the TIA magic, but here's my guess... I don't see anything equivalent to the expansion pins on the TIA but on the TIA you have way fewer graphic entries to be addressed. Compared to 16 palette entries per sprite and 16 per background on the NES, you only have 5 separate graphics entities on the TIA. Unlike the NES which directly outputs composite from the PPU there are 3 luma pins from the TIA that are combined externally along with chroma to create the RF signal. 3 bits is enough to indicate which of the 5 TIA graphics elements is being displayed per pixel. One way this could work is that the RGB board intercepts the palette writes destined to the TIA and remembers them. It then feeds a special palette entry per graphics element to generate a unique binary pattern on the luma pins per graphic element. Then it synthesizes all this data to generate a perfect RGB signal. Again I have no idea how this mod really works, I'm just piecing together information based on Tim's hints so I could be off base here.

 

The NESRGB is really a brilliant mod and if something similar is coming to the 2600 I cannot be more excited. I have yet to find a video mod for the 2600 that I like. If this works half as well as the NESRGB we're in for something special here.