Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

BigO

Members
 View Profile  See their activity

  • Content Count

    4,669

  • Joined

  • Last visited

Posts posted by BigO

  5. Posted

    Tim Worthington has confirmed that the Trak Ball is incompatible with the RGB mod. A switch needs to be installed to deactivate the extra button. Can anyone do this mod for me?

    Does the CX80 have independent 7800 compatible buttons or something?

     

    I'm sure there are a lot of people who could do the mod. It's probably simple but we'd need additional information about the incompatibility in question (I don't know who Tim is so I can't reason it out from that info.

     

    You might narrow down the pool of potential fixers by giving your location.

     

    Edit: I looked at the above referenced schematic and don't see a reason that one of the fire buttons would be different from the other. So I must be missing or misunderstanding something.

     

    What/where is the extra button that must be disabled?

  7. Posted

    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."

    • Like 3

  8. Posted

    Hello guys

     

    But I still don't understand why a light pen or a light gun would work in one but not the other direction.

     

    Sincerely

     

    Mathy

    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. :)

  9. Posted

    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. :D

  12. Posted

    Thanks BigO,

    'Is not the sensor itself is a single element, one-dimensional device?' I assume so, that is why I asked for a take away part guide.

    'What was the failure mode?' We tested many different light pen programs, including Atari Graphics cart and that SALT 2.07 cart. All have that problem.

    'Did it appear to detect the exact same position all the time on the broken axis?' Yes!!! Totally forgot, thank you so much, it was frozen in the lower left corner! Good point!

    Have made a photo of the light pen head, please see below.

    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.

  13. Posted

    @BigO: $24.2 plus customs plus tax for overseas... will result in something like > $30... But the price is not the problem, but they why, especially for others. For the computers we have:

    Technical Reference Notes or Manuals, else Hardware Manual. But not for the light pen. :-( Would love to add this for the Wiki.

    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.

  15. Posted

    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.

  16. Posted

    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. ;)

  18. Posted

    I found this recording of the complete "harmony smurf" tape on youtube:

     

    [...]

    It uses a single audio frequency, so it reminds morse code more than FSK when you hear it...

    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. :)

    • Like 1

  19. Posted

    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.

    • Like 1

  21. Posted

    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...

    • Like 1

  22. Posted

    The cable connecting to the Atari doesn't carry audio signals.

    4 pins of the Atari controller port are used for the connection and 4 pins are needed on the Kid Vid side as well. To save costs, the case and mechanics of an existing tape deck was reused, so it made sense to repurpose those two existing connectors which, paired, provide the required pins.

     

    And while the tapes are in stereo, and the kid vid module has a stereo head, it's not designed to play stereophonic music and therefore doesn't need a stereo jack.

    The left channel of the kid vid tapes is not supposed to ever be played back as audio, but only to be sent to the Atari, after being converted to a digital signal.

    Only the right channel goes to the built-in speaker and to the (mono!) "earphone" jack.

     

    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).

  24. Posted

    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.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...