Batari Basic or old school?

[Omegamatrix]

You're seriously saying that the bB game screenshots I posted look like games from 1977?

 

Try a bit less hyperbole, or a bit more objectivity.

 

Those are the cream of the crop, for sure. The new SMB game looks good too.

[+Random Terrain]

I know it's not a popular opinion but I don't think everyone should make a game just like everyone should not sing or play baseball. Some people are just bad at it.

 

Just remember that the all of the games people hate that were programmed in the 1980s were made using Assembly Language. Using Assembly Language is no guarantee that your game won't suck (unless you are doing a port of a great game that most people love).

 

The main thing I don't like is when people don't seem to care about quality. You can slap something together over the weekend with bB, but you should spend at least a month or two trying to get it as polished as possible. If you're trying to sell your game a week after you made it, the game probably isn't ready.

 

 

 

The main problem I see with a lot of bB users is they have no idea what the Atari is doing, and can't troubleshoot the root problems. Learn assembly, if for no other reason then to follow your code in Stella's debugger.

 

Some people aren't smart enough to do that. The info won't stay in the brain. Learning disabilities are a bitch.

[RevEng]

Batari Basic gives you quickness and speed, but assembly gives you complete control and mastery of your game. Most BB games all look the same to me, and kinda blocky.

 

I'm all about learning assembly. Once you do know asm, bB becomes transparent - it's mostly a thin framework of kernel, and simple commands that produce the assembly code you'd predict they would.

 

At that point, you can move on from the framework or don't, your preference. I've seen bB coders do both, and there's no shame in either.

 

 

 

The main problem I see with a lot of BB users is they have no idea what the Atari is doing, and can't troubleshoot the root problems. Learn assembly, if for no other reason then to follow your code in Stella's debugger.

 

I think by virtue of following a web forum for this we see a lot of the the lowest common denominator, and with a lower barrier to entry there's no denying that bB has a much lower common denominator than asm. But that shouldn't be held against the language as a whole if it's capable of producing gems in the hands of a skilled coder.

 

I will also add that I've seen assembly coders in the forums that have no idea what's going on with the hardware and 2600. They take someone's demo code and try to modify it to make a game, and when they've broken the code they ask for help debugging it.

 

 

 

Those are the cream of the crop, for sure. [...]

 

These ones were produced by myself, jrok, and Byte Knight. The interesting thing here is we share common ground in that we're all seasoned developers that won't release something until it meets our own high standards, not that we all share a deep knowledge of asm.

 

I excluded some very fun bB games from my screenshots only because my post was a response to the "no blank lines" issue, but the homebrew scene would be poorer without the bB games already mentioned by others in this thread. (and other bB games that were missed, like L.E.M and the original EMR.)

[+Gemintronic]

The main thing I don't like is when people don't seem to care about quality. You can slap something together over the weekend with bB, but you should spend at least a month or two trying to get it as polished as possible. If you're trying to sell your game a week after you made it, the game probably isn't ready.

 

Uh oh. I think I'm on R.T.s sh** list

 

http://www.atariage....ber-willy-done/

Decided to name the game and main hero/player Cyber Willy in homage to Chilly Willy of homebrew development fame.

 

As noted in my sig I've completed a Ludum Dare contest before so I at least have a taste of what 48 hour development is like. No, the contest technically isn't a 48 hour affair. I just completed a project so I didn't allow myself a huge amount of time for this contest Needless to say I've got a real chance of failing to meet the deadline. Wish me luck!

Edited September 27, 2012 by theloon

[HatefulGravey]

I had no idea there was such a divide in programmers in the home brew scene. I would love the program in asm, hell I would love to program at all and that is why I started asking about this. If one of the asm people would gladly point me to some good, tried and true documentation that will help me learn the language I'm game. Hell, at this point I'm very likely going to learn both anyway. It hasn't been that long since I programmed in other languages and I want to do this so I can't see a reason not to.

 

It was mentioned that the problem with bB is the people making the games have no idea what he 2600 is doing. Ok, I'll accept that to a degree, based on what I read about asm there is surely a deeper understanding of what is going on in the machine when you are using asm. That said there was very little information to help me make since of what is going on in the machine when I was reading about asm. I don't do well with "I know it makes no since now, but read this and it will make since later" stuff, and when I get it 5 times in 10 pages I start loosing my ability to read anymore from that text.

 

i'm also picking up on a fair about of elitist vibe from some of the asm talk. I understand the idea of suffering for your art, I understand having complete control over the hardware will help with the more complex stuff, but there seems to be no good learning tool for asm on the VCS from what I can see. Its not enough to learn the language and wrap your head around the kind of thinking needed to make a VCS game, you also have to be able to learn all this in a very scrambled and at time poorly explained format. Again, point me to the right way to learn and I'll do it. I mean no offense but don't point me to RT's site, I can't stand the layout. (sorry buddy, the more I look at it the more the colors and spacing of the bars on the edge of the screen kill me too.)

[+Random Terrain]

I mean no offense but don't point me to RT's site, I can't stand the layout.

 

What would you like to be changed?

[+Gemintronic]

Many people started with this video:

http://www.tinkernut.com/2010/01/05/how-to-make-an-atari-game/

[HatefulGravey]

What would you like to be changed?

 

Again man, I do not mean to over step or insult at all. You have a site full of information that is very useful and I have no site at all much less the information needed to make a site that is that helpful. I'll attach an image to help in this description but the bars down both sides of the page distract me more than anything else. The "meat" of the site is down the center in a bar that is a bit thin to my eyes so I feel like I'm ready 4 words at a time between two barriers.

 

There is as top bar, a bar under that, a bar to the left of the screen with a table of contents and then another bar to the right with a FAQ listed out. There is certainly a lot of navigation for the information, and that tends to leave very little area for the information itself.

[RevEng]

I had no idea there was such a divide in programmers in the home brew scene.

 

[...]

 

I'm also picking up on a fair about of elitist vibe from some of the asm talk. I understand the idea of suffering for your art, I understand having complete control over the hardware will help with the more complex stuff, but there seems to be no good learning tool for asm on the VCS from what I can see.

 

Just to give you the right picture, most of the asm coders aren't elitist at all, and I'd put Omegamatrix at the very top of the non-elitist list. He often helps out in the bB forums where he can, from an asm or logic perspective, along with other non-bB coders like Nukey, GroovyBee, and a few others.

 

Believe me when I say that those guys are the salt of the earth, and are only interested in being helpful for the sake of being helpful.

 

I don't believe godzillajoe actually codes, but there are a few asm coders with the same anti-bB sentiment. There used to be a lot more.

There are a few bad apples in every bushel. Don't let that sway you one way or another.

 

I think a blog post I made a while back is also relevant to the "suffer for your art" sentiment:

 

http://www.atariage....d-retro-coders/

[+SpiceWare]

I'm starting to wonder why anyone would code a complete game in asm.

Because you get more control in ASM. bB makes it easier, but at a price in that you're constrained by what bB supports as well as being limited in the amount of CPU time you get due to the processing overhead for the bB routines.

 

Seems the best bet is program the game in bB and tweek the stuff that needs it in asm.

This is pretty much how I got started, though it was back in 1980 learning BASIC on a Commodore PET in the computer labs after school (it was my freshman year so I learned it on my own as the computer classes were for juniors and seniors). I got a VIC 20 in 81 and soon ran into the limits of using BASIC, so I started writing small routines in 6502 assembly and called them from my BASIC code. Eventually I developed complete programs in assembly.

 

When I finally decided to write my first 2600 game, I already knew 6502 and had written many things in assembly for the VIC 20, C= 64 and C= 128 so the challenge was learning the specifics of the 2600 chipset as the 6507 in the Atari uses the same assembly language as the 6502.

 

One thing that's nice about Atari Age is a lot of source code has been made available and reviewing it can often help you figure out how to do things. For instance, in my blog, you can follow along as Medieval Mayhem was developed and most blog entries are accompanied with the source code. In the right column of the blog is a Categories group box, click on Medieval Mayhem to filter the blog entries to just those about Medieval Mayhem.

Edited September 27, 2012 by SpiceWare

[GroovyBee]

If you decide to take up programming for the 2600 just have fun doing it. Don't let the criticisms of others get you down or keep you from trying out new things. Everybody has to start from somewhere. In my mind there is absolutely no shame starting with bB. Its just a tool to help you get where you want to be. The hardest part is coming up with your game idea and then fitting into the resources available. You might have to rethink or simplify your game but on the other hand you might also come up with ideas that work with what you've got better. Thats the same principle on any CPU based console you might want to code for.

 

Once you get going then if you get stuck along the way always ask questions. There is no point losing heart in your project when you can't find a solution to a particular problem you are having. To get the best answer programmers like myself like to see what you've done to try and solve the problem yourself first. That "work" could be anything from a well composed idea or concept through to posting part working code or even fully working code that is buggy or even slow. I always think that if a poster can't put the effort into their own programming problem then why should I. We all have our own projects to work on, but sometimes its fun to have a detour and look at a small portion of somebody else's project. If you give out enough information for another programmer to get going on quickly then you'll get the best answers back in my opinion. Conversely if you look at the programmer's forums the people that say (paraphrasing) "I'm stuck on ...., please write/debug the code for me" don't get many good responses (if at all). I'm definitely in the "teach a man/woman to fish" camp .

 

If you've never programmed anything before then starting with bB wouldn't be the best choice in my opinion. I'd say pick a high level language and start to develop your game on a PC instead. Heresy I know (after what I've just said ). Once you get to grips with variables, arithmetic, loop structures, conditional statements and move onto moving/animating sprites, AI and logic in an environment that has a good high level language debugger you'll find bB much easier to get to grips with in my opinion. Don't get me wrong, Stella is a brilliant debugger for the 2600 but to get the best from it with bB coded games you need to be able to think in bB and 6502 at the same time.

 

If developing on a PC is too far away from your goal and doesn't have a retro/nostalgia feel then pick something like the A8 line of computers and start with its built in BASIC. The A8 scene is vibrant and full of a diverse set of programmers too. Plus there are plenty of legacy books to be had online or picked up cheaply from eBay.

[Mr SQL]

Because you get more control in ASM. bB makes it easier, but at a price in that you're constrained by what bB supports as well as being limited in the amount of CPU time you get due to the processing overhead for the bB routines.

 

 

This is pretty much how I got started, though it was back in 1980 learning BASIC on a Commodore PET in the computer labs after school (it was my freshman year so I learned it on my own as the computer classes were for juniors and seniors). I got a VIC 20 in 81 and soon ran into the limits of using BASIC, so I started writing small routines in 6502 assembly and called them from my BASIC code. Eventually I developed complete programs in assembly.

 

When I finally decided to write my first 2600 game, I already knew 6502 and had written many things in assembly for the VIC 20, C= 64 and C= 128 so the challenge was learning the specifics of the 2600 chipset as the 6507 in the Atari uses the same assembly language as the 6502.

 

One thing that's nice about Atari Age is a lot of source code has been made available and reviewing it can often help you figure out how to do things. For instance, in my blog, you can follow along as Medieval Mayhem was developed and most blog entries are accompanied with the source code. In the right column of the blog is a Categories group box, click on Medieval Mayhem to filter the blog entries to just those about Medieval Mayhem.

SpiceWare,

very cool! I had a very parallel experience as a freshman in Comp class with the seniors using the Commodore PET's; got along great with the students, not so well with the teacher

 

Agree about the unique 2600 hardware posing the learning curve and not Assembly language - HatefullGravy's comments about scanlines and the other esoterics being daunting are right on, particularly so if the programmer has never used Assembly before!

 

I think what makes the Tiny BASIC implementation (bB) so fantastic is that it abstracts the hardware in addition to allowing the higher level coding. I'm planning to release an abstract Assembly dev kit based on my virtual world scrolling engines to provide hardware abstraction and let the programmer focus on Assembly programming instead; excellent developers like the Loon, RT and disjaukifa (to name a few) who haven't picked up Assembly yet will find this kit a great tool for quickly learning Assembly without having to learn the chipset at the same time - the chipset should be the next step, I don't think I would have been comfortable learning them both at once.

 

bB is a great learning tool in this regard and will only make it easier for developers to learn Assembly but it will not help you with the chipset for having abstracted it so nicely

 

Developer can make awesome games with bB or Assembly and should use whatever environment they find the most comfortable; whichever implementation is chosen the resources here and on RT's site are fantastic. Your site is also a great resource, I looked at a paddle demo you had up for hints on discharging the cap

[+Random Terrain]

Again man, I do not mean to over step or insult at all. You have a site full of information that is very useful and I have no site at all much less the information needed to make a site that is that helpful. I'll attach an image to help in this description but the bars down both sides of the page distract me more than anything else. The "meat" of the site is down the center in a bar that is a bit thin to my eyes so I feel like I'm ready 4 words at a time between two barriers.

 

There is as top bar, a bar under that, a bar to the left of the screen with a table of contents and then another bar to the right with a FAQ listed out. There is certainly a lot of navigation for the information, and that tends to leave very little area for the information itself.

 

Oh, I see what you mean. Most of that page doesn't have the table of contents on the left side, starting here:

 

http://www.randomter...l#miscellaneous

 

But I can drop Things You Should Know down below the squished part to make it easier to read.

 

A few years ago, somebody wanted a table of contents, besides having an index. The table of contents can't go on the right side since it would force the index down too far. Do you have an idea where the table of contents could go where it won't squish the text area?

 

 

Update

 

Things You Should Know is now under the table of contents.

[HatefulGravey]

@GroovyBee I have programmed some before and most importantly I have taken a few programming structure and theory classes. That was 6 months of dealing with how programs work on a very pure level. No programming languages taught, just how to think like a program has to. So all those things about variables, arithmetic, loop structures, and conditional statements are well covered. I have even programmed in basic some in my life. Not much, and mostly just things for graphic calculators in high school and college, but it is something.

 

@RT Man I have no idea how to do it better. When I was designing sites I could really only design for myself. I have no idea what your goals are the for site, I don't know all the information you have there, to be honest I have spent very little time on the site and know next to nothing about the site map you are using. All I'm sure of is the crunched text distracts me. I wouldn't know how to fix that without loosing information. maybe a drop down menu system like Windows uses? People know it, and I know it can be coded in java because I did it before. That was 10 freaking years ago it seems, but I know it can be done.

[almightytodd]

I'm a computer professional with over 18 years experience. I have not attempted to program a game for the VCS in either bB or asm, but if I were to do it, I would start with bBASIC. Those who program in 6502 asm and understand the VCS video architecture have a level of brilliance that is difficult to understand. The two factors that may be missed in a discussion such as this are that:

 

1) there is a considerable amount of time that needs to be devoted struggling with asm to understand it before one can reach proficiency. Basically, you have to "think" like the 6502 CPU and the TIA chip and understand where each bit of data is going in eight bit chunks, between the registers, the tiny amount of RAM you have to work with, the ROM, and the TIA as you "race the beam" and draw the video elements onto the TV screen in real time.

 

2) The knowledge and understanding of asm programming is cumulative. The masters here who write all of these great assembly language games have devoted hundreds of hours to doing it, to the point where they can map things out in their head and rapidly see results in the development cycle of writing the source, running the assembler, loading the binary code into an emulator/debugger, and testing their changes. None of this is trivial.

 

Starting with bBASIC first will not "ruin" you for learning asm later if you decide it's what you really want to do. It will give you a sense of what programming is all about and help you evaluate how much time you'd like to put into this new hobby.

[godzillajoe]

You're seriously saying that the bB game screenshots I posted look like games from 1977?

 

Try a bit less hyperbole, or a bit more objectivity.

 

Those are all done in bB with no inline assembly?

 

Also, I'm not peeing on the tool, I'm peeing on the programmers.

 

Also, I'm peeing on my leg. Imperial IPA session.

[+Random Terrain]

Also, I'm not peeing on the tool, I'm peeing on the programmers.

 

You have to make choices:

 

http://www.randomter...l#kernelopchart

 

Do you keep the lines or do you get rid of them and lose a missile or two? If you get rid of the lines, you'll have two sprites and a ball and maybe one missile (depending on what options you choose). If you want to have two multicolored sprites, you're stuck with the ball and that's it. You could make a pretty version of Pong or Hot Potato or Hide the Salami.

 

Speaking of no blank lines, check out this 32 x 23 example program with no blank lines:

 

www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#maze_32x23

 

Not a lot you can do with that unless you use flicker.

[RevEng]

Those are all done in bB with no inline assembly?

3 of them use stock bB kernels, and no inline assembly.

3 of them use lightly modified bB kernels. (a few lines of asm inserted into the right place in the kernel) and about 2% assembly in the game logic.

2 of them use kernels written from scratch in asm, and about 15% asm in the game logic.

 

 

Also, I'm not peeing on the tool, I'm peeing on the programmers.

 

If that's the really the case, it's probably best to avoid saying you have a problem with bB, saying that all bB games look like they were from 1977, and saying that bB needs to mature first before non-1977-looking games will appear...

 

The problem I have with bB is the stuff being passed off as a "game" when it's essentially one blocky playfield and one badly drawn sprite chasing another badly drawn sprite.

To me bB games look like something from 1977 or stuff that I was making on my C=64 when I was 12. Again, no fault of the tool. It's a great learning tool and as it matures I think it will result in better games.

 

Don't damn the language for its worst examples, even if they're plenty. Judge it from its best examples.

[orange808]

I am noticing that this Super Mario thing didn't exist before bB and the IDE.

 

Hmm...

 

Seems to me that too few people have mastered assembler and the ones that do understand it aren't capable of cobbliing together the sprites and gameplay to make something that is interesting. Ever go down to the music store and realize that old guy behind the counter can play everything in the shop? Funny thing--he hasn't written anything original I want to listen to..

[HatefulGravey]

So do people that program all in asm have to give up missles and such for the same no lines look? What is it about bB that makes you have to pick? Not that I'm complaining, just wondering. I have been playing with bB for a few days now, I haven't had time for much more than play at the moment, but I do have 2 weeks off this month so I hope to learn a lot in that time.

[Omegamatrix]

So do people that program all in asm have to give up missles and such for the same no lines look?

 

Probably not.

 

 

I started programming just a few years ago. I had a VIC-20 when I was young, but didn't seriously know anything about programming until I started with the 2600. I read Andrew's Tutorial, and Machine Language For Beginners.

 

Nukey says there is some bad advice in that book, but it was pretty good to at least get an understanding. Anyhow my initial struggles where all in getting a rom to compile. Some of the code in the tutorials have gotten reformatted by the forum software, and you need to downloas VCS.H and MACRO.H at the bottom of Andrew's page (they are not packaged with DASM), TIMINT is not defined in the file, etc...

[+SpiceWare]

So do people that program all in asm have to give up missles and such for the same no lines look?

 

Yes, you do have to make tradeoffs - my page on Stay Frosty goes over some of the choices I had to make while developing that game. This bit, "the next tradeoff was to slightly narrow the platform area which saved 2 TIA updates per scanline", is about using a mirrored playfield and not updating PF0, which is why the upper platforms don't span the full width of the screen.

 

What is it about bB that makes you have to pick?

Just like I did in Stay Frosty, the display kernels included with bB had to make a tradeoff (which is what they documented). If you want to make different tradeoffs you can do so by writing a custom kernel.

Edited October 1, 2012 by SpiceWare

[Mr SQL]

Probably not.

 

 

I started programming just a few years ago. I had a VIC-20 when I was young, but didn't seriously know anything about programming until I started with the 2600. I read Andrew's Tutorial, and Machine Language For Beginners.

 

Nukey says there is some bad advice in that book, but it was pretty good to at least get an understanding. Anyhow my initial struggles where all in getting a rom to compile. Some of the code in the tutorials have gotten reformatted by the forum software, and you need to downloas VCS.H and MACRO.H at the bottom of Andrew's page (they are not packaged with DASM), TIMINT is not defined in the file, etc...

 

Omegamatrix,

Excellent point, Machine Language for Beginners is an excellent path to learning Assembly - it is the book I recommend using with my Abstract Assembly Development Kit for faster assimilation. Nukey had some very good points about some of the concepts it misses, but in doing so the book makes it easy for developers to make the transition and IMO trying to master the 2600's unique chipset at the same time as learning Assembly is even more extreme - kind of like learning BASIC or C by starting with three dimensional Array's.

 

HatefulGravey,

you might like the ASDK for learning Assembly, I just uploaded the manual and the dev kit to my thread of the same name

[RevEng]

So do people that program all in asm have to give up missles and such for the same no lines look? What is it about bB that makes you have to pick?

 

As Spiceware points out, there are trade-offs. Even when you program a custom kernel in assembly, you can't have everything...

 

Each line of the TV display is drawn very fast. So fast, in fact, that our poor 6507 CPU can only execute 76 cycles worth of instructions. That's 76 cycles with which to decide:

• which part of player0 is being displayed in this line?
  
• which part of player1 is being displayed in this line?
  
• which color player0 is being displayed with in this line?
  
• which color player1 is being displayed with in this line?
  
• is missile0 displayed in this line?
  
• is missile1 displayed in this line?
  
• is the ball displayed in this line?
  
• which part of the playfield is being displayed in this line?
  
• which color is the playfield displayed with in this line?
  
• ...
  

Even worse, many of these can't change during a good chunk of those 76 cycles, or else there will be visible glitching as the graphic element moves from left to right or right to left.

 

So as a kernel designer you pick and choose which of these are important to your game. If you're especially clever you can nudge your game design to limit vertical movement of some objects, so you can split the screen up into multiple kernels.

 

Unfortunately the bB standard kernel is at a disadvantage here. While bB is pretty flexible in allowing you to disable certain features to gain others, it can't match the flexibility of an assembly coder designing a custom kernel, and it can't assume your game design has limited vertical movement or similar tricks, or else it wouldn't be a general purpose game-creation tool.

 

Also worth mentioning that if you use hardware assistance via the DPC+ kernel, bB can create displays for some game designs that have more features than a custom non-hardware accelerated kernel could produce.

[Pioneer4x4]

I am so glad that bBasic exists. After a little putzing and years of reading about it. I am fairly confident, I could write something that functions on a 2600 in assembly. I have no "desire" to do that. bBasic allowed me to create working applications that run on a real 2600, that I never would have bothered getting a kernel running to do. All of my time is on the specific things that I personally wanted to do. I did have to learn a smidgeon of asm and how to use it in bBasic to be able to read the keypad controllers, and that was fun as well. To me, it is all about fun, and in my spare time.

I feel that there are 4 critical components are equally needed for me to get something working. As for quality of game or app... That is all up to the designer, what is the goal, and does the result meet the goal.

• harmony cart
  
• bBasic
  
• Stella
  
• AtariAge community