Urchlay

Yeah... I've been turning up lots of rumors too, but nothing definite. I was hoping someone who *knows* would speak up (maybe I should PM Curt Vendel). That's what Atari++ does for the floating point, when using the internal OS. I'd hate to try to do that for the whole OS... but a good chunk of software (especially games) will run just fine with all 0's where the floating point ROM should be. To make things clear, I'm not writing a new emulator, I'm just packaging one up for a site that hosts Linux packages, so users can just install it without dorking around with compilers & config options. I was hoping to find an OS I could include in the package, to make things even easier... but proprietary stuff (even "abandonware" like the Atari OS) would be a no-no. Yep, OS++ is (apparently) the only one. Even if it weren't the only one, it'd probably be the best one: Thomas put a lot of work into it, and it's impressive as hell. I don't know how hard it'd be to reimplement the FP... probably not hard for someone who really knows how it works, but I guess you'd have to take the "clean room" approach like Compaq did back when the cloned the PC BIOS. Right. What I was considering was packaging up the entire contents of the XFormer 2.5 zip file as a Linux package. The DOS executable & other stuff would be installed somewhere out-of-the-way, but the user really would be able to run XFormer through an emulator like dosbox or VirtualBox. Probably a lawyer would say that's a dodge, and it won't actually work as a legal protection. It's not commercial, but it's not personal either (the whole world would be able to download it). Nobody's seriously worried about getting sued, it's just that Free Software (and Open Source) people are picky about licenses (we want our licenses to be respected, so we make sure to respect others' licenses), and I don't want my package to get rejected because of license 'taint'. Actually, if this were a commercial product, and the decision were up to me, I'd just use the ROMs and gamble on nobody noticing (or caring). Of course, no-one in their right mind would let me make a decision like that

I'm trying to come up with an unencumbered OS ROM to include with an open source emulator package. Got a few questions that people in this forum probably can answer definitively: 1. Someone told me the Atari OS and/or BASIC ROMs have been released as public domain, but I can't find any supporting evidence for this after hours of googling. Is there anything to this? (Someone also told me all the OSS code for DOS and BASIC had been PD'ed, but not Atari's OS code). The closest I came to mention of this in my research was an announcement that Hasbro released all their rights to the Jaguar into the public domain... nothing about the 8-bit. 2. I know the ROMs were released to the XFormer developer long ago, and can be downloaded in the XFormer 2.5 zip file, but from what I can tell that doesn't mean I'm allowed to redistribute them, or even necessarily use them for other purposes than running XFormer. Everyone does it anyway, but my goal is to be 100% legit for this. Is it permitted for me to redistribute these ROMs at all? How about if I include the entire XFormer 2.5 program directory? 3. Are any of the OS variants like Omnimon or ARGS-OS public domain? (I know ARGS-OS uses the 800XL $D800-$DFFF math pack, but what about the rest of the OS? Rewrite, or just a patched version that's mostly Atari code?) 4. What is the story on the ROM from the Atarimax 32-in-1 OS upgrade, called "800 Compatible PD OS" or similar? Its 2K math pack is almost identical to the one in the 800XL, only 19 bytes different. Where did this ROM come from, and does the PD license only apply to the rest of the ROM, or is the floating point ROM also PD? 5. There's a "crippled" version of the XL/XE OS source floating around, posted to a lot of places (including this forum). Usually it's called "OS revision 5". Am I right in assuming this was leaked, and not released by Atari? (and if I'm wrong, how is it licensed?) There is a very nice free/open source OS ROM replacement called OS++ by Thomas Richter, author of the Atari++ emulator. It looks to be a complete rewrite of the XL OS, includes some nice extras (built-in DOS and R: handler), but completely lacks the floating point ROM ($D800-$DFFF area is all 0's). Obviously BASIC and a lot of serious software won't work without FP, but a lot of games work fine. If I could find a public domain math pack to use with it, my quest would be complete. So: 6. Where did the FP ROM in Omnimon come from? It's substantially different from the Atari ones, enough to probably count as a rewrite from scratch. Anyone know what the license on Omnimon and/or its math ROM is? 7. Does anyone know the status of the other FP replacements, like the Newell Fastchip (or is that the same thing as Omnimon uses)? 8. Has anyone here written a math pack replacement (maybe years & years ago) that would like to step forward & formally release it as public domain (or open source? I'd love to see source to something like that). 9. There's been a "Fastmath.rom" posted to a thread in this forum recently. What's the license on it? (It won't work with OS++ as-is, because it appears to use the alternate charset and cassette handler areas of the ROM, which OS++ also uses, but it'd still be useful to know about). OK, this turned out to be more than a few questions, sorry for blathering on, but this stuff is pretty important... anyone who has any answers, I'd love to hear from you.

Will the source for the DLL ever be released?

I just have to say it: I love this kind of digital archaeology. Keep it up!

MULE and Asteroids both support 4-player simultaneous play, lots of fun. Super Breakout can use up to 8 paddles, but there's no real point: players take turns, so the game could have been done with one paddle that gets passed around...

Sounds like it might be the original Disk Communicator program?

My first Atari hardware mod ever: unplug & remove the speaker from my 400. The keyclick noise drove me nuts... The 800XL was a definite improvement, could just turn the TV volume down while coding, or turn the keyclick off with a POKE. If anyone had suggested adding an internal speaker to my 800XL back then, I probably would have thought they were insane... possibly driven insane by too much keyclick noise? If I'd known how, it would have been cool to mod the 400, route the speaker sound to the TV (same as the XL). Anyone ever done that?

The only thing similar about MARIA display lists and ANTIC display lists is that they're both called a display list (and on MARIA you have a DLL, "display list list"). It's about like saying an SUV and a sports car are similar because they're both cars (true, but not useful, you can't easily use parts from one on the other, you don't "program" (drive) them the same way)... (Forgive the bad car analogy, I know it's trite...)

I gotta admit, I got a giggle out of it too. Insert BASIC cartridge, at READY prompt type: 10 ? PADDLE(0), PADDLE(1) 20 GOTO 10 RUN Move the stylus (or your finger?) around on the pad, you should see the numbers changing. IIRC, the first number will get smaller as you move towards the left of the pad, and the 2nd gets smaller as you move towards the top... I may have that backwards, but anyway the numbers should change as you move on the pad.

No idea such a thread existed, would be interested in reading it though. Link?

Is there a list somewhere of all the 400/800-only games? Atarimania's advanced search doesn't offer an option for that. The Atari 8-bit FAQ lists some, but I'm pretty sure I've run into some 800-only games that aren't listed there...

OK, here's the "final" version. It replaces the illegal JMPs with JMP $E45F, like Rybags said. Tested (in emulator) with OS A, B, and the 800XL OS, should work fine even on "weird" OSes like Omnimon or MyIDE... demon_attack_fixed.zip

Argh, I missed that. Wonder why the original programmer didn't just do that? Yeah, but the game plays fine whether you jump to SYSVBL or that part of the routine (I suppose the game doesn't use RTCLOCK or sw timer 1).

Directly jumping to the OS immediate VBLANK handler, which is a no-no (various Atari manuals warned not to do stuff like this, from day one). Actually, I'm guessing Demon Attack was originally developed on 400/800 OS revision A, because it contains JMP $E7D1... on rev A, $E7D1 is the start of the SYSVBL routine. On rev B, it's actually in the middle of the routine, and it's probably blind luck that the jump lands on a valid instruction and that the program still works. On the XL/XE OSes, the interrupt handlers all got moved to $Cxxx, so whatever's at $E7D1 is the wrong code to jump to (so the game crashes). dwhyte's modified version replaces the 2 instances of JMP $E7D1 with JMP $C10F, which is probably the start of SYSVBL on the XL/XE (I haven't checked). The version I posted is dwhyte's version plus a few bytes of init code that run before the game runs, and undo the patch if it's running on an 800. Now that I think of it, there's a better way to fix it... VVBKLI at $0222 is initialized to point to SYSVBL at boot, so it'd contain the correct address for the game to jump to. The game code changes the vector to point within itself, but it'd be easy to write a little init segment that loads before the game, grabs the contents of $0222/$0223, and saves them somewhere in memory the game doesn't use (maybe page 6, or the tape buffer, the usual suspects), then change the absolute JMPs in the game code to indirect JMPs, to vector through the saved SYSVBL. Doing it this way, it'd be less of a "dirty hack", and more likely to work with nonstandard/modified OSes like Omnimon.

Demon Attack jumps to SYSVBL, a documented entry point... so depending on how Omnimon/Supermon/etc works, my (admittedly simple) code might decide it's on an XL, and try to jump to the XL SYSVBL location. Anyone who uses one of these alternate OSes care to try it & let me know if it works? Thought of that, but then there are those 1 meg modded XEs that don't have the self-test ROM (or anyway they somehow use PORTB bit 7 for RAM banking). Thought of that too, but if they're running something like SpartaDOS 3.x, part of the OS ROM gets copied into RAM (I know the charset does at least, maybe some of the interrupt handlers too), so I'd have to know what I was doing there... Yah, thought of that too Actually I prefer not to mess with the $Cxxx area on an 800, since I don't know whether the undefined memory accesses are emulated correctly in atari800/atari++, and am too lazy to dig my real 800 out & set it up.. Hm, is a warmstart even necessary there? I suppose there might be some software out there that sets PORTB as outputs on the 800 (driver for the numeric keypad maybe?)... Another thing I thought of: there are quite a few "spare" bytes on the 800 that are initialized to 0, but on an XL they're used for something and therefore not 0. CHSALT ($026B) is a good candidate (on an XL it should never be 0, on an 800 it should always be 0, unless someone's breaking the rules).

For anyone interested, here's my own fixed version that works on 400/800 and XL/XE: Edit: attachment removed, see below for "proper" fixed version BTW, is there a "correct" way for code to determine whether it's running on a 400/800 or XL/XE? I just checked the high 4 bits of the 6502 RESET vector, and assume I'm on an XL/XE if it's $C (since on an 800, there's no ROM at $Cxxx, so the RESET vector can't point there). Does anyone know if any of the variant 800 OSes (Omnimon, etc) include ROM at $C000, and if so, do any of them actually point the RESET vector there? I can think of several other ways to check, including the revision byte at $FFF7... this way seemed simplest (least likely to get confused by patched OS ROMs).

Nice job... however, this version doesn't work on an 800. Can't believe a game as simple as this couldn't work on both. Still, thanks for the XL version, will be playing it quite a bit I think.

The 1200XL ROM is different, yes... but I think the compatibility issues are overstated. Is there a list somewhere of stuff that works on the 800XL ROM but not the 1200XL? Everything I've thrown at mine seems to work fine (mostly games). Another thing for the original poster to be aware of: The 1200XL's video output quality is the worst of all the Atari 8-bits. The s-video doesn't work (missing chroma signal, fixable by soldering 1 wire), the composite looks almost as bad as using RF on a TV, and even with the chroma fix, the s-video isn't much better than composite. If you're planning to get a 1200XL because you want to mod it, the Clearpic 2002 or S-Video 2.1 is the first hardware hacking you'll want to do (and well worth it: the video is beautiful afterwards). If all of the above is gobbledegook to you, then you probably don't want a 1200XL

If you're satisfied with a MyIDE instead of a full PBI mod, there's plenty of room in the case for it, and the result is a lot less frankensteinish... My 1200XL's got a MyIDE with a flash drive, but there's enough room for a laptop hard drive. Of course, the MyIDE uses a modified 800XL OS ROM, so your 1200XL also ends up needing that plus internal BASIC (which can be viewed as an upgrade or not). I went ahead & got a 32-in-1 OS and 256K RAM upgrade, and now I feel like I'm driving a Cadillac whenever I use the 1200XL

The video mod could be Clearpic 2002 or Supervideo 2.0/2.1... The SV 2.0/2.1 mod calls for a "composite disable" switch, which I left off the one I did on my 800XL (instead, I wired things so composite is always disabled). I can't remember whether Clearpic 2002 also has such a switch, or whether I borrowed the idea from SV2.1, but I deliberately didn't hook up the composite on my 1200XL when I did the Clearpic (my 1200XL board didn't quite match the description in the mod instructions, so I ended up with kind of a modded mod...) Clearpic 2002 directions for 1200XL: http://retrobits.net/atari/clearpic.shtml I was going to paste a link for the 1200XL Supervideo 2.1 mod, but either I don't have it in my bookmarks, or it doesn't exist (maybe it's an 800XL-only mod, which would explain why I did Clearpic on the 1200XL). Anyway, congratulations on your find. The 1200XL might be a red-headed stepchild, but some of us still love her

It's probably not what you're looking for, but I always liked Racing Destruction Set. Admittedly, it was more fun designing the tracks than it was to race on them... best way to play is two players, one tries to design an impossible track, and the other races on it, against the computer car. Bonus points for using a fast car when the gravity is set to "lunar". It would be a really cool project for someone to write a top-down Pole Position style game engine that can use the tracks designed in Racing Destruction Set. Anyone know anything about RDS's file format?

It's kind of off-topic, but I bet the guys who designed pkzip originally did it that way because the multipart stuff was intended for multiple floppy disks. If you store the header info on the first disk, you have to re-insert the first disk at the end of the zipping process so it can write the correct header info, which AFAIK includes the compressed file sizes as well as the originals... only way to find out the actual compressed size of each file is to actually compress it, so it couldn't have written the header info at the time the first disk was originally in the drive (well, it could have, but it'd have to either compress each file twice, or have enough RAM to store all the compressed files before writing them to floppies). I used to prefer arj, too, back in my short-lived MS-DOS days... but I can't remember how it got around this problem. Maybe by not storing the compressed size in the header, or maybe by making the user re-insert the first disk after the last one is written.

Except that e.g. various SDX versions present different messages for the same error (e.g. "Directory not found" vs "Path not found" or "Drive not present" vs "Device does not respond") Not a huge problem, I can either require a specific version, or else include all the possible errors from all the various versions (regex-based "parser", easy enough to do). 512 byte sectors also aren't a problem for now, since AFAIK they're not supported in atari800 yet, and nobody's too likely to run into a 512-byte ATR image in the wild... is there a freely available emulator ROM image for SDX 4.4, or is it still being sold commercially?

Would that be highway 92 in Kennesaw (or maybe Acworth), Georgia? There used to be a guy there who sold mostly NES and SNES games, but had a decent selection of 2600 carts... I never saw any 8-bit stuff though. Maybe 10-12 years ago I used to find Commodore 64 stuff there, but never Atari 8-bit. So am I, especially if it's the same flea market I think it is.

The forum software tries to only allow certain file types (zip, txt, jpg, gif, apparently rar, others?)... but it doesn't really examine the file contents, only the filename. You can rename anything so it ends in .zip and upload it to this forum, but anyone downloading it will have to rename it to its original "file type" extension. The trouble you had is that the forum allows filenames ending in .rar, but not in .r01, .r02, etc (so no multipart rars). Actually, I think newer versions of rar call the files "file.part01.rar", "file.part02.rar", etc... so that should be allowed (all parts end in .rar).