Jump to content
IGNORED

Fully documented, reverse-engineered STAR RAIDERS source code available


lwiest
 Share

Recommended Posts

(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 -- Lorenz

PS: 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.

  • Like 29
Link to comment
Share on other sites

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 by lbaeza
  • Like 2
Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

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.

 

  • Like 7
Link to comment
Share on other sites

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?post-13040-0-04760800-1460086722_thumb.jpg

 

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 by Kyle22
  • Like 1
Link to comment
Share on other sites

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 by Kyle22
  • Like 3
Link to comment
Share on other sites

  • 1 year later...

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

  • Like 4
Link to comment
Share on other sites

  • 3 years later...
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.

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...