Fox-1 / mnx

My reason to go for an O.S.S.C. is the lag-free conversion because it's not an upscaler but a scan doubler in stead. This will do for the ST/MegaSte/Falcon/Jaguar because those use RGB but unfortunately the O.S.S.C doesn't support video/S-video. I need to convert those to, preferably, analog RGB first, with VGA as a second option. I was not aware that there are Amber RGB versions too. Maybe I should consider to skip the O.S.S.C. for now and go for a set-up as you have now. My main display only has HDMI inputs but AFAIK it should work fine with a simple VGA->HDMI adapter but didn't actually try it. As for the A8 picture quality... I don't expect miracles but as long as the result is better then using the plain video input the SCART provides, and is lag-free, I'll be satisfied. As a bonus I'll get rid of possible NTSC/PAL issues too. I'm in PAL land, so using the 1200XL and 5200 always was a bit troublesome because not every tube TV was prepared for that. edit: typo's

S-vid to VGA... On what system(s) do you use that converter? Looking for a way to get a signal that can be fed to an O.S.S.C. https://www.videogameperfection.com/products/open-source-converter/ and go to HDMI that way. Initially wanted to go from S-vid to RGB but such converters are hard to get. Next option is to go from S-Vid to a lag-free VGA signal and go from there. The converter you have seems to do exactly that.

Finally I found something to whine over! A bit of an inconvenience in Altirra is the forced DOS 2.x filename limitation. Underscores, and a number as the first character, are not allowed in filenames when adding them with the image explorer. However this is in line with the DOS 2.x naming convention this is a bit annoying as almost any other DOS 2.x format-compatible DOS allow these by design. Is there a solution that won't clutter the menu's, like an override flag or something like that?

Just some thoughts... In stead of focusing on the SIO... * If I read it correctly you seem to have the title screen in memory all the time so I assume it's reused every time a new game is started. Maybe it's possible to use the fancy title screen only at load time and replace it with a more simple (read: lower memory usage) one to use in-game? * In case you have multiple long display lists: are those hard coded with .byte arrays? You can construct these with routines and rebuild them each time you need them, thus reusing the same memory space for all display lists. Only useful if these are pretty large since you need space for the build-code too. * Did you plan more features but left them out because of memory constraints? Since you have DOS loaded anyways you can eat your heart out when you're loading data from disk at the time it's needed. * Is there any eye-candy that is not really necessary to play the game? You can relocate it under the O.S. memory when running on XL/XE and skip it in case it runs on 800.

From the faq: http://faqs.cs.uu.nl/na-dir/atari-8-bit/faq.html - - - Express!, by Keith Ledbetter, 1985-1986- Strengths: auto-dialer and reliable XMODEM transfers- Version 3: XMODEM/CRC, ability to download .BIN files on CompuServe using XMODEM, VIDTEX mode for CompuServe cursor positioning, R-Time 8 support - Each version includes an integrated modem handler- Original version: 1030 Express! (September 1985) - Integrated T: handler- 850 Express! 3.0 release date: 9/24/86 (earlier releases include 1.1) - Integrated R: handler- 1030 Express! 3.0 release date: 11/1/86 (earlier releases include 2.0, 2.1) - Integrated T: handler- MPP Express! 3.0 release date: 12/1/86 (earlier releases include 1.1) - Integrated R: handler is Chilcott MPP handler- Also the basis for SX Express! from Atari (1988) and for the Express! cartridge from Orion Micro Systems (1990) - - - I'm fairly certain a BBS version of "Express" on cartridge doesn't exist. At least not official. Wouldn't make sense either because of the nature how a BBS works. The pass-thru design for the terminal cartridge is a logical decision. Their other products, like SDX and RT8, were also designed like that and one who often calls out to BBS' would appreciate this. It's also useful for sysops, who run a BBS, to make calls themselves. By enabling/disabling the Express cartridge they can switch back and forth without taking the BBS offline. The fact that later versions of BBS Express Pro! have it built-in as an external command for easy access without having to reboot the BBS has a reason.

There are lot's of different OmniView versions around, both official and modified versions. http://atari.fox-1.nl/atari-400-800-xl-xe/400-800-xl-xe-tools/omniview-roms-and-manual/

Just did exactly the same, with the same tools too :-) Same result. Doesn't work with SpartaDos either. Appears to start at $2000 with a JMP $20A9 at where the DL is created to display the "ATOS RULES!!" text, but upside-down. Then the fun starts with some self modifying code

Sound to me like a software configuration issue, like, no bootable ATR present as D1: on the SIO2SD or something like that. In case it's not the only device in the SIO chain, you'd take a look over here: http://atariage.com/forums/topic/174145-sio2sd-daisy-chaining-problem/?do=findComment&comment=2162818

The above solution is exclusively for the 1200XL. The 600XL and 800XL don't have the mentioned resistor (which basically means those have this solution built-in by design).

Low level will do but depending on what other data devices are connected to the SIO bus you may get some unwanted side effect you'd want to take care of. Now the Arduino listens to all data that crosses the SIO lines it will respond to every match you implemented. The Arduino doesn't know If this is a command/data byte intended for a disk drive or one that it needs to respond to. Kind of the same behavior one gets with some SIO midi interfaces where a connected midi keyboard starts playing notes when loading a disk because some of the bytes traveling the SIO lines match the midi ones.

MyDos is shareware and has no copy protection. Even the source code is included in the original releases.

Reminds me of that large stack of old 5,25" disks I stashed in my shed years ago. I think it's still there. Someone wanted to get rid of them but forgot to mention those were all hard sectored disks.

If you mean that it doesn't show the pressed keys... that's normal behavior. The "all tests" is more like a demo thing than a testing tool.

Without any programming experience on Atari this may be a challenge. Not impossible, of course. It all depends on your device, be it real or emulated, on how to communicate with it. If you want something useful you need a device driver on the Atari which understands the XIO commands. With a disk drive you talk to "D:" to work with data on disk because the disk drive has a ROM that listens to "D:" commands. Atari loads the "D:" from disk when DOS is booted. You need to do the same on an Arduino as has been done in the disk drive, but for a custom "?:" device you invented. So, where you'd use XIO 1,#1,aux1,aux2,"D:file.ext" to work with a disk file you'll now use XIO 1,#1,aux1,aux2,"?:" to talk to your emulated device. Which commands are possible, and what they do, is up to you. Not sure if an Arduino will cut it. May need something more powerful, like RPI. b.t.w, using a joystick port to control things is way easier.

Exactly that. Just be very sure the polarity is right. Double check, triple-measure, I guess you get it :-)

Pro! 5.0b is not SDX compatible for multiple reasons. There are max-file/dir issues. Some CMD's have lot's of small data files. Those are stored in a directory and when it's full a new directory will be created automatically. If such a CMD reads all directory entries into their pre-defined buffer problems will arise. The SDX file/dir limit is higher and will overflow the buffer. Apart from that, Pro can only handle SpartaDos formatted disks. Disk-based versions like 3.2/3.3 with a 16MB limit that is. Any CMD that uses Note/Point routines (like the message bases and some data base tools) will likely cause problems when trying to access sectors above the 16MB limit. Not sure if the core itself also uses Note/Point but if it does the problems are even bigger, especially when used with memory overlays.

Does it need to be software? If it's just for checking I guess you can just read a paddle register. Something like: if peek(53776)>227 then stereo if peek(53776)<228 then mono

Or check the ANTIC CO21698 is PAL CO12296 or CO21697 is NTSC

The power supplies you buy from Best are about as old, or even older, as the ones you already have. Sure, they may be unused but things like capacitors wear out anyway. If a true authentic, all Atari, set-up is what you want, that's the way to go. If you want one that runs cooler, is smaller, is easier available and replaceable, energy-saving and cheaper, then go for a modern solution. Or at least consider it. You can also source the power from a PC system but that's only practical if you have one nearby which usually runs anyways. Most versatile disk drive replacement is a SIO2PC, either by RS232 (older systems) or USB connection, with the Aspeqt/Respect software. Can't go wrong with that and you can always add other devices later on.

The read-only data on a regular BBS is usually a small .EXE and a few tiny .CMD's. Everything else is data that needs updating. You'll end up with only a few KB's that can be kept in ROM. Totally not worth it, especially if you also take into account that updating the core ain't that easy anymore.

Do yourself a favor and get a modern 5VDC power supply (at least 1.5A but 2A or a bit more is better). Snap the cable with DIN from a broken one and connect it to the new one.

It may be nice for some but not for me. Because of the lack of support I gave up on Pro! a while ago.

A flash cart is not a real cartridge. Just another writable data storage device.

Lance from Video61 talked about a BBS Pro release on cartridge, many years ago. Still waiting... Thoughts... you can put any BBS on a cartridge as long as you have at least some additional space to store config/message/user/etc data. Useful? Not really. The read-only data on a BBS usually is only a small fraction of the whole.

Of course. Now I see. Mixed it up with the way I save .DCM's as .ATR's. For K-Boot ATR's I use the, now 20 year old, AtrUtil 95 from Ken Siders. Despite being a 32bit Win95 tool it still does the job, even on Win10 64bit.