Fox-1 / mnx

That seems to be right. I think the issue turns up when trying to rename files when using wildcard characters in the filename.

No. The positive from one cap and the negative from the other cap must be tied together. That point is your 0 Volt.

Usually, three-legged caps are just 2-in1's. Example for a 12V symetric PS: o---[]|---o---[]|----o + - + - From left-to-right: o +12VDC __o 0V __o -12VDC Using two separate 4700uF ones with 2 of the legs connected, acting as 1 leg, you'll get the same result. Double-check the schematics if this is true for your caps. However it's the most logical use of the 3 legs there may be exceptions.

Three lead caps may be used with symetric power supplies. They can be replaced with two separate caps if physically possible.

Wrong baudrates will give rubbish data, but rubbish is indeed data too. The 850 has an R: driver in it's ROM, ready to download by an Atari, but that's just one way to load the driver into RAM. One can load the same, or similar, driver afterwards from disk as well. At boot, the Atari O.S. does some polling on the SIO bus. If looks for a connected, intelligent device. If it finds a disk drive, CIO will try to boot from it and that's it. You'll end up with anything the disk drive spits out. In most cases this is DOS or a game or what but there are more advanced disk drives that push data from their ROM first, like Speedy disk drives. If it finds an 850, it'll boot from that, which means the R: driver will be downloaded. Part of this process is the +5V line on the SIO bus. The 850 knows the Atari did a cold start (was powered up) because it monitors the status of it. It's one or the other. If a disk boot happened, the 850 keeps silence. If the 850 booted, the disk drive does nothing. This way you can easily boot the R: driver without using a disk drive, like when using cassettes. This is also why you need to execute a short piece of code when booted from disk to trigger the 850 and download the driver. Some terminal programs have this trigger built in (Bobterm), others don't (IceTerm). At boot the Atari doesn't really look for a D: or R: device. It just looks for "a" device and acts upon. But still, it does look for something (or should be at least) at power-up as long START isn't pressed. That's why I think the little logic on the SIO bus is required because frames may not be sent when the Atari gets the wrong initial feedback.

I noticed your other posts... PRCONN.HND and ATARI850.HND both expect an intelligent device to be present on the bus (P:R:C and Atari 850) so, unless you emulate their CPU behavior on the Arduino, those drivers aren't useful. Not sure about RS232.SYS but this may be a driver for "dumb" devices, like R:Verter. From the top of my head... the required logic juggles a bit with the TX/RX/CMD signals. Without it frames won't pass because CMD has to be low/high or inverted when RX or TX is active, or the other way around. Well, something like that but I hope you'll get it :-) Apart from that, also the baudrate on both devices has to match.

Is there anything in between the SIO bus and Arduino port, hardware wise? An R: handler on Atari usually expects some, quite simplistic, hokey-pokey logic to be present on the SIO bus. I think the most most basic approach would be an R:verter interface. Also, see: http://atariage.com/forums/topic/279135-sio-from-basic/?do=findComment&comment=4034995

The official Atari, yes, but third party bank switched memory expansions, like Mosaic and MagnaRAM, were already around in the early 400/800 era.

Issues like this often point to caps because of their nature of how they work and wear out, but if the problem is common, why is it there's no readily available solution? (or maybe there is one I just don't know about) If it really turns out to be caps, modern ones should make the problem go away for a long time. No need to order expensive boards (when overseas) then.

I think the sloppy journalism (back then) was the result of the lack of information that came with a product. Manufacturers often took facts for granted and don't inform others. If "the others" happened to be the same ones that need to review your product you quickly run into situations like this. I mean, you can't do much if "Atari announced a $100,- 48K module" is all you got and by the time the magazine was printed a properly priced 1064 would already be available, making the article somewhat outdated.

Never had a (working) 810 but I'm curious about the "bad boards" issue. Sure, replacement boards are easy to get by (yet) but what does it take to repair a "bad board" in such way that it won't go bad again? Or not that quick at least. They worked at one point so it must be something that can be solved.

That would've more impact if it was Stephen Hawking saying that.

So,, it's above your head?

You need to keep in mind that the 600XL was a brand new product back then. Considering the fact that new XL (software-)possibilities will still be invented today, over 30 years after that review, I think it wasn't a bad attempt.

It's too bad Bo and Ernest don't do much Atari related things these days. Their Atari 8-Bit MS-Dos tools were one of the first of this kind, all done in assembly, so, small and fast. Had an MS-Dos box running for many years with basically nothing installed but Volkov Commander, SIO2PC, and all those tiny XL/XE tools.

I think "XDIRLIST" http://members.home.nl/stack/Atari/atarixle.html#XDIRLIST does what you want but it's an old MS-Dos tool. Getting it to work on modern O.S.' requires some effort.

In the Analog Computing review of the new 600XL they mention a 48K $100 memory expansion module. For what it's worth...

BASIC RPM tool: http://atari.fox-1.nl/atari-400-800-xl-xe/400-800-xl-xe-tools/dskrpm/ DOS 2.8F with RPM feature: http://atari.fox-1.nl/atari-400-800-xl-xe/400-800-xl-xe-tools/dos-2-8f/ DOS 2.5F (about the same as above): http://atari.fox-1.nl/atari-400-800-xl-xe/400-800-xl-xe-tools/dos-2-5f/ SmartDOS 8.2D with SpeedCheck: http://atari.fox-1.nl/atari-400-800-xl-xe/400-800-xl-xe-tools/smartdos-8-2d/ SmartDOS 1.5R Beta with Speedcheck: http://atari.fox-1.nl/atari-400-800-xl-xe/400-800-xl-xe-tools/smartdos-1-5r-beta-test-version/

For Forth's Sake...

Or add a tiny hardware reset circuit: http://www.b-pahl.de/atari8bit/Computer/computer.html (Kaltstart-reset-taster = Cold start reset button)

You can still make the pot usable but mainly for your own purposes as there's (almost?) no software that supports it. Even if the value of the pot is way off compared to the one in a paddle it still does something. If it's worth the effort to do the mod is a second.

>safe on XE game system If it's proven to be safe on an XL/XE, it'll be safe on as XEGS as it's the same sytem. >except analog pot The Atari uses the analog pots as well (paddles)

Aware, yes, but same issue as searching online. Too much info to find it. The article I have in mind was from either Ken Siders or Ben "the Alchemist" Poehland so it may be an "Atari Classics magazine" article. I only remember the ATR8000 was included too but that's pretty much all I know.

I'm lazy so I'll ask... What's the frequency of those Traco stabilizers? Are they suitable for analog audio equipment without having to worry about audible side effect?

All above are viable options but a bit overkill for just an extra button or two. Attaching 2 wires to your internal keyboard connector (pin 7 and 11) gives you the option to connect an external space-button. I have a CX85 keypad which is modified by it's previous owner. It has an extra connector which needs to be plugged into a modified 800XL. The mod is just wires attached to the keyboard connection (number keys) to let the CX85 work without a driver. It's pretty much what you want.