Star Raiders Source Code to be released?

[tschak909]

Curt, do you have details on the cross assembler that atari used? It's referred to as 'Atari CAMAC' in the file, was that an in house creation by atari, or was it a third party tool that they used? I was curious (if it was an atari in house thing) if you had a copy of the assembler itself, and knew what it ran on? I think it'd be interesting to setup an emulator of the DEC mini's that atari was using, and reproduce the compilation techniques that atari originally used.

 

EDIT: guess CAMAC was for a DG system instead, regardless I'm willing to learn to set it all up to get the 'real atari experience,' at least in emulation, if you can find a copy of the program.

 

CAMAC was literally the Atari Macro Assembler that was ported to run on the MV/8000 (think of it as a 32-bit Eclipse, which...again, think of it like an extended Nova) that was the mainstay of the consumer dept. in the early 80s.

 

It was later ported to the department VAX.

 

-Thom

[JamesD]

Code addresses match up now and byte order appears to be correct for word sized data.
I'm not sure all data addresses match up but it's late.

*edit*

I couldn't sleep without giving the data addresses a look. They seem to match up.
Maybe someone could give the bin a comparison to the ROM to see if they have any differences.
If there are any differences, we can look back through the code at those addresses to see what's messed up.

StarRaidersCA65.zip

Edited October 18, 2015 by JamesD

[JamesD]

I didn't declare the data sections as BSS so they ended up in the bin file.
And there are data errors I'll fix in the morning.

[JamesD]

I hate it when I can't leave something alone.

 

This builds a bin file identical to the ROM.

There are two differences between the Star Raiders ROM file and what was in the listing.

The source was modded to reflect those differences but I made note of it and had the original line copied and commented out.

*edit*

Feel free to send beer. Now I need sleep!!!!!!!!!!!!!!!!!

StarRaidersCA65.zip

Edited October 18, 2015 by JamesD

[JamesD]

One last update.

I removed a comment I had added about the code being different. That got fixed when I removed extra bytes from the data.

And I removed all the org statements I commented out and replaced with .res
Where two ORGs were used after a single label I used two .RES statements because the author was indicating multiple groups of data.

At this point, all it needs is for someone to look through the code for truncated lines and to restore them from the scanned listing.
I'm not going to do that myself.

StarRaidersCA65.zip

[MEtalGuy66]

Awesome.. Now adapt It into an ATARI client program for a Multiplayer-Online game using a modern PC as the "galaxy-server" and serving game data out over telnet. (That way you could use Lantronix, APE, etc. and not have to require/support overheaded crap like the dragon-Ip cart..)

[JamesD]

Awesome.. Now adapt It into an ATARI client program for a Multiplayer-Online game using a modern PC as the "galaxy-server" and serving game data out over telnet. (That way you could use Lantronix, APE, etc. and not have to require/support overheaded crap like the dragon-Ip cart..)

I think I'd make it faster and assembled at an address for running from disk first.

[Fletch]

Awesome.. Now adapt It into an ATARI client program for a Multiplayer-Online game using a modern PC as the "galaxy-server" and serving game data out over telnet. (That way you could use Lantronix, APE, etc. and not have to require/support overheaded crap like the dragon-Ip cart..)

Haven't seen a Ken post in a while. Don't always agree with his posts, but I sure do appreciate his candor.

[+Mitch]

Nice work JamesD!

 

Mitch

[JamesD]

At line 590 an opcode is hard coded using .byte and .word

It uses the form of STA ABS,X that uses a 16 bit number for the absolute address.

This could use the direct page form and I'm not sure why he didn't let the assembler automatically decide.
This is in ROM so there can't be any self modification there and it's part of the initialization code so I don't see any reason why it would be copied to RAM.
Since it's not part of any main loop changing it won't offer any speed enhancement once the game starts but it will save a byte and speed up initialization.

 

It's the only place I found this.


*edit*

Maybe page alignment?

Edited October 19, 2015 by JamesD

[Rybags]

The forced absolute mode would be so that it doesn't inadvertantly wipe all of Page zero out. Note that in zero-page indexed modes there's address wraparound. By using absolute addressing it just means the first 100 or so bytes of the stack get wiped.

Edited October 19, 2015 by Rybags

[JamesD]

The forced absolute mode would be so that it doesn't inadvertantly wipe all of Page zero out. Note that in zero-page indexed modes there's address wraparound. By using absolute addressing it just means the first 100 or so bytes of the stack get wiped.

 

I'm guessing this was a code space optimization to initialize more stuff with one loop to fit more in the ROM

 

Is there some system stuff below $62 on page zero by any chance?

[Rybags]

It would probably make no difference if it wiped all of Page zero since it's done early on and the cart doesn't have high score or prettymuch anything needing preserving across a warmstart.

 

Once the system's up and running you have z-page stuff like RTCLOK and the attract mode colour shift/mask stuff that gets maintained by VBlank.

If you're not using SIO or CIO then the lower half of z-page doesn't really matter. And since it's a diag mode cart you don't need to worry about the BOOT flag or DOS/CASINI.

 

My guess is the programmer early on probably decided to not wipe that part of memory - the method used is cheaper than doing CPX #$62 / BCC nn

[JamesD]

It would probably make no difference if it wiped all of Page zero since it's done early on and the cart doesn't have high score or prettymuch anything needing preserving across a warmstart.

Hence my questioning why he wasted the byte and clock cycles.

 

Once the system's up and running you have z-page stuff like RTCLOK and the attract mode colour shift/mask stuff that gets maintained by VBlank.

If you're not using SIO or CIO then the lower half of z-page doesn't really matter. And since it's a diag mode cart you don't need to worry about the BOOT flag or DOS/CASINI.

 

My guess is the programmer early on probably decided to not wipe that part of memory - the method used is cheaper than doing CPX #$62 / BCC nn

The question is, why he decided not to wipe that part of memory which we may never know.

[JamesD]

I found another comment about an instruction being different from the ROM and have removed it.

I'm looking at a couple potential optimizations. It looks easy but I have to look at all the code to be sure of the impact.

[JamesD]

There is just enough space reserved on page 0 for two of the tables such as XPOSH, XPOSL, or XSIGN.
XPOSH and XSIGN are accessed the most so that has the potential to offer the largest speedup for the least work.

I'm guessing something like that was on page zero at one time which would explain why $62 was used as a start address on page zero.

I don't even know if this will run (I don't even have an Atari emulator installed at the moment) but if someone wants to give it a try, XPOSH and XSIGN are located on page zero with this version.
Just change the name to StarRaiders.ROM to get it to work I suppose.
This is just a quick n dirty change so I'm not giving out the source. Anyone could to it in about 30 seconds.
StarRaiders.bin

[Goochman]

There is just enough space reserved on page 0 for two of the tables such as XPOSH, XPOSL, or XSIGN.

XPOSH and XSIGN are accessed the most so that has the potential to offer the largest speedup for the least work.

 

I'm guessing something like that was on page zero at one time which would explain why $62 was used as a start address on page zero.

 

I don't even know if this will run (I don't even have an Atari emulator installed at the moment) but if someone wants to give it a try, XPOSH and XSIGN are located on page zero with this version.

Just change the name to StarRaiders.ROM to get it to work I suppose.

This is just a quick n dirty change so I'm not giving out the source. Anyone could to it in about 30 seconds.

StarRaiders.bin

 

Altirra and Atari800Win cant recognize the file - something along the lines of no compatible headers found.

[JamesD]

 

Altirra and Atari800Win cant recognize the file - something along the lines of no compatible headers found.

Well, the first $133 bytes are identical to the StarRaiders.ROM I downloaded so it's not a header.

The file appears shorter so that's probably the issue.

[JamesD]

With some bytes to pad out the file so the length is correct and the start info at the end is at the right address

I'll have to install an emulator if I'm going to keep messing with it.
*edit*
I'll repost it once I know it's working.

Edited October 19, 2015 by JamesD

[JamesD]

I had to add about 53 bytes of padding due to the shorter code.
It runs on Altirra so I think it's working. If nothing else, this makes more room in the ROM for something else.

*edit*
this may lock up, I don't know how to run the game or the emulator.
It does start up and I've been able to change speeds, long range scan and a couple other things.

It's going to need some debugging.

StarRaiders.bin

Edited October 19, 2015 by JamesD

[a8isa1]

I had to add about 53 bytes of padding due to the shorter code.

It runs on Altirra so I think it's working. If nothing else, this makes more room in the ROM for something else.

 

*edit*

this may lock up, I don't know how to run the game or the emulator.

It does start up and I've been able to change speeds, long range scan and a couple other things.

 

It's going to need some debugging.

James, kudos for converting the source to CA65 format!

 

In your patched version while in combat mode moving the joystick does strange things. LEFT or UP makes the stars collapse inward and locks up the game. RIGHT looks like the warp effect but faster. I forget what DOWN does.. SELECT no longer changes the difficulty level. It seems to do a RESET instead.

 

DOWN activates random effects and seems to attempt cassette I/O

 

[Mind, you I did my testing from Atari800 2.1.0 with patches disabled]

Edited October 19, 2015 by a8isa1

[JamesD]

That version doesn't even start up correct. Instead of cycling through the text it seems to jump right into the game.
Once I move XSIGN back to where it was, the game starts up normal even though XPOSH is still on page zero.

I'm guessing some code related to XSIGN or XPOSH is running off the end of it's memory block.

*edit*
And I think it's XSIGN since using XPOSL and XPOSH in either order doesn't display the same problem


*edit*
I'll have to spend some time looking through the code at what is going on.
No matter which one I put on page zero I end up with some odd behavior or a crash.
It will speed up the game though.

Edited October 19, 2015 by JamesD

[JamesD]

Anyone know of any instructions that behave differently with signs or flags between absolute direct page indexed and absolute indexed versions?

[Rybags]

The done thing in the early days was leave OS Ram well alone unless you're actually dealing with the component that uses it.

Also note it's entirely possible SR was in development before the OS was even finalised.

 

The funny thing is, running as a diag cart is more trouble than it's worth since you have to perform system initialization yourself. The copy protection benefits are near non-existent, the insert/copy to Ram method works no matter what mode the cart runs in.

 

Later games (e.g Donkey Kong?) use the method of run via the cart Init vector and don't return. This lets the OS do almost all system initialization but disallows any booting and gives the cartridge control before the screen device is opened.

 

 

Potential problems of moving indexed stuff to z-page: if there's references which for whatever reason use a large offset which cause wraparound on page zero. Otherwise there should be no problem.

I would suggest if moving stuff to z-page. In initial testing, leave as absolute instructions. Put a trap in Altirra which detects any memory access to $100-$17F. If none occur then there should be no risk of address wraparound and the instructions can be changed to z-page.

Edited October 20, 2015 by Rybags

[JamesD]

Actually, I was going to put each block on page zero individually with some space around it and put break points in the unused areas.