lwiest Posted April 1, 2016 Share Posted April 1, 2016 (This is an update of my previous post http://atariage.com/forums/topic/243904-star-raiders-source-code-to-be-released/page-9?do=findComment&comment=3422364, starting a new thread.)During the last years, as a hobby afterhours project, I reverse-engineered a complete, extensively documented assembly language source code of STAR RAIDERS for the Atari 8-bit Home Computer System. I created it directly from the binary file of the ROM cartridge, finishing it in September 2015. It is available on GitHub (http://github.com/lwiest/StarRaiders).You may find it useful if you are curious about the internals of STAR RAIDERS or if you are planning to make your own, modified version.After very positive reader feedback on the initial release of my reverse-engineered source code I reviewed it again, resulting in a minor update.Enjoy -- LorenzPS: I was absolutely thrilled to learn that in October 2015 scans of the original STAR RAIDERS source code (https://archive.org/details/AtariStarRaidersSourceCode) re-surfaced. To my delight, inspection of the original source code confirmed the findings of my reverse-engineered version and caused only a few simple corrections. Even more, the documentation of my reverse-engineered version adds a substantial amount of information - from overall theory of operation down to some tricky details - to the understanding of the often sparsely commented original (quite expected for source code never meant for publication). So, if you are interested in learing how STAR RAIDERS works, my reverse-engineered source code could be of help to you. 29 Quote Link to comment Share on other sites More sharing options...
lbaeza Posted April 1, 2016 Share Posted April 1, 2016 (edited) Hello Lorenz Thanks for providing us with this work, there's nothing like good commented code to learn how things work. When did you start documenting the source?There's so much information on the comments, that you could even write a book on how SR was programmed... Kind regards, Louis BQ Edited April 1, 2016 by lbaeza 2 Quote Link to comment Share on other sites More sharing options...
R4ngerM4n Posted April 2, 2016 Share Posted April 2, 2016 Wow! Quote Link to comment Share on other sites More sharing options...
+MrFish Posted April 2, 2016 Share Posted April 2, 2016 Nice job... very detailed! Quote Link to comment Share on other sites More sharing options...
+Stephen Posted April 2, 2016 Share Posted April 2, 2016 Amazing work. Perhaps you could work with jac to help speed up the Syncalc disassembly that has just been started? 1 Quote Link to comment Share on other sites More sharing options...
retrobits Posted April 2, 2016 Share Posted April 2, 2016 Fantastic job. You must have been working on this for years. I assume you strip the comments to actually assemble it with Mac/65? Quote Link to comment Share on other sites More sharing options...
JamesD Posted April 3, 2016 Share Posted April 3, 2016 (edited) Notice the original thread he mentionshttp://atariage.com/forums/topic/243904-star-raiders-source-code-to-be-released/page-9?hl=star+raiders&do=findComment&comment=3422561 Edited April 3, 2016 by JamesD Quote Link to comment Share on other sites More sharing options...
lwiest Posted April 5, 2016 Author Share Posted April 5, 2016 Hello Lorenz Thanks for providing us with this work, there's nothing like good commented code to learn how things work. When did you start documenting the source? There's so much information on the comments, that you could even write a book on how SR was programmed... Kind regards, Louis BQ Actually, I started with the reverse-engineering effort first (quite some years ago) in order to make sense of the cartridge's bytes, then came documenting the source code. Think of it as a very long-term sudoku or crossword puzzle . I'm glad you like the result. 3 Quote Link to comment Share on other sites More sharing options...
lwiest Posted April 5, 2016 Author Share Posted April 5, 2016 Fantastic job. You must have been working on this for years. I assume you strip the comments to actually assemble it with Mac/65? Yes, I spend a couple of years on this, on and off. With regard to assembly with MAC/65: I actually assembled the entire reverse-engineered STAR RAIDERS source code (including the comments) with MAC/65 on an AtariWinPlus 800 emulator with 64K. MAC/65 is able to assemble programs larger than the available memory of the ATARI - as long as they are stored in MAC/65 tokenized format. What I did was to split my reverse-engineered source code in 23 parts, loaded each part in MAC/65 and saved each part as a tokenized MAC/65 file. They won't fit on an (emulated) Atari floppy disk but the emulator provides an "H" device, which lets you access folders on your hard drive. Finally I wrote a short MAC/65 program that chained togther all the tokenized parts. Assembly worked fine. The output, both the assembly list file and the binary object file, was written to the hard drive folder. Final technical detail: The object file that MAC/65 produces is not a contiguous block of binary data but a list of binary segments. I had another program automatically combine these segments into one big segment, which I eventually compared with the reference ROM. 7 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted April 5, 2016 Share Posted April 5, 2016 Do you still have those 23 parts? I'd like to assemble it on my 800. Quote Link to comment Share on other sites More sharing options...
8Bitjunkie Posted April 6, 2016 Share Posted April 6, 2016 awesome :-) Quote Link to comment Share on other sites More sharing options...
lwiest Posted April 7, 2016 Author Share Posted April 7, 2016 Do you still have those 23 parts? I'd like to assemble it on my 800. There you go! Find instructions in the ZIP. Enjoy! -- Lorenz AssembleItYourself.zip 7 Quote Link to comment Share on other sites More sharing options...
R4ngerM4n Posted April 7, 2016 Share Posted April 7, 2016 How about disassembling 'Alternate Reality - The City' 2 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted April 7, 2016 Share Posted April 7, 2016 There you go! Find instructions in the ZIP. Enjoy! -- Lorenz Thanks. I'll put it on my 800 when I get home and see how long it takes to assemble. 1 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted April 8, 2016 Share Posted April 8, 2016 (edited) It assembles in 2 minutes on the 800 Incognito. I added .opt no list, changed .include #H: to .include #D:, and added the variable ROMCART. I then used .if ROMCART=0 to add both a JMP to INITCOLD at $A000, and a $02E0 segment .word INITCOLD for run address. If ROMCART = 1 then (after compacting the extra segments) it assembles to a nice 8192 byte .ROM file that works fine. If ROMCART = 0 then (after compacting the extra segments or not) it assembles to a file that runs under DOS, but the character set is corrupted. I am doing this all on the 800, in MAC/65, so it takes a while to read through everything. The characters in the status window are corrupted, as is the galactic map. I suspect this is because of the location of the character set. I haven't really looked at it all yet. Picture is attached. Thanks Lorenz for all your excellent work. Do you have any ideas about how to (easily) make the code switchable for ROM image or DOS file? Edit: nevermind. I changed origin to $9FFD if assembling to DOS file to offset the 3 bytes added by the JMP INITCOLD. That way everything stays at the same address. It works now. Edited April 8, 2016 by Kyle22 1 Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted April 8, 2016 Share Posted April 8, 2016 (edited) Got it! Don't bother with the JMP. Only add 10 ROMCART=0 to MASTER.M65. then do the following to part 23. At the end, type: (a higher line number than the last one) .IF ROMCART = 0 " *= $02E0 " .WORD INITCOLD " .ENDIF I hope I helped others by commenting on my (slow) learning process. I think that's all. I'll upload an .ATR tomorrow. Edited April 8, 2016 by Kyle22 3 Quote Link to comment Share on other sites More sharing options...
mechanerd Posted January 7, 2018 Share Posted January 7, 2018 Using the source code I made a trainer hacked version of Star Raiders 2018.. I finally can pass Star Commander Class 4. The trainer version.Changed copyright line to a title declaring it a trainer so there aren't funny videos claiming pwning the game when it's a hack. Shields take all hits do no damage. Reduced energy usage that determines final score. The shields, computer, and tracking all take zero energy. The engines run at any speed with power level 2 consumption. Hyperwarp takes only 1-2 sector jump chunks of energy no matter the distance. Calls you a "CHEATER" instead of "CONGRATULATIONS" instead at the end. A few ATASCII changes here, a few NOPs there, tested it. Got it right I think. Maybe two hours of fun. I used the PC based Omnivore editor. Onimon to stop and check registers along the way. Star_Raiders_Trainer_2018.xex 4 Quote Link to comment Share on other sites More sharing options...
8-bit and more Posted July 26, 2021 Share Posted July 26, 2021 On 4/5/2016 at 12:37 PM, lwiest said: Yes, I spend a couple of years on this, on and off. With regard to assembly with MAC/65: I actually assembled the entire reverse-engineered STAR RAIDERS source code (including the comments) with MAC/65 on an AtariWinPlus 800 emulator with 64K. MAC/65 is able to assemble programs larger than the available memory of the ATARI - as long as they are stored in MAC/65 tokenized format. What I did was to split my reverse-engineered source code in 23 parts, loaded each part in MAC/65 and saved each part as a tokenized MAC/65 file. They won't fit on an (emulated) Atari floppy disk but the emulator provides an "H" device, which lets you access folders on your hard drive. Finally I wrote a short MAC/65 program that chained togther all the tokenized parts. Assembly worked fine. The output, both the assembly list file and the binary object file, was written to the hard drive folder. Final technical detail: The object file that MAC/65 produces is not a contiguous block of binary data but a list of binary segments. I had another program automatically combine these segments into one big segment, which I eventually compared with the reference ROM. Can you explain the final step of building the binary? You mention "Final technical detail: The object file that MAC/65 produces is not a contiguous block of binary data but a list of binary segments. I had another program automatically combine these segments into one big segment, " How is this done? thanks. Quote Link to comment Share on other sites More sharing options...
Rybags Posted July 26, 2021 Share Posted July 26, 2021 There's various ways you could do it - a quick/dirty way for cartridges could be to congigure a 52K 400/800 in Altirra then boot a low memory Dos (e.g. most of them) with no cartridge present. Then binary load the file using the option to not run it. Then save it back to another file (though you'd need to check the cartridge bytes to get the init/run) Quote Link to comment Share on other sites More sharing options...
8-bit and more Posted July 26, 2021 Share Posted July 26, 2021 2 hours ago, Rybags said: There's various ways you could do it - a quick/dirty way for cartridges could be to congigure a 52K 400/800 in Altirra then boot a low memory Dos (e.g. most of them) with no cartridge present. Then binary load the file using the option to not run it. Then save it back to another file (though you'd need to check the cartridge bytes to get the init/run) I tried this and the "Binary Load" with the /N option still seems to bomb (i get garbage on the screen after the binary load). Not sure why this is happening. Any ideas? Quote Link to comment Share on other sites More sharing options...
Rybags Posted July 26, 2021 Share Posted July 26, 2021 The load address will be $8000 or $A000 and end address $BFFF which means the display on a 48K config will corrupt. That's why 52K should work - the screen should be allocated around $CC00 which means the cart area is preserved. Though you then get the problem of the OS bug that zeroes hardware registers but you can still have a workable system. In Altirra you need to select 400/800 as the system type with 52K and no cartridges present. 1 Quote Link to comment Share on other sites More sharing options...
8-bit and more Posted July 26, 2021 Share Posted July 26, 2021 19 minutes ago, Rybags said: The load address will be $8000 or $A000 and end address $BFFF which means the display on a 48K config will corrupt. That's why 52K should work - the screen should be allocated around $CC00 which means the cart area is preserved. Though you then get the problem of the OS bug that zeroes hardware registers but you can still have a workable system. In Altirra you need to select 400/800 as the system type with 52K and no cartridges present. Tried that and same result. The code is assembled at $A000. Any other ideas? LOL thanks. Quote Link to comment Share on other sites More sharing options...
Rybags Posted July 26, 2021 Share Posted July 26, 2021 Your config must be wrong. Press F8 when Dos finishes loading then enter .dumpdlist into the console window. If your config is right the Display List should be at $CC20. Quote Link to comment Share on other sites More sharing options...
8-bit and more Posted July 26, 2021 Share Posted July 26, 2021 scratch the last post by me, I was running a different emulator and not Altirra. I tried with Altirra and it finally loaded without stepping on the display. Now on to try and build the proper rom file. 1 Quote Link to comment Share on other sites More sharing options...
8-bit and more Posted July 26, 2021 Share Posted July 26, 2021 4 hours ago, Rybags said: There's various ways you could do it - a quick/dirty way for cartridges could be to congigure a 52K 400/800 in Altirra then boot a low memory Dos (e.g. most of them) with no cartridge present. Then binary load the file using the option to not run it. Then save it back to another file (though you'd need to check the cartridge bytes to get the init/run) SO....I was able to load the binary, then save to another file using init address of A000 (tried 8000 also). Tried loading the file no luck, also tried mounting the file as a cart in altirra, no luck...learning a lot tho! Quote Link to comment Share on other sites More sharing options...
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.