21 replies to this topic

[SeaGtGruff]

I've started writing a tutorial series about batari BASIC programming, aimed at beginners, but I have a few questions for everyone before I get too involved in it, since the answers will determine how I should proceed.

(1) The tutorial is intended for beginners, so I'm assuming the reader isn't already familiar with the technical details of the Atari's registers, features, etc. For this reason, I'm trying to explain these things as they come up. For example, if I'm about to do "COLUBK = $06", I first explain that "COLUBK" is a register whose name is short for "the color and luminance of the background," and then I discuss the Atari's colors-- how the high-nibble specifies the hue (and what the hues are), how the low-nibble specifies the luminance, and therefore this means hexadecimal notation works best for specifying a particular color value.

Question: Would that sort of detailed explanation be too boring for the readers, or is it the kind of information that beginners need to know?

(2) Since bB is still very much in development, with possible changes occurring from one version to the next (e.g., changing the bit-reference character from parentheses to curly-brackets), I thought it would be good to start the tutorial with version 0.1 Alpha, and then quickly progress through the other releases, so I can actually illustrate the process of modifying an existing bB program to work with a newer release. After all, anything I write could become outdated by a new release, so I'd like to work that into the tutorial. Each time a new version is released, I can describe the changes that would be needed, and also show how something that was done a particular way in an older version could be done more easily or more cleanly in a newer version.

Question: Is that a good idea, or will people dislike having to start with 0.1 Alpha?

(3) I'm already working on a game of my own, and I want to include a game in the tutorial series, but working on the tutorial will cut into development time for my own game. For that reason, I decided to use my own game as the example, so I can develop it and write the tutorial at the same time. I also plan to include other games as the series continues, since each type of game can have its own set of special needs.

Question: Do you think readers would be interested in following the development of my adventure game, or would that seem too egotistical/self-serving?

Thank you in advance for any answers or other comments.

Michael Rideout

[Random Terrain]

SeaGtGruff, on Thu Sep 1, 2005 1:01 AM, said:

(1) The tutorial is intended for beginners, so I'm assuming the reader isn't already familiar with the technical details of the Atari's registers, features, etc. For this reason, I'm trying to explain these things as they come up. For example, if I'm about to do "COLUBK = $06", I first explain that "COLUBK" is a register whose name is short for "the color and luminance of the background," and then I discuss the Atari's colors-- how the high-nibble specifies the hue (and what the hues are), how the low-nibble specifies the luminance, and therefore this means hexadecimal notation works best for specifying a particular color value.

Right, I hardly ever remember what abbreviated things mean, so it helps to have it spelled out like I have here:

http://www.randomter...nds.html#colors

I also never remember the difference between hue and luminance unless I look them up since the words seem like they came from another planet. Maybe you could explain the roots of the words so it makes more sense. When I tried to learn Assembly language back in the early 1980s, I learned the most basic thing there is to know about hex numbers. It wasn't hard to learn that A to F was 10 to 15, so maybe a newbie will understand. I kept my color chart decimal though since I always have to go back to the chart. There is no way that I can remember all 16 colors and what order they are in, so I'd always have to look up the hex number and if I have to look that up, I can just as easily use the decimal number which I like to use better anyway.

SeaGtGruff, on Thu Sep 1, 2005 1:01 AM, said:

Question: Would that sort of detailed explanation be too boring for the readers, or is it the kind of information that beginners need to know?

Detail is good if you use common words and put things in logical chunks. Some long, boring explanation full of big words and jargon would not be helpful, so keep it as simple as possible.

SeaGtGruff, on Thu Sep 1, 2005 1:01 AM, said:

(2) Since bB is still very much in development, with possible changes occurring from one version to the next (e.g., changing the bit-reference character from parentheses to curly-brackets), I thought it would be good to start the tutorial with version 0.1 Alpha, and then quickly progress through the other releases, so I can actually illustrate the process of modifying an existing bB program to work with a newer release. After all, anything I write could become outdated by a new release, so I'd like to work that into the tutorial. Each time a new version is released, I can describe the changes that would be needed, and also show how something that was done a particular way in an older version could be done more easily or more cleanly in a newer version.

Question: Is that a good idea, or will people dislike having to start with 0.1 Alpha?

People would dislike it. No one wants to use a semi-broken version of the language. They will use the latest one that is the most stable and works the best and that is version 0.35 Alpha at this time. You'd just be wasting your time on older versions. I'd start with 0.35 Alpha and update the text if the language changes enough to require it.

SeaGtGruff, on Thu Sep 1, 2005 1:01 AM, said:

(3) I'm already working on a game of my own, and I want to include a game in the tutorial series, but working on the tutorial will cut into development time for my own game. For that reason, I decided to use my own game as the example, so I can develop it and write the tutorial at the same time. I also plan to include other games as the series continues, since each type of game can have its own set of special needs.

Question: Do you think readers would be interested in following the development of my adventure game, or would that seem too egotistical/self-serving?

If you keep it in tutorial form explaining what you are doing and what you did such as if you planned it all out first, if you made an outline or a flowchart and stuff like that. I don't like tutorials that are similar to a blog though. I don't want to know what you ate for breakfast or what a cute little poopie your cat made. If it's just the facts using easy to understand words in a form that is easy on the eyes, it will be great.

Edited by Random Terrain, Mon Dec 17, 2007 1:26 AM.

[SeaGtGruff]

Random Terrain, on Thu Sep 1, 2005 3:05 AM, said:

Right, I hardly ever remember what abbreviated things mean, so it helps to have it spelled out [...]

I also never remember the difference between hue and luminance unless I look them up since the words seem like they came from another planet. Maybe you could explain the roots of the words so it makes more sense. [...]

Okay, I'll include include technical explanations, but keep them brief and succint. That will be the hardest part for me, because once I launch into "teacher mode," I can get *so* carried away!

Random Terrain, on Thu Sep 1, 2005 3:05 AM, said:

[...] No one wants to use a semi-broken version of the language. They will use the latest one that is the most stable and works the best and that is version 0.35 Alpha at this time. You'd just be wasting your time on older versions. I'd start with 0.35 Alpha and update the text if the language changes enough to require it.

Okay, I'll start with 0.35 Alpha.

Random Terrain, on Thu Sep 1, 2005 3:05 AM, said:

If you keep it in tutorial form explaining what you are doing and what you did such as if you planned it all out first, if you made an outline or a flowchart and stuff like that. I don't like tutorials that are similar to a blog though. I don't want to know what you ate for breakfast or what a cute little poopie your cat made. If it's just the facts using easy to understand words in a form that is easy on the eyes, it will be great.

I'm laughing! (about the cat poopie) Okay, I'll use my game as an example, but I'll try not to get bloggish about it!

Also, once I got into it, I was intending to ask the readers about what sorts of games they want to see discussed (e.g., platform games, space games, etc.). And I'm intending to assign "homework," like "Come up with a game idea of your own," so anyone participating in the series would be welcome to make suggestions as I go along, or ask about something they're having trouble with in their own game(which I may or may not be able to help with, but hopefully someone else could help if I can't).

Right now I'm reluctant to post anything I've written thus far, since I keep going over it thinking I've tried to explain too much, or am spending time on something that most readers might not need to be told, etc.

Any other comments or suggestions are much appreciated.

Michael Rideout

[batari]

I think a good tutorial would be easy to follow and not get into deep technical details right away. Though if you are using HTML or something like that, you could effectively do both by allowing the "student" to click on a term for a detailed explanation.

For instance, one could do just fine with bB programming without ever knowing that one nybble is the color and one is the hue in COLUBK and instead went off of a chart like RT made for the help file. The visual of the color chart is much more meaningful to a beginner, I think. But if one wants to know the technical details, there could be a link that explains more.

SeaGtGruff, on Thu Sep 1, 2005 3:55 AM, said:

Okay, I'll start with 0.35 Alpha.

I agree that going from 0.35 is the correct thing to do. I would only give a brief mention of the bugs and workarounds of earlier versions in case one wants to adapt early code, and I would remove this section later as the code base for later versions of bB grows.

I realize that it was inconvenient for some to change bit access from () to {}, but it's better this way since functions are a more important programming feature than bit access, and functions almost universally use () in other languages.

However, I wouldn't worry too much about something like this coming up in the future. Since I have heard no bug reports or feature requests at all for 0.35, I guess this means that it's maturing (or nobody is using it.) Therefore if there aren't many major bugs, programs written for 0.35 are more likely to work in later versions, and more important features are less likely to crop up that will supplant existing features.

Random Terrain, on Thu Sep 1, 2005 3:05 AM, said:

If you keep it in tutorial form explaining what you are doing and what you did such as if you planned it all out first, if you made an outline or a flowchart and stuff like that. I don't like tutorials that are similar to a blog though. I don't want to know what you ate for breakfast or what a cute little poopie your cat made. If it's just the facts using easy to understand words in a form that is easy on the eyes, it will be great.

I don't mind it being a little informal, in fact it's more interesting this way and easier to follow than a dry, matter-of-fact type of tutorial. But I agree with RT that you should keep it all relevant...

SeaGtGruff, on Thu Sep 1, 2005 3:55 AM, said:

Also, once I got into it, I was intending to ask the readers about what sorts of games they want to see discussed (e.g., platform games, space games, etc.). And I'm intending to assign "homework," like "Come up with a game idea of your own," so anyone participating in the series would be welcome to make suggestions as I go along, or ask about something they're having trouble with in their own game(which I may or may not be able to help with, but hopefully someone else could help if I can't).

I think homework is a good idea.

[joeybastard]

I look forward to this tutorial. I've been screwing around with bB but not getting too far. I think all of the pot I smoked in high school erased the part of my brain the could do some BASIC programming.

[gambler172]

Hi
a tutorial for beginners would be great,because i have no knowledge about programming,but would like to try Batari Basic.
greetings Gambler172

[potatohead]

Totally agree that any tutorials should target the latest release.

Batari: I'm in the not using it camp at the moment. It's gonna take a while to move my code over to 0.35. (sorry)

On the tutorial: Learning how to do something simple, then building on it in stages works well.

The very best introduction to a new language, for me at least, happened to be the O'reilly Perl books. It started out with very simple things, then just kept adding on until something great eventually was all documented. I would shoot for that, if it were me.

Also, comment your sample code and your game code. Err on the side of too many comments. Learning how the language works is not too difficult, IMHO. Making it easy for folks to parse your code is golden.

Language and hardware limits aside, the tough part is all the subtle things that need to work together. Here is a short list of things that ended up being very important while I continue to work on Ooze:

- the order of things is very important. Simple questions like, do I update a variable, then draw a playfield block, or draw the playfield block, then update the variable? The answer to this question was the difference between a lot of buggy code and far less code that ran well. Doing things in the right order can sharply reduce the number of extra, unplanned conditions the gamecode must handle.

-every last bit counts. At first, the memory limitations do not seem significant. It's easy to get something up and running. Refining it and handling all the little issues that come from that consume a *lot* of memory. Using bit comparisons to better leverage every avaliable bit is a big deal if the game has any level of complexity at all. I ended up doing a coupla rewrites as I ran into this issue over and over. I'm gonna have to do another one before it's all over. The earlier you realize this, the fewer times you will run out of storage.

-comment your code. I find that I already forget some of the little hows and whys behind my own code. (And it's not been that long.) Verbose comments written to your future self really help changes you don't know you are going to make yet happen easier with fewer bugs.

-task seperation. At first, it seems like you can just write your game with few worries. Soon, game complexity becomes an issue. Breaking down tasks into specific chunks allows for easier changes and clarity. The earlier one can develop some program structure, the easier this all will be.

-loops. Because the game logic runs every frame, the program needs to be able to execute almost everything all the time. Breaking down the game elements into little chunks that know when they need to act, based on the actions of other chunks is very important. The bit flags are invaluable here. An example (that I've yet to do) would be sound. One game element interacts with another and sets a flag that tells the sound element to go ahead and make the sound.

-what really needs to be in ram? Using the ROM space for game data, with the data statement really is important too. Some things just don't need to be variable. If these things can be found out and placed in the ROM, you have just that much more RAM for complexity.

-reusing variables. An example is a pointer to a data element. I found that I could waste RAM by setting up a coupla variables to point to different things in the data, or I could access the data, one element at a time, while incrementing the same variable as a pointer. The result was the need for fewer general purpose temporary variables and more room for complexity.

I listed these here because these are the things that people are really gonna struggle with. Learning the language limits is one thing, putting together programs that have any level of complexity is another. Ideally a solid tutorial can at least hint at that. I plan on documenting some of my experience when I have some free time and my project is up and running on 0.35...

Either way, the more the merrier. I've learned something new from each and every program posted so far, and that's the coolest part for me.

[SeaGtGruff]

batari, on Thu Sep 1, 2005 6:38 AM, said:

I think a good tutorial would be easy to follow and not get into deep technical details right away.  Though if you are using HTML or something like that, you could effectively do both by allowing the "student" to click on a term for a detailed explanation.

For instance, one could do just fine with bB programming without ever knowing that one nybble is the color and one is the hue in COLUBK and instead went off of a chart like RT made for the help file.  The visual of the color chart is much more meaningful to a beginner, I think.  But if one wants to know the technical details, there could be a link that explains more.

I like that idea. I was writing it in plain text, because I figured I'd be posting it in this forum where people can read it without having to download anything. But it would probably be better to do it as a self-contained "mini web site" that people can download and install on their computers, so they can read it offline.

batari, on Thu Sep 1, 2005 6:38 AM, said:

I agree that going from 0.35 is the correct thing to do. [...]

[...] Since I have heard no bug reports or feature requests at all for 0.35, I guess this means that it's maturing (or nobody is using it.)  Therefore if there aren't many major bugs, programs written for 0.35 are more likely to work in later versions, and more important features are less likely to crop up that will supplant existing features.

I've run into a few bugs in 0.35, but I haven't taken the time to document them yet, because when I was converting my program from 0.2 to 0.35, I was more interested in getting it to work quickly, so I didn't make a list of the things I ran into. But here are a few things I've noticed, which I'll eventually try to provide some examples of:

Sometimes text that's in a "rem" line will compile, but it doesn't happen all the time, and I haven't figured out when or why it does. All I know is I had a large section of routines after my main loop, and I remarked almost every one of them out while I was making my code "0.35-friendly." My plan was to get part of it to compile successfully, then uncomment a little bit more and get it working, etc. When I compiled the program and got an error message, I opened the .asm file and found some statements that had been compiled-- even though there was a "rem" at the front of the line (and yes, there was a space in front of the "rem"). Also, I've found that you can't put just anything after the "rem," because if certain characters are in a remark, it may cause an error, as if the remark is being scanned by the compiler instead of being ignored. For example, in 0.1 you couldn't include a colon inside a remark, but you can in 0.35-- *most* of the time.

Also, the documentation for 0.35 says that division or multiplication by a power of 2 doesn't require an "include," but it actually does, because "div_mul.asm" isn't automatically included, so you'll get an error. If you add "include div_mul.asm" at the beginning of your program, the error goes away. Or you can edit "default.inc" to add "div_mul.asm," but I wanted to keep "default.inc" just like it was when it "came straight out of the box" so to speak.

The bug in "pfhline" has been fixed (where using "off" caused unexpected results), but the same sort of bug in "pfvline" is still there.

And sometimes when I compile a program, I get a strange error message, but the line it refers to is okay-- and if I turn around and recompile the program without making any changes to it, it will either get a *different* error (or the same sort of error but on a different line), or it will go ahead and compile correctly! It's weird, and I need to get a good example for you to look at.

Michael Rideout

[SeaGtGruff]

joeybastard, on Thu Sep 1, 2005 10:48 AM, said:

I look forward to this tutorial.  I've been screwing around with bB but not getting too far.  I think all of the pot I smoked in high school erased the part of my brain the could do some BASIC programming.

Then I'll see if I can give you a reboot!

Michael Rideout

[SeaGtGruff]

gambler172, on Thu Sep 1, 2005 2:37 PM, said:

Hi
a tutorial for beginners would be great,because i have no knowledge about programming,but would like to try Batari Basic.
greetings Gambler172

I'm going to assume that the readers have no programming knowledge, but I'll have to assume that they at least know how to use a computer! That's one of the tough parts about trying to write a "how to"-- knowing how much to assume that the reader already knows. I work in programming and support, and I deal with users at all levels of understanding. It's frustrating to try to help users, and to have to talk some of them through every infinitesimal little thing, like if they don't know the difference between left-click, double-click, and right-click. When I tell them to double-click on an icon, and they ask me "With the left button, or with the right button?", I want to scream! I'll probably err more on the side of giving too much information than too little, but I'll have to draw the line somewhere.

Michael Rideout

[SeaGtGruff]

potatohead, on Thu Sep 1, 2005 4:14 PM, said:

On the tutorial:  Learning how to do something simple, then building on it in stages works well.

Yep, I plan to start simple, and explain each step along the way. It will take longer to complete a game that way, but of course I won't have to keep explaining the same things over and over, so it should pick up speed as more and more of the groundwork gets laid down.

potatohead, on Thu Sep 1, 2005 4:14 PM, said:

Language and hardware limits aside, the tough part is all the subtle things that need to work together.  Here is a short list of things that ended up being very important while I continue to work on Ooze:
[...]

Thanks for that list! I agree with them!

As far as the order of things, one example of how that can make a big difference is with collision checking, especially if you want to "bounce" the player off of the wall to keep him from just walking through it. You must check for a collision first, then "bounce" the player back so it isn't overlapping the wall anymore, *before* you read the joystick and change the player's motion appropriately.

As far as using the bits effectively, I plan to do things the long way, or the hard way, or the wasteful way at first, just so I can then turn around and discuss why that way isn't the best way, and show how there are ways to improve it.

I didn't include a lot of comments in my 0.0 and 0.1 listings of Reventure, but I intend to use a lot of comments in the tutorial. In fact, the first thing I'm going to talk about-- once I get past the preliminary stuff and am ready to talk about programming-- is the "rem" command. On the other hand, I also intend to show how the "dim" command can help make a program more "self-documenting," by giving the variables more understandable names.

Michael Rideout

[batari]

SeaGtGruff, on Thu Sep 1, 2005 6:31 PM, said:

I've run into a few bugs in 0.35, but I haven't taken the time to document them yet, because when I was converting my program from 0.2 to 0.35, I was more interested in getting it to work quickly, so I didn't make a list of the things I ran into. But here are a few things I've noticed, which I'll eventually try to provide some examples of:

Sometimes text that's in a "rem" line will compile

Please PM me with any code where this occurs - no need to investigate specific cases, I can do that.

Quote

Also, the documentation for 0.35 says that division or multiplication by a power of 2 doesn't require an "include," but it actually does, because "div_mul.asm" isn't automatically included, so you'll get an error.

Hmmm... I'll look into this.

Quote

The bug in "pfhline" has been fixed (where using "off" caused unexpected results), but the same sort of bug in "pfvline" is still there.

So "off" doesn't work quite right?

Quote

And sometimes when I compile a program, I get a strange error message, but the line it refers to is okay-- and if I turn around and recompile the program without making any changes to it, it will either get a *different* error (or the same sort of error but on a different line), or it will go ahead and compile correctly! It's weird, and I need to get a good example for you to look at.

This shouldn't happen. The errors may still be strange and cryptic, but they should at least be consistent. If you have an example of this, please PM me the code.

[potatohead]

Quote

As far as the order of things, one example of how that can make a big difference is with collision checking, especially if you want to "bounce" the player off of the wall to keep him from just walking through it. You must check for a collision first, then "bounce" the player back so it isn't overlapping the wall anymore, *before* you read the joystick and change the player's motion appropriately.

Yes! That is a great example and one that I bumped into as well when getting the interaction between the ooze and the bullets working properly. Another one for me was when to draw new ooze. Done at the wrong time, it was impossible to know just what a collision did exactly.

Being able to read playfield pixels directly would have mitigated some of these problems. However I thought it good to practice completely understanding the game state at any time. The code is more solid that way...

Sounds like we all might get something out of this tutorial! Looking forward to it.

[SeaGtGruff]

batari, on Thu Sep 1, 2005 10:16 PM, said:

SeaGtGruff, on Thu Sep 1, 2005 6:31 PM, said:

I've run into a few bugs in 0.35, but I haven't taken the time to document them yet, because when I was converting my program from 0.2 to 0.35, I was more interested in getting it to work quickly, so I didn't make a list of the things I ran into. But here are a few things I've noticed, which I'll eventually try to provide some examples of:

Sometimes text that's in a "rem" line will compile

Please PM me with any code where this occurs - no need to investigate specific cases, I can do that.

Quote

Also, the documentation for 0.35 says that division or multiplication by a power of 2 doesn't require an "include," but it actually does, because "div_mul.asm" isn't automatically included, so you'll get an error.

Hmmm... I'll look into this.

No need, it was my error-- the documentation says that division by numbers which are multiples of 2 *does* require the include to be added to your program-- I read it wrong. Sorry about that!

batari, on Thu Sep 1, 2005 10:16 PM, said:

Quote

The bug in "pfhline" has been fixed (where using "off" caused unexpected results), but the same sort of bug in "pfvline" is still there.

So "off" doesn't work quite right?

That's correct. pfhline seems to work great, but pfvline still has the same bug as before, as far as I can tell. Or it might be with "flip" rather than with "off." I'll post an example tomorrow night.

batari, on Thu Sep 1, 2005 10:16 PM, said:

Quote

And sometimes when I compile a program, I get a strange error message, but the line it refers to is okay-- and if I turn around and recompile the program without making any changes to it, it will either get a *different* error (or the same sort of error but on a different line), or it will go ahead and compile correctly! It's weird, and I need to get a good example for you to look at.

This shouldn't happen. The errors may still be strange and cryptic, but they should at least be consistent. If you have an example of this, please PM me the code.

I got the error again tonight while compiling the sample.bas program, even after it had compiled correctly just minutes before (and I hadn't changed it). The error says that "variables aren't supported in bit access operations," or something like that (I can't remember the precise wording-- bit operations, bit arrays, or bit access). I immediately compiled again, and there was no error. I couldn't get it to happen again, but this is what I realized:

I had minimized the 2600IDE window, then restored it and recompiled, which gave the error message about variables not being allowed with bit access or whatnot. But if I didn't minimize and restore the window, no error. I tried to duplicate it, but couldn't. It's as if something happened when I minimized/restored, but I had also been doing stuff in other open windows (not with bB, but with Front Page, and the other night it was WordPad I was working in), so I don't know if this was some kind of freaky Windows thing, or something with 2600IDE. I *do* know that if I minimize 2600IDE, then restore it, sometimes/usually the 2600IDE window comes up "blank," like the program listing is invisible. I can scroll the window and get the text back (it was there all the time, just "white on white" or else the screen mem for the window had gotten clobbered). I see this kind of thing happen in Windows sometimes, so it might not be a bB or 2600IDE issue per se, but *something* is causing the "variables not allowed with bit whatevers" error to occur on occasion even though there is nothing "wrong" with the code.

Michael Rideout

[batari]

SeaGtGruff, on Fri Sep 2, 2005 2:06 AM, said:

No need, it was my error-- the documentation says that division by numbers which are multiples of 2 *does* require the include to be added to your program-- I read it wrong. Sorry about that!

Really? because division by 2, 4, 8, 16, 32, 64, or 128 should compile without need for a module. Or at least this was my intent.

SeaGtGruff said:

I got the error again tonight while compiling the sample.bas program, even after it had compiled correctly just minutes before (and I hadn't changed it). The error says that "variables aren't supported in bit access operations," or something like that (I can't remember the precise

This error will (or should) only happen if the program finds "}" and then finds something other than 0-9 directly before it. E.g, a{4} is OK, a{x} is not. Also, between {}, spacing is important. E.g. a{4} is OK, a{ 4 } is not. I can fix the spacing issue here if this is confusing.

If this error is occurring with no } in your program at all, I have no idea what's happening.

[SeaGtGruff]

batari, on Fri Sep 2, 2005 4:18 AM, said:

SeaGtGruff, on Fri Sep 2, 2005 2:06 AM, said:

No need, it was my error-- the documentation says that division by numbers which are multiples of 2 *does* require the include to be added to your program-- I read it wrong. Sorry about that!

Really? because division by 2, 4, 8, 16, 32, 64, or 128 should compile without need for a module. Or at least this was my intent.

From the help.html file:

"Multiplication of a variable to a number 10 or less does not require you to include a module. The exception to this rule is any number that is a power of two, i.e. 16, 32, 64, or 128."

I had read this wrong the first time-- it says that * or / by 10 or less requires no module, but * or / by a power of 2 does.

batari, on Fri Sep 2, 2005 4:18 AM, said:

SeaGtGruff said:

I got the error again tonight while compiling the sample.bas program, even after it had compiled correctly just minutes before (and I hadn't changed it). The error says that "variables aren't supported in bit access operations," or something like that (I can't remember the precise

This error will (or should) only happen if the program finds "}" and then finds something other than 0-9 directly before it. E.g, a{4} is OK, a{x} is not. Also, between {}, spacing is important. E.g. a{4} is OK, a{ 4 } is not. I can fix the spacing issue here if this is confusing.

If this error is occurring with no } in your program at all, I have no idea what's happening.

Last night it happened with the sample.bas program, just minutes after I had already compiled it with no error, and I had not changed the code at all, just minimized the 2600IDE window, was working on my tutorial in Front Page, and I restored the 2600IDE program and recompiled the program so I could copy and paste the compile results message into my web page-- but I got the error. Then I recompiled again, without changing anything, and no error.

Regarding the pfvline bug, I remembered more details after I logged off last night. It looks like it isn't stopping at the desired row_ending value, it starts in the specified row and then continues all the way to the bottom of the screen no matter what the ending row is.

I don't have time right now, but I'll post examples of everything tonight after I get home, including trying to duplicate the error message, and seeing if I can get the problem with the rem statement (I think I may still have the code, or I can take my old 0.2 code and comment out the same portions as I'd done before).

Michael Rideout

[kisrael]

I thought about starting my own tutorial, though right now my todo list is a bit on the long side.

I not-so-humbly think my 2600 101 is a decent model...a few pages of background explanation, then starting with a simple program, and then using the simple program as a model for enhancements, highlighting the differences from the last version with red.

I think the initial introduction is important. It has to have two facets: one is description of what the atari has to work with: 2 player graphics, 2 missiles, a ball, a playfield, some rudimentary sound. Mention that some games reuse players, or flicker, but don't get too technical.

The next thing is to explain what batariBASIC brings to the party...that it grabs memory to do the PF screen mapping, the players, the score, etc, maybe mention what a kernal is and then say that bB might added extra kernals in the future...

[SeaGtGruff]

I have the week off between Christmas and New Year's, so I plan to work on my bB tutorial and finally launch it. Since it's aimed at beginners, I'm including some instructions on how to use an IDE. I'd originally planned to use 2600IDE, but now I'm thinking about using a free full-featured IDE. After doing a brief search, I just downloaded Crimson Editor. I'm sure there are many other free IDEs to choose from, but this was one of the first ones I saw that looks fairly robust. Of course, now I have to build some custom files so Crimson Editor will recognize and be able to highlight the bB keywords, 6502 opcodes, and 2600 register names, as well as macros for compiling and running bB programs. This brings me to two questions before I invest much time in setting up the custom files for Crimson Editor:

(1) Does Crimson Editor meet with most everyone's approval? What I mean is, do any of you who are already programming in bB, or who are thinking of starting to program in bB, have any other free IDEs that you want to suggest I use instead of Crimson Editor? The main features I'm looking for are (a) color highlighting of the keywords and the ability to customize the keyword list for a new language; (b) full editing features, e.g., search and replace; © automatic backups and the ability to configure the backup feature; and (d) the ability to create macros for compiling programs and running programs. Anyone with strong feelings in favor of another IDE, or against Crimson Editor, should please speak up now. I just downloaded it and haven't really tested it yet (I can't very well try it out with bB until I customize it for bB, which I haven't done yet), so if anyone having familiarity with Crimson Editor knows of any glaring glitches or annoying shortcomings, please let me know.

(2) The file extensions I've been using with bB and 2600IDE-- .bas and .asm-- are already used for other languages. Of course, I could just trash the syntax files for those extensions, but it might be a good idea for us to come up with file extensions that are more unique to bB and 6502 assembly. I know that 2600IDE uses .26b as one of the recognized file extensions for bB source files, so I could set up custom files under that extension, or I could use something else, like .2600bas, .bB, etc. And .asm is a popular file extension among 6502 assembly programmers, but it's also used with other assembly languages, so we could come up with an extension for 6502 assembly source files in general, or even for Atari 2600 assembly source files in particular-- like .26a, .2600asm, etc. Does anyone want to offer comments or suggestions about this issue? Of course, people could create their own custom syntax files and macros, etc., but I'd like to set things up in advance as much as possible for the readers.

Thank you,

Michael Rideout

[Random Terrain]

SeaGtGruff, on Sat Dec 24, 2005 11:47 PM, said:

(1) Does Crimson Editor meet with most everyone's approval? What I mean is, do any of you who are already programming in bB, or who are thinking of starting to program in bB, have any other free IDEs that you want to suggest I use instead of Crimson Editor?

I never tried Crimson Editor. I usually use the front end that was made for a certain program.

SeaGtGruff, on Sat Dec 24, 2005 11:47 PM, said:

The main features I'm looking for are (a) color highlighting of the keywords and the ability to customize the keyword list for a new language. . .

Nice.

SeaGtGruff, on Sat Dec 24, 2005 11:47 PM, said:

(b) full editing features, e.g., search and replace; © automatic backups and the ability to configure the backup feature. . .

Cool.

Does this mean we would lose the sprite and playfield editors? I like how we can save and load images. I just wish we could highlight sprite code in our program, click a button and have it appear in the editor. Not being able to do that means that once you create something, you can never edit it. You have to redraw it. That's a waste of time and energy when a tool could instantly put the image in the editor for you. All the tool would have to do is read the highlighted numbers and flip the image so it's not upside-down in the editor.

Later on, it would also be nice to have a tool that helps you create animations. You see all of the frames including the live result and you can also copy and paste from frame to frame. Kind of like the following page except it would be made for batari Basic and would include the features I mentioned:

http://alienbill.com...yerpalnext.html

If Crimson Editor can have sprite and playfield editors, do you think it could turn the squares black or white as long as the mouse button is held down instead of requiring an actual click for each square? That would save a little time cut down on unnecessary repetitive stress on your hand and arm too.

Thanks.

[SeaGtGruff]

Random Terrain, on Sun Dec 25, 2005 1:42 AM, said:

Does this mean we would lose the sprite and playfield editors? I like how we can save and load images. I just wish we could highlight sprite code in our program, click a button and have it appear in the editor. Not being able to do that means that once you create something, you can never edit it. You have to redraw it. That's a waste of time and energy when a tool could instantly put the image in the editor for you. All the tool would have to do is read the highlighted numbers and flip the image so it's not upside-down in the editor.

Later on, it would also be nice to have a tool that helps you create animations. You see all of the frames including the live result and you can also copy and paste from frame to frame. Kind of like the following page except it would be made for batari Basic and would include the features I mentioned:

http://alienbill.com...yerpalnext.html

If Crimson Editor can have sprite and playfield editors, do you think it could turn the squares black or white as long as the mouse button is held down instead of requiring an actual click for each square? That would save a little time cut down on unnecessary repetitive stress on your hand and arm too.

Thanks.

I hadn't thought about that! The only potentially negative thing I'd seen so far about Crimson Editor is that it doesn't seem to have hex viewer/editor capabilities, which can be useful for viewing and hacking non-disassembled binary files, but which shouldn't be very much needed for actual bB and 6502 programming.

Crimson Editor is a general-purpose IDE (not specific to any target computer or game console or programming language), so it doesn't have built-in tools for creating and editing player and playfield graphics for the Atari 2600. It should be possible to create such editors as separate programs and call them with macros, but the resulting code would have to be cut-and-pasted into the bB program.

That's what's nice about an IDE like 2600IDE-- since it's tailor-made for a given language and machine, it can include only those menu functions which are needed, and can contain built-in tools that are fully-integrated into the IDE. On the other hand, a general-purpose IDE can have so many menu functions that the user is apt to be bewildered and intimidated, plus there are no built-in tools for doing specific things (like playfield editing) that are specific to a given machine.

To be honest, I don't especially like the playfield editor that's in 2600IDE-- not because of the way it works, but because of the code it generates. It creates a series of pfpixel statements, and drawing a playfield by turning the individual pixels on or off with a series of pfpixel statements takes a lot of machine cycles and ROM. It would be better if the playfield editor created data statements for the playfield, similar to the way I drew the castle in the sample program I posted in another thread-- although that would also require the user to call a routine for moving the resulting data into the playfield's RAM locations, flipping the bytes that need to be flipped, as in my sample program. Depending on the screen (i.e., how many pixels are to be turned on, and how they're positioned relative to each other), moving 48 bytes into playfield RAM can be a much quicker way to draw the playfield, and might require less ROM as well. But for some playfields, it might be quicker to use pfpixel, pfhline, and pfvline to draw the screen-- assuming that the playfield is already cleared. If the playfield needs to be cleared each time anyway, then the bytes approach is probably better anyway as far as speed, but might take up more ROM than using just a few pfpixel, pfhline, and pfvline statements.

I guess I could include information on both-- 2600IDE and Crimson Editor. But it would be simpler to cover just one editor in the tutorial, since I'd like to include screenshots where appropriate. I'll play around with Crimson Editor this weekend to see how well it works-- after all, I might want to use it myself whether or not it's the IDE that I end up covering in my tutorial. Actually, I prefer to use Multi-Edit, since it's what we use at work (so I'm very familiar with it), and I bought a copy for myself earlier this year. But Multi-Edit is probably way too expensive for most of the people who'll be reading my tutorial, whereas Crimson Editor is free.

Michael Rideout

[Random Terrain]

SeaGtGruff, on Sun Dec 25, 2005 1:46 AM, said:

It should be possible to create such editors as separate programs and call them with macros, but the resulting code would have to be cut-and-pasted into the bB program.

Copying and pasting the results would be fine with me. I just hope we'll be able to do the reverse. Paste some sprite code into the sprite editor and it will read it, flip it, and display it so you can edit it.

SeaGtGruff, on Sun Dec 25, 2005 1:46 AM, said:

To be honest, I don't especially like the playfield editor that's in 2600IDE-- not because of the way it works, but because of the code it generates. It creates a series of pfpixel statements, and drawing a playfield by turning the individual pixels on or off with a series of pfpixel statements takes a lot of machine cycles and ROM. It would be better if the playfield editor created data statements for the playfield, similar to the way I drew the castle in the sample program I posted in another thread-- although that would also require the user to call a routine for moving the resulting data into the playfield's RAM locations, flipping the bytes that need to be flipped, as in my sample program. Depending on the screen (i.e., how many pixels are to be turned on, and how they're positioned relative to each other), moving 48 bytes into playfield RAM can be a much quicker way to draw the playfield, and might require less ROM as well. But for some playfields, it might be quicker to use pfpixel, pfhline, and pfvline to draw the screen-- assuming that the playfield is already cleared. If the playfield needs to be cleared each time anyway, then the bytes approach is probably better anyway as far as speed, but might take up more ROM than using just a few pfpixel, pfhline, and pfvline statements.

If we could have a smarter playfield editor, that would also be great. Maybe the user could select between the two types of results. One option would use data statements and the other would use pfpixel, pfhline, and pfvline. The user could determine which one is best for each task.

[SeaGtGruff]

Random Terrain, on Sun Dec 25, 2005 4:58 AM, said:

SeaGtGruff, on Sun Dec 25, 2005 1:46 AM, said:

It should be possible to create such editors as separate programs and call them with macros, but the resulting code would have to be cut-and-pasted into the bB program.

Copying and pasting the results would be fine with me. I just hope we'll be able to do the reverse. Paste some sprite code into the sprite editor and it will read it, flip it, and display it so you can edit it.

SeaGtGruff, on Sun Dec 25, 2005 1:46 AM, said:

To be honest, I don't especially like the playfield editor that's in 2600IDE-- not because of the way it works, but because of the code it generates. It creates a series of pfpixel statements, and drawing a playfield by turning the individual pixels on or off with a series of pfpixel statements takes a lot of machine cycles and ROM. It would be better if the playfield editor created data statements for the playfield, similar to the way I drew the castle in the sample program I posted in another thread-- although that would also require the user to call a routine for moving the resulting data into the playfield's RAM locations, flipping the bytes that need to be flipped, as in my sample program. Depending on the screen (i.e., how many pixels are to be turned on, and how they're positioned relative to each other), moving 48 bytes into playfield RAM can be a much quicker way to draw the playfield, and might require less ROM as well. But for some playfields, it might be quicker to use pfpixel, pfhline, and pfvline to draw the screen-- assuming that the playfield is already cleared. If the playfield needs to be cleared each time anyway, then the bytes approach is probably better anyway as far as speed, but might take up more ROM than using just a few pfpixel, pfhline, and pfvline statements.

If we could have a smarter playfield editor, that would also be great. Maybe the user could select between the two types of results. One option would use data statements and the other would use pfpixel, pfhline, and pfvline. The user could determine which one is best for each task.

I played around with Crimson Editor last night, and it works great-- very easy to use, and easy to add user-defined tools to the menu.

I had the terminology wrong. The user-defined macros are for recording and replaying a series of keystrokes-- which is also useful; e.g., you could create a macro for something like "if joy0fire then", and you could use the macro to type that out for you everytime you needed to check the fire button in your program.

It's easy to customize Crimson Editor as far as adding new languages or changing the user preferences. I set up batari BASIC for the ".bB" extension, since ".bas" is already defined for Visual Basic, but the users can easily change the extension to something else, like ".26b", or even redefine the ".bas" extension to be used for batari BASIC if they won't ever use Crimson Editor for Visual Basic programming.

I added "batari BASIC Files" to the file types, and defined the known extensions for it as "*.bB;*.26b;*.bas", so if you're browsing a directory for bB files, any programs with those three extensions will show up in the files listing-- but again, the user can change that if desired.

In fact, you don't need to define a language at all, you can just write bB programs without setting anything up. The main advantage of defining a new language is that it allows Crimson Editor to highlight all the keywords for that language in different colors, plus the ability to display just the files of that language type in a file listing.

I set up two user-defined tools-- "Compile bB Program" (it just calls the compile batch and shows the results of the compile in an output window), and "Run bB Program in z26" (it just invokes z26 with the name of the compiled program). The user can change that to use Stella or some other emulator instead. And it's easy to modify the command to use any switches desired, so there could be multiple tools for running a program-- e.g., one to run a standard 2k or 4k ROM, another to run a 16k ROM that uses M-Network bankswitching, another to run ROMs that use Atari bankswitching, etc.

Since the text output from a program can be captured and displayed in the output window, if someone were to write a program for creating or editing playfields, and output the necessary statements (data, pfpixel, pfhline, or pfvline), then the output could be shown in Crimson Editor's output window, and could be cut and pasted into the bB program. I'm not up to writing a tool like that right now, but if no one else can do it, then I might be able to write something in Visual Basic for playfield editing, player editing, or even color selection (i.e., click on a color in the palette display, and it returns the appropriate hexadecimal or decimal value to the output window). However, my first priority is to work on the tutorial and finally launch it, so I won't be attempting to write any tools like that until sometime in the future.

Michael Rideout