Help making bB act like the old version

[ibogost]

I'm about to assign my annual Batari Basic projects in my class at Georgia Tech. Before xmas we'll have 30 new Atari games. However, I have a problem. Up until now I've been using the earlier version of bB. Version 1.0 of bB does too much.

 

To be frank, I don't like the additions, for my purposes. I don't like the ability to bank switch to 32k, I don't like the support for superchip RAM, I don't like the multisprite kernel. I know this is probably unimaginable for most of you, but the reason I use bB is precisely APPLY the constraints of the machine circa 1980 or so.

 

So, I'm hoping someone here can tell me how much "set legacy" restores of these old constraints. Do I need to do anything else to apply the 4k, 2 sprite kernel limitation?

 

Thanks in advance.

[Bryan]

I understand your question, but to really get a feel for programming at Atari in the late 70's you need to set up a minimal 6502 assembler on a VAX mainframe and make them all share time on a small number of terminals. Oh yes, you'll also need a slow, wide line printer and a klunky EPROM burner. Personally, I can't believe anything got done!

[+batari]

I'm about to assign my annual Batari Basic projects in my class at Georgia Tech. Before xmas we'll have 30 new Atari games. However, I have a problem. Up until now I've been using the earlier version of bB. Version 1.0 of bB does too much.

 

To be frank, I don't like the additions, for my purposes. I don't like the ability to bank switch to 32k, I don't like the support for superchip RAM, I don't like the multisprite kernel. I know this is probably unimaginable for most of you, but the reason I use bB is precisely APPLY the constraints of the machine circa 1980 or so.

 

So, I'm hoping someone here can tell me how much "set legacy" restores of these old constraints. Do I need to do anything else to apply the 4k, 2 sprite kernel limitation?

 

Thanks in advance.

The reason for the "legacy" command was for compatibility with older binaries, as the horizontal positioning routine was changed for one that runs a little faster and actually places the objects where you think they should appear (i.e. zero=left edge, 159=right edge.) The end result is that the objects in new routine will be placed 14 pixels to the left of where the old routine placed them, so old binaries will probably not run correctly unless the option is used.

 

Legacy doesn't constrain RAM/ROM or kernel options, but since these things are only used if specifically invoked, older binaries compiled under 1.0 still won't use them. In that sense, the pre-1980 experience is still there if you want it to be.

Edited November 18, 2007 by batari

[ibogost]

I understand your question, but to really get a feel for programming at Atari in the late 70's you need to set up a minimal 6502 assembler on a VAX mainframe and make them all share time on a small number of terminals. Oh yes, you'll also need a slow, wide line printer and a klunky EPROM burner. Personally, I can't believe anything got done!

 

Yeah, I know what you mean. I'm speaking of the aesthetics of the system in its earliest state tho. I also teach a different course where we do what you suggest -- without the VAX tho -- and it's great fun.

[ibogost]

The reason for the "legacy" command was for compatibility with older binaries, as the horizontal positioning routine was changed for one that runs a little faster and actually places the objects where you think they should appear (i.e. zero=left edge, 159=right edge.) The end result is that the objects in new routine will be placed 14 pixels to the left of where the old routine placed them, so old binaries will probably not run correctly unless the option is used.

 

Legacy doesn't constrain RAM/ROM or kernel options, but since these things are only used if specifically invoked, older binaries compiled under 1.0 still won't use them. In that sense, the pre-1980 experience is still there if you want it to be.

 

Excellent, thanks for the quick reply. I have a lot of sample code from previous terms that students might want to use. Is there any harm in having them set legacy, or should I really avoid that.

 

The RAM and kernel options are now clear thanks to your explanation.

[potatohead]

Is there any good reason not to just continue to use the older bB releases?

 

The one I used to write Ooze had few issues. Can't remember which one it was now, but it was solid overall.

 

Who would have thought somebody would come back and say "Batari Basic does too much?" (Big grin over here Batari!)

Edited November 18, 2007 by potatohead

[ibogost]

Is there any good reason not to just continue to use the older bB releases?

 

The one I used to write Ooze had few issues. Can't remember which one it was now, but it was solid overall.

 

Yeah there were a number of quirks and bugs that got fixed, which is great. Also I didn't keep the old binaries around. And the new reference is really quite good (the old one was great too, but the new one is even better).

 

Who would have thought somebody would come back and say "Batari Basic does too much?" (Big grin over here Batari!)

 

Hahaha, totally. And I realized I probably sounded like a total ass in my original post. This is an awesome little toolkit and I greatly appreciate having it!

[+batari]

The reason for the "legacy" command was for compatibility with older binaries, as the horizontal positioning routine was changed for one that runs a little faster and actually places the objects where you think they should appear (i.e. zero=left edge, 159=right edge.) The end result is that the objects in new routine will be placed 14 pixels to the left of where the old routine placed them, so old binaries will probably not run correctly unless the option is used.

 

Legacy doesn't constrain RAM/ROM or kernel options, but since these things are only used if specifically invoked, older binaries compiled under 1.0 still won't use them. In that sense, the pre-1980 experience is still there if you want it to be.

 

Excellent, thanks for the quick reply. I have a lot of sample code from previous terms that students might want to use. Is there any harm in having them set legacy, or should I really avoid that.

 

The RAM and kernel options are now clear thanks to your explanation.

The legacy option will use 24 additional bytes of ROM space and uses some time in the vblank area, but for what you're doing, this probably doesn't matter.

[potatohead]

I know what you mean about complexity.

 

When I was working with the older bB, there was just enough to explore a game concept, but not much else. It forced me to consider the dynamics of the thing first, then consider how to realize it on the machine. The two were connected in an interesting way. Also, expectations being low, means a higher tolerance for abstractions and simplifications.

 

Getting "the game" done mattered, because not much else could!

 

Now it's easier to lose scope. There is the game dynamic idea, and it's implementation. Now, with so many options, implementation can take on a life of it's own, sometimes impacting the pure game idea in a negative way. I'm gonna revisit Ooze, my first Batari Basic project, here soon. It's a whole different animal now, and while I think some of the advances will totally make for a better game experience, I also find that added complexity less fun and more work.

 

Also, I think if I had started Ooze now, instead of then, my idea of how the game dynamic should go, would be different as well. The limitations have an impact on this, that's not always for the best, IMHO.

 

Really, those limitations and that time (80's in particular), are key to seeing the art. I realize now, more fully, why you have this element in your course.

 

None of this is a Batari Basic negative though. It's absolutely a wonderful project. And just look at the stuff people are doing! All very good to see and enjoy. Just want to make that clear to Batari