rmzalbar

I found the problem. The UAV diagram I copied in the other thread is wrong. If you used my post to wire, that would switch the Sync and LUM wires around incorrectly. The solder points on the UAV are silkscreened S, 0, 1, 2, 3 The correct routing is: Atari -- UAV CSYNC(Tia 2) S LUM0 (Tia 8) 1 LUM1 (TIA 5) 2 LUM2 (TIA 7) 3 UAV pin silkscreened 0 is unused for 2600 installs. Crossbow's photo of the UAV solder points has the correct routing. I deeply apologize for this mixup - and now I know why I miswired my own the first time around. Swap those wires around on the UAV and you should be good to go.

Your issue looks similar to one I had when I mistakenly swapped the Sync and one of the LUM wires from TIA to the UAV. Once I corrected this, everything looked excellent. What you are seeing is primarily weak horizontal sync, not vertical, although the vertical is affected too - it's the same signal. Explanation: A composite signal requires each component of the signal to be at certain voltage levels - such as the black level, the white level, and the sync pulse. The luminance levels (brightness for each pixel, shades of gray and color alike) are any voltage steps in between the black and white voltages. However, the Atari generates each component of the video as a 5v TTL signal, simple on or off. It then runs each one through a resistor divider to set its voltage to the correct level, then mixes them all together to get the composite. That's why there are three LUM signals - each one goes through a different voltage divider to get three different-sized "steps" and then TIA, by using them together in different binary combinations, can generate 8 different luminance levels (because the LUM signals add together.) The UAV has its own network of resistors that do this downmixing process directly from the signals on the TIA, bypassing the ones on the Atari. If you get the order of the wires wrong the sync pulse and luminance will be going into the wrong resistor networks, get set to the wrong voltage levels and you'll get weak sync and wrong-looking colors. Also make sure your color is the correct TIA wire too, that might cause the ghosting.

OK. This should do it. Let me know if you have questions or if your board seems different. Here's a connection diagram I stole from somewhere: Video from Atari to UAV Ignore the pins meant to plug into the CD4050. The wires from the Atari TIA get soldered to the corresponding jumper pins on the left half of the UAV. This is the video signal FROM the Atari TO the UAV. Remove all jumpers. You will be connecting the following 5 wires: SYNC - from TIA pin 2 to UAV jumper pin SYNC (see diagram below) LUM0 - to UAV jumper pin LUM0 (see diagram below) LUM1 - to UAV jumper pin LUM1 (see diagram below) LUM2 - to UAV jumper pin LUM2 (see diagram below) COLOR - to UAV COLOR IN - bottom-most pin of green jumper block (see diagram) Audio from Atari directly to RCA audio jacks Audio CAN come directly from TIA pins 12 or 13 - they're already bridged on the Atari. However, I picked it up from the other side of a capacitor that's already on the Atari, see my diagram. Taking it from this capacitor protects the TIA a bit better. I bridged the audio to both L and R jacks together. It's mono, but this way you get two jacks so you can have sound out of both sides of a stereo amplifier. Audio ground can be shared with the video ground from the UAV (I tied the grounds together for all of the jacks.) I didn't want to solder directly to the TIA, and I didn't have good access to underneath the board for my installation so I soldered the TIA wires instead to the component legs that each TIA pin is connected to. Here's a diagram of that: Power and GND to the UAV from the Atari I picked this off from two capacitors up near the player 1 joystick port. Power: The upper pin of capacitor C236 (see my photo,you can see the large power trace it connects to at the top) GND: The rightmost pin(s) of C228/229, which branches off the large grounding area for the shield. (see my photo) These both go to the two leftmost pads on the UAV, see diagram. This came out electrically clean, so I didn't need to split the pads for either power or GND or anything like that. Video OUT from the UAV to your rear panel jacks These connections all come from the upper 5 terminals on the green terminal block - see the diagram at top of post.

Question: Does your version of the UAV have jumper pins or just holes in that area?

It's open.. and photographed. Later I'll trace it out and come back with point-to-point instructions. OK I guess mine is a Rev 12, NTSC.. but no 4050. Anyway: I did all my work from the top so I could fit everything under the original shield. I notched the top side of the shield to run out the video/audio and drilled a hole in the PCB for them too. Note where I ran red and black wires to get clean power and GND for the UAV. I followed the traces from the TIA pins over to the resistors on the right, and tapped them at that point. This was just for aesthetic reasons so I didn't have to solder directly to the TIA. My version of the UAV doesn't have jumpers installed, but that doesn't matter, since I'm soldering directly to where the jumpers would connect to anyway. On the bottom of the PCB is just the saturation boost mod, a resistor and a capacitor, added back in at a point that doesn't interfere with the UAV. The saturation boost mod is optional and only affects RF so there's no point to installing it if you don't want it, or don't plan to use RF. You can ignore the copper tape, that was to help clean up the RF output when I installed the jack for coax.

Alright, well mine's later than a rev 12 because it has no 4050, which is the important thing. I'll open it up today if I can, tomorrow if I can't.

I did my rev 12 which is basically the same. It's been a few years, but I would be happy to open it up and show you what I did. Is yours PAL or NTSC?

I use wet baking soda to scour cart edge contacts with my fingers. It doesn't affect the gold plating and gets them shiny clean. It even makes NES and Intellivision carts work. Only useful if you can open the cart, though.

We also have all the justice money can buy. For better or worse

An emulator is illegal? A program that mimics the behavior of hardware without copying its design? Whaaat?

Schematic is here, it's a Jerzy Sobola one so very clear to read but may have some errors and this one looks a little bit incomplete in the composite mixing area. But compare it to the 800XL one and you should determine which components to lift so you don't have to cut. 800XLF (Freddie): https://systemembedded.eu/viewtopic.php?t=39 800XL: https://systemembedded.eu/viewtopic.php?t=38

Has anyone ever tried just picking off UAV video and sending it to the RF modulator? Doesn't that work? Rather than leaving the 4050 in.

There were people out there who would kill for this.. 😜

WELL. I figured this out. Mine is a 4-switch with no 4050 so I manually wired it. I had 3 wires swapped around, 2 luma and 1 sync! I don't know how I made a mistake like that, or why I didn't find it quickly. I must have been looking at an erroneous pinout or something of the sort back then, and I evidently didn't look at the signals live, but sure enough when I put the oscilloscope on the sync input I saw a luma pattern. D'oh!! The luma and sync are TTL signals that then go through different voltage dividers (on the Atari on the way to the modulator, but also on the UAV board in a similar way) to set their relative levels, so that 3 separate TTL luma signals can be mixed in binary fashion to make several luma levels and you get a proper sync level. They were going through the wrong resistor networks so they were at the wrong levels! The sync pulse was too small, causing unstable sync. On bright screens or games that flash the screen brightly, it would lose sync altogether.

I am disappointed. I wanted in on this class-action. I always want in on class actions, whatever they're about, really. I.. I like that.

I'm not a fan of Facebook's influence in the world, but I don't feel any particular emotions toward the platform itself. I use it in a very directly utilitarian way: I belong to the old computer groups and use it for that purpose only. I don't use it for anything else, my bookmark goes straight to the groups interface. No doomscrolling, no stalking friends, no anything except old computer nerds. I'm okay with it on that basis.

I just wanted to add my congratulations on a great port of this great game. I also want to say Thanks! for permitting it to run under NTSC. The PAL divide can be really brutal to us Americans at times.

The Last Ninja series had some very nice pixel art and a banger of a soundtrack (on the C64 at least) but the playability was.. not good. I've seen this to be a thing with European gaming tastes in general during that era; style above substance, and if style is all you have we'll just take it anyway. Compare nearly any US publishers (Accolade, Activision, Epyx, DataSoft, Electronic Arts, Microprose, Synapse, Broderbund, HesWare, SSI, Origin, Sierra, Muse, Lucasfilm, Infocom, Mindscape, etc.. ..and people ask why I don't convert all my machines to PAL..?) who consistently turned out quality, QUALITY titles against, well, just about everything else. It's a real shame, because I would love to see a fusion of talents, east and west, in an alternate universe. At least we seem to be getting that with homebrew and smallscale retro releases these days! Somehow, the ZX Spectrum seemed to have largely avoided these issues, probably because playability was much easier to get on that system than shiny glitter. The ZX is my favorite eurogaming experience.

I have a 600XL, an 800XL and a 1200XL, and ended up being very fortunate that all three of them were fully socketed, and on top of that the 600XL(AWC) and 800XL(Alps) both had mechanical keyboards. Not a hint of trouble with any of them, and only had one bad key.. and it was just a cracked solder joint. Atari built them good enough. The 1200XL of course needed a keyboard matrix refresh.

That's exactly how Ghostbusters copy protection works: There's an intentional error on one of the tracks that the game checks for while loading. Disk copy programs wouldn't copy the error, so the copies would refuse to load. The disk drive responds to an error with a track zero seek - that's the noise you hear. It's harmless for nearly all drives (some really early model 1541 drive were known to get bumped out of alignment over time.) This was common only in the earliest days of copy protection; disk copy tools could soon reproduce those errors properly while copying, and so the game publishers had to move on to more sophisticated methods that didn't cause read errors. I have a copy of Ghostbusters that runs correctly on both PAL and NTSC machines, and has that protection patched out. It's a combination of a specific original disk image with a Maverick parameter applied. Could provide .G64 of it but you'd need some way to remaster it to a disk, such as a Zoomfloppy setup. Another early Activision title I have that does the head bump-o-rama: Zone Ranger.

What happens if you have an XL and accidentally set this? Can you recover from that or is it JTAG time?

I would just like to thank Phaeron for creating a8rawconv. I just used it for the first time to write an image back to a real disk, a copy-protected Fort Apocalypse atx, with SCP hardware and a 96-tpi drive. Boots up on my real Atari just fine (once I set the 1050 to unHappy.) Is it an impractical way to load Fort Apocalyse? Definitely. Do I love putting the disk in the drive, powering on, and listening to it boot up just like I did 35 years ago? YOU BET!!

Not long after COVID hit, I had to put everything in storage and move into a tiny place. Nearly all of my fun projects got shelved. I recently took my Atari crates out though so I may get to it soon. I think when I last looked at it, I found the logic for the original happy wasn't accessible in the Atarimax setup and that I possibly couldn't do better than Binarygeek, but I hadn't written it off yet.

Very nice 600XL. I acquired one early in the year, and finally got around to giving it a similar treatment over the last week. Yours came out very clean, I was never confident enough to touch the aluminum on any of mine. Mine has the same AWC keyboard - it's pretty decent, doesn't block if you hit the keys off-center the way the ALPS keyboard on my 800XL somewhat does. Mine had a cracked solder joint on the "M" key. I've been fortunate that the two XL machines I got both happened to come with mechanical keyboards The keys just work and no worries about membranes, but I shudder to think what I'll do if any of the switches ever need to be replaced. I game mine the U1MB and the Super Video 2.1 treatment. I used FJCs 3-wire 64k mod instead of the Lotharek one. I removed the battery holder from the underside of the U1MB to allow me to mount it about 5mm closer to the motherboard to take some pressure off the keyboard ribbon. I intend to modify and reinstall the shield again at a later point.

Looks like after Super Video 2.1, the chroma and luma communicate through a three-component series of 75R, .001uf, 75R, combo. The capacitor and resistor form an RC filter and probably filters (I suppose) the luma out of the chroma. Worth a try? This is from 800XL SV 2.1 (the pre-Super Video schematic also showed that series to combine the luma and chroma, but of course there's no chroma to pin 5.) Also note the composite-disable switch I mentioned in that string. You likely won't have 75R resistors, but you can just use a single 150R and capacitor in series. The only reason for the order of the three is to set the composite output impedance, which is in the middle of the series, to 75 ohms.