Fully documented, reverse-engineered STAR RAIDERS source code available

[lwiest]

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

[lbaeza]

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

[R4ngerM4n]

Wow!

[+MrFish]

Nice job... very detailed!

[+Stephen]

Amazing work. Perhaps you could work with jac to help speed up the Syncalc disassembly that has just been started?

[retrobits]

Fantastic job. You must have been working on this for years.

I assume you strip the comments to actually assemble it with Mac/65?

[JamesD]

Notice the original thread he mentions
http://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

[lwiest]

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.

[lwiest]

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.

 

[Kyle22]

Do you still have those 23 parts? I'd like to assemble it on my 800.

[8Bitjunkie]

awesome :-)

[lwiest]

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

[R4ngerM4n]

How about disassembling 'Alternate Reality - The City'

[Kyle22]

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.

[Kyle22]

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

[Kyle22]

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

[mechanerd]

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

[8-bit and more]

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.

[Rybags]

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)

[8-bit and more]

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?

[Rybags]

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.

[8-bit and more]

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.

[Rybags]

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.

[8-bit and more]

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.

[8-bit and more]

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!