Atari 2600 BASIC compiler is here!

[yuppicide]

I think it's funny to play along with the sample file. You can get hung up on the side of the screen and your character will flicker, but if you wiggle the controls you can "break through" to the other side.

 

You can hide off screen and trick the other guy.. he'll go in a different direction and be off the screen for a good 5 or 8 seconds.

[Serguei2]

Is 2600 basic limited to make 2k and 4k or it support larger carts like 8k, 16k,...?

[Jacob Rose]

I have been talking about something like this for YEARS. People said it could not be done. Of course mine would probably be more in-depth than this one is, but this is a start and I'm gonna check it out.

 

It could be the start of an actually 2600 game design program or a 2600 development system. The way I envision my idea was a graphic editor built in, and different routines that could allow you to make a variety of games with little effort. Almost like a Gamemaker or Click N Play designed to make 2600 games.

888295[/snapback]

 

Hmm, yours does sound pretty good, but one difference you've overlooked is that this one exists, and yours doesn't. *grin*

 

You've got to walk before you can run...this may be the first step toward realizing your vision!

[yuppicide]

Alright I've been fooling around. Let's say I want to make a title screen of some sort.. what's the easiest way to make a whole screen's graphics?! I have something simple drawn up. Of course starting with a title screen isn't something I should do, but it's something easy to do and I'm just fooling around right now.

 

Such as you have player0 and player1, would I draw a bunch of them, position them all where they need to go with a variable?!

[Jacob Rose]

Alright I've been fooling around. Let's say I want to make a title screen of some sort.. what's the easiest way to make a whole screen's graphics?! I have something simple drawn up. Of course starting with a title screen isn't something I should do, but it's something easy to do and I'm just fooling around right now.

 

Such as you have player0 and player1, would I draw a bunch of them, position them all where they need to go with a variable?!

888327[/snapback]

 

Since BATARI BASIC seems to support asymmetric playfields, I'd say that' s the best route. You can do a nice low-resolution (but full screen) title screen like in WARRING WORMS or CRAZY BALLOON. Doing high-resolution title screens like in STARGATE or, um, this game requires very specialized coding. Maybe that could be a future addition to the toolset, though; a special title graphic operator just for drawing 6-column VDEL graphics?

Edited July 8, 2005 by Jacob Rose

[kisrael]

batari,

like I mentioned on [stella], this is very cool. And as yuppicide said, congrats on hunkering down and doing what people have just been talking about. (And some people said it couldn't be done, but more said that it would be limited...)

 

I need some time to play with it in its current form, but there is a ton of potential here.

 

Here's an idea: maybe you can make the functions completely modular-- rather than embedding the BASIC->ASM translation in C, have each defined in a text file that describes the mapping. Then we could have libraries of functions, and experienced coders could write functions: A function could be anything from a different kernal to 16 bit math (like I mention on [stella].

 

Does this have a permanent web home yet? I'd be more than delighted to give you an URL like http://alienbill.com/2600/basic/ -- and/or maybe someday you could get http://www.atariage.com/2600/programming/basic/ or some such.

 

Just some thoughts. Great stuff.

[attendo]

To make a beep, I'd set AUDC0 and AUDF0 at the beginning of the program.  I think these might produce a good "beep" sound:

 

5 AUDC0 = 12 : AUDF0 = 3

 

then when the ball changes direction, you can also set AUDV0 = 15 to turn the sound on, then set AUDV0 = 0 sometime after the call to "drawscreen" which will keep the sound on for about 1/60th of a second, but should be perfect for a pong game.  To keep the sound on longer, you would need to set up a counter or something of that sort and turn it off after several iterations through the game loop.

 

Much thanks, ill try it but still if you want to make a new basic language with its own syntax then it would look nicer to just use something like:

 

SOUND channel,frequency (SOUND 0,25)

VOLUME channel,volume (VOLUME 1,15)

 

Then just replace when compiling SOUND with AUDF0 or AUDF1 according to the first variable (channel).

 

And replacing every BEEP command with AUDC0 = 12 : AUDF0 = 3 ? Just some random thoughts, I know its easier said than done

Edited July 8, 2005 by attendo

[Cybergoth]

Hi there!

 

SOUND channel,frequency (SOUND 0,25)

VOLUME channel,volume (VOLUME 1,15)

 

I'd suggest using music.h here, then it could be readable as in

 

SOUND 0, LEAD_C5

 

Greetings,

Manuel

[attendo]

I just tried the AUDC0 = ..etc. stuff and it works great! But Batari you will realise that you will soon flood the Atari scene with 100s of new homebrews from newbies made with your basic version

 

Have you already decided on a definitive name for the gam..language?

2600 Basic sounds a bit like a cart for an atari, BATARI BASIC did sound nice

[yuppicide]

I don't see the market flooded with 100's of homebrews from Newbies. It still has some learning curve to it. I see more homebrews being made, but not 100's.

 

That Belling The Cat screen looks really nice. I'd be happy to make something even worse than that heh.

[Godzilla]

Much ass, this kicketh. Try it, I will. To you, many thanks.

[potatohead]

"I don't see the market flooded with 100's of homebrews from Newbies. It still has some learning curve to it. I see more homebrews being made, but not 100's."

 

Give it some time....

 

I spent a little time this morning playing with the basic, then looking at the assembly. (Man, it's been a long time.) Just being able to express basic changes in a simple, high level, way really helps clarify the whole process. --at least it does for me.

 

Anyway, it all works good on Linux. I futzed around with different player shapes, movements and other things. Doing those things, from a raw assembly code file would have taken most of the day. --Nice, IMHO.

 

I want the ball!

[Brad2600]

I have some experience with Java programming and I was wondering, what would it take to make the transition to programming in Basic or C or any other language? I am interested in using this compiler if I can find a basic tutorial and some time to look it over.

 

Very exciting though!

[attendo]

Basic is very simple, Beginners All-purpose Symbolic Instruction Code There are many basic tutorials on the net but they won't be for this basic version..lol..they still have to make some.

Edited July 8, 2005 by attendo

[djmips]

Very interesting.

 

Just for kicks, I'll think I'll give it a go and see 'bout making a simple game with this. I have an idea already.

 

I've always thought that it would be nice to do some game logic at least using decent macros if not an actual compiler.

 

BTW - it was very common in the early days of compilers to generate asm code instead of machine code directly.

[+batari]

Is 2600 basic limited to make 2k and 4k or it support larger carts like 8k, 16k,...?

888306[/snapback]

Right now it's only 4k - and when you run out of code space, compilation will fail. If I can figure out how to seamlessly allow bigger carts when 4k is used up, I will put this in.

[+batari]

Alright I've been fooling around. Let's say I want to make a title screen of some sort.. what's the easiest way to make a whole screen's graphics?! I have something simple drawn up. Of course starting with a title screen isn't something I should do, but it's something easy to do and I'm just fooling around right now.

 

Such as you have player0 and player1, would I draw a bunch of them, position them all where they need to go with a variable?!

888327[/snapback]

For now, you can use inline asm to create a more snazzy title screen - for instance, using the TIA playfield painter program, you can take the asm code that this creates and paste it right into a BASIC program with a little finagling. I believe it takes up quite a bit of space, though.

 

You could draw multiple player 0 and player 1 graphics but you'd have to display them on alternate frames by flickering. Probably wouldn't look too good. There may be a better way coming, though.

 

I little while ago, I write a kernel for 48-wide by 192 high graphics with a color change every scanline, which can take a graphic created with a graphics editing program (as MS Paintbrush/photoshop, etc) converted to data with Eckhard's PCX2GRP utility. The issue is that the kernel and graphics data takes about 2.5k of ROM, so this functionality would not be a part of BASIC itself, but rather, a title screen would have to be created with a separate utility and linked with the BASIC binary later by making it an 8k bankswitched binary.

 

Here's a screenshot of the display screen for an upcoming cart full of minigames to give you an idea of what the title screen kernel can do:

 

 

I don't want to get people too excited yet though - this all takes time...

[+batari]

batari,

like I mentioned on [stella], this is very cool. And as yuppicide said, congrats on hunkering down and doing what people have just been talking about. (And some people said it couldn't be done, but more said that it would be limited...)

 

I need some time to play with it in its current form, but there is a ton of potential here.

 

Here's an idea: maybe you can make the functions completely modular-- rather than embedding the BASIC->ASM translation in C, have each defined in a text file that describes the mapping. Then we could have libraries of functions, and experienced coders could write functions: A function could be anything from a different kernal to 16 bit math (like I mention on [stella].

I think I know what you mean... it would make the code easier to understand and maintain, too. I'd have to think about how to code this.

Does this have a permanent web home yet? I'd be more than delighted to give you an URL like http://alienbill.com/2600/basic/ -- and/or maybe someday you could get http://www.atariage.com/2600/programming/basic/ or some such.

 

Just some thoughts. Great stuff.

888333[/snapback]

You can put it up on your web page. I used to have my own web server from 2000-2003 but a hacker broke in and did an rm -rf * and I never got around to getting it going again, then I moved and had to go with an ISP that doesn't allow webservers Chances are, I won't get a webserver going again, so feel free to host this.

[supercat]

Is 2600 basic limited to make 2k and 4k or it support larger carts like 8k, 16k,...?

888306[/snapback]

Right now it's only 4k - and when you run out of code space, compilation will fail. If I can figure out how to seamlessly allow bigger carts when 4k is used up, I will put this in.

888526[/snapback]

 

How about having an 8K mode which puts the video kernel and graphics in one bank and everything else in the other? That wouldn't necessarily be the optimal division, but it should be pretty simple to do seamlessly.

[kisrael]

I'll get on making a quick and dirty page for this at that URL.

 

Re: Title Screen... the 48 pixel centered graphics can be pretty sweet, though I think I got pretty good results w/ JoustPong / FlapPing with the Playfield. The pixels are pretty fat, but even when I went to a 2LK to save ROM space (halving the ROM needed for the page) it was still pretty ok looking, and is more dramatic.

 

I'm still thill thinking that "kernal chunks" are a good way to go...they can be pretty modular. So in the current case, it would be cool if "score" was a different subkernal than the main game display. And then each chunk just has to declare its preconditions and postconditions, what registers it munges, that kind of thing. And that way, something like the 48 pixel graphic can alternate with a full scren thing, or a kernal that uses the sprites.

 

I didn't have much luck using some of the playfield graphics you include, are they fully implemented yet? And this may be a dumb question, but can you have multiple pixels and lines on one displayed screen? I was wondering how you did that, since a mapped playfield takes up so much precious RAM...

[+batari]

Is 2600 basic limited to make 2k and 4k or it support larger carts like 8k, 16k,...?

888306[/snapback]

Right now it's only 4k - and when you run out of code space, compilation will fail. If I can figure out how to seamlessly allow bigger carts when 4k is used up, I will put this in.

888526[/snapback]

 

How about having an 8K mode which puts the video kernel and graphics in one bank and everything else in the other? That wouldn't necessarily be the optimal division, but it should be pretty simple to do seamlessly.

888543[/snapback]

That would work, but I'd make it an option since some may prefer a 4k game for various reasons. However, a title screen like the one I posted above should also fit in one bank, along with the BASIC kernel and user graphics, so then one would have a full 4k for code in the other bank. Or perhaps even 12k of code, if I allowed 16k roms.

[+batari]

I didn't have much luck using some of the playfield graphics you include, are they fully implemented yet?  And this may be a dumb question, but can you have multiple pixels and lines on one displayed screen?  I was wondering how you did that, since a mapped playfield takes up so much precious RAM...

888556[/snapback]

It could as simple as COLUPF not being set - it's black by default.

 

The syntax is:

 

pfpixel xpos ypos action

pfvline xpos ypos endypos action

pfhline xpos ypos endxpos action

pfscroll direction

 

where xpos is 0-31

ypos is 0-11

endypos is bigger than ypos, and 0-11

endxpos is bigger than xpos, and 0-31

actoin is on, off or flip (flip turns the pixel on if it is off, or off if it is on)

direction is left, right, up or down.

 

Here's some examples:

 

10 pfpixel 3 4 on

20 pfvline 5 5 8 flip

30 pfhline 7 4 27 on

40 pfscroll up

 

And yes, the playfield takes a full 48 bytes of RAM. However, you can use this as general-purpose variable storage if you don't use a playfield and COLUPF is the same as COLUBK, though doing so is not recommended at this time. In the future I'll allow this explicitly in some fashion.

[supercat]

That would work, but I'd make it an option since some may prefer a 4k game for various reasons.

888576[/snapback]

 

Naturally, people who want a 4K game should be free to design one. I was just suggesting the above as probably the easiest way to allow people to go beyond 4K.

[potatohead]

Well, ok a game can be made with this. I just put up a coupla walls, used one player for the ball, the other for the paddle, made some edits and got moving objects.

 

So far, no hardware collision is used. Just math controlling the motion of the ball.

 

Boring as hell actually, but hey this does prove the learning curve is quite a bit better using this tool. --Nice work, I've got something in a day running on a 2600

 

Here is the basic code:

 

1 rem smartbranching on
10 x = 50 : y = 90 : w = 40 : v = 40
11 d = 1 : e = 1 : f = 0 : g = 0
20 COLUPF = 30
30 COLUP0 = 120 : player0x = x : player0y = y
40 scorecolor = 10
45 player0:
%01000010
%11111111
%11111111
%00000000
end
46 player1:
%00000000
%00011000
%00111100
%01111110
%00111100
%00011000
%00000000
end
47 a = a + 1 : if a < 3 then 90
49 a = 0
51 w = w + d : v = v + e
64 player1x = w : player1y = v
65 pfvline 0 0 11 on
66 pfhline 0 0 31 on
67 pfvline 31 0 11 on
68 pfhline 0 11 31 on
90 drawscreen
91 f = x + 250 : g = x + 5
95 if v > 88 then 99
96 goto 173
99 e = 255
100 if w < f then e = 1
102 if w > g then e = 1
173 if v < 15 then e = 1
175 if w > 148 then d = 255
177 if w < 35 then d = 1
180 if joy0left then x = x - 1
190 if joy0right then x = x + 1
200 goto 30

 

Screenie and binary attached.

 

 

 

boring_game.zip

[attendo]

Lol, was working on something similair to, try it out if you like, when you fail to catch the ball you will here a different sound than when you catch it. Code is a bit messy do, I think.

 

1 rem smartbranching on
2 rem dong v.02 by attendo
5 AUDC0 = 5 : AUDF0 = 3
6 AUDC1 = 4 : AUDF1 = 5
10 x = 80 : y = 44 : a = 1 : b = 1 : c = 80 : d = 0 : z = 0
20 COLUP0 = $CE
30 player0x = x : player0y = y
40 player0:
%00011000
%00111100
%01111110
%01111110
%00111100
%00011000
end
41 COLUP1 = $0E
42 player1x = c : player1y = 88
43 player1:
%11111111
%11111111
%00000000
end
46 z = c + 6 : if x > z then goto 80
47 z = c - 6 : if x < z then goto 80
49 d = d + 1 : if d < 2 then goto 56
50 if X > 166 then a = 0 - a : AUDV0 = 15
51 if x < 16 then a = 0 - a : AUDV0 = 15
52 if y > 88 then b = 0 - b : AUDV0 = 15
53 if y < 11 then b = 0 - b : AUDV0 = 15
54 x = x + a
55 y = y + b : d = 0
56 if joy0left then c = c - 1
57 if joy0right then c = c + 1
58 if c < 8 then c = 8
59 if c > 159 then c = 159
65 drawscreen
66 AUDV0 = 0 : AUDV1 = 0
70 goto 20
75 rem sub
80 if y < 87 then goto 49
83 AUDV1 = 15
85 x = rand : if x > 160 then x = 160
86 if x < 16 then x = 16
90 y = rand : if y > 20 then y = 20
92 if y < 11 then y = 11
99 goto 50

 

btw: next time i will only add an attachment posts will get so annoyingly long this way, sorry.

 

Things to do: + 2nd player, + score, + walls? + cpu player, + mainscreen, + weapons, +coffee, +time