Jump to content

Photo

Tron Arcade - Beta version.


30 replies to this topic

#1 jbs30000 OFFLINE  

jbs30000

    Moonsweeper

  • 472 posts

Posted Thu Mar 15, 2007 9:01 PM

This is the second time I'm typing this, the first attempt to post this got eaten up.

I made an Atari 2600 version of the Tron arcade game. It was a rush job, so it's riddled with problems, but I'm in the middle of working on a second version which won't only fix these problems, but also add some things, like score keeping :P .

Also, I have a question. I'm using 2 banks and I thought that maybe each bank would have 26 variables each, but after testing this, I found out that a-z seems to be universal, or only apply to bank 1. Even though I'm studying the asm output fom the bas files I compile, I'm still not that familiar with 6502 assembly or the 2600 memory layout, but I'm sure that there must be memory in each bank that I can use for variables using inline assembly. So if anybody can help me out, I'd appreciate it. Thank you.

Attached File  Tron.bas.bin   16KB   190 downloadsAttached File  TronNotes.txt   1.42KB   128 downloads

#2 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,707 posts
  • Location:The land of Gorch

Posted Thu Mar 15, 2007 9:36 PM

Ram memory and Rom memory are 2 seperate animals. While you can bankswitch to your heart's content (within reason) to make more rom space as long as you keep within the boundries according to that bankswitch scheme, the same is not true for Ram. The 2600 itself only offers 128 bytes of user ram...with some bits a little higher that can be configured to read/write...and that's if you are programming in pure assembly.
The ram variables are read/written the same way regardless of what rom bank you are in. So you need to try to reuse ram wherever you can. Got a variable that doesn't apply to this portion of the game? Reuse it for something else. Got a variable that only holds a value of 0-3? Use 2 bits to hold it instead of the full 8-bit byte.

#3 jbs30000 OFFLINE  

jbs30000

    Moonsweeper

  • Topic Starter
  • 472 posts

Posted Thu Mar 15, 2007 11:25 PM

Ram memory and Rom memory are 2 seperate animals.

Well yeah, I am aware of that. I've done programing for fun off an on for years, just not for an Atari, or 6502 CPU for that matter.

While you can bankswitch to your heart's content (within reason) to make more rom space as long as you keep within the boundries according to that bankswitch scheme, the same is not true for Ram. The 2600 itself only offers 128 bytes of user ram...with some bits a little higher that can be configured to read/write...and that's if you are programming in pure assembly.

OK, I understand, each bank is just ROM, rather than a mix of ROM and RAM. Makes sense.

The ram variables are read/written the same way regardless of what rom bank you are in. So you need to try to reuse ram wherever you can. Got a variable that doesn't apply to this portion of the game? Reuse it for something else. Got a variable that only holds a value of 0-3? Use 2 bits to hold it instead of the full 8-bit byte.

Yeah, I'm familiar with all that already. Only having 128 bytes (or 26 bytes using Batari Basic) isn't going to be a problem.

Thank you for answering my question.

#4 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,558 posts
  • Location:Georgia, USA

Posted Thu Mar 15, 2007 11:35 PM

I'm using 2 banks and I thought that maybe each bank would have 26 variables each, but after testing this, I found out that a-z seems to be universal, or only apply to bank 1. Even though I'm studying the asm output fom the bas files I compile, I'm still not that familiar with 6502 assembly or the 2600 memory layout, but I'm sure that there must be memory in each bank that I can use for variables using inline assembly.

Here's a very simplified memory map of the Atari 2600 VCS (I'm using hex addresses):

$0000 to $002C = TIA chip

$0080 to $00FF = RAM (RIOT chip)

$0280 to $0285 = I/O (RIOT chip)

$0294 to $0297 = Timer (RIOT chip)

$1000 to $1FFF = Cartridge slot (4K)

Due to the way the 6507 CPU is designed (i.e., with only 13 address pins instead of 16 address pins), it can address or "see" only 8K of memory, therefore the rest of the 64K contains mirror images of the primary 8K address space. And due to the way the TIA and RIOT chips are designed-- especially the way they're connected to the 6507's address pins-- the memory locations which are shown above for the TIA and RIOT chips are mirrored throughout the primary 8K address space. But all of that mirroring doesn't really matter as far as your question is concerned-- I'm just trying to give you a very simplified picture of how the 2600's memory is mapped out, without going into too many details.

So what you have are 128 bytes of RAM at addresses $0080 through $00FF, and 4K of cartridge ROM plugged into addresses $1000 through $1FFF. To create an 8K game, you need to use some kind of bankswitching to swap the ROM. Most 8K carts use a bankswitching method that swaps out all 4K of the cart memory area, although some bankswitching methods swap smaller banks (e.g., 2K banks or 1K banks).

Anyway, the RAM and ROM are in two completely different areas of memory, and swapping between two or more ROM banks to get carts that are 8K, 12K, 16K, 32K, etc., doesn't have any effect on the RAM-- you're still stuck with only 128 bytes of RAM.

However, some carts have extra RAM added to them. As far as I know, only bankswitched carts have any extra RAM (i.e., no 2K or 4K carts were ever produced with extra RAM in them)-- but don't assume that bankswitching automatically adds extra RAM, because not all bankswitched carts have extra RAM. Some of the schemes that add extra RAM have a set amount of extra RAM that's always in the same spot within the cart memory, and the extra RAM never changes as you swap banks. This is how the Superchip works-- it adds 128 bytes of extra RAM at the beginning of the cart area, and those 128 bytes of RAM do *not* get swapped as you swap banks. But there are a few bankswitching schemes that add multiple *banks* of extra RAM, and you can select between those RAM banks the same way you can select ROM banks. The classic example would be M-Network's E7 bankswitching scheme, which has a 1K RAM bank that can be selected at one area of the cart memory, and four separate 256-byte RAM banks that can be swapped around at a different area of the cart memory. On the other hand, the new 4A50 bankswitching scheme has 32K of extra RAM that can be swapped around at three different memory areas in chunks of 2K, 1.5K, or 256 bytes of RAM.

As far as batari Basic programs are concerned, the only "official" way to use any extra RAM at this time is to specify the Superchip option in your program, which doubles the amount of available RAM by adding an extra 128 bytes of RAM. A while back, I unofficially modified batari Basic version 0.35 to allow M-Network's E7 bankswitching scheme to be used, but there are three drawbacks to using that modified version: (1) it doesn't include the enhancements that were made to batari Basic after version 0.35; (2) it was a bit cumbersome to use; and-- most importantly-- (3) there are no modern homebrew carts that replicate the M-Network E7 bankswitching method, so if you write a game using that method, you won't be able to produce carts and sell your game!

Thus, at present the best way to get more RAM variables in your batari Basic games is to specify the Superchip option. All you have to do is add "SC" to the romsize, as follows:

For an 8K game that uses the Superchip:
set romsize 8kSC

For a 16K game that uses the Superchip:
set romsize 16kSC

For a 32K game that uses the Superchip:
set romsize 32kSC

Be sure to read the version 1.0 documentation for information on how to use the Superchip RAM. :)

Note that if you create a batari Basic game with the Superchip option, you *can* have carts made and sell your game, because there are modern homebrew boards available with the Superchip! :)

Michael

#5 jbs30000 OFFLINE  

jbs30000

    Moonsweeper

  • Topic Starter
  • 472 posts

Posted Fri Mar 16, 2007 3:08 AM

I'm using 2 banks and I thought that maybe each bank would have 26 variables each, but after testing this, I found out that a-z seems to be universal, or only apply to bank 1. Even though I'm studying the asm output fom the bas files I compile, I'm still not that familiar with 6502 assembly or the 2600 memory layout, but I'm sure that there must be memory in each bank that I can use for variables using inline assembly.

Here's a very simplified memory map of the Atari 2600 VCS (I'm using hex addresses):

$0000 to $002C = TIA chip

$0080 to $00FF = RAM (RIOT chip)

$0280 to $0285 = I/O (RIOT chip)

$0294 to $0297 = Timer (RIOT chip)

$1000 to $1FFF = Cartridge slot (4K)

Due to the way the 6507 CPU is designed (i.e., with only 13 address pins instead of 16 address pins), it can address or "see" only 8K of memory, therefore the rest of the 64K contains mirror images of the primary 8K address space. And due to the way the TIA and RIOT chips are designed-- especially the way they're connected to the 6507's address pins-- the memory locations which are shown above for the TIA and RIOT chips are mirrored throughout the primary 8K address space. But all of that mirroring doesn't really matter as far as your question is concerned-- I'm just trying to give you a very simplified picture of how the 2600's memory is mapped out, without going into too many details.

So what you have are 128 bytes of RAM at addresses $0080 through $00FF, and 4K of cartridge ROM plugged into addresses $1000 through $1FFF. To create an 8K game, you need to use some kind of bankswitching to swap the ROM. Most 8K carts use a bankswitching method that swaps out all 4K of the cart memory area, although some bankswitching methods swap smaller banks (e.g., 2K banks or 1K banks).

Anyway, the RAM and ROM are in two completely different areas of memory, and swapping between two or more ROM banks to get carts that are 8K, 12K, 16K, 32K, etc., doesn't have any effect on the RAM-- you're still stuck with only 128 bytes of RAM.

However, some carts have extra RAM added to them. As far as I know, only bankswitched carts have any extra RAM (i.e., no 2K or 4K carts were ever produced with extra RAM in them)-- but don't assume that bankswitching automatically adds extra RAM, because not all bankswitched carts have extra RAM. Some of the schemes that add extra RAM have a set amount of extra RAM that's always in the same spot within the cart memory, and the extra RAM never changes as you swap banks. This is how the Superchip works-- it adds 128 bytes of extra RAM at the beginning of the cart area, and those 128 bytes of RAM do *not* get swapped as you swap banks. But there are a few bankswitching schemes that add multiple *banks* of extra RAM, and you can select between those RAM banks the same way you can select ROM banks. The classic example would be M-Network's E7 bankswitching scheme, which has a 1K RAM bank that can be selected at one area of the cart memory, and four separate 256-byte RAM banks that can be swapped around at a different area of the cart memory. On the other hand, the new 4A50 bankswitching scheme has 32K of extra RAM that can be swapped around at three different memory areas in chunks of 2K, 1.5K, or 256 bytes of RAM.

As far as batari Basic programs are concerned, the only "official" way to use any extra RAM at this time is to specify the Superchip option in your program, which doubles the amount of available RAM by adding an extra 128 bytes of RAM. A while back, I unofficially modified batari Basic version 0.35 to allow M-Network's E7 bankswitching scheme to be used, but there are three drawbacks to using that modified version: (1) it doesn't include the enhancements that were made to batari Basic after version 0.35; (2) it was a bit cumbersome to use; and-- most importantly-- (3) there are no modern homebrew carts that replicate the M-Network E7 bankswitching method, so if you write a game using that method, you won't be able to produce carts and sell your game!

Thus, at present the best way to get more RAM variables in your batari Basic games is to specify the Superchip option. All you have to do is add "SC" to the romsize, as follows:

For an 8K game that uses the Superchip:
set romsize 8kSC

For a 16K game that uses the Superchip:
set romsize 16kSC

For a 32K game that uses the Superchip:
set romsize 32kSC

Be sure to read the version 1.0 documentation for information on how to use the Superchip RAM. :)

Note that if you create a batari Basic game with the Superchip option, you *can* have carts made and sell your game, because there are modern homebrew boards available with the Superchip! :)

Michael

Holly cow, so much detail in that post, you really know your stuff.

Well, I might have a use for the Superchip option in the future, but for what I'm working on now, I think the 26 variable limit will do.

If you don't mind, I have one more question, which is neither here nor there, I'm just asking out of curiosity.

When I studied the asm for assigning sprite designs for players 0 & 1 I noticed something interesting. I noticed that a .data 0 is added to the sprite data statements so that the player0height or player1height matches the number of rows after a player0: or player1: statement, but I'm just curious why since
data LightCycleUp  %00011000, %00100100, %01100110, %01100110,  %00100100, %01100110, %00100100, %00011000endBlueSpriteUp asm 	LDA #<LightCycleUp 	STA player0pointerlo 	LDA #>LightCycleUp 	STA player0pointerhi 	LDA #7 	STA player0heightend
seems to work just fine.

#6 batari OFFLINE  

batari

    )66]U('=I;B$*

  • 6,666 posts
  • begin 644 contest

Posted Fri Mar 16, 2007 4:44 AM

When I studied the asm for assigning sprite designs for players 0 & 1 I noticed something interesting. I noticed that a .data 0 is added to the sprite data statements so that the player0height or player1height matches the number of rows after a player0: or player1: statement, but I'm just curious why since

data LightCycleUp  %00011000, %00100100, %01100110, %01100110,  %00100100, %01100110, %00100100, %00011000endBlueSpriteUp asm 	LDA #<LightCycleUp 	STA player0pointerlo 	LDA #>LightCycleUp 	STA player0pointerhi 	LDA #7 	STA player0heightend
seems to work just fine.

That's a really good question. The zeros were needed at one time (i.e. before VDEL was used in the kernel), and although they aren't technically needed anymore, removing them would have shifted all sprites down by one pixel, so it was left in for reverse compatibility.

But now that you mention it, there is probably a better solution that may take a little space to implement but will save one byte for every sprite, so I'll look into this.

#7 Vic George 2K3 OFFLINE  

Vic George 2K3

    Quadrunner

  • 5,598 posts
  • I was corn this way.
  • Location:Westfield, MA, USA

Posted Fri Mar 16, 2007 12:06 PM

Can we have pics of your progress posted, please?

#8 gambler172 OFFLINE  

gambler172

    River Patroller

  • 3,142 posts
  • none
  • Location:germany

Posted Fri Mar 16, 2007 12:27 PM

:) Nice
greetings gambler172

#9 jbs30000 OFFLINE  

jbs30000

    Moonsweeper

  • Topic Starter
  • 472 posts

Posted Fri Mar 16, 2007 1:01 PM

When I studied the asm for assigning sprite designs for players 0 & 1 I noticed something interesting. I noticed that a .data 0 is added to the sprite data statements so that the player0height or player1height matches the number of rows after a player0: or player1: statement, but I'm just curious why since

data LightCycleUp  %00011000, %00100100, %01100110, %01100110,  %00100100, %01100110, %00100100, %00011000endBlueSpriteUp asm 	LDA #<LightCycleUp 	STA player0pointerlo 	LDA #>LightCycleUp 	STA player0pointerhi 	LDA #7 	STA player0heightend
seems to work just fine.

That's a really good question. The zeros were needed at one time (i.e. before VDEL was used in the kernel), and although they aren't technically needed anymore, removing them would have shifted all sprites down by one pixel, so it was left in for reverse compatibility.

But now that you mention it, there is probably a better solution that may take a little space to implement but will save one byte for every sprite, so I'll look into this.

Wow, I might have actually made a difference, I fee so honored :cool: .
Of course at one byte per sprite, people may not notice a difference unless they have a bunch of sprite definitions in their program. But I still want you to go ahead and see about changing this, so that I can claim the credit for the idea :D

#10 jbs30000 OFFLINE  

jbs30000

    Moonsweeper

  • Topic Starter
  • 472 posts

Posted Fri Mar 16, 2007 1:13 PM

Can we have pics of your progress posted, please?

I assume you're talking about my program. I tried to put one in the announcement post, but got a strange error. I'll try again. Here's the new...I guess it would be a main menu. It's the same, except I've added a counter in the middle that, just like in the arcade game, will count down and then choose a game for you if you don't select on yourself.

Also, I changed the score graphics so that the numbers are like those in the arcade game, and I included the life counter and defined the life counter sprite to, again, look like what's in the arcade game.

Tron2.PNG

I tried to move the life sprites over using dim lives_centered=1, but it didn't change their position at all.

#11 jbs30000 OFFLINE  

jbs30000

    Moonsweeper

  • Topic Starter
  • 472 posts

Posted Fri Mar 16, 2007 1:14 PM

:) Nice
greetings gambler172

Thanks.

#12 Jess Ragan OFFLINE  

Jess Ragan

    Phanto of the Opera

  • 9,701 posts
  • Keys and Thank You
  • Location:The Arid Zone

Posted Sat Mar 17, 2007 2:32 AM

You're tackling all four mini-games? Ambitious!

JR

#13 Vic George 2K3 OFFLINE  

Vic George 2K3

    Quadrunner

  • 5,598 posts
  • I was corn this way.
  • Location:Westfield, MA, USA

Posted Sat Mar 17, 2007 6:26 AM

Not bad for something made in Batari BASIC.

#14 tjb OFFLINE  

tjb

    Stargunner

  • 1,030 posts
  • Let's play soccer
  • Location:San Antonio, Texas

Posted Sat Mar 17, 2007 7:17 AM

Wow, that's pretty cool! I can't believe you were able to support all 4 games! Impressive. This will make a great addition to the 2600 library.

tjb

#15 haroldoop OFFLINE  

haroldoop

    Star Raider

  • 96 posts
  • Location:Brazil

Posted Sat Mar 17, 2007 10:39 AM

Very nice game!

#16 mos6507 OFFLINE  

mos6507

    River Patroller

  • 4,915 posts

Posted Sat Mar 17, 2007 11:34 AM

Great potential here.

The key to playing the breakout level is being able to move your guy in both axes. You are moving the guy up on a rail to avoid scrolling the cone. You should come up with a way to scroll the cone instead.

#17 jbs30000 OFFLINE  

jbs30000

    Moonsweeper

  • Topic Starter
  • 472 posts

Posted Sun Mar 18, 2007 1:14 PM

Jess Ragan, Vic George 2K3, tjb, and haroldop, thank you very much.

Besides getting rid of all the problems from the first version, I'm also doing everything I can to make the game come closer to matching the arcade. Looking at the message board, in the Hombrew Discussion they're talking about a 2600 version of Tron and one of the things someone mentioned was doing the dual set up of the joystick to move the player and use a paddle to move the arm just like the spinner does in the arcade version. I'm really thinking about doing that even though it'll be slightly more complex and involve a lot more sprites. Although I'll probably finish this version that just uses the joystick first and then do the joystick/paddle combo as another release.

Oh, and something I could use help on, music and sound effects. I was able to get a simple beep when the tanks fired at each other, but I don't know how to do anything like car or tank moving noises, if anybody could help me with that, I'd appreciate it. And if I knew how to read sheet music, I'd find some from the arcade and use WebTune2600 to play it on the Atari.

Oh, and mos6507, I'm definitely planning on making the MPC cone drop down. In the last version I used a variable to hold which row to start rotating the blocks. At a regular timed inverval, I would use pfhline to turn off all the pixels across the bottom of the screen, then scroll the screen down by 1 and increase the variable. But for some reason not only did the blocks not rotate right after the first scroll, but I couldn't scroll the screen down more than 3 times. But at any rate, in this version I'll just do things somewhat differently and drop the cone down.

#18 lucifershalo OFFLINE  

lucifershalo

    River Patroller

  • 2,934 posts
  • Location:Belgium

Posted Sun Mar 18, 2007 3:39 PM

wow, u have my support
and everytime that u post an updated bin file
I will test it on gp2x and onto a real 2600

#19 jbs30000 OFFLINE  

jbs30000

    Moonsweeper

  • Topic Starter
  • 472 posts

Posted Mon Mar 26, 2007 4:06 PM

Minor Update.
It took me about a week, but I finally finished.....the tank game. I had to rewrite the sucker about 3 or 4 times but it's finally done. I focused on that because it's the hardest game for me to write. With maybe the exception of the grid spiders game, all the rest should be a peice of cake.

Let's see, other than that. I redid the Tron sprites and the tank sprites. I read that in the arcade version, there's like, 11 or 12 levels, mine only has 3, but when I post the program here, I'll also post the code so anybody who can improve it will be more than welcome. I toyed with trying a superchip version so that I can use a 32x32 screen for backgrounds that are more faithful to the arcade, but I have to rearange some code because simply adding an SC to the romsize gives me a blank screen. Anyway, here's a couple of pictures. The first is from the tank game, and the second shows how I've redrawn Tron himself. I tried doing a print screen to capture the third level of the tank game, since it has 3 enemy tanks, but only 1 tank shows (and not that it makes a difference, but I'm not using the multisprite kernel).

Tron1.PNG Tron2.PNG

#20 atari2600land ONLINE  

atari2600land

    Waffles:

  • 10,979 posts
  • Man's best invention. Ever.
  • Location:Salem, Oregon

Posted Wed Mar 28, 2007 1:29 PM

I have a suggestion. IMHO, the Surround-type level begins and ends too fast. One minute you're pressing left or right to avoid the guy, and then once you've hit the wall, you're pressing left or right on the game select screen and it chooses another game. At least that's how it is for me.

Edited by atari2600land, Wed Mar 28, 2007 1:30 PM.


#21 Lord Helmet OFFLINE  

Lord Helmet

    Don't forget your helmet!

  • 9,988 posts
  • Location:Denver, CO.

Posted Wed Mar 28, 2007 1:33 PM

Looks good...especially for a batari basic game. Keep it up!

#22 jjsonique OFFLINE  

jjsonique

    Space Invader

  • 30 posts

Posted Thu Mar 29, 2007 10:14 AM

Just another vote of "this is great! please continue!" :thumbsup:

I do agree with the statement above that the cycle race sequence would be better with pauses both before and after it.

#23 jbs30000 OFFLINE  

jbs30000

    Moonsweeper

  • Topic Starter
  • 472 posts

Posted Thu Mar 29, 2007 7:23 PM

I'm working on the cycle game right now. I noticed that problem too and will eliminate it in the version I'm working on.

#24 jbs30000 OFFLINE  

jbs30000

    Moonsweeper

  • Topic Starter
  • 472 posts

Posted Sun Apr 1, 2007 7:59 PM

OK, minor update, I now have 50% of the game done. The Tank and MPC Cone games. I have sound effects for them, although I don't have a sound effect for either tank firing at each other, but I do have the low rumble and the beep beep that's constantly in the background. In the cone game the boomp sound that's made as the blocks rotate is similar, but compared with original, noticeably different, and the sound of firing the disk sounds different too.

I'm going to start the grid spiders (or sometimes called grid bugs) game now. And I'll probably have to start completely over with the light cycle game after that.

#25 Gregory DG OFFLINE  

Gregory DG

    TAT IS BACK!

  • 11,228 posts
  • Go Cardinals!
  • Location:Winter Haven, FL

Posted Sun Apr 1, 2007 9:00 PM

I like what you've got so far! It's about time there was a proper TRON Arcade game ported to SOME system! (I know it's in the GBA Tron 2.0 game, but it's a hidden game.)




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users