Jump to content
IGNORED

ASM or bBasic?


Recommended Posts

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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! ; )

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Johnny,

 

to might want to take a look at these two talks:

About the 6502:

http://www.youtube.com/watch?v=K5miMbqYB4E

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

About the 2600:

http://www.youtube.com/watch?v=qvpwf50a48E

 

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
  • Like 1
Link to comment
Share on other sites

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

- though I often say "VCS" as that's what it was known as when we got ours :)
Link to comment
Share on other sites

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

 

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.

 

Great presentation, [...]

Thanks!

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.

 

I will say it was odd hearing "two thousand six hundred" all the time, here it's

- 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. :(

Link to comment
Share on other sites

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.

 

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.

post-3056-0-31199800-1336486822_thumb.png post-3056-0-31771700-1336486828_thumb.png post-3056-0-12600900-1336486835_thumb.gif

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.

post-3056-0-71341600-1336488321_thumb.png

 

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.

post-3056-0-57062600-1336487655_thumb.png post-3056-0-26329200-1336487662_thumb.png

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.

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.

 

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.

 

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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 :D

Edited by SpiceWare
Link to comment
Share on other sites

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*

Link to comment
Share on other sites

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.

post-3056-0-65754900-1336689453_thumb.png

 

post-3056-0-02693000-1336689513_thumb.png

 

http://www.atariage....25#entry2373058

http://www.atariage....ace-rocks-2600/

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...