dwhyte Posted July 28, 2008 Share Posted July 28, 2008 (edited) I've never been a fan of translator software. I've always liked games to run without a translator disk or cart. So needless to say running Demon Attack has always been a thorn in my side when I had to boot up a translator disk to play it on a real system, or changing system modes on an emulator. Well here's an XL/XE compatible Demon Attack that no longer requires OS translation. I've yet to see one out there other than the DemonAttack/Pitfall (which isn't file'ized) disk on Atarimania... Demon_Attack__XL_XE_.zip Edited July 28, 2008 by dwhyte Quote Link to comment Share on other sites More sharing options...
classics Posted July 29, 2008 Share Posted July 29, 2008 Nice one! Steve Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted July 29, 2008 Share Posted July 29, 2008 The cart image was done before, but not a file version as you've done: New 1mb cartridge-loader. Select 1 of 15 games Quote Link to comment Share on other sites More sharing options...
Urchlay Posted July 29, 2008 Share Posted July 29, 2008 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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted July 29, 2008 Share Posted July 29, 2008 I'm sure the version I've got on floppy (pirate Exe) works fine on the XL. Kinda funny that someone would take trouble to XL-fix a game but then break it for older machines. Quote Link to comment Share on other sites More sharing options...
carmel_andrews Posted July 29, 2008 Share Posted July 29, 2008 perhaps someone can 'patch the code' in the program to detect what o/s the game is running in and make suitable adjustments so that you can run the game on any a8 (without translator disks etc) Quote Link to comment Share on other sites More sharing options...
carmel_andrews Posted July 29, 2008 Share Posted July 29, 2008 (edited) oops....sticky button Edited July 29, 2008 by carmel_andrews Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted July 29, 2008 Share Posted July 29, 2008 I recall Mr-Atari's fix did just that Quote Link to comment Share on other sites More sharing options...
Urchlay Posted July 29, 2008 Share Posted July 29, 2008 (edited) 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). Edited July 29, 2008 by Urchlay Quote Link to comment Share on other sites More sharing options...
Rybags Posted July 29, 2008 Share Posted July 29, 2008 (edited) SuperMon has ROM at $C000 and pretty sure OmniView and probably all others do too. Given that the 10K on the 400/800 is pretty packed by default, you'd be hard pressed to fit much more into it. I guess the revision byte check mightn't work on certain alternative OSes for the XL that give it extra legacy compatability, although in such cases the incompatability issues usually don't appear anyway. Other ways to detect 800 vs XL: Switch in the Self-Test ROM and test for it at $5000. Switch out the OS and check if a range of memory changes within the OS address space. Check the contents of $CC00-$CC0F (second character set), although that might fail with modded OSes which use that area for code. Do a warmstart ($E474) then check if PORTB is in output mode. Edited July 29, 2008 by Rybags Quote Link to comment Share on other sites More sharing options...
Urchlay Posted July 29, 2008 Share Posted July 29, 2008 SuperMon has ROM at $C000 and pretty sure OmniView and probably all others do too. Given that the 10K on the 400/800 is pretty packed by default, you'd be hard pressed to fit much more into it. I guess the revision byte check mightn't work on certain alternative OSes for the XL that give it extra legacy compatability, although in such cases the incompatability issues usually don't appear anyway. 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? Switch in the Self-Test ROM and test for it at $5000. 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). Switch out the OS and check if a range of memory changes within the OS address space. 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... Check the contents of $CC00-$CC0F (second character set), although that might fail with modded OSes which use that area for code. 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.. Do a warmstart ($E474) then check if PORTB is in output mode. 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). Quote Link to comment Share on other sites More sharing options...
Rybags Posted July 29, 2008 Share Posted July 29, 2008 Another: Check the "Reset Magic" 3 bytes at $33D. XL OS initializes specific values there, and never modifies them after coldstart. Quote Link to comment Share on other sites More sharing options...
Bryan Posted July 29, 2008 Share Posted July 29, 2008 What exactly is Demon Attack doing that makes it OS dependent? Quote Link to comment Share on other sites More sharing options...
Urchlay Posted July 29, 2008 Share Posted July 29, 2008 What exactly is Demon Attack doing that makes it OS dependent? 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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted July 29, 2008 Share Posted July 29, 2008 Easier still - the contents of those vectors are just the operands of the documented Jump Table addresses at $E45F/$E462. Easiest - just JMP $E45F. C10F seems to also be part way into Stage 1 VBlank, just after RTCLOCK is incremented and software Timer 1 is checked. Quote Link to comment Share on other sites More sharing options...
Bryan Posted July 29, 2008 Share Posted July 29, 2008 What exactly is Demon Attack doing that makes it OS dependent? 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). I figured it was something like that. I like the idea of fixing the call rather than patching the illegal jump. Nice to have these games finally fixed. Quote Link to comment Share on other sites More sharing options...
Urchlay Posted July 29, 2008 Share Posted July 29, 2008 Easier still - the contents of those vectors are just the operands of the documented Jump Table addresses at $E45F/$E462.Easiest - just JMP $E45F. Argh, I missed that. Wonder why the original programmer didn't just do that? C10F seems to also be part way into Stage 1 VBlank, just after RTCLOCK is incremented and software Timer 1 is checked. 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). Quote Link to comment Share on other sites More sharing options...
Urchlay Posted July 29, 2008 Share Posted July 29, 2008 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 Quote Link to comment Share on other sites More sharing options...
Rybags Posted July 29, 2008 Share Posted July 29, 2008 I'm all curious now why my old disk version works. Maybe I fixed it all those years ago and just forgot. Quote Link to comment Share on other sites More sharing options...
carmel_andrews Posted July 29, 2008 Share Posted July 29, 2008 Will these 'little tricks' work on every A800 only game....or does it depend on how the game was programmed/coded Quote Link to comment Share on other sites More sharing options...
Bryan Posted July 29, 2008 Share Posted July 29, 2008 (edited) Will these 'little tricks' work on every A800 only game....or does it depend on how the game was programmed/coded Most of the time it's something like this, where interrupts aren't handled properly and/or a jump is made directly into the OS. I think there was a game or two that did things like messing with PORTB. Edited July 29, 2008 by Bryan Quote Link to comment Share on other sites More sharing options...
Urchlay Posted July 29, 2008 Share Posted July 29, 2008 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... Quote Link to comment Share on other sites More sharing options...
carmel_andrews Posted July 29, 2008 Share Posted July 29, 2008 If mem. recalls PortB (D301h) does something totally different on an 800 (like control the other two j/s ports) Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted July 29, 2008 Share Posted July 29, 2008 Actually, I'm guessing Demon Attack was originally developed on 400/800 OS revision A Didn't anyone bother to read the Atarimax thread? Quote Link to comment Share on other sites More sharing options...
Urchlay Posted July 29, 2008 Share Posted July 29, 2008 Didn't anyone bother to read the Atarimax thread? No idea such a thread existed, would be interested in reading it though. Link? Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.