Jump to content
ZeroPage Homebrew

Programming my First 2600 Game (In ASM)

Recommended Posts

It's happening! I'm a couple of sessions into creating my first game for the Atari 2600. As revealed on the ZPH show it's a port and I'll be programming it in assembly. It's going to be a little slow going, sneaking in a couple of hours here and there each week where I can.

 

The first iteration of the game will be VERY simple but should still be fun to play. It will only involve playfield, one player character and maybe the background if I can get that going as well so it shouldn't be taxing on the system or my programming skills.

 

I already have a good start on the psuedocode and I'm using Darrell Spice Jr's collect tutorial as a learning template to help me get a handle on things. I've programmed simple things in assembly before (and a number of other things in other languages) but it's been a while. With all the great examples of code on the forums and elsewhere I think I'll be able to muddle my way through, at least at first. I won't hesitate to ask questions if I get stuck!

 

I'll reveal what the game is when I've got this first iteration of it working. There won't be any enemies, so it's just you against the environment at first. Looking forward to all of this!

Edited by ZeroPage Homebrew
  • Like 9

Share this post


Link to post
Share on other sites

Good luck James! Enjoy the fun!

  • Like 1

Share this post


Link to post
Share on other sites

I've now done some preliminary animated graphics for the player, there's 9 distinct frames for now. There will be more variety as the game has more complexity but that will be it for the initial version.

 

They're 8x8 and they don't look super great as individual graphics, especially in only one colour but I'm hoping they look a lot better in motion and will help identify what you're seeing. The whole loop for the 9 frames takes just under 1/2 second to display so it should give a nice illusion of movement.

Edited by ZeroPage Homebrew
  • Like 2

Share this post


Link to post
Share on other sites
2 hours ago, ZeroPage Homebrew said:

I've now done some preliminary animated graphics for the player, there's 9 distinct frames for now. There will be more variety as the game has more complexity but that will be it for the initial version.

 

They're 8x8 and they don't look super great as individual graphics, especially in only one colour but I'm hoping they look a lot better in motion and will help identify what you're seeing. The whole loop for the 9 frames takes just under 1/2 second to display so it should give a nice illusion of movement.

Gotta start somewhere James - your on the road to discovery my friend!  Don't get too down about how things look initially - the core thing is getting the gameplay right and everything else will come in good time.

 

Looking forward to the world premiere one day! 

  • Like 1

Share this post


Link to post
Share on other sites

Ran into the first interesting challenge of choosing to make a game with an asymmetric playfield that fills almost the whole screen and is active on (possibly) every line. Doing reading about asymmetric playfields, they state that there's VERY little time left to do anything else as you're constantly updating the information for the first half or second half of the 20 bits on the playfield, ugh!

 

I think I can get around that issue if I position the player character before the playfield draws and set the graphics to blank. When it reaches the point where I need to see the player, all I'll have to do it put the correct graphics in, as I would have to do anyway, and then set it to blank again when it's finished drawing it.

 

I will most likely start with trying a mirrored asymmetric playfield. This has a huge advantage in the fact that I won't have to update PF0 as I don't need it to extend the play area into those regions. This will save me a lot of cycles and leave time for other things. I've already had to made some concessions for porting this game over to the VCS so I don't think it'll be to big of a deal.

 

One of my next challenges is code something to translate pre-programmed stored/random values from 16bits to 32bits (doubling the width) to fill PF1/PF2/PF2/PF1 taking into account that PF1&PF2 are written in the opposite direction. I've already figured this out in my head but I'll see if translates well into actual code.

  • Like 2

Share this post


Link to post
Share on other sites

Having time to display what you need is of course the biggest challenge of programming on the Atari. For what it's worth, mirrored asymmetric kernel that uses only PF1 and PF2 is actually how the standard kernel in batari Basic is setup, and it has time to display all of the objects by making use of a two-line kernel. @SpiceWare has a good tutorial that includes explaining how to make use of a two-line kernel, in case you aren't already aware of it.  🙂 

 

I'm anxious to see what your mystery project is! I can't imagine having gotten to the point of having a playable demo of something without having asked for help at some point during the process as I was learning.

  • Like 2

Share this post


Link to post
Share on other sites

Phew, big accomplishment today on my game, at least for me. I was able to read playfield data that I've stored in ROM, move it into RAM and display the whole thing on the screen on a stable display. I'm currently using a mirrored playfield, but I don't know if I'll be able to continue using that, depending on how the kernel timing works out going forward.

 

To Do List:

  • Generate "random" playfield data instead of stored playfield (DONE on 20200704)
  • Generate "random" playfield data based using INTIM (DONE on 20200712)
  • Filled playfield data with "random" data (DONE on 20200716)
  • Display the playfield correctly formatted
  • Add color to the playfield
  • Scroll the playfield
  • Display player on the screen
  • Move the player
  • Animate the player
  • Colour the player
  • Detect collisions
  • Have start, game over & restart conditions

Phew, after all of that, I'll reveal the game on the show!

 

- James

Edited by ZeroPage Homebrew
  • Like 3

Share this post


Link to post
Share on other sites

Did a little more development on the game today and was able to generate a "random" playfield, checking off one more thing from the "To Do" list. From all the reading I've done on the AA forums, there really isn't anything than can be read from VCS that can help generate a random number. The only way to generate a "random" number is to get one based off of input timing from the player, like when the player presses the button/reset to start the game.

- James

  • Like 2

Share this post


Link to post
Share on other sites
2 hours ago, Thomas Jentzsch said:

INTIM should be random initially.

Oh perfect, thanks Thomas! I'll give reading from INTIM for a random number on my next programming session and update here. 🙂

 

- James

Share this post


Link to post
Share on other sites

Yesterday I had a bit of time:

 

- Added INTIM to the code to be the seed for the LSFR generated playfield

- Cleaned up code a bit

 

Next time I'll be working on displaying the playfield correctly.

 

- James

  • Like 2

Share this post


Link to post
Share on other sites

Was able to fit in a couple of hours tonight and was able to fill some/all of the playfield with randomly generated numbers. I was also able to show the playfield with mirrored asymmetrical information, looks different on the left and right all the way down the screen, hooray!!

 

It's still not storing and/or displaying all the data correctly but I'll save that for next time...

 

As a side note, I'm getting a lot more used to typing and programming in assembly so I'm speeding up in that regard.

 

- James

  • Like 3

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...