mellis

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.

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.

It looks to me like that unit would benefit from the Retrobrite process discussed in the 8-bit section of the forum.

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.

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.

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.

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.

I'm interested in 2. Machine breakdown is: 1. Atari 800XL 2. Atari 7800

Sounds like it's worth contacting Best Electronics: http://www.best-electronics-ca.com

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.

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?

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.

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.

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.

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.

I am also interested in both.

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.

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

I have a question for the OS X users out there: Assuming SIO Server's double-density bug was fixed, is there a single additional feature that would make it more usable for you? Folder imaging was mentioned earlier. To me it seems running a Win32 compatibility layer is a bit heavyweight for a peripheral emulator.

Hi folks. I really don't want to hijack this AspeQt thread, but I will post a few bits to contribute to the turn the conversation has taken. I wrote SIO Server to scratch an itch I had a few years ago. It was designed to satisfy my own personal requirements, and then I released it to the public just in case others might derive some utility from it. Until recently, SIO Server has had two active users that I know of. The double-density bug is definitely in there (and fixable), but I never did get around to correcting it because it wasn't a problem for my personal use-case and there were other peripheral emulator solutions that everyone seemed pretty happy with. SIO Server is actually two programs: the GUI process and the communication daemon. When the GUI launches, it spawns a priority-elevated communication daemon as a child process. The daemon and the GUI communicate with one another using piped I/O. The approach minimizes CPU usage and helps to ensure that the priority-elevated daemon can continue to communicate even if the host system is delayed updating the GUI. Although I am a long-time Mac OS X (née NEXTSTEP)/iOS developer, the GUI is written in Java in order to facilitate porting the app to other POSIX-compliant OSes. The core of the communication daemon was written in portable, POSIX-compliant C by Belboz, and I added many enhancements to it. The communication daemon has been tested on Mac OS X and Linux systems, and it can be launched from the command line. In short, I never got around to fixing the double-density issue or to creating a Linux build because: I was happy with the software (for what I needed), nobody else was terribly interested, and I've had little time to spare anyway. That said, I am glad to see that the program has proven helpful in some way: as a troubleshooting tool.

I want one! Please put my name on the list.

I was on the Atari 8-bit and ST roundtables on GEnie. My handle was old enough that it was [FIRSTNAME]-[LASTNAME], not the usual [iNITIALS].[LASTNAME] that came to be used later on. Good times.

Nice write-up, Algus. Best has been my choice for Atari parts since the early 1990s.

One thing I enjoy reading about in the forums is various installation strategies for Atari modifications. I recently completed the Easier 7800 Composite Mod (thanks Puppetmark and Underball!), and I'm pretty satisfied with the modification itself and the installation, so I figured I'd share some pics too. Here is the bottom side (component side) of the prototype board: Here is the top side (circuit side) of the prototype board: I used wires with connectors so that the board can easily be removed. This is helpful because once installed, the 7800 logic board cannot be removed without first removing the composite board (the yellow RCA connector extends though the hole in the back of the 7800 case plastic thereby preventing the board from being lifted). Now with the board installed and connected (yes, there is clearance for the RF shield): And finally, a shot of the back of the system (8mm headphone jack is on the left, and the composite plug is on the right):

I probably should have included a link to the application, huh? Sorry about that. Download it here: http://www.ellissoftworks.com/sioserver/SIO%20Server.app.zip