16 replies to this topic

[atari2600land]

With Stella's Stocking now out, and with Jumpman being considered as a 64k game, is it possible and/or practical to have bB make 64k games? What needs to be done in order to make this possible?

[SeaGtGruff]

atari2600land, on Wed Feb 27, 2008 11:38 PM, said:

With Stella's Stocking now out, and with Jumpman being considered as a 64k game, is it possible and/or practical to have bB make 64k games? What needs to be done in order to make this possible?

Yes, it's certainly possible. What needs to be done? It depends on the bank-switching method. 4A50 can do 128K games with 32K extra RAM. The problem is, bB can be modified by end users like me to add other bankswitching schemes, but those other schemes will be cumbersome to use in bB until the compiler is changed to work with them. I'm sidetracked with other things right now, otherwise I would have posted another addition to my 4A50 thread last Sunday night.

Michael

[batari]

I've been thinking about this. The problem is that bB relies on the state of the upper 3 address bits (which aren't connected to the 6507) to determine what bank it's currently in and to determine what bank to return to when it encounters a return. It works well because it doesn't use any unnecessary RAM, and the bits are set automatically. If the banks match, bB skips the bankswitch access. But with 3 bits, you can only support 8 banks.

So in order to seamlessly support 64k, bB would need to push another byte on the stack for each subroutine so it knew what bank it's in and where to return to. Cross-bank subroutines already push several bytes on the stack, but I can't think of any reasonable alternative.

The upside of pushing another byte is that the new limit goes up to 512k

[SeaGtGruff]

batari, on Thu Feb 28, 2008 2:15 AM, said:

I've been thinking about this. The problem is that bB relies on the state of the upper 3 address bits (which aren't connected to the 6507) to determine what bank it's currently in and to determine what bank to return to when it encounters a return. It works well because it doesn't use any unnecessary RAM, and the bits are set automatically. If the banks match, bB skips the bankswitch access. But with 3 bits, you can only support 8 banks.

So in order to seamlessly support 64k, bB would need to push another byte on the stack for each subroutine so it knew what bank it's in and where to return to. Cross-bank subroutines already push several bytes on the stack, but I can't think of any reasonable alternative.

The upside of pushing another byte is that the new limit goes up to 512k

In my initial includes for 4A50, I used RORG addresses that were just $F000, $F800, $FE00, or $FF00, because I figured there weren't enough 16-bit addresses to assign unique RORG addresses to each bank. But last week I realized that you can have RORG addresses larger than 16 bits, and DASM will still use just 2 bytes (16 bits) when referring to the addresses in the actual code! So now I'm assigning unique RORG addresses to all banks:

$001000 through $03F000 for the lower-region banks (numbered 0 through 31)
$001800 through $01F800 for the middle-region banks (numbered 0 through 15)
$001E00 through $1FFE00 for the upper-region banks (numbered 0 through 255)

I've currently got a "4a50_macro.h" include file with macros for declaring the start of a given bank-- one macro for starting a new lower-region bank, a second macro for starting a new middle-region bank, and a third macro for starting a new upper-region bank-- and each macro also displays the number of bytes free in the previous bank. I use the "." in the macros to get the current 3-byte address (for determining the number of bytes free in the previous bank), and then I calculate the ORG and RORG addresses for the new bank based on the bank number. I'm now working on macros for other things, such as switching to a particular bank, or doing a goto or gosub to a different bank, etc.

The problem is that, to call a macro within the bB program, the programmer will need to use "asm," which will be kind of messy. But when (or if) you officially add 4A50 support to bB, the macros would be taken care of by the compiler-- i.e., the macros would be replaced by new bB commands, and when the compiler sees a particular command, it would insert the appropriate assembly code for that command.

Michael

[Random Terrain]

batari, on Thu Feb 28, 2008 3:15 AM, said:

The upside of pushing another byte is that the new limit goes up to 512k

Holy cow! I hope that will be included in the next bB update!

Did anyone else see that?

512k

[Allan]

Random Terrain, on Wed Mar 12, 2008 1:41 PM, said:

batari, on Thu Feb 28, 2008 3:15 AM, said:

The upside of pushing another byte is that the new limit goes up to 512k

Holy cow! I hope that will be included in the next bB update!

Did anyone else see that?

512k

I love that little picture, RT. Yea, 512K 2600 games would be almost un-real.

Allan

[SeaGtGruff]

Allan, on Wed Mar 12, 2008 2:07 PM, said:

Random Terrain, on Wed Mar 12, 2008 1:41 PM, said:

batari, on Thu Feb 28, 2008 3:15 AM, said:

The upside of pushing another byte is that the new limit goes up to 512k

Holy cow! I hope that will be included in the next bB update!

Did anyone else see that?

512k

I love that little picture, RT. Yea, 512K 2600 games would be almost un-real.

Allan

I don't think he was talking about 512K ROMs, he was talking about the RORG statements. The maximum ROM size would depend on the bankswitching method used. I know the 4A50 bankswitching scheme can go up to 128K ROMs, but I'm not sure if there are any that go up to 512K ROM-- Tigervision, perhaps? Right now, bB doesn't support Tigervision.

Michael

[batari]

SeaGtGruff, on Wed Mar 12, 2008 1:43 PM, said:

Allan, on Wed Mar 12, 2008 2:07 PM, said:

Random Terrain, on Wed Mar 12, 2008 1:41 PM, said:

batari, on Thu Feb 28, 2008 3:15 AM, said:

The upside of pushing another byte is that the new limit goes up to 512k

Holy cow! I hope that will be included in the next bB update!

Did anyone else see that?

512k

I love that little picture, RT. Yea, 512K 2600 games would be almost un-real.

Allan

I don't think he was talking about 512K ROMs, he was talking about the RORG statements. The maximum ROM size would depend on the bankswitching method used. I know the 4A50 bankswitching scheme can go up to 128K ROMs, but I'm not sure if there are any that go up to 512K ROM-- Tigervision, perhaps? Right now, bB doesn't support Tigervision.

Michael

Superbanking supports 256k (I worked on this scheme a few months ago and built a prototype.) The next version of Stella should support it, as will bB (eventually.) I came up with this scheme so I'd have enough space for a game that I hope to finish someday.

However, I should be working on bB and getting another release out there, even if it's just releasing the work I've already done over the past year.

[Random Terrain]

batari, on Thu Mar 13, 2008 3:56 AM, said:

Superbanking supports 256k (I worked on this scheme a few months ago and built a prototype.) The next version of Stella should support it, as will bB (eventually.) I came up with this scheme so I'd have enough space for a game that I hope to finish someday.

256k is still pretty darn good.

256k

batari, on Thu Mar 13, 2008 3:56 AM, said:

However, I should be working on bB and getting another release out there, even if it's just releasing the work I've already done over the past year.

Do you have any drool-inducing hints about the new changes to come?

[batari]

Random Terrain, on Thu Mar 13, 2008 8:04 AM, said:

batari, on Thu Mar 13, 2008 3:56 AM, said:

Superbanking supports 256k (I worked on this scheme a few months ago and built a prototype.) The next version of Stella should support it, as will bB (eventually.) I came up with this scheme so I'd have enough space for a game that I hope to finish someday.

256k is still pretty darn good.

256k

batari, on Thu Mar 13, 2008 3:56 AM, said:

However, I should be working on bB and getting another release out there, even if it's just releasing the work I've already done over the past year.

Do you have any drool-inducing hints about the new changes to come?

There have been a lot of bugfixes and optimizations (e.g. in some cases, games may recover a few hundred bytes) and a couple of new commands added to the compiler.

I've started on scrolling in the multisprite kernel, and it's "sort of" working, and I have what I'm calling "vectors" working in the standard kernel, but need to add compiler support for them. By "vector," I mean you are able to turn a missile into a line or an arc connecting two points, for example like the Pitfall vines. Or you can also use a missile as a "fake player" by varying the width, or you can shift a player object per line to make it look more interesting, like the cows in Stampede or the dolphin in Dolphin. The only drawback to this is the HMOVE "comb" at the left edge of the screen, but there seems to be no way around that.

[SpiceWare]

batari, on Fri Mar 14, 2008 2:35 PM, said:

you can shift a player object per line to make it look more interesting, like the cows in Stampede or the dolphin in Dolphin.

Or the dragon in Medieval Mayhem

[batari]

SpiceWare, on Fri Mar 14, 2008 4:33 PM, said:

batari, on Fri Mar 14, 2008 2:35 PM, said:

you can shift a player object per line to make it look more interesting, like the cows in Stampede or the dolphin in Dolphin.

Or the dragon in Medieval Mayhem

I would have mentioned that but I think the dragon uses both players, and bB will only allow for one, and I didn't want to mislead anyone

[SpiceWare]

That's true, it does shift both player objects on each line.

[MausGames]

batari, on Fri Mar 14, 2008 3:35 PM, said:

There have been a lot of bugfixes and optimizations (e.g. in some cases, games may recover a few hundred bytes) and a couple of new commands added to the compiler.

I've started on scrolling in the multisprite kernel, and it's "sort of" working, and I have what I'm calling "vectors" working in the standard kernel, but need to add compiler support for them. By "vector," I mean you are able to turn a missile into a line or an arc connecting two points, for example like the Pitfall vines. Or you can also use a missile as a "fake player" by varying the width, or you can shift a player object per line to make it look more interesting, like the cows in Stampede or the dolphin in Dolphin. The only drawback to this is the HMOVE "comb" at the left edge of the screen, but there seems to be no way around that.

That sounds great, any sacrifices when using the missile in those ways? I especially like the "fake player" idea - will we be able to define more than one shape? Will it work with both missiles, or the ball? As far as bug fixes, what bothers me most is the mess that results from trying to use vertical scrolling with advanced kernel options. I think a "set debug_cyclescore vblank" would be a really useful addition, if possible. 1.0 is awesome though, you've done an amazing job.

[Random Terrain]

batari, on Fri Mar 14, 2008 4:35 PM, said:

There have been a lot of bugfixes and optimizations (e.g. in some cases, games may recover a few hundred bytes) and a couple of new commands added to the compiler.

I've started on scrolling in the multisprite kernel, and it's "sort of" working, and I have what I'm calling "vectors" working in the standard kernel, but need to add compiler support for them. By "vector," I mean you are able to turn a missile into a line or an arc connecting two points, for example like the Pitfall vines. Or you can also use a missile as a "fake player" by varying the width, or you can shift a player object per line to make it look more interesting, like the cows in Stampede or the dolphin in Dolphin. The only drawback to this is the HMOVE "comb" at the left edge of the screen, but there seems to be no way around that.

Great news. I want to try it all, but I especially want to play with the Pitfall-like vine and the wiggly sprites.

[batari]

I had to go back and look at my code to remember what I did.

If you use a vector, you lose the ball, and it appears that you can only use player1 or missile1. Also, using a vector seems to prevent you from using a multicolored P1. However, if shifting the missile per line, you can turn the missile on and off per line as well.

You can use the above to make the missile into a "fake player" (for example, a 4-wide missile shifted per line might resemble a lightning bolt, similar to that in Tossing Cookies.)

You should be able to vary the missile width per scanline, either 1, 2, 4 or 8 wide per scanline instead of shifting, but it appears that you will lack the ability to turn the missile on and off if you do this. I need to do a little more work to get this part working, but in theory it should work.

If you wish to use player1 shifted per-line, use of missile1 is limited in sort of a weird way. I'll get into that later.

I probably should attempt to integrate this into a beta release of bB so people can play with them and report bugs.

Lastly, I am now thinking that "vectors" are not a good name for these, because the term has another distinct meaning in programming. Any suggestions for another name?

Edited by batari, Sat Mar 15, 2008 1:40 AM.

[Random Terrain]

batari, on Sat Mar 15, 2008 3:38 AM, said:

Lastly, I am now thinking that "vectors" are not a good name for these, because the term has another distinct meaning in programming. Any suggestions for another name?

What about Dynamic Missiles as a general description and when you are specifically talking about the 'vine' type, you could call those Point to Point Dynamic Missiles.