68 replies to this topic

[JohnnyRockets]

Hey gang,

Need a bit of guidance here.


I have programmed both in ASM and BASIC in my life, and both are cool.  Certainly BASIC is easier in some ways.


If I want to dive into programming the 2600, which language should I focus on?  Or is it just personal preference?



Thanks!



JR

[Propane13]

If you've done ASM, and like ASM, I'd say start there.
If you've never done ASM, bAtari is great.

[SpiceWare]

While bB is impressive, you'll be able to do a lot more with ASM.

One thing you'll need to get a handle on is cycle counts.  When I learned 6502 back in the 80s it wasn't something I needed to learn, but it's very important when writing the kernel routines for 2600 games.  There's no video RAM, the kernel is the code that updates TIA (the video chip) scanline-by-scanline in real time.

If you're not familiar with cycle counts, check the replies this topic.  I posted an example in it which might help.

[RevEng]

It depends on which benefits matter to you the most...

Assembly pro's:

• allows for more compact code than bB.
  
• gives you finer control than just plain bB without inline assembly.
  
• gives you a feeling for the way things used to be done. (though you will be using massively-superior tools compared to commercial coders had, back in the day)
  
• provides more street-cred in some circles.

bB pro's:

• integrated code libraries, kernels, and higher level language allow for faster development time.
  
• optional vbb editor allows for visual approach
  
• ability to freely mix bB and assembly code allows the advanced bB coder the ability to reap the benefits of assembly code.

[JohnnyRockets]

Well put!  I guess I'll just have to tinker with one, and then try the same thing on the other and see what is more "fun".  Because it does just come down to fun for me.


Thanks everyone!

[theloon]

I'd say bB would let you test gameplay concepts more quickly.  If you've got some ASM experience it would be nice to have another person making mini kernels for Batari BASIC.

[JohnnyRockets]

I'm leaning towards ASM, just cause I'm geeky that way (no offense to anyone, just talking about myself purely here).

But I don't understand the concept of "making mini kernels", can you explain?

Allow me again to draw everyone's attention to fact that I absolutely ZERO about all things Atari!

But I'm gonna learn!  ; )

[Pioneer4x4]

I highly recommend bBasic first.   You still need to know almost all of the idiosyncrasies of  the Atari and how it handles its minimal sprites.  You just don't have to worry as much about timing.

[jdrose]

Good question.

bBasic is a great language and I appreciate the effort that went into it.
I used it to get familiar with the RIOT. However, it is not the native language of the 6507, thus it is a barrier between you and the processor.

In my opinion, I would say just dive in and learn 6507. It has a very small instruction set and is not difficult to learn at all. Though it does take months or years to master. Also it is really important to learn 6507 so you can make code as small and elegant as possible. It is also possible to know what is going on with the 6507 to the cycle. That's important in the VCS environment.

[JohnnyRockets]

Thanks jdrose!

That was my final decision too!  I have started down that road, just bought my first 2600 and now I'm buying a Harmony cart.

JR

[jdrose]

Pardon me. I meant to write TIA instead of RIOT.

[SvOlli]

Johnny,

to might want to take a look at these two talks:
About the 6502:

(The 6507 is a stripped down version of the 6502)
About the 2600:


These should provide you with enough information to give you an orientation about what you need to know.

And also keep in mind, that running code on the Harmony is fun, but development usually takes place in an emulator, probably Stella, since there you got a debugger where you can single-step your code. Not only useful for finding bugs in your code, but also to learn from other people's code.

Greetings,
SvOlli

Edited by SvOlli, Sun May 6, 2012 2:09 PM.

[JohnnyRockets]

Super cool SvOlli!

Thanks!

[Dan Iacovelli]

if you know asm then go with it
bB is basically used for beginners who want to get their feet wet in programing and don't want to do ASM.
I love bB and especially with Vb ide lot easy

[SpiceWare]

SvOlli, on Sun May 6, 2012 2:09 PM, said:

And also keep in mind, that running code on the Harmony is fun

I'd go so far as to say it's required to have something like the Harmony to run the code on real hardware.  Stella's debugger is invaluable, but I've run into things over the years that worked OK in Stella, but not on the Atari (such as screen jitter when timing is off).

Great presentation, I downloaded the higher quality version and watched it on my iPad last night.  I'm curious as to which games you're still trying to figure out how they did? One thing that helps is to use Stella's Fixed Debug Colors feature.  I have some examples of doing that in the slides from my presentation I did here in Houston last year.  Search for the word "complex", the examples are in the slides following it.

I will say it was odd hearing "two thousand six hundred" all the time, here it's  "twenty six hundred"  - though I often say "VCS" as that's what it was known as when we got ours  

[SvOlli]

Just a quick one, before I head off to work.

SpiceWare, on Mon May 7, 2012 4:54 PM, said:

Stella's debugger is invaluable, but I've run into things over the years that worked OK in Stella, but not on the Atari (such as screen jitter when timing is off).

Not any more. With the most recent versions, if you're timing is slightly off, the output will become black'n'white.

SpiceWare, on Mon May 7, 2012 4:54 PM, said:

Great presentation, [...]

Thanks!

SpiceWare, on Mon May 7, 2012 4:54 PM, said:

I'm curious as to which games you're still trying to figure out how they did?

That was a reference to Solaris. I'm really impressed on how Doug Neubauer drew the Saturn-like planet on the starting screen.

SpiceWare, on Mon May 7, 2012 4:54 PM, said:

I will say it was odd hearing "two thousand six hundred" all the time, here it's  "twenty six hundred"  - though I often say "VCS" as that's what it was known as when we got ours  

That should be because I'm a German native. In German it's very uncommon to use the ...-hundred for anything above nineteen.

What I also noticed, when I first owned my 2600, it was just called "The Atari". If I now point of in some chat that I did a talk about "the very first Atari console" almost everyone get's mistaken and assumes that it's an Atari ST that I'm talking about.

[SpiceWare]

SvOlli, on Tue May 8, 2012 12:04 AM, said:

Not any more. With the most recent versions, if you're timing is slightly off, the output will become black'n'white.

That's a PAL color-loss thing where the color goes away if the number of scanlines becomes odd.  That doesn't happen in NTSC. What I was referring to was if your overscan is off, and it's higher some frames and lower on others then the screen will jitter (wiggle, shake, slightly move) up and down.  Stella doesn't emulate that.  I'm also doing Harmony/Melody development(Frantic and Space Rocks) and while we did get Stella to run ARM code, it doesn't emulate cycles for the ARM code so it's very easy to exceed vertical blank and overscan time.

Quote

That was a reference to Solaris. I'm really impressed on how Doug Neubauer drew the Saturn-like planet on the starting screen.

Looking at the debug colors, the planet is drawn just with player 1 while the ring is drawn with player 0 and missile 0.  The white strip down the left side means that HMOVE is being hit on every single scanline, so object(s) are being moved left/right.

Watching the TIA tab in the debugger while stepping the code a scanline at a time, you'll see that player 0 is set to a single 1x sprite and is shifted left to right as the scanlines are being drawn.  Missile 0 is also shifted left to right.  Player 1 is set to 2x size (so the 8 pixels are doubled to span 16 pixels) and is shifted left and right to make it look smooth.  Stella shows anything that changed since the last step using green text on a red background, so in this screenshot of the debugger you can see that every object's position was changed from the prior scanline.


I did the same shifting 2x player trick in Medieval Mayhem for the dragon, though I only hit HMOVE on the scanlines the players get shifted on.

  I came up with that after I noticed how large, yet detailed looking, the dolphin and squid looked in the game Dolphin.  I think tracked down an an interview with Matthew Hubbard on how he did it.

Quote

SS: How did the idea for Dolphin come about?

MH: I wanted to make a game where the main characters were a little bigger than normal on the 2600, using double-size mode and line-by-line single pixel shifting. I experimented with making a dolphin animation, and everyone who saw the early screens knew immediately that the pixels represented a dolphin, so I moved forward from there.

Quote

That should be because I'm a German native. In German it's very uncommon to use the ...-hundred for anything above nineteen.

Don't remember if we were taught that (ja ich kann deutsch, aber nicht sehr gut) as my German classes were 30 years ago.  Like a lot of Americans, I learned another language in high school, but we don't often get to use them so they fade from memory - if you drive a few hours you end up in another country and need another language, it takes me 3 days to reach Canada and they speak English there.  We lived outside Chicago when I learned German, if I had known I'd end up in Texas then learning Spanish would have been a lot more helpful.

Quote

What I also noticed, when I first owned my 2600, it was just called "The Atari". If I now point of in some chat that I did a talk about "the very first Atari console" almost everyone get's mistaken and assumes that it's an Atari ST that I'm talking about.

It was also known as just "The Atari" here.

[SvOlli]

Darell,

thanks for the great explanation, it was better that what I figured out myself, as I did the analysis last week myself. I forgot to mention that.

btw: how are debug colors activated. Didn't find it on the first quick look.

[stephena]

SvOlli, on Thu May 10, 2012 2:33 PM, said:

Darell,

thanks for the great explanation, it was better that what I figured out myself, as I did the analysis last week myself. I forgot to mention that.

btw: how are debug colors activated. Didn't find it on the first quick look.

Alt-Comma (Cmd-Comma for OSX).

[SpiceWare]

Your welcome.  

I'm on a Mac, so I use Command-Comma to toggle it.  In Stella's help file, go to section 5. Keyboard Layout.  It's in a table called Developer Keys.  Linux/Windows uses ALT-Command.

I see stephena beat me to it

Edited by SpiceWare, Thu May 10, 2012 2:49 PM.

[SvOlli]

Thanks to you both,

now I also was able to solve the other mystery: how they did the color bars on the Activision logo. A combination of playfield and ballsprite, changing COLUBK in the middle of the screen. Clever, very clever. An idea I couldn't come up with more the 25 years later... *sigh*

[SpiceWare]

SvOlli, on Thu May 10, 2012 3:28 PM, said:

Thanks to you both,

now I also was able to solve the other mystery: how they did the color bars on the Activision logo. A combination of playfield and ballsprite, changing COLUBK in the middle of the screen. Clever, very clever. An idea I couldn't come up with more the 25 years later... *sigh*

Here's a fun one for you - 48 pixels with 2 colors and no flicker.




http://www.atariage....25#entry2373058
http://www.atariage....ace-rocks-2600/

[SvOlli]

SpiceWare, on Thu May 10, 2012 4:39 PM, said:

Here's a fun one for you - 48 pixels with 2 colors and no flicker.

That's an easy one. You're cheating by using the DPC+ chip.

The maze selection can be done without, though: negate the gfx data, set CTRLPF to $02 and set different values for COLUP0 and COLUP1.

P.S.: Nice game, once this gets completed you can go for a "Robotron: 2084" port, which is imho the best game of that category. At least, it's the one of the games with the highest bodycount per second.

But we are getting way off-topic, aren't we?

[SpiceWare]

It helps, but there's free cycles in there so I'm pretty sure it could be done without DPC+.  Worse case would be to give up the scanline-by-scanline changing of both colors (so it'd be like the menu options in Frantic as opposed to those in Space Rocks).

It's done by using inverse graphics - the sprites are black and the color comes from the background and the playfield/ball.  VBLANK is turned on/off so that the color of the playfield doesn't show on either side of the 48 pixels.  VBLANK can't be changed at the exact cycle it needs to be, so the missiles are used to help hide the background on both sides of the 48 pixels.

Thanks, though I don't think Robotron would work well.  I did some experiments with the Asteroids kernel and showed that there'd be way too much flicker when the robots converge.

It happens, but at least JohnnyRocket's got the answers he was looking for.

[SvOlli]

SpiceWare, on Fri May 11, 2012 3:06 PM, said:

Thanks, though I don't think Robotron would work well.  I did some experiments with the Asteroids kernel and showed that there'd be way too much flicker when the robots converge.

I was kidding on this one. Forgot the smiley though, sorry.

I've got a MAME arcade in my living room (German description and images are here: http://blog.h8u.de/-274) also running Robotron: 2084, and the big fun comes from two parts: the two joystick control, which can be done on the 2600 by clamping joysticks to the table, and the ~100 enemies, which just can't be done on the 2600. Another fun part is the usage of the blitter for nice explosions of the enemies.

While you could do a Frenzy with Robotron controls, it still misses the overwhelming flood of enemies and the nice explosions.

But seeing your spacerocks100.bin, I must say, I've expected much worse for 50 sprites on half a screen.