Atari 2600 BASIC compiler is here!

[yuppicide]

BUG REPORT (in the Breakout Clone): The second row of bricks never disappear. You hit them and it shows a brick on the first row disappearing, but it's already gone. It blinks on and off real quick.

 

Anyway, good job. In the future maybe we can have a contest open to NEW homebrew makers to see whast games they can come up. People will be free to ask questions here, but most of the work must be done by a n00b programmer. Maybe we could even do some sort of prize.

 

Now I have a question.. in the breakout clone, what lines of code were used to make the outer border?!

[Cybergoth]

Hi there!

 

Hm... just added three new lines to the sample code, but the third (PF0 = 4) will break it:

 

1 rem smartbranching on
2 pfvline 0 0 11 on
3 pfvline 31 0 11 on
4 rem PF0 = 4
10 x = 50 : y = 50 : w = 40 : v = 40
20 COLUPF = 90
30 COLUP0 = 120 : player0x = x : player0y = y
40 scorecolor = 10
45 player0:
%01000010
%11111111
%11111111
%01111110
%00111100
%00011000
%00011000
%00011000
end
46 player1:
%00111100
%00011000
%00011000
%00011000
%11100111
%10100101
%10011001
%00100100
end
47 a = a + 1 : if a < 3 then 59
49 a = 0
50 if v < y then v = v + 1
51 if v > y then v = v - 1
52 if w < x then w = w + 1
53 if w > x then w = w - 1
54 player1x = w : player1y = v
59 drawscreen
60 if joy0up then y = y - 1
80 if joy0down then y = y + 1
100 if joy0left then x = x - 1
120 if joy0right then x = x + 1
140 goto 30

 

Greetings,

Manuel

[potatohead]

Ok, we have a rough users guide done now. I've attached it in rtf format for anyone wanting to learn what I did last night. It needs work, but I'm hoping others will add to this text and build it from here.

 

I'm an Open Source kind of guy, so share and share alike, but please do keep credits, license terms and other such bits intact so we have this document in the future for everyone to use.

 

Thanks.

 

Update: I've made a number of corrections to the users guide. Re-download if you already have a copy.

 

batari_users_guide.rtf

Edited July 10, 2005 by potatohead

[potatohead]

BUG REPORT (in the Breakout Clone): The second row of bricks never disappear. You hit them and it shows a brick on the first row disappearing, but it's already gone. It blinks on and off real quick.

 

Anyway, good job. In the future maybe we can have a contest open to NEW homebrew makers to see whast games they can come up. People will be free to ask questions here, but most of the work must be done by a n00b programmer. Maybe we could even do some sort of prize.

 

Now I have a question.. in the breakout clone, what lines of code were used to make the outer border?!

888968[/snapback]

 

Yep, it's there all right. I didn't add the math to handle the second set of bricks. It was late

 

Anyway, the borders are interesting. I didn't realize, at first, that they actually exist in ram. That's what makes one able to turn off the bricks! The lines that draw them are:

 

65 pfvline 0 0 11 on
66 pfhline 0 0 31 on
67 pfvline 31 0 11 on
68 pfhline 0 11 31 on

 

They set the appropriate bits in the 40 byte playfield memory to be drawn by the kernel when the drawscreen command happens.

 

Each element of the playfield can be toggled on and off with more line statements or the pixel statement during the game logic part of the program.

 

You can see that in the brick code below. (Yeah, the one with one of many bugs in it!)

 

112 pfpixel j 3 off : l = 1

 

I didn't do the math yet to determine which row of bricks was being hit. The '3' basically locks the changes to the first row.

 

To fix it, one needs to convert the ball shaped player y position, or compare it to a range of values, in order to get the brick vertical position.

 

I'll leave this as an exercise for those wanting something to do with this compiler!

 

I'll probably come back and do this again, or maybe do the ooze game later.

Edited July 9, 2005 by potatohead

[yuppicide]

I thought those were what you used for the playfield. Nice documentation. There's one error on my screen.. where you did the subtraction there's some funky character there's no - minus sign.

 

Would be great to see a feature in the future where you can move the score from the bottom to the top if you want and also limit it's digits.

[Clint Thompson]

Wow... that is very cool!

 

Who knows... since I roughly know some BASIC maybe I"ll sit down and screw around with it someday here soon! Looks like I might be buying me some 2600 PCBs and madness... and hopefully this BASiC can be built onto bigger and better as time moves along...

[potatohead]

I thought those were what you used for the playfield. Nice documentation. There's one error on my screen.. where you did the subtraction there's some funky character there's no - minus sign.

 

Would be great to see a feature in the future where you can move the score from the bottom to the top if you want and also limit it's digits.

889080[/snapback]

 

 

Well, you are supposed to use them for the playfield --but you can use them for anything else you want to. Basically the 2600 does not bring much to the table graphics wise. It's best to use whatever you can to get the desired effect. There are few hard rules in this regard.

 

If you think about it, I used a player for the ball too. (Because the ball is not yet part of the kernel)

 

Bummer about the subtract char. That happens in OO.org sometimes. It's something I'm doing becuase I know many folks that do not bump into that. Thanks for your kind words on the docs. It's a first pass, much more will be needed yet. At some point we should put together a FAQ to go along with that document.

 

Anyone notice any errors yet? I've got plenty of omissions for sure, but I'm looking for errors, waiting for this to evolve a bit before really getting too detailed.

 

Anyone do anything else with this yet?

 

Update: I've made a number of corrections and additions to the users guide text. I'll leave it alone for a while until it makes sense to make major changes. Re-download if you already have a copy.

Edited July 10, 2005 by potatohead

[+batari]

Hi there!

 

Hm... just added three new lines to the sample code, but the third (PF0 = 4) will break it:

888972[/snapback]

What happened? I tried removing the rem, and it compiled fine and ran, but the PF0 = 4 had no effect.

[+batari]

Ok, we have a rough users guide done now.  I've attached it in rtf format for anyone wanting to learn what I did last night.  It needs work, but I'm hoping others will add to this text and build it from here.

 

I'm an Open Source kind of guy, so share and share alike, but please do keep credits, license terms and other such bits intact so we have this document in the future for everyone to use.

 

Thanks.

 

Update:  I've made a number of corrections to the users guide.  Re-download if you already have a copy.

 

batari_users_guide.rtf

889005[/snapback]

Thanks! It's cool that so many seem to like the project and several people are offering to help. I'll look at the document tonight.

[+batari]

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)

888931[/snapback]

I was actually thinking of TI-BASIC when I initially came up with this, given that it's so limited I thought of a way to compile something like it without too much trouble. As I worked on it more, I thought of ways to exceed the capabilities of TI BASIC, at least in its handling of "if-then" statements, so it's probably not a coincidence that you saw similarities...

[+batari]

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

Could you send me the source + generated asm that caused this error? Thanks.

 

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.

888889[/snapback]

Yeah, I wrote the README file in about a half hour - I was keeping this project to myself for so long since I don't like to announce things unless I'm sure I can do them unlike some people... So once it was working good enough to unleash on the world, I was too anxious to release it to write documentation that made any sense...

[yuppicide]

I haven't spoken to my Father in about 8 or 10 years now (or that side of the family). My Father is a great person, we just weren't super close since my parents were divorced before I was a year old. I used to see him on weekends and one day when I got older I didn't want to go over his place. I wanted to go out with friends. Anyway, one weekend grew into two, two grew into four, before you know it I hadn't seen my Father in a long time! I want to contact him and say hi. I've always though if I could get an Atari 2600 game built I'd put a "This is dedicated to" on the front screen and send one to my Father. We had the Atari when it first came out and I loved it.

 

Anyway, enough sap. I have been waiting for something like this for YEARS. I hope it'll keep getting expanded upon. I'd love to see a lot more sample tutorials and sample code made up to study. I've had ideas for games and nobody here really had any interest in working them out and this is a good start for me to actually making them a reality.

 

With some help you could help me realize my childhood dream and find the strength to just go say hi to my Dad. Aww.

 

PS - Maybe you can put up a PayPal donate button. I know I'd contribute a few dollars as soon as I get back to work.

Edited July 10, 2005 by yuppicide

[yuppicide]

What's the easiest say to print a screen of text?!

 

Like say I want to say "THANK YOU" for example?!

[+batari]

What's the easiest say to print a screen of text?!

 

Like say I want to say "THANK YOU" for example?!

889160[/snapback]

Right now the only way is with the big playfield blocks, without using inline asm, that is. In the future there may be a way to make actual title screens without too much trouble, either by using smaller playfield blocks or the 48x192 bitmapped sprite kernel that I talked about eariler.

[potatohead]

 

Update: I've made a number of corrections to the users guide. Re-download if you already have a copy.

 

batari_users_guide.rtf

889005[/snapback]

Thanks! It's cool that so many seem to like the project and several people are offering to help. I'll look at the document tonight.

889144[/snapback]

 

Feel free to hack/correct/add/delete. It's really a seed document, intended to get the ball rolling for those who need a little info to get started. I'm afraid it does not cover all your program will do, but I tend to stick with the golden rule:

 

write what you know and leave out what you don't.

[gambler172]

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.

888905[/snapback]

 

Hi Kirk

i get an error in german language.Translated in english it means,that 2600.exe

is not a good file to open DOS or WINDOWS programs.Maybe a problem with

AUTOEXEC.NT (whatever that means)

If i try to load it in the Dos Box,i get this message

No DPMI get csdpmi*.zip

 

Maybe,you can help

greetings Gambler172

[Cybergoth]

Hi there!

 

Hi there!

 

Hm... just added three new lines to the sample code, but the third (PF0 = 4) will break it:

888972[/snapback]

What happened? I tried removing the rem, and it compiled fine and ran, but the PF0 = 4 had no effect.

889142[/snapback]

 

It's totally weird, I don't get it at all...

 

The error I get is

--- Unresolved Symbol List
player46_1               0000 ????         (R )
NO_ILLEGAL_OPCODES       0000 ????         (R )
--- 2 Unresolved Symbols

Unrecoverable error(s) in pass, aborting assembly!
Complete.

 

Further analizing this reveals, that while the code is in both cases 100% identical:

...
   LDA #<player46_1

   STA player1pointer
   LDA #>player46_1

   STA player1pointer+1
   JMP .46jump1
if (<*) > (<(*+8))
   repeat ($100-<*)
   nop
   repend
   endif
player46_1

   .byte 0
   .byte  %00111100
   .byte  %00011000
   .byte  %00011000
...

 

It'll one time assemble this:

 

752  f3ea         a9 f5        LDA	#<player46_1
   753  f3ec
   754  f3ec         85 8c        STA	player1pointer
   755  f3ee         a9 f3        LDA	#>player46_1
   756  f3f0
   757  f3f0         85 8d        STA	player1pointer+1
   758  f3f2         4c fe f3        JMP	.46jump1
   759  f3f5      -       if	(<*) > (<(*+8))
   760  f3f5      -       repeat	($100-<*)
   761  f3f5      -       nop
   762  f3f5      -       repend
   763  f3f5           endif
   764  f3f5       player46_1
   765  f3f5
   766  f3f5         00        .byte.b	0
   767  f3f6         3c        .byte.b	%00111100
   768  f3f7         18        .byte.b	%00011000
   769  f3f8         18        .byte.b	%00011000

 

and the other time this:

 

   755  f3ee         a9 00        LDA	#<player46_1
   756  f3f0
   757  f3f0         85 8c        STA	player1pointer
   758  f3f2         a9 00        LDA	#>player46_1
   759  f3f4
   760  f3f4         85 8d        STA	player1pointer+1
   761  f3f6         4c 02 f4        JMP	.46jump1
   762  f3f9           if	(<*) > (<(*+8))
   763  f3f9           repeat	($100-<*)
   764  f3f9         ea        nop
   763  f3f9           repend
   764  f3fa
   765  f3fa         3c        .byte.b	%00111100
   766  f3fb         18        .byte.b	%00011000
   767  f3fc         18        .byte.b	%00011000

 

As if DASM just hickups the "endif" and the label away...

Never seen something like this before...

 

Greetings,

Manuel

[+batari]

Further analizing this reveals, that while the code is in both cases 100% identical:

 

I think I found the problem. apparently my files were created on both UN*X and DOS systems, and UN*X uses just LF and DOS uses CR+LF in text files and different types of files were concatenated together, which seems to be confusing DASM. It seems like it shouldn't matter, but apparently it does.

 

So I simply converted two asm files to CR+LF and it solved the problem, for now. In the next release, I'll have to work around this somehow. So if you're having the same problem, replace the two asm files with the ones I posted here.

fixed_asm_files.ZIP

[Cybergoth]

Hi there!

 

Thanks, that did the trick!

 

Greetings,

Manuel

[attendo]

im working on something special for 2600Basic, hope to finish it this evening..

[yuppicide]

I love you.

 

im working on something special for 2600Basic, hope to finish it this evening..

889245[/snapback]

[potatohead]

Hey, here is a nice ship, with a bullet and nothing to shoot. Might make for the beginnings of the ooze game...

 

1 rem smartbranching on
2 rem init code set intial values here
10 x = 50 : y = 89 : w = 60 : v = 60 : b = 0
12 AUDC0 = 13
20 pfhline 0 0 31 on
22 pfvline 0 0 10 on
23 pfvline 31 0 10 on
49 rem
50 rem begin display loop
51 rem
60 COLUPF = 90 : COLUP0 = 120 : scorecolor = 15 : COLUP1 = 47
70 player1x = w : player1y = v : player0x = x : player0y = y
80 player0:
%01000010
%11100111
%11111111
%01111110
%00111100
%00011000
%00011000
%00011000
end
85 player1:
%00011000
%00010000
%00001000
%00010000
%00001000
end
99 rem
100 rem display loop
101 rem
200 drawscreen
250 if joy0left then x = x - 1
255 if joy0right then x = x + 1
260 if x < 35 then x = 35
264 if x > 147 then x = 147
270 if INPT4 < 15 then b = 1
280 if b = 0 then w = x : v = y - 8
300 if b = 1 then 700
500 goto 50
599 rem
600 rem subroutines live below here
610 rem
700 if v > 5 then v = v - 4 : AUDV0 = 10
705 AUDF0 = v / 2
710 if v < 5 then b = 0 : AUDV0 = 0
720 goto 500

shooter.zip

[yuppicide]

OH NO! Someone might actually try to make Knight Rider if those people see this thread. Look out!

[+Random Terrain]

I don't want to try this yet until it has settled down a bit, but it sounds like it's going to be cool. Will this eventually be merged into an existing emulator so that you can instantly try out ideas (like you could with Blitz Basic) or will you have to compile it, then run it using an emulator? Blitz Basic instantly compiled your programs to ultra fast, 100% machine code before running each time, so you could have instant feedback. It would be cool if you could do something similar with this by integrating an emulator.

[+batari]

I don't want to try this yet until it has settled down a bit, but it sounds like it's going to be cool. Will this eventually be merged into an existing emulator so that you can instantly try out ideas (like you could with Blitz Basic) or will you have to compile it, then run it using an emulator? Blitz Basic instantly compiled your programs to ultra fast, 100% machine code before running each time, so you could have instant feedback. It would be cool if you could do something similar with this by integrating an emulator.

889404[/snapback]

Attendo is one step ahead of you... Yes, it's been done!