Tron Arcade - Beta version.

[jbs30000]

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 .

 

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.

 

Tron.bas.binTronNotes.txt

[Nukey Shay]

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.

[jbs30000]

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.

[SeaGtGruff]

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

[jbs30000]

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, %00011000
end
BlueSpriteUp
asm
	LDA #<LightCycleUp
	STA player0pointerlo
	LDA #>LightCycleUp
	STA player0pointerhi
	LDA #7
	STA player0height
end

seems to work just fine.

[+batari]

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, %00011000
end
BlueSpriteUp
asm
	LDA #<LightCycleUp
	STA player0pointerlo
	LDA #>LightCycleUp
	STA player0pointerhi
	LDA #7
	STA player0height
end

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.

[Vic George 2K3]

Can we have pics of your progress posted, please?

[gambler172]

Nice

greetings gambler172

[jbs30000]

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, %00011000
end
BlueSpriteUp
asm
	LDA #<LightCycleUp
	STA player0pointerlo
	LDA #>LightCycleUp
	STA player0pointerhi
	LDA #7
	STA player0height
end

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 .

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

[jbs30000]

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.

 

 

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

[jbs30000]

Nice

greetings gambler172

Thanks.

[Jess Ragan]

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

 

JR

[Vic George 2K3]

Not bad for something made in Batari BASIC.

[tjb]

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

[haroldoop]

Very nice game!

[mos6507]

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.

[jbs30000]

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.

[lucifershalo]

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

[jbs30000]

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

 

[+atari2600land]

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 March 28, 2007 by atari2600land

[Lord Helmet]

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

[jjsonique]

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

 

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

[jbs30000]

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.

[jbs30000]

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.

[Gregory DG]

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