BigO

I'd probably epoxy the part back in place then, once cured, sand off any flash then epoxy a light gauge sheet metal mending plate across the break on the surface of the pillar to reinforce the repair. Then again, I follow the philosophy "if it's worth doing it's worth overdoing."

I'm with Mathy on this. As far as I know, a light pen doesn't know anything about direction or axis or the position of the detected pixel in any way. It sees light above a pre-established threshold of brightness and says "I see it!". It's up to the external hardware/software to know which pixel/position was being illuminated when the pen reported detection. I'm just making stuff up here, but my troubleshooting thought process is wanting me to think: It may have been detecting/reporting intermittently due to an electrical failure (bad cable) or failure in the active electronics. Or is mechanically out of spec such that it may have been detecting only when held at a very specific angle to the screen. Or maybe the brightness of the screen was just barely at the threshold of detection (possibly due to a defective sensor) so the illuminated pixel could sometimes be detected and sometimes not. It'll be interesting to see the ultimate outcome. This is how we learn.

Having no expertise in the matter, I tend to agree that it's broken. I still don't understand what was meant when it was said that it worked in one axis but not the other. That's what got my attention as I wanted to understand how the light pen could detect an axis in any way. Still interested in the outcome and hope that some documentation of it's design and/or functionality come out of this exercise. Never can tell when I might own one of these things. And if I own it, you can bet it was cheap enough that it's probably broken.

So, to recap, we're still not sure whether the light pen is broken or not.

"The Mind Boggles"...brain wave controlled dice based word game?

Hmm...frozen in the lower left corner does not equate in my mind to working in one axis. That sounds like working in no axes, possibly not detecting the light at all. Which would lend credence to the theory about the brightness of the screen. Or maybe the sensor became less sensitive due to optics or electronics. Maybe the sensor failed entirely. If you knew more about the electronics, you could probably build a static test harness fairly easily. Knowing the pinout of the device would probably be enough to give that a try.

Understood. If I had a use for a lightpen, I'd probably pick up that eBay one since I'm in the US. But, I wouldn't pay $30 either. I was searching around a little and found almost no useful information on the CX-75, so I respect what you're doing in terms of discovering and documenting. Too bad you can't pick up a working version for reference, though. I assume someone can or has disassembled/decompiled software to see exactly how it's reading from the pen in case there are any clues there. Good luck with your efforts.

You might also "fix" it by buying one for $7.95 on eBay. https://www.ebay.com/itm/Atari-CX-75-Light-Pen-800-XL-XE-No-Software-no-Manual/132876977520?hash=item1ef015c570:g:XtsAAOSwa1ZcBgjD

I'm curiously following this just because it runs contrary to the little knowledge I have of light pens and I expect that I'll learn more from the ultimate fix of this problem. As I understand it, the sensor in a light pen detects light of a given brightness or it does not. Only the driving host device knows how to interpret the position based on the timing of the light detection. Only the pixel being currently drawn should be bright enough to trigger the sensor. The light gun itself shouldn't have any clue where the pixel is that it just detected. So, I'm really curious how the light pen itself could be responsible for making one axis function but not the other. Is not the sensor itself is a single element, one-dimensional device? What was the failure mode? Did it appear to detect the exact same position all the time on the broken axis? Or did it appear to detect light at every position on the broken axis? Or did it appear to just be off by a few rows/columns in the broken axis? Would the mismatch in position change if you rotate the barrel of the light pen as though the input optics were not reading directly out in front of the sensor? Maybe the polling logic actually somehow/somewhy (<< should be a word) reads the sensor twice to determine X and Y position and a pulse for one of those reads is too short to activate a weak, failing component? I'm really just making stuff up here but am interested in seeing what the real reason turns out to be.

If the tape you mentioned earlier is in your possession, you might try ripping it to an MP3/WAV/whatever and posting it up. Somebody might run with it. Maybe somebody can identify the serial communication protocol. That might be enough to get somebody interested in pursuing an adapter or a solid state Kid Vid emulator. The hardware side should be doable if somebody wanted to build a solid state Kid Vid emulator. There are cheap MP3 modules and Arduinos out there. With those in hand, it's just a simple matter of programming.

Okay, a few seconds of listening to that and I totally understand TJ not wanting to listen to those tapes again.

Interesting. Conversion to a digital signal may be fairly easy. My first guess would be that the longer intervals are the beginning of a frame or the beginning of a message. Somebody who's good at disassembly can probably spot the detection of similar patterns being looked for by the code. Somebody with a Kid Vid, a digital storage Oscilloscope and a tape deck could lay up the digital signal out from the Kid Vid next to the audio track to see if there's a direct one-to-one correlation between "tone present" and a digital 1 or 0 from the Kid Vid digital output.. I wonder if the decoding could be as simple as amplifying and rectifying the signal with a filter capacitor to smooth the output. The output doesn't have to be ripple free and super clean. It just has to stay above and below the digital logic thresholds for the duration of a bit. Seems like a scheme like that would be appropriate to the time period. An op-amp comparator set up with an appropriately low reference voltage could probably crank out a 90% duty cycle square wave from a sine wave. Again, a little filtering to keep the signal from dipping too low in the "off" times might work. Hearing the "sound" of the KV digital output could tell how sophisticated the demodulation is. Just throwing out some thoughts that anyone is free to run with if they so choose. As ridiculous as it might be, I wouldn't put it past somebody around here to eventually do a homebrew Kid Vid compatible game.

A quick glance at the comments seems to confirm a typical serial data stream. That means, in my estimation, that the control track is translated to a pure digital signal outside of the console. Tracing the execution in Stella and counting cycles, one should be able to figure out the expected bit rate. Comparing that theoretical bit rate to the waveforms on the control track, it could be determined if the control data represents a one to one bit per signal change relationship. That would tell whether I'm right in guessing that it uses a simple FSK encoding of the data. I remember playing with a tool that could translate Supercharger audio to binary. (wav2bin?) Something like that with a means of tuning the bit rate could decipher the audio from the tapes if captured to wav files.

Cool.

Has anyone disassembled the ROM from the cartridge? That'd probably be informative. My initial thought was that the tape would only play one tone on that channel and that any data (such as "which game") would be interpreted from a serial data stream, not that a specific tone would represent a specific game. I don't think the Atari could sample fast enough to discern very many different frequencies. At most, I was thinking the control channel would play two different frequencies each explicitly representing a 1 bit or a 0 bit (FSK). The internal works of the Kid Vid would have a demodulator like a moDEM to translate the tones to digital. In that case, playing the tape in a normal deck, you'd hear "modem sounds" (providing you're old enough to know what that sounds like an young enough to still be able to hear). At the simplest, I thought tone or absence of tone might be used to represent 1/0. But, I'm just making wild guesses. For all I really know, there might be DTMF tones recorded on the control channel. Has the audio from both tracks been ripped and put on the internet somewhere? I didn't find it with a quick search. It's kind of an interesting subject, now that I've started thinking about it. Now I wish I hadn't flipped the Kid Vid that I just knew I'd never have any interest in playing with...

What "sound" comes off of the control channel of the tape? If it's a consistent tone, one might be able to simply feed it into a properly configured one-shot to generate a logic signal to feed into the console (dependent upon appropriate amplitude).

Do you know for sure that the console type matches the TV type? NTSC, PAL, etc? I haven't seen it in person but it seems like 50 vs 60 Hz could cause the horizontal hold issue visible in the pictures.

It shouldn't be too difficult to examine the signals from the console and verify by analyzing the disassembled code. I vaguely recall testing my KidVid with the ROMs on a harmony so I think the ROMs function in that environment. My bench is buried in other projects at the moment or I'd try to see what I can see.

Just another thought, polarity of the plug would likely be meaningful so I'd make sure that it was wired per the schematic (assuming the schematic has been proven correct).

I played Space Harrier more than anything and tried several others, but ultimately my one game turned out to be "Sell the SMS". The guy that played with me must have been impressed as he ended up with an SMS himself.

I've made a cable, but I had an actual Kid Vid to use it on so I never had to do a deep dive into the "how does it work?" issue. Looking at the cable schematic, it appears to be using pin 8 Ground for one of the pins. That could mean several things: The Atari is switching +5V on/off with respect to ground by leaving that second pin in output mode and alternating between HI and LO. The IO pin is being switched between input and output mode. If pulled LO when in output mode, that would apply 0V to both pins, possibly looking like a closed switch. When in input mode, it would be high impedance looking like an open switch. Something else that I'm not clever enough to reason out. I would test the output of the Atari by measuring the IO pin against both ground (controller pin 8 ) and +5V (pin 7) when the tape is supposed to be active and inactive. If you get no voltage from the IO pin with respect to pin 8 and no voltage with respect to pin 7 then you know that the IO pin is set to input mode, thus providing a high impedance (like an open switch). Otherwise, if the IO pin is in output mode, you'll get a voltage against one of those pins and you'll know it's just switching between HI and LO output states. It seems likely that whatever scheme was employed could be adapted with a transistor or something to drive a different type of tape recorder. If you can figure out what exactly the Atari is doing, you or somebody else should be able to use those signals to ultimately drive a simple SPST dry contact relay (using appropriate flyback diode and/or other means of isolation and protection). With that achieved, you would be able to drive nearly any of these tape decks with the "remote" switch no matter what scheme it employs to detect the switch condition. Have you measured for voltage across an open mechanical switch that's "remote" controlling your tape recorder? Maybe it is putting out a voltage and interrupting or passing it through to control the tape motor. This would be the other half of the equation needed to understand why it's not working when driven by the Atari. Have you looked at the internals of the jack that it plugs into? Plugging something into the jack may mechanically break the connection to the motor power. Or, it may be providing ground or something to a more sophisticated circuit. I gave away the last tape deck I had or I'd now be compelled to pop it open and figure out exactly how the remote function worked.

Once I saw it, I realized it must be a way around technical constraints and the Venetian Blinds effect did come to mind but I never really understood what it meant nor did I realize it was a "back in the day" thing. Now I know. And, yeah, I'll never be able to un-notice either. Probably will never be able to wrap the score again due to the distraction of the score display.

After umpteen years playing this game, tonight I finally noticed that characters in the score display are vertically offset from one another by a scanline.

I suppose it would depend on the jitter being observed. I can see how ripple that's not in sync with the sampling frequency could cause the paddle input to vary with no actual change in resistance, but I wouldn't expect it to amount to much. I haven't noticed that happening on the 2600. If you're seeing that on the 2600, I don't see much harm on trying it. I guess if there's substantial resistance between the power supply and the chip somewhere this could cause the TIA to power up too slowly, but that's a stretch. But, jitter on the 2600 is widely known to be caused by dirty or otherwise malfunctioning pots. I haven't seen anybody claim that addressing the pots didn't fix the jitter problem.