Atari 2600 BASIC compiler is here!

[+batari]

Cool! Good to see people are already doing things with the compiler/language. Ironically, I haven't yet written anything more interesting than the sample program for my own compiler

[attendo]

Perhaps you can add some basic short demonstrations/tutorials with the zip, for example for sound, controllers, graphics, collision, etc. It gives new people something to look at, try and learn from.

[potatohead]

Ok, here is the last version of this simple brick game. I wanted to know if a complete game was possible and it is!

 

Math limits are used to constrain the location of the ball within the walls. Hardware collision is used to detect a brick to be eliminated, based on the ball variables. (Was surprised this bit actually worked.)

 

There are sounds for different events, a random ball starting position and the joystick trigger resets the game. I didn't futz with the score, nor did I handle the end of game condition very well. Strange things happen when you miss the ball.

 

Here is the code and the binary again.

 

(This was fun!)

 

1 rem smartbranching on
5 AUDC0 = 12 : AUDF0 = 3
10 x = 50 : y = 90 : w = rand : v = 60
11 d = 1 : e = 255 : f = 0 : g = 0 : h = 1 : i = 0 : j = 0 : k = 0 : l = 0
12 if w > 100 then w = 100
14 if w < 40 then w = 40
20 COLUPF = 54 : COLUBK = 17
22 pfhline 0 2 31 on
23 pfhline 0 3 31 on
30 COLUP0 = 120 : player0x = x : player0y = y : l = l - 1
40 scorecolor = 10
45 player0:
%01000010
%11111111
%11111111
%00000000
end
46 player1:
%00011000
%00111100
%01111110
%00111100
%00011000
end
47 a = a + 1 : if a < 3 then 90
49 a = 0 : i = INPT4
51 w = w + d : v = v + e
52 if l = 0 then l = 4 : w = w - d
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
69 AUDV0 = 0
90 drawscreen
92 f = x + 250 : g = x + 5
93 if CXP1FB < 64 then 154
94 if l = 1 then 154
110 j = w - 28 : j = j / 2 : j = j / 2
112 pfpixel j 3 off : l = 1
118 AUDF0 = 58 : h = 1
130 if e = 1 then e = 255
134 if e = 255 then e = 1
154 if v > 88 then 159
157 goto 173
159 e = 255 : h = 1 : l = 0
160 if w < f then e = 1 : h = 0 : AUDF0 = 50
162 if w > g then e = 1 : h = 0 : AUDF0 = 50
173 if v < 15 then e = 1 : h = 1 : AUDF0 = 40 : l = 0
175 if w > 148 then d = 255 : h = 1 : AUDF0 = 70 : l = 0
177 if w < 35 then d = 1 : h = 1 : AUDF0 = 70 : l = 0
179 if h = 1 then h = 0 : AUDV0 = 15
180 if joy0left then x = x - 1 
190 if joy0right then x = x + 1
195 if i < 15 then 5
200 goto 30

 

working_game.zip

Edited July 9, 2005 by potatohead

[+batari]

Perhaps you can add some basic short demonstrations/tutorials with the zip, for example for sound, controllers, graphics, collision, etc. It gives new people something to look at, try and learn from.

888820[/snapback]

THis, along with putting the ball into the kernel, and improving the parsing top the current priority list.

[+batari]

93 if CXP1FB < 64 then 154

If you want to use the TIA regs directly, you can, but I did try to simplify the collision regs. I've done it correctly then this should work as well:

 

93 if collision(player1,playfield) then 154

 

I've gotta get some better examples/tutorials/docs going soon...

Edited July 9, 2005 by batari

[potatohead]

Perhaps you can add some basic short demonstrations/tutorials with the zip, for example for sound, controllers, graphics, collision, etc. It gives new people something to look at, try and learn from.

888820[/snapback]

THis, along with putting the ball into the kernel, and improving the parsing top the current priority list.

888823[/snapback]

 

Feel free to include the game with your package if you want. It's not going to win any style points, but it does give someone plenty to tinker with.

 

I didn't find the parsing limits annoying at all. There are not many complex statements. Being able to express more complex things (such as those with paranthesis) would be handy however.

 

Addressing the playfield directly as an array would not be a bad idea either.

 

I like the sound the way it is. Using the registers is important. Getting too high level will place even more sharp limits on what can be done. Better to make this aspect clearer, IMHO.

 

My suggestion would be to include tags like you did for drawscreen to better differentiate between init code and kernel code.

 

One thing I tried, that did not work was this:

 

10 init stuff

20 draw playfield

30 increment player positions (begin of kernel loop)

40 do other stuff)

50 drawscreen

60 do game logic... (I assume this is the vblank period)

65 if something is true, go do something else @ 100

66 set a flag

67 carry on with game logic

70 goto 30

100 something else to be done

110 goto 67

 

The little bit of code @ 100 ran all the time anyway, or it seemed to for me. This part of things is confusing....

 

Longer variable names and lables to be used in place of line numbers would make things easier to follow. Basic programs tend to get messy...

 

Would be nice to optionally dedicate an area of ram for the score and just have it work by setting variables.... (this might be expensive though.)

 

Good job though. It was capable of a game right out of the gate. Given the timing issues, this is one hell of an accomplishment!

 

Doug Dingus

[potatohead]

Just saw your post. --Nice. Knowing that (and probably a few other things) would have helped!

 

Was fun all the same.

[+batari]

Yes, I'm going to allow labels and/or line numbers (actually both will be optional) and slightly more complex statements (maybe limit to one boolean operator so it's not too hard to parse.)

 

And I'll allow defining your own variable names - I just need to figure out a good way to do this.

65 if something is true, go do something else @ 100

Seems like this should have worked and not jumped to line 100 all the time. What was the condition? Could be another bug in the compiler or something strange with the condition

[potatohead]

Yes, I'm going to allow labels and/or line numbers (actually both will be optional) and slightly more complex statements (maybe limit to one boolean operator so it's not too hard to parse.) 

 

And I'll allow defining your own variable names - I just need to figure out a good way to do this.

65 if something is true, go do something else @ 100

Seems like this should have worked and not jumped to line 100 all the time. What was the condition? Could be another bug in the compiler or something strange with the condition

888829[/snapback]

 

I'll see if I still have the code snippet. If you say it should work correctly, then it probably did. (Everything else behaved in a sane manner, why not?) Probably my logic error. Had a few of those trying to determine the right comparisons to make...

 

Either way, it's easy enough to test another day.

[DracIsBack]

Thanks for doing this, Fred. Some of us who've wanted to get into homebrews for a while but aren't experienced programmers would benefit from this! Here's to hoping your idea will expand to the 8-bit/5200 and 7800 too!

[kisrael]

Thanks for doing this, Fred. Some of us who've wanted to get into homebrews for a while but aren't experienced programmers would benefit from this! Here's to hoping your idea will expand to the 8-bit/5200 and 7800 too!

 

Umm, doesn't the 8-bit already have a pretty good BASIC?

 

[kisrael]

I'm proud to announce:

The Semi-Official Batari BASIC Homepage

I've gotten Batari's blessing to appoint myself keeper of the page, at the very least for the time being. I'll work to keep it updated with the latest version, as well as including sample code and maybe extra documentation.

 

Potatohead, I went ahead and added "working_game.bas" there, along with a screenshot and your description of it. You seemed pretty relaxed about its use so I just made sure you were properly accredited.

Edited July 9, 2005 by kisrael

[kisrael]

Bug report I think, though I don't know if I'm doing something wrong...

 

I wanted to mess with the graphic commands you showed me so I entered them into sample.bas as lines 41-44:

41 pfpixel 3 4 on
42 pfvline 5 5 8 flip
43 pfhline 7 4 27 on
44 pfscroll up

 

That worked pretty well, but I wanted to see what it looked like without the scrolling, so I tried removing line 44...at that point the compile started to fail with a DASM error:

DASM V2.20.10, Macro Assembler ©1988-2004

--- Unresolved Symbol List

player46_1 0000 ???? (R )

NO_ILLEGAL_OPCODES 0000 ???? (R )

--- 2 Unresolved Symbols

glancing at the generated asm code, I do see that the player46_1 label is there, though actually I don't know enough about the processor directives that precede it to know if that's confusing the issue or what.

 

Maybe someone (potatohead, would this interest you?) could write up a summary of the commands so far, especially what the arguments seem to be, and how big the playfield graphics range is (0-31 for the width, right?)

 

Oh, and thinking of the README, Batari, when you say

"Other functions: (better category name here)

these are all called in an if-then statement, e.g."

 

I think a useful term would be "conditionals" or "conditional functions". I believe that's even the correct "computer science" usage, but suddenly I'm not sure if it applies to just what's being evaluated or the whole if then thing.

 

Heh, random thought, unfortunately I don't have time to try it out: remember Andrew Davie's idea for a learning game The Ooze? It might be possible to make a rough prototype of that in Batari BASIC 0.1....

[Gregory DG]

Cooooooool! Maybe I can actually write a 2600 game now!

[gambler172]

I'm probably going to get a mix of praise and criticism for this.  Anyway, I've written a BASIC compiler for the Atari 2600.  Yes, you read that right.  This is not a joke!

 

Of course there is no "print" statement, string operations or arrays... But I've managed to abstract some of the harder things to simple BASIC keywords and functions.

 

Also, it doesn't generate binaries directly, instead it converts them to an assembly file in DASM syntax, then invokes DASM to make a binary.  It comes with a canned kernel with two players, two missiles, and asymmetric playfield and a 6-digit score, but it is possible for a somewhat-experienced programmer to make it work with almost any kernel.

 

It is my hope that folks will use this BASIC as a stepping stone to serious 2600/6502 programming, much like some of us did in the past on our C-64's, Apples or Atari 8-bits.  Since it generates meaningful assemblies instead of binaries, I think this is likely, or at least I remain hopeful.

 

The included kernel uses a bitmapped 32x12 playfield and has easy to use scrolling routines too, which could be used to make a car racing game or something of that sort.  Calling the display kernel is not automatic - you must use the drawscreen function.

 

[technical stuff]

Also, the compiler generates pretty efficient code, or at least I think so.  As long as you're not using too many of the playfield scrolling routines, I think (I hope) it's unlikely that you will exceed the time alloted for overscan/vblank.  The compiler also inserts conditional compilation flags to prevent player graphics from wrapping page boundaries and can also be configured to automatically use branches instead of jumps where the target is near.

 

Also, I haven't abstracted out all 2600 intricacies - you still have direct access to any TIA register and can include inline assembly.  In fact you must use TIA regs for some things, like colors and sound, but you access them just like any other variable.

[/technical stuff]

 

To learn more, read the README file or ask me questions, or tell me I'm crazy or something since I have been critical about this very thing in the past...

 

Please try it out and tell me what you all think!

887465[/snapback]

 

 

Hi

how can i load the basic compiler under windows xp?

i always get an error message,also,when i try to load with Dos box.

greetings Gambler172

[jason novak]

code.txtThis looks really cool. I see in the readme you note it's really picky about extra spaces. I don't know C but I've attached some quick and dirty code I'd use to clean it up in VB

[Cybergoth]

Hi there!

 

Here's to hoping your idea will expand to the 8-bit/5200 and 7800 too!

 

Umm, doesn't the 8-bit already have a pretty good BASIC?

 

5200 BASIC is also available for a couple of years already.

 

Greetings,

Manuel

[potatohead]

Nice starter page. (And I see you played my first 2600 game!)

 

The ooze game is totally doable. All the elements needed are in the rough game I wrote.

 

I'm thinking about custom kernels right now. The idea has some merit. One of the more difficult things about the 2600 is all the timing constraints. That is what keeps batari basic (I like the name) from becoming too general in scope. If It were me, I would hammer out a few different display kernels, then provide a command:

 

05 usekernel x

 

where x would represent one of a few different kernels. That way, the general commands would all remain the same, but how they are used would depend on the kernel at hand. More games could be written this way, while keeping compile time issues at a sane level. If this is not clear, consider the old 8bitter graphics modes. The hybrid ones, where some text was made available at the bottom of the screen used a different 'kernel' (display list) than those that didn't.

 

Looking at the one kernel we have working, variatiions could include, score at top, bottom, no score, etc... the programmer gets more creative freedom for a lot less compiler development.

 

Another thought along those lines would be the ability to include dasm compatable in-line assembly too. Since all the labels are standardized, little bits of code, to change colors mid-screen perhaps, would be possible too. The idea being to keep any given kernel fairly rigid, but as useful as it can be. Of course, this goes beyond basic...

 

I will probably knock out a quick command reference later today. If it's good, by all means post it on the page --if not it lives here

 

One biggie, newbies will want to know is the program structure and necessary flow:

 

There are four parts:

 

Init

 

Stuff to be done every frame

 

Stuff to be done after the frame has drawn, but before the next one starts

 

subroutines (Fred, these work fine, BTW --it was me)

 

eg:

 

05 rem init to happen once on start or reset (goto 5)

10 x = 0 : y = 5 : COLBK = 30

20 pfhline 2 3 20

 

 

30 rem display loop (Happens every frame)

40 player0x = x : player0y = y : l = l - 1

45 player0:

%01000010

%11111111

%11111111

%00000000

end

46 player1:

%00011000

%00111100

%01111110

%00111100

%00011000

end

90 drawscreen

91 rem This ends the display section and a frame has been drawn ?

92 rem entering VBI period where you have a fair number of cycles to do game logic

 

 

170 rem game logic, move player positions, check collisions, etc...

180 if joy0left then x = x - 1

190 if joy0right then x = x + 1

200 if something then goto 400

210 do something else

230 goto 30

231 rem without this and line 420, your game does nothing but display 1 frame and crash.

 

400 rem subroutine

410 COLBK = 5

420 goto 230

 

This overall structure made sense to me as I've been lurking around here forever, lacking the time to really knock out some assembly. I'm not sure it will make sense to fresh people wanting to give this a go.

[kisrael]

Hi

how can i load the basic compiler under windows xp?

i always get an error message,also,when i try to load with Dos box.

Gamble, two suggestiosn:

1. don't quote great big messages just to put a few lines at the end

2. It works fine for me under XP... you need to tell us what error message you're getting or we're going to have NO IDEA what to suggest.

[kisrael]

Here's to hoping your idea will expand to the 8-bit/5200 and 7800 too!

 

Umm, doesn't the 8-bit already have a pretty good BASIC?

 

5200 BASIC is also available for a couple of years already.

Oh, hmm, maybe worth checking out.

 

Actually I was being a little flippant...I've been realizing that Batari BASIC is really a crosscompiler. Though I remember the Atari 8bits had some neat sounding languages (like "Action", is that one?) that promised great performance and also ease of use.

 

Anyway, thinking ahead to future things for 8bits , maybe a crosscompiler, is WAY WAY WAAAAAAAY too far ahead.

 

 

And potatohead, glad to see your interest in helping out!

[potatohead]

Umm, doesn't the 8-bit already have a pretty good BASIC?

 

 

The 8 bit basic is worth a look. As a kid, I got it to do a lot of things. With little bits of assembly mixed in here and there (DLI, blitter code, vertical player missle movement, sound, etc...) fair games are possible.

 

The archive site, which I can't seem to remember right now, has the books online.

[potatohead]

Oh, I almost forgot my one other suggestion.

 

It would be great for the compiler to output how much of the code space has been used. That way a person can get an idea of what remains possible without having to just code and hope!

[Mindfield]

Wow, this is great! I can see just from the posts here that there is still much to do on it, but the fact that there is any type of BASIC-style language at all is impressive to say the least. At the very least it's an excellent teaching tool to learn both assembler language and general structure of 2600 programming. Very nice! A fleshier usage guide is definitely needed, of course, but being that the project has just begun you can't expect everything at once. :-)

 

I've been meaning to start into 2600 programming -- it's been years since I touched 6502 assembler so I'd definitely need a refresher -- this may give me the push I need to really get the ball rolling!

[Dan Iacovelli]

this reminds me of Ti-Extended basic. Imostly grew up working on ti-basic and Extened basic(the difference between the two is extened basic has sprites as well as speech and can do some asm language (peeks and pokes..) and Ti-basic doesn't have that))

(I'm trying to get Laserman done using the batari basic language)

[danwinslow]

One thing to do about the spaces is to collapse them down to one right after you read in the line. If you have string literals then you have to exclude them from this. The way I usually do it is to transfer the string character by character to a second buffer, inc'ing the destination pointer only on a non whitespace char or the first whitespace char of a group.