Jump to content

mellis

Members
  • Content Count

    320
  • Joined

  • Last visited

Everything posted by mellis

  1. You have done a thorough job troubleshooting so far. This reminds me of a troubleshooting session I had with a malfunctioning Roomba (yes, the robotic vacuum). After extensive troubleshooting, I decided that there had to be some undetectable conductive material messing with the logic. Figuring I had nothing to lose as the board was going to be trash anyway, I ran it through a dishwasher cycle. Here's exactly what I did: 1. Emptied the dishwasher 2. Loaded just the circuit board into the top rack (glassware rack) 3. Ran a no-heat-dry cycle with normal detergent After the cycle, I bathed the board in isopropyl alcohol to displace any water. I then let the board air dry for two days. After all of that, I have the Roomba working flawlessly. I am not promising this will work for you, but being as the board was filthy, it might be the only way to eliminate the hidden conductive material. Good luck!
  2. If you are prepared to trash the bottom case anyway, you might try filling the screw holes with glue, let the glue set, and then re-drill pilot holes for the screws. That *might* fix it, and it sounds like you have nothing to lose if you're pitching the case anyway. Let the glue set for at least 24 hours.
  3. PDF is not too bad - it is a subset of PostScript, which is text-based page definition language. The Atari should be perfectly capable of generating useful output. It would be way more challenging if the Atari had to generate raster-based output for today's high resolution printers.
  4. Thankfully, AirPrint (called ePrint by HP) standardizes wireless printing these days. Most modern printers support it, and it is the way by which mobile devices print.
  5. Do not fry your 800XL by using the Commodore power supply. They are NOT compatible.
  6. The crux of the problem is that, for the Mac port, SDL v1's audio is based on Carbon Audio Units. I suppose some effort could be expended to back port the audio code from SDL v2 (which uses CoreAudio) to SDL v1, as SDL v2's audio API is compatible with SDL v1. In doing so, a new SDL v1+ hybrid for Mac would result :-P . I have isolated the areas that need changing, and the changes seem fairly localized. That said, I've made no effort to ascertain which pieces of code are particular to the Mac port and which pertain to the Atari800 codebase. If I get a chance to play with it some more, I will post here. My immediate objective was to get enough ported to SDL v2 to get it to compile. At that point, I will need to address the keyboard input as the next order of business.
  7. Hi folks. I saw this thread and looked into it. As it stands, sound is never going to work in Sierra or later because the current codebase relies on the SDL v1 library. SDL v1 uses Carbon Audio Units for sound on the Mac, and that API has been deprecated for the last couple of OS X versions, pending its ultimate removal in Sierra. I also looked at the possibility of swapping in SDL v2. It is doable, and I played with it. I might even finish it, but while SDL v2 fixes audio (as it now employs CoreAudio as it should), it brings some API incompatibilities with SDL v1 that require some reworking of the code. Unfortunately, the Objective C code in the app has some important deficiencies -- specifically, multi-parameter Objective C method calls lack parameter names. I spent a little time and sorted that out, but my point here is that it requires a little reworking to use SDL v2 and is more effort than simply recompiling.
  8. No promises this will fix it, but if you have another ST handy, you might try swapping the video shifter chip from the working one to the double-vision computer. The shifters are inside of the shielded box on the logic board, and they are usually socketed.
  9. It does look better in that picture. I just did a 520ST that was particularly greenish a couple of weeks ago. The keys need another hit, but the case looks like a new one now.
  10. It looks to me like that unit would benefit from the Retrobrite process discussed in the 8-bit section of the forum.
  11. I currently have two 5-pin DIN cables prepared: 1. 5-pin DIN -> Chroma/Luma/Audio RCA for the Commodore 1702 2. 5-pin DIN -> S-video (mini-DIN) + audio RCA What I need is a third cable: 3. 5-pin DIN -> Composite/Audio RCA What I do not have handy is a 5-pin DIN connector, and the only local store that had anything I could hack up was Radio Shack (which is now gone). Sure, I can order some parts from Mouser, but in the meantime, I could easily pop over to just about any department store and grab an s-video -> composite adapter that will allow me to use Cable #2 with the LED TVs. Nevertheless, before I do that, I will rummage through the parts bin one more time to make sure I don't have the other end of a 5-pin DIN cable already on hand.
  12. Yes, I have a Commodore 1702 monitor (separate chroma/luma) that I can dig out, and I've already made a 5-pin DIN -> Chroma/Luma/Audio RCA cable for that. Unfortunately, my HD LED TVs all lack an s-video input, so I need to pick up an s-video -> composite adapter in order to see how they process the signal from the UAV. Of course, such an adapter means that I will lose the benefit of s-video's independent chroma/luma connections, but ultimately I was hoping to use this particular 800XL with those TVs anyway. Ironically, if testing reveals that the capture device is basically just recombining the chroma/luma signals internally, my attempt to troubleshoot using the highest quality connection available (s-video) will have inadvertently sent me on a wild-goose-chase. Oh well, it won't be the first time that's happened.
  13. Hi Bryan. I am using an El Gato USB2 video capture device, so perhaps that has something to do with it. FWIW, both my Xbox 360 and Atari Jaguar don't have the banding when connected via s-video, but I can understand that this might be an apples vs. oranges comparison as it pertains to the 8-bit systems. Regarding hypothesis #1, "You're using Composite Video in place of Luma", I did ohm out each connection from the DIN's solder pads to the corresponding terminal block connector on the UAV, and everything checked out. I will double check though, as this same thought did occur to me. I've attached a picture of the luma-only connection. Thanks for your thoughts.
  14. I've installed a plug-in board into my 800XL, and I have some test results to post. My 800XL has a Rev D logic board only four socketed ICs. I chose to solder the socket included with the UAV atop the existing 4050 chip. In the end, the UAV does work, but there is still noticeable vertical banding. I saw the earlier post regarding proper grounding, but I have not yet undertaken to make any ground modifications. Attached are two files: 1. 800XL with simple s-video mod.jpg -- shows how my 800XL's s-video image looked before the mod 2. 800XL with UAV video upgrade.jpg -- shows how my 800XL's s-video image looks with the UAV installed. It seems that the vertical banding is particularly noticeable on a blue background. Other colors don't present it as much.
  15. I'm interested in 2. Machine breakdown is: 1. Atari 800XL 2. Atari 7800
  16. mellis

    Xmas Help!

    Sounds like it's worth contacting Best Electronics: http://www.best-electronics-ca.com
  17. FWIW, I'm of your generation and I interpreted your original post exactly as Joey Z did, but this is the internet, so I shrugged it off in a "it takes all kinds of people" sort of way. That said, I wouldn't poke at him too much. You know what your intent and tone was, but I don't think everyone received it the same way as you intended.
  18. Ok, I understand. You'd ideally like to see high-level language bindings to access the cart. Thinking about that some more, would you like to be able to upload code written in the same high-level language to the cart at run-time (where it is then interpreted on the cart itself), or would you be content to compile the code written in the high-level language down to machine language, store it, and then upload that from Atari BASIC at run-time?
  19. Just curious - what were you hoping this cart would do? It is a 65816 coprocessor, which means it sits there and runs custom code in parallel with the Atari. Nothing more.
  20. The problem is that POKEY's PORTB register is used for memory management XL or XE systems, while on the 400 and 800 used it was for the 3rd and 4th joysticks. From what I've been reading, I can't imagine that this GUI would work at all on a 48K system (such as the 800 or an expanded 400), and if PORTB is being used for joysticks, then it is most certainly not being used to access the uppermost 16K on 64K systems or any expanded memory on 130XE (or RAM upgraded) systems.
  21. I hate to tell you this, but assuming you grabbed whatever adapters you had handy and connected them up while disregarding their voltage and type (Did they output DC or AC?), you could've easily fried those components. The presence of an illuminated indicator light does not mean that they are good.
  22. I'm surprised you are seeing high CPU load in SIO Server. To avoid adding noise to this thread, can you PM me these details: 1. What Mac hardware are you using? 2. What OS are you running? 3. What type of USB->Serial adapter do you have? 4. What type of CPU load do you see? I would expect you'd see no more than 30% of a single core during a long I/O burst. I'm curious about how much of a CPU load you are seeing. I've used three SIO Server windows to serve virtual disk drives to three connected Ataris at one point, and CPU usage never reached 100% during simultaneous disk access.
  23. Correct - without a driver, the hardware cannot be used. However, the tech note reluctantly explains how to configure your system to use FTDI's original drivers instead of Apple's bundled driver (which is new in Mavericks). From the symptoms described here, I suspect the problem exists at the driver level. There are many ways to interact with a TTY (serial) device, and it is possible that SIO2OSX and SIO Server happen to use the port and its signal lines in a way that is more in line with the driver author's expected use case.
  24. This Apple tech note might explain the difference between Mavericks and earlier OS X versions. Apple is now bundling their own FTDI drivers with the OS. The tech note includes instructions for using the FTDI drivers instead of Apple's own driver. I wonder if doing so might help AspeQT users. https://developer.apple.com/library/mac/technotes/tn2315/_index.html
×
×
  • Create New...