x=usr(1536)

Last weekend, I picked up another CX53 trak-ball in reasonably decent shape. Going into it, I knew that it would need bearings, so I ordered Console5's Atari 2600 / 5200 CX22 / CX53 Trak-Ball Service Kit. This is a kit that I've used before for both the CX22 and CX53, so am familiar with both the kit and innards of the respective trak-balls. The 'new' trak-ball was opened up this evening to give it a thorough cleaning in anticipation of parts arriving in the next day or two. As part of this process, I ran across something interesting: Atari evidently used two different roller shaft styles at different points in the trak-ball's life. Looking at Console5's wiki entry on replacing the X/Y roller shaft bearings, they show a photo of of the encoder wheel being attached to a notched shaft and held in place by three plastic tabs on the encoder wheel itself. This is how one of my CX53s is configured. However, the one I acquired this past weekend has straight roller shafts ending in a splined surface, with the encoder wheel having a solid plastic collar that presses directly onto the splined shaft end. Solid-collar encoder wheel: View through the encoder wheel's mounting hole: Splined roller shaft: Close-up of the splined end: The reason that I mention all of this is largely because documentation of it elsewhere wasn't cropping up. FWIW, I don't expect bearing fitment to be an issue, but this could impact someone's plans to fit new encoder wheels depending on the type of shaft in use. My guess is that this is something that changed in the production run and may have been a swapout if a unit was brought in for service. For reference, the unit with the splined shafts has a 4-digit serial number and was made in the 19th week of 1983; the unit with the notched shafts has a serial number in the 10,000s and was manufactured in the 31st week of 1983. As for removing the encoder wheel: the entire assembly was placed in a bench vise with the back of the encoder wheel flat against the top of the vise. A small hammer and flathead screwdriver were used to gently tap the shaft out of the encoder wheel, which worked perfectly.

I wonder if the seller has purchased shares in the manufacturer of Armor-All.

IIRC, this is essentially how the basic composite mods consisting of one transistor and two resistors work. They pick off the internal composite, amplify it, and output it. It works, but there are better-quality options.

It appears as though you're confusing two different (and incompatible) display output methods with each other. The output that you're referring to is RF (TV); it can't act as a composite output without modification. This is not compatible with a device that has composite input - you must connect it to a TV's RF (antenna) input to get a picture and audio. The 600XL's RF output is RF only, not both. One thing to be aware of: without modification, you will not be able to connect the machine to a monitor via (S)VGA. The A8 doesn't generate RGB signals, which is what the (S)VGA monitor will expect. If connecting to an LCD, the Sophia may be an option for you. However, that will output DVI, so you'll need to add a DVI-to-SVGA adapter into the mix. It won't look great. Bear in mind that the 600XL is generating composite video internally before sending it to the RF modulator to be displayed on a TV. Adding in the demodulator (the device that you're talking about) will turn the RF back into composite. Each time a conversion (Composite to RF, RF back to composite) is performed, some of the picture signal ends up not being where it needs to be to provide a sharp image. The resulting image is typically soft, with indistinct colour separation. Slightly marshmallowy is the best that I can describe it, which is extremely subjective (though not inaccurate). You'll need to decide for yourself how much of it you're willing to tolerate. That cable isn't converting anything; it's just breaking out certain signals onto the RCA and S-Video connectors. It won't help with your situation. Unless you're willing to commit to modifying the machine by installing a monitor jack and UAV or similar, your only realistic option is to make the TV usable based on what you've described as being available to you. Option two is to connect the 600XL to the RF input of a VCR and use the VCR's composite or S-Video output to connect it to a compatible display. This is functionally-equivalent to going the demodulator route you were talking about earlier, though results may be better (or not) through a VCR than with a Chinese converter.

As long as the marketplace keeps rewarding them by buying everything they crank out, they'll keep cranking out crap. Crap sells. It's as simple as that.

3) Tacos

If it sells, why should they care? As long as there are people out there who will buy anything with an Atari logo slapped on it, there's no incentive to make a product that's actually halfway decent.

All of which makes sense. FWIW, the expectation isn't so much that it would generate the absolute best video output, but rather that it would give really good video that's consistently reproducible from device to device. Still, points taken, especially re: finding a device using the chip in order to get a feel for the video quality. This is pretty much my thinking: it would be fairly close to the UAV or Spectre in terms of internal modification, but with HDMI output. Where its value looks to be is in the possibility of a single-board internal HDMI solution as well as making the need for Y/C or Composite signals generated from a separate board entirely optional (in an A8, at least). One thing I'll note is that while I didn't poke around extensively, I wasn't having much luck finding anything equivalent in the single-chip-solution department. There is one chip (Panasonic MN864729) used in some versions of the PS4 that may be an option, but given that it went into a Sony product the datasheet isn't really floating around so can't confirm that.

Nifty! Just to be clear: the adapter you're referring to is this one, correct?

While looking into ICs for something unrelated, I ran across the Analog Devices ADV7850 (datasheet attached). This chip looks to have been primarily designed with switching multiple inputs to a single output in mind, but has features that may be of interest for A8 video output. The chip has inputs for both Y/C (luma / chroma, aka S-Video) and composite video as well as audio. Digital encoding of the analogue signals is performed on the chip itself with no preprocessing needed provided that signal levels are within the spec the chip expects. This has me wondering if it couldn't be used in conjunction with the A8's existing Y/C output (or Y/C from a UAV or similar) to provide onboard HDMI output. This could conceivably make it a single-board solution, similar to the UAV. In machines without on-board Y/C signals (2600, 5200, 7800) either their existing composite signals could be used (it has a comb filter to separate Y/C from a composite signal), or this IC could be daisy-chained with a UAV in order to pull Y/C directly to it. Not going to be building a prototype anytime soon that uses this, but am interested to hear any thoughts on the subject. ADV7850.pdf

True, and I don't disagree with you. Where I see the distinction with Atari, though, is that the 1400 and 1450 were meant to be on the market while the 1030 was also being sold. If the 1400 and 1450 had internal 300-baud modems as planned and the 1030 was a 1200-baud device, all that the 1030 would really do is make the 1400 and 1450 look to contain an obsolete modem. Also agreed, though I think that voice could have been included with less difficulty as Atari wasn't also manufacturing a voice synthesis peripheral at the same time. Definitely agreed on the internal modem, though, or that it would need to somehow be upgradable at some point.

Market research indicates that people who repeatedly spend money on things like this enjoy being kicked in the nuts. Atari's just making sure that they get their money's worth.

Which brings up a good point: having a 1200-baud (or higher) modem on sale while also selling the 1400 / 1450 would have created a situation where the modem in the computer would have been seen as obsolete compared to its peripheral equivalent. Atari was more than capable of making dumb decisions, but even that one would have been too obvious for them to gloss over.

Don't believe that that should make a difference; PAL channel width was 8MHz regardless of whether it was transmitted on UHF or VHF. In any event, the OP's machine is NTSC, which output on NTSC VHF channels 2 or 3 depending on which one was selected.

Wait... I thought time machines were for going back in time and killing Hitler.

To be fair, it's not just XEs that this happens to - I've also seen it happen on XLs, both stock and modified. My 600XL with an internal 64K upgrade (41464s with a 100ns refresh rate, IIRC) is particularly touchy in this regard, but I've also seen it affect both the 800XL and 1200XL with stock RAM. All of the machines showing this behaviour that I've described above are using the stock mask ROMs. As you point out, EPROM shouldn't be a factor.

Funnily enough, I have exactly that sitting half-built on the table right now Other projects (and having a couple of other ways to play 2600 games) have kinda back-burnered it, though.

Posting this here because although it involves comparison with the Concerto, the behaviour I'm seeing seems to be Harmony-related. This is on a Harmony Encore used with a UAV-modded 2600 Jr. Take a look at the following post and the one right after it: I realise that this is software that's in development and the author doesn't have real hardware to test on. However, his game has consistently crashed on the Harmony Encore in recent builds but not on the Concerto. My Concerto is running specialised firmware used for testing CEM compatibility, so it's not 100% the same as what is out in the wild at present. Just reporting this because it's one of the few cases I can remember where compatibility between the two machines was markedly different.

I think I may have misunderstood part of the gameplay mechanics. Eating a fruit starts the timer that counts down to when it disappears. However, it also appears to close off the vertical tunnels and open the horizontal ones for the duration of the timer. Once it hits zero, the fruit disappears and tunnels revert. Is this how it should behave? If so, my earlier comment that the side tunnels were broken is invalidated. Concerto testing: Build functionality is much improved over the previous one. Only crash (black screen) was in the DPC version, right after the start music. All three versions have the jumpy screen bug (known, but figured I'd confirm it for all three). Harmony Encore testing: Javatari version crashes right after the start music. Displays the 'PACMAN MAP' screen with what looks like a corrupt Pac-Man in the centre box. Multisprite has the same crash as Javatari. DPC version displays same crash as when run in the Concerto. Have to say, it's definitely shaping up. Looking forward to the more complex mazes of the DPC version.

It's enough of a passthrough device that the video and audio passing through the 5200 take their own paths to the RF modulator completely outside of the video circuitry used by the 5200. There are a number of misconceptions floating around about that particular device; I certainly had my own at one point. But it is literally a 4-port with no Colour / B&W switch using the 5200 as an RF modulator and PSU. (Not aimed specifically at you, @Rybags - just mentioning how non-interactive with the 5200 the CX55 actually is for anyone wondering.)

Given the context, it's probably derived from the slang term 'Armageddon Dildos'. First paragraph for the answer.

Never mind the thread title, here's the Sex Pistols:

Speaking strictly for myself: it's Windows-only. This is fine, but makes it difficult to recommend given that I've used it very little as a result. FWIW, I recommended Atari800 based on experiences with Atari800MacX. While I've used both, I've used the latter far more extensively - but in the case of the former, more than Altirra. Altirra is a damned good emulator, however. Won't debate that for a second.

For Windows, take a look at Atari800. Supports pretty much every A8-variant machine (including the 5200) extremely well. On macOS, Atari800MacX is equivalent, being a port of the Windows version. This is the one I use and can absolutely recommend it.

How? It's basically a 4-port 2600. It uses the 5200 for power and display, but doesn't use any of the 5200's ICs. Neither one can communicate with the other - at least, not without significant modification.