collinp

I'm surprised there's been no activity on this thread since November. In my opinion this is the best 2600 video mod ever. Though compatibility in RGB mode through the XRGB-mini is not 100%, it is very close. There are only a handful of games that have strange timings and don't work well. Warlords is the most popular and there is already a patched version to address the issue. Others have reported no issues with RGB TVs and other converters so this looks like an XRGB-mini issue where it does not handle certain non-standard timings well. The video timings for 2600 games are generated by the game code itself so it's not surprising that some are a little out of spec. I just tried the brand new 2.0.2 XRGB-mini firmware and there seems to be no difference in ROM compatibility in RGB mode. My older retro-console pipeline is an XRGB-3 connected through a Lumagen video processor. Currently that's how I have the Atari wired in. I have seen no issues there even with the original Warlords ROM. In S-video mode this mod has been 100% compatible through the XRGB-mini for me. Though timings are preserved, the video signal is completely regenerated and it's crisp and beautiful. Three color palettes are selectable and those palettes can in theory be customized through the EEPROM on the mod if the palettes are not to your liking. Even if you only use this for an s-video mod I think this is the best 2600 s-video mod and I've tried a bunch of them.

Hi Tim - Your site states that "Palettes may be modified by the user (requires a serial EEPROM programmer)." Are you planning to release any more information on the ROM format so we can try custom palettes? Thanks.

Ooh, you've got a non-socketed TIA. That's pretty rare. Desoldering a 40 pin chip with just a wick or hand pump is challenging. If you've got a Hakko desoldering iron on order just wait for that to arrive. A proper desoldering iron can make the job shockingly easy. I haven't used the Hakko but I have used other brands and they make desoldering a breeze.

I've had the RGB mod installed for about a month now and played a lot of ROMs on it. The only two I've encountered issues with on the RGB input on XRGB-mini are Aquaventure and Warlords. I'm sure there are more ROMs with odd timings to be discovered, but it's definitely a minority. The XRGB-mini is much more robust at handling these ROMs with odd timings on s-video and composite so you can always use those inputs as a fallback.

Or composite/s-video is too bright. But actually I think the deltas are due to the XRGB-mini. The calibration controls on the XRGB are not great, with no real contrast control. I could pull down black level to be accurate and white level would come down at the same time, but I couldn't adjust white level separate from black level. This is about as close as you can reasonably expect an XRGB-mini to be but a better processor might do, well, better. I agree that s-video is quite a viable option with 2600RGB. It's reasonably sharp and bright. It's so much better than any other s-video mod I've tried. It's also very compatible with the XRGB-mini across a variety of games. As you can see from other posts from me about Warlords the XRGB-mini's RGB input is more sensitive to odd video timings than it's s-video input.

I think things got a bit delayed because of the "startup bug". I just got my 2600RGB board with the fix in the mail today. So fixed boards are hitting US shores. Perhaps that's good news for the US distributor? Who knows. As pleasant surprise I also received my 2600RGB kit for the Sixer. Tim, is the Sixer installation guide going to be posted soon? I can probably figure it out, but the 4 switch had some subtlties like laying down some components that might have left me guessing without a guide.

Nice highlighting! .s files will get some generic assembly highlighting by default but nothing quite so fancy as what you've done. In theory more sophisticated highlighting is possible using xclangspec files though I haven't given it a shot. Xcode is a very purpose built IDE focused on iOS and Mac development so it's extensibility is not the greatest. Well, at its core it's clearly very extensible, but much of that functionality is buried deep in system files and often undocumented. I spend a lot of time in Xcode so it's nice to have my Atari experiments use a familiar IDE. It's also a free IDE which may be appealing to newcomers. I would guess those with established workflows will probably want to stick with what they've got. - Collin

Once upon a time there was a Mac OS X Xcode template for VCS development. Unfortunately time seems to have passed the VCS templates by. I couldn't even check them out. They are behind broken links and reportedly don't work with modern Xcode releases anyway. So I made a new template. The goal is to streamline my experimentation with 2600 programming, but it could be useful for others so I thought I'd share it here. I make no guarantees about how well it will work on your particular setup or any promises that I will update it in the future. Contents The template generates a simple project containing : main.s The main assembly file. Any additional files should be incorporated into main.s through include statements. This is the only file that is passed to dasm. The main.s default code is based on Andrew Davie's "Our First Kernel" though somewhat cleaned up with loops instead of repeated statements. It should give a solid blue screen when run. dasm, vcs.h and macro.h These files are embedded in the template and will be copied into any projects generated with this template. Any globally installed dasm or include files will be ignored in favor of these project specific ones. I like this approach because all the files necessary to generate the binary are embedded in the project. If I want to move this to another machine or build it years from now I do not have to recreate the build environment to make it work. Other's may want to use their globally installed dasm and in that case it shouldn't be too hard to hack the makefile. Makefile A dead simple makefile to kick off dasm. It will use your standard Xcode settings for project name and build location. The Xcode build destination is by default deep inside ~/Library/Developer/Xcode/DerivedData/ Considering that directory is hidden by default it seems like a weird place to put builds. I usually change my build destination to something more accessible and the makefile will honor those settings. Usage Unzip the archive and put the whole Atari folder into ~/Library/Developer/Xcode/Templates/ If you are using the GUI hold down the option key when opening the Go menu and a "Library" option will appear allowing you to access the Library folder. Now you can chose the Atari VCS template when you create a new project in Xcode. There doesn't seem to be a way to configure schemes through project templates so one more step is necessary if you want to auto launch your ROM in Stella. Choose menu : Product -> Scheme -> Edit Scheme... Select Run item from list on the left In the Info tab's Executable popup menu choose Other... Navigate to the Stella app and choose it In the Arguments tab add an argument with the value including the quotes of "$(BUILT_PRODUCTS_DIR)/$(PRODUCT_NAME).bin" Once you have setup Stella as the executable you can build and run from within the Xcode GUI and Stella will be launched with your changes. I have used this template a bunch on Xcode 6. In brief testing it does appear to be compatible with Xcode 7 as well. Even if this template doesn't create projects exactly how you wish, hopefully it will still be valuable as a starting point to configure Xcode as desired for VCS development. Atari.zip

The 2600RGB mod has a pause mod built right in. No additional mod necessary. It's disabled by default but if you hold the palette switch down for 30 seconds you can enable it. Then a brief tap on the palette button pauses or un-pauses the 2600. The 2600RGB remembers if the pause feature enabled even if power is lost. Note that all pause mods cause the video signal to drop since the game is what is generating the video timing and it's been paused. The video signal will resume after the game us un-paused. If you are using a CRT the signal should recover quickly, but if you are using something like the XRGB-mini the signal may take a second or two to re-sink and by that time you may be dead!

I calibrated the s-video / composite input on the XRGB-mini the best I could. Strangely it doesn't appear to have a contrast control, but I got it pretty close to correct with patterns from a DVD player. Here are some comparison shots with the XRGB calibrated. These are all with Palette setting #1 which looks a lot like the Stella emulator "Standard" palette. 2600RGB - Composite 2600RGB - S-Video 2600RGB - RGB

There are 3 palettes. #1 I would call natural, #2 I would call vibrant, #3 I would call garish. I prefer #1 and honestly don't see myself having a big desire to change it. I can definitely imagine that some people will like #2 because the colors pop more. I'm kind of confused as to what #3 is for as I've yet to see anything that looks right with it. The palette switch can also be used to pause the Atari. Like all Atari pause mods the console does not generate a valid video signal when paused. I'm using an XRGB-mini and it takes a couple seconds to resync the video on unpause. Since most Atari games are action oriented those several seconds can be critical. As such I don't see myself using the pause mode very often either. Those with CRT TVs may find it much more useful. I've got a Sixer with an s-video mod that I plan to swap out for a 2600RGB. That console doesn't have a channel switch and I'm loath to drill holes for a switch. I will likely not externalize the palette switch on that install. I think it will be fine. I did not externalize the palette switch on my NES either and I'm happy with that decision. The back of this Vader may be a little underwhelming. I just swapped the mini-DIN 8 for the RF cable. I just added some leads for audio since there are no pins for audio on Tim's mini-DIN 8 board. Audio seems good enough for me over the mini-DIN 8. If I crank the AV system I can definitely hear some noise, but I can hear noise even with the separate audio jack that Tim includes with the kit. The Atari wasn't exactly designed for audiophiles. There may be slightly more noise in the mini-DIN 8 cable than the separate audio jack but they're pretty close. At normal listening levels the noise floor seems fine. I have a longer mini-DIN 8 cable that I was thinking would be a good replacement for the RF cable as it is a similar ~12 foot length. That cable definitely exhibits noticeably more noise. The noise is clear at lower volume levels than the shorter cable, but those volume levels are still higher than I'd want to play Atari on so it might still be an option. Since I've found a few ROMs who's video timings don't play nicely with the XRGB-mini's RGB input I have been exploring installing a Nintendo multi-AV connector so I have the option to choose s-video, composite, or RGB all from the same port. Currently I have the mult-AV wired up but not mounted. I'm just using the Atari with the top off and accessing the connector that way. It's a convenient way to compare game behavior on RGB vs. S-video. I haven't decided what I'm going to do with this Vader. It might get the Nintendo connector. I really don't want to drill holes in the Sixer so I'm almost certainly going with a mini-DIN 8 tethered cable there.

Works like a champ. Thanks.

jarreboum's post got me thinking that it would be nice to use the channel switch for a palette switch. I don't intend to use RF again and the switch will be just sitting there unused on a 4 switcher. After some searching I found a momentary switch that is a near perfect replacement for the normal dual throw channel switch. C&K Components L112022ML04Q Available from Mouser here : http://www.mouser.com/ProductDetail/CK-Components/L112022ML04Q/?qs=%2fha2pyFaduiTtMo24X4GBTvNpiYC5gPBTBmqwgkiexxVfRTku62AKw%3d%3d Here is photo comparing the momentary switch on the left with a standard Atari dual throw switch on the right. Below is some information on how I installed the switch in my system. *** I am not responsible if you kill your console with this information. *** When the switch is installed on the board the default position is to the right (Channel 3). This connects +5V to the center pole. Pushing the switch to the left connects the center pole to ground and then it springs back to the right position. The ground connection is fortunately exactly what we want for palette selection, but we need to do something about the 5V. Cutting off the pin on the switch which connects to 5V is not a solution. I sacrificed a switch so you don't have to. With just two pins holding the switch on the board it can twist fairly easily when you push it. With all 3 pins soldered down the switch has a very solid feel. I thought about putting a diode on the center pole so 5V can't flow into the 2600RGB palette switch, but I felt more secure cutting the 5V connection to the switch entirely. The copper is quite wide and thick for this trace. Unlike cutting traces on later systems an X-acto Knife wasn't cutting it, so I used a small Dremel sanding bit to disconnect the trace. The center pole connects to the RF circuit for channel selection. I removed the connection to the RF circuit and used the through-hole on the board to mount an angled pin connector which is connected to the "P" pin on the 2600RGB. Though I don't intend to use it I decide to fix the RF circuit that I just broke. You can either tie the pin removed to ground on the RF can for channel 2 or tie it to the resistor that the 5V rail terminates at for channel 3. I chose channel 3 since that is the default switch position. Note the wire from the vertical RF board to the pink resistor in the photo below. Final install photos. It looks factory to me. I'll remove the unnecessary jumper wires eventually. I'm still experimenting with the AV connections.

I'm thinking this is an XRGB-mini issue because it does not happen on a BVM with an RGB signal and it does not happen with the 2600RGB's s-video or composite through the XRGB-mini. But who know you may be right it could be a 2600RGB bug. I see no problems with Gangster Alley, Missile Command, Dodge 'em, Holey Moley, or Tempest (prototype). I did find another ROM that's not too happy with RGB. Aquaventure (prototype). Over RGB to the XRGB it displays an image but has a lot of vertical shaking. It also has no problems over s-video on the XRGB-mini.

I tried Joust and have seen no issues when cycling back to the title screen. I tried Empire Strikes Back and had no issue after destroying an AT-AT I tried various XRGB-mini settings with Warlords. The best combo I can find is to set Sync Time to 100 and Sync Mode to Off. I believe Sync Time 100 is setting a long time before the XRGB decides it's lost input lock and Sync Mode Off is decoupling the input and output frame rate. With this combo the Warlords image stays on the screen, but hops up or down a scanline every few seconds. It's certainly playable but not perfect. It's pretty clear at this point that this is not a 2600RGB issue. If anything this proves how faithful the 2600RGB is to the original video timings. This appears to be a game with unusual timing characteristics that the XRGB-mini doesn't tolerate well over RGB. I am curious if other games like this will be found.

I absolutely agree. That is assuming we can find an XRGB setting that fixes the issues. I like Warlords quite a bit so I'm grateful for a hack in the meantime. Plus the hack gives some insight into what the XRGB doesn't like. Maybe this is the setting we're looking for. I'll try it this weekend. If it's easy. It's possible we'll find a setting to make the original game work and I wouldn't want you to waste your time. Medieval Mayhem is a pretty impressive piece of work. Hard to believe we're still able to push the Atari even further than they did in the 80s.

Oh nice. That appears to fix it. Thanks. I guess the XRGB-mini isn't quite as tolerant to incorrect timing as a CRT. If you manage to fix the king position I for one would be happy. I wonder how many other Atari titles will be discovered with other video timing errors that the XRGB-mini doesn't like on RGB. Thanks again.

I tried a higher sync level and lower sync level relative to the default, but I have not tried sweeping over the whole sync range yet. I will try the whole range, maybe this evening. I have to stop the game to get the xrgb menus back so it's a bit of a slow process.

Has anyone tried Warlords? I'm having some trouble with Warlords via RGB to an XRGB-mini. I can sometimes see a stable image but then the screen goes black after a few seconds and stays that way. This is using either a Harmony or the original cart. It works fine via composite or s-video from the 2600RGB so this may be an XRGB-mini issue. Hopefully this is a setting I can tweak on the XRGB, but so far I haven't found anything that works. All other games I've tried work great and look absolutely fabulous though.

FYI - I noticed the mod for the Atari six-switch is available for order.

If doing this sort of install sounds fun I'm sure you can learn to solder and do it yourself. I'd recommend starting with some hobby kits or something a little less challenging to get your bearings. I would consider this an intermediate project. Soldering the sockets and pin headers isn't too bad with a good iron. A few things need to be desoldered which is easy with a proper desoldering iron, but can be a challenge with hand pumps or solder wicks. Two items need to be laid down on their sides which involves desoldering then re-soldering with little pieces of wire for leg extensions to put things in the right place. This doesn't have the benefit of being held in place by a through-hole and I think might challenging for a beginner. Alternately if you just want this mod in your Atari there are installers you can pay to do it. I think the thread originator is an installer. Also it's probably more cost effective to pay an installer than buy a good iron if you are unlikely to ever solder again.

What that looks like to me is a deinterlacer gaining and losing lock. It may be the particular deinterlacer mode on the xrgb-mini he was using. We'll have to see with more testing. Overall these screen shots look great. I'm most surprised by the brightness delta between s-video/composite and RGB. I'm pretty certain my NESRGB doesn't do that. I wonder if it's an xrgb-mini setting too, though darcagn did state he did a settings reset on the xrgb. Since we've got a way to jump start the "startup bug" boards, I may have to install mine and join the fun.

And my 2600RGB kit showed up today. I ordered August 1st, it shipped on August 4th and was delivered to me in the US on August 17th. However, this unit has a startup bug and a replacement was supposedly shipped on 14th. Another two weeks to wait. I may try installing this one until the fixed unit arrives. I was planning on using pin headers anyway so swapping it out should be easy. I wish there were more details on the "startup bug". I would guess the issue is intermittent since it wasn't caught until after shipping. If it's just that the 2600RGB occasionally doesn't initialize properly on power up and you need to restart the console to get it going, I could live with that temporarily.

In addition to what darcagn said, I would add that many sets have trouble with 240p signals over composite or s-video too. Composite and S-video are a bit more likely to show a picture than component but the TV is likely to treat it as 480i and make a mess of it. It's one of the challenges to hooking up any old game console to a modern digital TV. This site covers 240p pretty extensively and reviews pretty much every scaler on the market for 240p performance. http://retrogaming.hazard-city.de Scroll down to "A Few Basic Definitions" for an overview.

The 2600RGB can output s-video or composite as well as RGB. It can also do component with a small add-on board. I'd consider installing one of these even if I was only looking for s-video or composite. Most Atari video mods are dark and undersaturated. This page is quite old but it gives you a flavor for what you can expect from most mods http://www.cheeptech.com/2600mods/2600mods.shtml The 2600RGB on the other hand will regenerate much of the video signal from scratch and the result should be impressive. The NESRGB is a very similar design particularly in the output stages and it's s-video out is really, really good. RGB is better of course but s-video is closer than you might think. As darcagn said a few posts up about the RGB output "you can basically expect the output to look crystal clear and perfect just like an emulator would" With S-video it will be a little less clear with a little more color smearing, but overall a similar effect. Also be aware that classic consoles output 240p even after video mods. Many modern TVs can't handle that signal despite having the right connectors. You may need some sort of converter box. A popular one is the xrgb-mini. It is nice though a bit pricey.