Assembly language VS batari Basic

[kid_snz]

Hello everyone!

 

I am a newbie who just recently started learning batari Basic. I guess this has probably been discussed here in the past, but I couldn't find it so I decided to post this.

 

Are there any differences in features between games written in Assembly language and batari Basic? For example, something can't be done with one or the other, or something is much easier with either one. I'm new and I don't want to try Assembly language at first, but I wanted to know if there is any difference in knowledge.

 

Arigato,
Shinji

[+Gemintronic]

batari BASIC gives you a variety of graphic kernels pre-made.  These have advantages and disadvantages that are set in stone.

 

So, the good news is that you can focus on content creation and game design.  The bad news is sometimes you spend brain power working around features that might be lacking in one kernel or another.

 

UPDATE:  I should also explain that programmers have to tell the 2600 how to draw things on the screen at a very low level - literally line by line on a TV screen.  So, no tile buffer or hardware scrolling.  One must write assembly to manually draw things on the screen and leave time enough for game logic.  batari BASIC takes care of most of that.

[Mikebloke]

If you've used basic before then it certainly helps with using any basic program or modern basic compiler for those systems.

 

As a new programmer even having zero basic understanding batari basic would be recommended. You can make games fairly quickly, with the feel of a game and get fulfillment. 

 

I would recommend checking out tutorials available here and elsewhere on the Internet. 

 

Yes, batari basic is easier to use, but it comes with its payoffs. One being you will not be able to fully explore the possibilities of the system like assembly could. The other thing is your games will have that 'look' of using batari basic as you learn - it'll look similar to other games in batari basic. A minor issue at this point, but the game will not do some commands as efficiently as assembly would, leading to some timing issues potentially. 

 

I'm making it sound negative but it really isn't. I'd rather use batari basic over 2600 assembly! Go for it and give it a go and have fun. 

[orange808]

https://atariage.com/forums/topic/281105-open-source-c-project-template-now-available/

[kid_snz]

27 minutes ago, Gemintronic said:

batari BASIC gives you a variety of graphic kernels pre-made.  These have advantages and disadvantages that are set in stone.

 

So, the good news is that you can focus on content creation and game design.  The bad news is sometimes you spend brain power working around features that might be lacking in one kernel or another.

 

UPDATE:  I guess I should also explain that YOU have to tell the 2600 how to draw things on the screen at a very low level.  Line by line on the TV screen.  So, no tile buffer or hardware scrolling.  You write assembly to manually draw things on the screen and hope you have time for game logic.

If I understand correctly, you are saying that games that seem very unique to me, such as Fishing Derby, Star Wars: The Empire Strikes Back, and Mangia' for example, cannot be made in batari Basic? If so, that is very sad news

 

But thanks for your comment! It was very clear. How much of the community here do you think uses each of these?

[kid_snz]

1 minute ago, orange808 said:

https://atariage.com/forums/topic/281105-open-source-c-project-template-now-available/

Haha didn't know that and thank you!

[+Gemintronic]

Just now, kid_snz said:

If I understand correctly, you are saying that games that seem very unique to me, such as Fishing Derby, Star Wars: The Empire Strikes Back, and Mangia' for example, cannot be made in batari Basic? If so, that is very sad news

 

But thanks for your comment! It was very clear. How much of the community here do you think uses each of these?

 

No, no.  Games like that can be made.  It's a matter of selecting the pre-made graphic kernel that will get you there.  Though, possibly you might have to decide between one tradeoff or another.  To get exactly Fishing Derby you would need to go assembly and have the expertise to write the graphical features yourself.

 

[kid_snz]

33 minutes ago, Mikebloke said:

If you've used basic before then it certainly helps with using any basic program or modern basic compiler for those systems.

 

As a new programmer even having zero basic understanding batari basic would be recommended. You can make games fairly quickly, with the feel of a game and get fulfillment. 

 

I would recommend checking out tutorials available here and elsewhere on the Internet. 

 

Yes, batari basic is easier to use, but it comes with its payoffs. One being you will not be able to fully explore the possibilities of the system like assembly could. The other thing is your games will have that 'look' of using batari basic as you learn - it'll look similar to other games in batari basic. A minor issue at this point, but the game will not do some commands as efficiently as assembly would, leading to some timing issues potentially. 

 

I'm making it sound negative but it really isn't. I'd rather use batari basic over 2600 assembly! Go for it and give it a go and have fun. 

Thanks for the comment! It's very clear now. I'm really new to this, so, for now, I'll give batari basic a shot!

 

Btw, I asked one person before you as well, what do you think is the ratio of people use those two and C++ this community? Just a simple interest.

[+splendidnut]

I've done 'C'-ish programming for the Congo Bongo POC.  But that's done in my own homebrew compiler so I'm not sure if that counts for anything. 

[kid_snz]

10 minutes ago, Gemintronic said:

 

No, no.  Games like that can be made.  It's a matter of selecting the pre-made graphic kernel that will get you there.  Though, possibly you might have to decide between one tradeoff or another.  To get exactly Fishing Derby you would need to go assembly and have the expertise to write the graphical features yourself.

 

That sounds good that batari Basic still could make unique looking games like them. Anyway again I'm too new to this kinds and just try batari Batari for now. Thank you again.

[kid_snz]

16 minutes ago, splendidnut said:

I've done 'C'-ish programming for the Congo Bongo POC.  But that's done in my own homebrew compiler so I'm not sure if that counts for anything. 

I was just told by others that there are not only two, but C++ as well. Please don't make me confused further...lol Btw thank you for the info!

Edited June 30, 2022 by kid_snz

[LatchKeyKid]

Lots of good info here regarding bB that is helpful to a n00b (like me!).  One question I have regarding the kernels is whether DPC+ is subject to the same limitations for multicolor sprites as the normal bB kernels.  According to this chart:

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#kernelopchart

 

You lose access to the respective missile when you make the player sprite multicolor.   The link below seems to indicate that this particular restriction isn't true for DPC+.

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_missiles

 

Quote

Notice how the colors of player0 contaminate missile0 and how the colors of the virtual sprite contaminate missile1 in the example image below:

 

Is there some other serious tradeoff with regard to sprites?  Not losing missiles for gameplay seems like a huge bonus on top of not having the missing line between blocks tradeoff as well.   Is it just harder to code with?  I keep expecting the other shoe to drop with DPC+ but it seems quite flexible.  I know it uses external hardware in most custom programmable cartridges for use on actual hardware whereas I don't believe the normal bB kernels do (?). 

[+Gemintronic]

16 hours ago, LatchKeyKid said:

Is there some other serious tradeoff with regard to sprites?  Not losing missiles for gameplay seems like a huge bonus on top of not having the missing line between blocks tradeoff as well.   Is it just harder to code with?  I keep expecting the other shoe to drop with DPC+ but it seems quite flexible.  I know it uses external hardware in most custom programmable cartridges for use on actual hardware whereas I don't believe the normal bB kernels do (?). 

 

Compared to the standard bB kernel there is more to learn.  But, I am getting closer to being comfortable making the leap with my experience with the multi sprite kernel.  Perhaps the stepping stones to learning should be: Standard Kernel -> Multi Sprite Kernel -> DPC+

 

Only one of the 10 sprites is immune to flickering so avoiding flickering becomes a big issue.  What looks good on Stella or a particular LCD panel may look like garbage on another.  When you share your work with others someone is going to have a bad time if you assume flickering is always acceptable.

 

I've heard these concerns and counter arguments (though I haven't used DPC+ myself):

 

* DPC+ ARM assist makes the games no longer classic 2600 titles.  However, it allows mere mortals to make awesome looking games.

* DPC+ is in parts closed source?  So, no one but AtariAge can make DPC+ boards.  I guess?  But, AtariAge is also the best quality so..

 

[LatchKeyKid]

2 hours ago, Gemintronic said:

 

Compared to the standard bB kernel there is more to learn.  But, I am getting closer to being comfortable making the leap with my experience with the multi sprite kernel.  Perhaps the stepping stones to learning should be: Standard Kernel -> Multi Sprite Kernel -> DPC+

 

 

Thanks for the reply and I definitely think that's the most wise starting point.  I might be ok with my game idea with the standard kernel but may have to find more creative ways to deal with the loss of potentially both missile sprites and reusing the ball (in addition to what I had hoped).  That's why I was asking about DPC+ as it didn't seem to have the same limitations.  I was hoping for a pitfall style megaman/ghosts and goblins shooter where you can shoot the enemies and they can occasionally fire back (depending on the enemy).  I don't think that will be possible with multicolor sprites with the standard kernel (the player sprite is already single color with the ball hopefully used to add a splash of color).

 

With your experience with standard kernel and bB, how "plug and play" is it in terms of programming?  I see alot of sample programs over on randomterrain for various aspects like title screens and scoreboards and wasn't sure if you could just cut and paste them in for some basic functionality.

 

Quote

've heard these concerns and counter arguments (though I haven't used DPC+ myself):

 

* DPC+ ARM assist makes the games no longer classic 2600 titles.  However, it allows mere mortals to make awesome looking games.

* DPC+ is in parts closed source?  So, no one but AtariAge can make DPC+ boards.  I guess?  But, AtariAge is also the best quality so..

 

I aspire to be mere mortal but am more realistically unwashed masses at this point in terms of ability.     Is the board/cartridge restriction a big deal?  I'm genuinely asking as I only use Stella at the moment.  It seemed like it was mostly compatible with the various cartridges out there that you can program yourself judging by folks comments but admittedly I may be completely wrong about that (like working with Harmony carts as that seems to be the most common one mentioned it seems).

[+Gemintronic]

To me the open source / closed source thing isn't a biggie because AtariAge is awesome.  But, not all makers of closed source products can be trusted and wont always nurture their creations.  Usually the community has more opportunities to participate in open source hardware and software in general.

 

Some people like having the ability to make their own boards from scratch.  Or, to have multiple choices for vendors who can.  Also, there's that philosophical question on whether leaning on an ARM CPU is really a 2600 game.  Like a Ford Fiesta with a Taurus Sho engine.  Is it really a Ford Fiesta at that point?

 

But, all signs point to AtariAge on this one.   AtariAge has been around and ain't disappearing.  The quality is top notch.  All the tools and community support are right here.  So, it's a no brainer.

 

 

[+Andrew Davie]

2 hours ago, Gemintronic said:

Also, there's that philosophical question on whether leaning on an ARM CPU is really a 2600 game.  Like a Ford Fiesta with a Taurus Sho engine.  Is it really a Ford Fiesta at that point?

Horse. Dead. Stop flogging

For those interested in philosophy, check out the ship of Theseus, which basically suggests this argument has been around for, well, 2600 years

 

The Ship of Theseus is a thought experiment about whether an object that has had all of its original components replaced remains fundamentally the same object. Theseus was the mythical Greek founder-king of Athens, and the question was raised by ancient philosophers (e.g. Heraclitus and Plato): If the ship of Theseus were kept in a harbor and every part on the ship were replaced one at a time, would it then be a new ship? If it is not the same ship, then at what point did it stop being the ship of Theseus? If it is the same ship, then could all the removed pieces be reassembled to form a ship, and would that be the ship of Theseus? The concept is one of the oldest in Western philosophy, going back to the time of 500–400 BC. It is a common theme in the field of metaphysics.

FWIW, I have been having a lot of fun programming for the CDFJ bankswitch scheme, in C/C++ (and assembler).  You can make the TIA do some interesting things if you push it hard enough using the ARM's extra speed. 

 

Mmh... "Ship of Theseus" would be a good name for a '2600 game...

[+GoldLeader]

12 minutes ago, Andrew Davie said:

Horse. Dead. Stop flogging

For those interested in philosophy, check out the ship of Theseus, which basically suggests this argument has been around for, well, 2600 years

 

The Ship of Theseus is a thought experiment about whether an object that has had all of its original components replaced remains fundamentally the same object. Theseus was the mythical Greek founder-king of Athens, and the question was raised by ancient philosophers (e.g. Heraclitus and Plato): If the ship of Theseus were kept in a harbor and every part on the ship were replaced one at a time, would it then be a new ship? If it is not the same ship, then at what point did it stop being the ship of Theseus? If it is the same ship, then could all the removed pieces be reassembled to form a ship, and would that be the ship of Theseus? The concept is one of the oldest in Western philosophy, going back to the time of 500–400 BC. It is a common theme in the field of metaphysics.

FWIW, I have been having a lot of fun programming for the CDFJ bankswitch scheme, in C/C++ (and assembler).  You can make the TIA do some interesting things if you push it hard enough using the ARM's extra speed. 

 

Mmh... "Ship of Theseus" would be a good name for a '2600 game...

 

Or perhaps an album by a progressive metal band.

[+Gemintronic]

29 minutes ago, Andrew Davie said:

Horse. Dead. Stop flogging

 

Not my viewpoint: just explaining the rationale.  As I stated before it allows mere mortals to make decent looking games.  Everyone accepts NES games as NES games and they almost from the beginning had hardware assist.

[LatchKeyKid]

4 hours ago, Gemintronic said:

 

Not my viewpoint: just explaining the rationale.  As I stated before it allows mere mortals to make decent looking games.  Everyone accepts NES games as NES games and they almost from the beginning had hardware assist.

Sorry to ask for the clarification.  I didn't realize it was a topic minefield potentially.  With on cartridge expansions being a part of Atari gaming since the middle of the generation and NES from almost the beginning (as you said), I didn't think it was an issue so far into the future.  Though I do see a distinction between added ram or a sound chip and an actual improved CPU, as long as the original hardware is still doing most of the processing and not being completely bypassed then I'm fine with the assist as an evolution of what came before other than maybe qualifying for various award categories.

 

Regardless, I recently found out that my favorite homebrew games I've discovered so far use the bB standard kernel so I'm a bit more enthused about using that and trying to potentially work around the restrictions instead of bypassing them.  Of course that assumes that I get past the 10% inspiration and make any progress on the 90% perspiration part of the potential project. 

[+Gemintronic]

Yeah, some of the things I tried to explain can cause misunderstandings even when two people agree on a subject.  Figured I'd take the hit so there's at least a little less confusion moving forward ?

 

The main thing that got me completing projects is to start small.  Make mini micro nano games that exercise your knowledge in one area.  Say, an experiment in placing a sprite on the screen.  Or, moving a sprite on the screen.  Tiny steps that lead to a bare minimum "game".  Here is my first project: https://atariage.com/forums/topic/165286-conversion-of-drunken-pooper/#comments

 

Also, many developers back in the day found neat tricks and made games around them.  Today we think ZOMG top down side scrolling boomer shooter with RPG elementzzz.!@$#.24132  *cough* I mean, game design first and figure out the coding later.  On my 2600 projects I find a neat feature the 2600 can do and build up from there.

[orange808]

Still singing the ol' AtariAge ARM "greatest hits", I see.

 

If my project ever gets finished, you're going to sh*t your pants and have a seizure. Just know I'll be laughing at you when you complain.  ?

 

And, if you try to sell my efforts short with that "mere mortal" sh*t, I'll embarrass you.

Edited July 2, 2022 by orange808

[+Gemintronic]

16 minutes ago, orange808 said:

Still singing the ol' AtariAge ARM "greatest hits", I see.

 

If my project ever gets finished, you're going to sh*t your pants and have a seizure. Just know I'll be laughing at you when you complain.  ?

 

And, if you try to sell my efforts short with that "mere mortal" sh*t, I'll embarrass you.

 

I don't know who you're talking to.  But, I'll gladly try any hardware / software stack you come up with.

 

UPDATE:  I was the originator of the "mere mortal" comment.  I was using it as a reference to the fact that beginners can make good looking games on DPC+ without a career in low level assembly.   We almost never communicate so I don't understand why you'd assume I hate you or your work.  I don't.  I'd love more neat projects that enable game makers to make great games.

[+Andrew Davie]

16 minutes ago, orange808 said:

Still singing the ol' AtariAge ARM "greatest hits", I see.

 

If my project ever gets finished, you're going to sh*t your pants and have a seizure. Just know I'll be laughing at you when you complain.  ?

 

And, if you try to sell my efforts short with that "mere mortal" sh*t, I'll embarrass you.

I'll show you mine if you show me yours

 

[orange808]

1 minute ago, Andrew Davie said:

I'll show you mine if you show me yours

 

To be perfectly honest, you're a genius and I especially wouldn't ever show you something that isn't presentable. The same way I wouldn't touch the keys if Stevie Wonder was in the room. 

[LatchKeyKid]

46 minutes ago, Gemintronic said:

The main thing that got me completing projects is to start small.  Make mini micro nano games that exercise your knowledge in one area.  Say, an experiment in placing a sprite on the screen.  Or, moving a sprite on the screen.  Tiny steps that lead to a bare minimum "game".  Here is my first project: https://atariage.com/forums/topic/165286-conversion-of-drunken-pooper/#comments

 

Also, many developers back in the day found neat tricks and made games around them.  Today we think ZOMG top down side scrolling boomer shooter with RPG elementzzz.!@$#.24132  *cough* I mean, game design first and figure out the coding later.  On my 2600 projects I find a neat feature the 2600 can do and build up from there.

 

Thanks and definitely good advice.  I've been watching youtube series (plural) about asm coding but I think that it's above what I'm capable of (whether just now or forever remains to be seen).  That's why I took an interest in bB and ask questions.  I started with the idea but with the hardware limitations of the 2600 in mind.  So far, I've just got the general theme, gameplay style, and player character sprites done so the next step would be as you posted (although in my case checking to see if I can add the ball for added color to a single color sprite with enough CPU cycles left over for other things) just getting the sprite on screen and moving then animated.