krewat Posted November 4, 2009 Share Posted November 4, 2009 Hello everyone, it's been a while (almost a year) since I started trying to get the IM/SG/WG/One-on-One sources back from the dead (dead floppies, that is). I managed to get all of IM source code back, managed to "find" a copy of the 2500AD 6502 cross-assembler and linker version 5.x, massaged the source code to work with this newer version of the assembler, and LO-AND-BEHOLD... Got it assembled, and compared to the original version (plus the cartridge rom I found here) and it all checks out except for some uninitialized memory that doesn't have to match anyway. Hurray! I was able to play the game (the compiled one) on the MESS emulator, was able to debug an issue I was having with my version (banks were not in the right order - DUH!) with it's internal debugger (which is pretty good, but could use some usability work). So, now to find the "impossible" bug. I'll keep you all updated. Quote Link to comment Share on other sites More sharing options...
CPUWIZ Posted November 4, 2009 Share Posted November 4, 2009 You could just diff the fixed version and track down where the change(s) were made. Impossiblemissionfixed.zip Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 4, 2009 Share Posted November 4, 2009 Cool. Can we have a look at your source code? Quote Link to comment Share on other sites More sharing options...
+Mitch Posted November 4, 2009 Share Posted November 4, 2009 Cool, I'm glad you were able to get it up and compiling. I wish you luck on finding the bug. Mitch Quote Link to comment Share on other sites More sharing options...
segasaturn Posted November 4, 2009 Share Posted November 4, 2009 I thought somebody already released (in rom form) but maybe I'm wrong.......anyway, I would like to play the game with the "fixed" bug, so tell me when your done Quote Link to comment Share on other sites More sharing options...
krewat Posted November 4, 2009 Author Share Posted November 4, 2009 You could just diff the fixed version and track down where the change(s) were made. I did that a while back, and will revisit the "diffs" I have saved. Problem is, didn't someone once say that the "fix" introduced another bug? Quote Link to comment Share on other sites More sharing options...
jaybird3rd Posted November 4, 2009 Share Posted November 4, 2009 Problem is, didn't someone once say that the "fix" introduced another bug? I seem to remember hearing that as well. I can't say I've encountered any bugs myself, but that's probably because the game is too brutally hard for me! I need to practice some more. I greatly appreciate your looking into this. Even though I can't play it beyond the first few screens, I love Impossible Mission on the 7800, and it would be great to get an "official" updated version directly from the author! I'm always interested in hearing about the original 7800 development tools, too. I hadn't heard of the 2500AD 6502 assembler/linker until you mentioned it, but it looks like it's still available in a Windows version (although it's a bit pricey for me). I wonder how it compares with the free tools that many of us hobby developers use today (such as DASM). Could DASM compile your original code, or would it have to be modified to conform to the DASM syntax? Quote Link to comment Share on other sites More sharing options...
krewat Posted November 4, 2009 Author Share Posted November 4, 2009 Just for grins, I enabled the "god flag" that Atari had me put into the game so they could test it quickly. This disabled robot movement, but if you ran into one, it'll still kill you. So I made another check in the collision code for the god flag, and was able to easily search every room without a problem. Well, except for the crazy one with all the different levels in it I found only 23 of the 35 needed puzzle pieces after searching every object. Does this match with what everyone else remembers about the bug? As for the assembler discrepancy... When I first worked for Computer Magic, they did their 6502 development on Commodore 64, and then uploaded it to the 7800 through a single joystick line. Very slow, to say the least. They did do 2600 development before I got there, and they certainly worked on Atari 400/800 systems too, as "Kayos" floppies were regularly used for scratch disks http://www.atarimania.com/game-atari-400-800-xl-xe-kayos_2757.html When I first got involved with the Atari 7800, I do not know why, nor do I remember much about it, but I believe Atari didn't even have the Atari 800 development system up and running, or at least, they didn't offer it to us. It was much later (like a year or more) when they finally said "hey, we have an Atari 800 development system". Also, I do not recall them having a development static ram cartridge available neither. Either that, or they wanted money for it, which my cheapo bosses wouldn't pay for But then, I can't blame them. So, I set out to make my own development system using my personal IBM-XT. I made a new BIOS for the 7800 itself, a static ram cartridge, and pushed 8-bit parallel data into the 7800 from the printer parallel port of the XT. Much faster. I do not recall exactly where I got the 2500 AD cross-assembler. It might have been directly from Epyx. I really don't know. I do know, however that it was version 3.x. The version I am using now is version 5.02. I found a 4.0 version, but it didn't have "Absolute" and "Relative" directives which is odd. But 5.02 (and a demo version 5.05) does. I later used an IBM-AT for development, which I had overclocked, and was using that for the Impossible Mission which was the last game I did. Quote Link to comment Share on other sites More sharing options...
+Mitch Posted November 4, 2009 Share Posted November 4, 2009 You could just diff the fixed version and track down where the change(s) were made. I did that a while back, and will revisit the "diffs" I have saved. Problem is, didn't someone once say that the "fix" introduced another bug? It depends which fixed version you are referring to. I didn't check to see which one Cpuwiz posted but there is the PAL version that was fixed. There is John's version which I believe is a back port of the PAL version. There is the proto fixed Atari version that has the new bug in the puzzle rooms. I also have a fixed NTSC version done by someone who has since left the hobby, Art if you want a copy of it send me a PM. Mitch Quote Link to comment Share on other sites More sharing options...
krewat Posted November 4, 2009 Author Share Posted November 4, 2009 Oh, and as for using other assemblers, it is very possible, but the way the code is setup into modules, and the banking used with the 7800, makes overlays or at least "relocatable" code using a REAL LINKER a major necessity. Without an assembler/compiler generating object code, and then a linker to generate each bank separately, it would take a major overhaul of the code. When I get time, I'll look into it more, but when I first started this, I checked out every assembler I could find in the public domain, and nothing really did what I needed, AND the source code needed some major changes just to assemble in the first place. I keep wanting to say "compile" and not "assemble" but after posting on 6502.org about some 2500 AD issues I was having, I was reminded many times it's "assemble" and not "compile". Oh well. Quote Link to comment Share on other sites More sharing options...
tjb Posted November 4, 2009 Share Posted November 4, 2009 Any chance you might post a binary for Impossible Mission with the God mode flag enabled? It would be nice for people like me who can't get very far in the game. I'd just like to be able to look at some of the screens I wouldn't normally be able to get to. tjb Quote Link to comment Share on other sites More sharing options...
+Propane13 Posted November 4, 2009 Share Posted November 4, 2009 23 out of 36 puzzle pieces-- yes, that sounds right. But, I believe it could be random for any game (so, a few more or less). As a potential hint, the rumor was that the bug was just one simple issue-- puzzle pieces were accidentally able to be hidden behind terminals, besides other objects in the room. This means they were "placed" in the room, but they were inaccessible. This would account for random pieces available in different configurations. To test this theory, enable God mode, hit reset a few times, and try a new layout. You may get 23, or you may get a different number. I *think* I had different numbers in my trials, but it has been a long time since those tests. For the record, yes, my version was a revert of the PAL version (the PAL version works fine). It is an NTSC ROM that I guarantee is beatable. I basically changed the colors that were different, and display list list parameters to match scanlines. I beat it twice, as did other people on these forums. However, this is probably not worth a lot to the original programmer, since it's compiled code, and not source code (I was unsure what the source code was that changed). Good luck! -John Quote Link to comment Share on other sites More sharing options...
Bruce Tomlin Posted November 4, 2009 Share Posted November 4, 2009 (edited) I'm always interested in hearing about the original 7800 development tools, too. I hadn't heard of the 2500AD 6502 assembler/linker until you mentioned it, but it looks like it's still available in a Windows version (although it's a bit pricey for me). In a previous job I used version 5 of their 6809 assembler. Basically it was a cross-assembler from back in the day before cheap fast CPUs, cheap fast hard disks, and the gnu tools, not to mention people like me who wrote their own cross-assemblers. (Once the code was sufficiently factored, it took me a day or two to add 6809 support.) The main feature of 2500AD was that it supported linking together separate object code modules, and it also had a C compiler available. (At least there was a C compiler for 6809, though all I ever got was the manual unless I ended up with the floppy disks in a pile somewhere.) It also let you be lazy, because its parser didn't require a semicolon before comments. Back in the day, when floppy disks were less than 200K (the source for a 32K game runs 300-400K with hard tabs), hard disks cost half as much as a new car, and CPU speeds were measured in single-digit megahertz, it was a big thing to be able to assemble/compile just one module and link in the rest. Nowadays it takes less time to assemble the code than to start up the emulator, and I think nothing about disassembler listings that take up a megabyte in the early stages, other than it takes half a second to open the file. I wouldn't mind adding modules and linking support to my own assembler, but your average 2+GHz CPU makes it not worth the effort. If all you want to do is break up the files into smaller chunks, an "include" directive works just as well. Anyhow, I think it would be cool to see the source code too. It's the comments and label names that are the interesting part, but comments tended to be scarce back in the days of 32 to 64 column screens. Only the real pros (and Apple II users) had the luxury of 80-column screens. I'll see if I can't disassemble and diff out the changes. Gotta hunt for the various binaries first. Edited November 4, 2009 by Bruce Tomlin Quote Link to comment Share on other sites More sharing options...
krewat Posted November 4, 2009 Author Share Posted November 4, 2009 If you have the capability, doing this will allow you to enable the "god flag" if you hold down the PAUSE button as the game starts: In the original ROM, at offset 0x1C8DA, you'll find three bytes, "A9 FF EA" which equate to: LDA #$FF NOP Replacing those three bytes with "AD 82 02" which equates to: LDA $0282 This will load the switch values into register A. The released "original" ROM just loads a dummy value to make the compare false, and pads with a NOP (no-op) so that Atari could patch the binary and enable the GOD flag without a major recompile. I shipped the original to Atari without it enabled to keep this "easter egg" from reaching the market The GOD flag in the original will disable the robots, but you will still die if you hit one. Quote Link to comment Share on other sites More sharing options...
krewat Posted November 4, 2009 Author Share Posted November 4, 2009 Back in the day, when floppy disks were less than 200K (the source for a 32K game runs 300-400K with hard tabs), hard disks cost half as much as a new car, and CPU speeds were measured in single-digit megahertz, it was a big thing to be able to assemble/compile just one module and link in the rest. Nowadays it takes less time to assemble the code than to start up the emulator, and I think nothing about disassembler listings that take up a megabyte in the early stages, other than it takes half a second to open the file. Lucky me, I had an IBM-XT in 1985 with 2 10 meg harddrives, and began working at Computer Magic around 1986. It was my ability to code assembler for the IBM-PC/XT/AT that got me the job By the time I worked for Computer Magic, I had gleaned a 30 meg drive from a Micro-PDP-11, hacked the BIOS for the hard drive controller, and I was FLYIN' I wouldn't mind adding modules and linking support to my own assembler, but your average 2+GHz CPU makes it not worth the effort. If all you want to do is break up the files into smaller chunks, an "include" directive works just as well. I agree in principle. However, when you are working with multiple banks of code (overlays), like the Atari 7800, linking and not including does make some things easier. Anyhow, I think it would be cool to see the source code too. It's the comments and label names that are the interesting part, but comments tended to be scarce back in the days of 32 to 64 column screens. Only the real pros (and Apple II users) had the luxury of 80-column screens. I'll see if I can't disassemble and diff out the changes. Gotta hunt for the various binaries first. I just checked that "fixed" binary from Atari, I think it is. It's called im81189.bin. Not entirely sure where I got it from. There is a place where a random number generator is called in the original code, and it just plonks a puzzle piece down in the random object without any checking if it's a terminal or not. The "fixed" version has a table of objects, and a one-zero flag to indicate terminals or non-terminals, and a loop that calls the random number generator, checks the table for the one flag, and if set, loops back for another random number. Avoiding the terminals in the process. There are some graphics changes too, but nothing to do with puzzle pieces, or at least, the logic involved in managing them. So, it definitely looks like "my" original code did it incorrectly. So I wonder how it could have worked right EVER. There is an easier way not to store puzzle pieces (or it turns out, lift inits and robot snoozes) in terminals. The search count of an object is $FF is the object is a terminal. An easy check. I will definitely incorporate this. Quote Link to comment Share on other sites More sharing options...
+Propane13 Posted November 5, 2009 Share Posted November 5, 2009 Woohoo! The bug is found! Would you mind commenting on the graphics changes? That actually seems kind of cool to me. -John Quote Link to comment Share on other sites More sharing options...
Bruce Tomlin Posted November 5, 2009 Share Posted November 5, 2009 (edited) I agree in principle. However, when you are working with multiple banks of code (overlays), like the Atari 7800, linking and not including does make some things easier. Nah, bank switching is cake. All you need is multiple ORGs and a few conditionals to check that no page is running over the end. But I suppose it might be nice during development if you have to move stuff from one bank to another. Then all you need to do is mess with the linker control files. But when you're creating a lot of different assorted combinations of modules (like the legacy 6809 code where I worked) into a system with banked 4x32K ROM and 4x16K RAM, it does become kind of essential. However, their later 6809 code was all done position-independent, with an RTOS that would assign them RAM and handle the bank switching, so all modules were self-contained and could be put just about anywhere except for the few that required more than 16K of ROM (the second half had to be in page N+1). After I wrote a Turbo Pascal program to put the modules together and a couple of DOS batch files to mimic a primitive make system, things went together real easy. Edited November 5, 2009 by Bruce Tomlin Quote Link to comment Share on other sites More sharing options...
krewat Posted November 5, 2009 Author Share Posted November 5, 2009 Woohoo! The bug is found! Yeah, still trying to figure out if it was a bug introduced later, or if it was there all along. Would you mind commenting on the graphics changes? That actually seems kind of cool to me. All I know is certain locations within the graphics areas are different between the original released ROM and the "fixed" version that Atari had. It might be something to do with back-porting the PAL version and something didn't make it. I'll see what's really up with that. Quote Link to comment Share on other sites More sharing options...
CRV Posted November 6, 2009 Share Posted November 6, 2009 They did do 2600 development before I got there... I wonder what 2600 games they did, if any... Quote Link to comment Share on other sites More sharing options...
krewat Posted November 6, 2009 Author Share Posted November 6, 2009 They did do 2600 development before I got there... I wonder what 2600 games they did, if any... I don't know. They might have been working on a port of Kayos for all I know and never completed it. Remember, this is all from about 23 years ago, so my memory isn't the best of events at that time, much less things I noticed in passing. Just did a Google of "Computer Magic Atari" and got this: Mad-Netter: http://www-sul.stanford.edu/depts/hasrg/histsci/GamesM_ME.htm OOH! And this: http://www.atarimania.com/screenshots_games_atari-2600-vcs-commavid-computer-magic_page-publisher_1-67_2_G.html And a complete search: http://www.atarimania.com/pgelstsoft.awp?system=2&type=G&publisher=67&step=25 Dunno if "CommaVid/Computer Magic" means the company I worked for, but ... Quote Link to comment Share on other sites More sharing options...
krewat Posted November 6, 2009 Author Share Posted November 6, 2009 Atari 800: And a catalog listing: http://www.atarimania.com/catalog-atari-commavid-computer-magic-_141_2.html I remember Mines of Minos Quote Link to comment Share on other sites More sharing options...
DracIsBack Posted November 6, 2009 Share Posted November 6, 2009 So, it definitely looks like "my" original code did it incorrectly. So I wonder how it could have worked right EVER. When you fix the code, maybe you can slip in a "Another visitor ... stay a while, stay for ever ..." too! Quote Link to comment Share on other sites More sharing options...
CRV Posted November 8, 2009 Share Posted November 8, 2009 Dunno if "CommaVid/Computer Magic" means the company I worked for, but ... From what I understand, CommaVid was originally going to be called Computer Magic. CommaVid was a Chicago-area company started by physicists. Quote Link to comment Share on other sites More sharing options...
krewat Posted November 9, 2009 Author Share Posted November 9, 2009 From what I understand, CommaVid was originally going to be called Computer Magic. CommaVid was a Chicago-area company started by physicists. Interesting. Found this: http://www.digitpress.com/archives/cc_commavid.htm So, I guess it wasn't the same place. The guys I worked for certainly weren't physicists, and were on Long Island Quote Link to comment Share on other sites More sharing options...
krewat Posted November 26, 2009 Author Share Posted November 26, 2009 Just an update on this, came up with a quick solution, and am going to test it over the Thanksgiving weekend. My daughter googled my name, and came up with this: http://www.gamedev.net/community/forums/topic.asp?topic_id=552830 Last paragraph Funny. It's only been about 21 years. Wonder how gamedev.net heard about this? Come on, someone has to 'fess up! 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.