Atari 2600 BASIC compiler is here!

[+batari]

Personally, guys, I'd suggest not rushing for too much publicity yet. Let this thing mature a while, it's still so young and raw...

892364[/snapback]

Maybe you're right - it might me good to at least wait until this is good enough to call it beta instead of alpha.

[bliprob]

Personally, guys, I'd suggest not rushing for too much publicity yet. Let this thing mature a while, it's still so young and raw...

892364[/snapback]

Maybe you're right - it might me good to at least wait until this is good enough to call it beta instead of alpha.

892419[/snapback]

 

Slashdot wasn't enough publicity?

 

But yeah, probably would want to wait for the multiple kernels option... or a mad rush of new users will ask over and over about two scores.

[Dan Iacovelli]

I think the playfield commands are clear enough for instance: if you do pfhline 1 10 30 you will get a line on the bottom starting in the 1st column 10th row and 30 copies.

a more simple comparison is if you compre it to TI basic Playfield commands:

Call hchar ( row,column , char, rep) just have to reverse the row and column and

drop the char since batari basic doesn't use it.

[vdub_bobby]

That's a good idea.  Though the format is a little deceiving since some of the playfield bytes have their bits reversed, and I'd probably want to make it a logical bit-to-pixel mapping instead.  So there's no reason why I'd have to use %010010... I could use something else that's easier to visualize.  What do you think?

Well, I think that in BASIC you'd want to hide the weirdness of the bit order of the PF bytes from the programmer. On the other hand, maybe not.

 

But even assigning each 1/4 of the PF separately would still be easier than plotting points and drawing lines. Like this:

95 rem playfieldleft is normal
100 playfieldleft:
%11111110
%10000000
%10000000
%10000000
%10000000
%10000000
%10000000
%10000000
%10000000
%10000000
%11111110
105 rem playfieldleftcenter is reversed
110 playfieldleftcenter:
%11111110
%00000000
%00000000
%00000000
%00000000
%00000000
%00000000
%00000000
%00000000
%00000000
%11111110
115 rem playfieldrightcenter is normal
120 playfieldrightcenter:
%11111110
%00000000
%00000000
%00000000
%00000000
%00000000
%00000000
%00000000
%00000000
%00000000
%11111110
125 rem playfieldright is reversed
130 playfieldright:
%11111110
%10000000
%10000000
%10000000
%10000000
%10000000
%10000000
%10000000
%10000000
%10000000
%11111110

To create this screen:

100 playfield:
%111111100111111001111111
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%111111100111111001111111

[+batari]

That's a good idea.  Though the format is a little deceiving since some of the playfield bytes have their bits reversed, and I'd probably want to make it a logical bit-to-pixel mapping instead.  So there's no reason why I'd have to use %010010... I could use something else that's easier to visualize.  What do you think?

Well, I think that in BASIC you'd want to hide the weirdness of the bit order of the PF bytes from the programmer. On the other hand, maybe not.

892450[/snapback]

I definitely want to hide that weirdness - it's not complicated to understand, it's just annoying. I'll include a mention of the weirdness in the docs, definitely, so those moving on to assembly aren't surprised when things work a little differently.

 

I guess what I meant is that I could use something other than % and 0 and 1, like this:

XXXXXXXXXXXXXXX..XXXXXXXXXXXXXXX
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
X..............................X
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

[danwinslow]

Batari, the parsing issues are going to drive you insane. I am speaking from personal experience. My advice is to set up a real parser now before you get too much kluged in there. It just gets worse as you go along. You need expression trees, BNF, etc. Yah, lex and yacc are good. Cryptic but they work.

 

Actually, you should be able to find pre-made basic parsers out on the net that you could mod. I will see if I can't find a couple and post them.

Edited July 15, 2005 by danwinslow

[+batari]

Batari, the parsing issues are going to drive you insane. I am speaking from personal experience. My advice is to set up a real parser now before you get too much kluged in there. It just gets worse as you go along. You need expression trees, BNF, etc. Yah, lex and yacc are good. Cryptic but they work.

892472[/snapback]

This is the plan - but for now I patched up the parsing by preprocessing the input, and the compiler is now much more forgiving about spacing/whitespace or lack thereof.

 

I will definitely need something much better for parsing more complex statements - in this case I agree that this will begin to get away from me before long if I don't bite the bullet soon and learn how to use lex/yacc.

[kisrael]

I think a cool feature would be the ability to write to the entire playfield like you write to the players, like this:

100 playfield:
%111111111111111111111111
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%111111111111111111111111

This would make the creation of an adventure game (in the vein of Superman, ROTLA, or Adventure) with multiple screens much easier.

892361[/snapback]

That's a good idea. Though the format is a little deceiving since some of the playfield bytes have their bits reversed, and I'd probably want to make it a logical bit-to-pixel mapping instead. So there's no reason why I'd have to use %010010... I could use something else that's easier to visualize. What do you think?

892417[/snapback]

Very good thought -- don't make things look alike that aren't.

_ and X or something for characters?

 

Also, will this be at the same low resolution as the hline/vline type graphics, or can it be higher?

[+batari]

I think a cool feature would be the ability to write to the entire playfield like you write to the players, like this:

100 playfield:
%111111111111111111111111
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%100000000000000000000001
%111111111111111111111111

This would make the creation of an adventure game (in the vein of Superman, ROTLA, or Adventure) with multiple screens much easier.

892361[/snapback]

That's a good idea. Though the format is a little deceiving since some of the playfield bytes have their bits reversed, and I'd probably want to make it a logical bit-to-pixel mapping instead. So there's no reason why I'd have to use %010010... I could use something else that's easier to visualize. What do you think?

892417[/snapback]

Very good thought -- don't make things look alike that aren't.

_ and X or something for characters?

 

Also, will this be at the same low resolution as the hline/vline type graphics, or can it be higher?

892480[/snapback]

Since it's in ROM, it could be higher resolution, but using a higher resolution would also preclude using the pf plotting routines on the same screen.

 

Therefore you would have three choices - one, to use the existing kernel, but have the playfield command copy the data to RAM when it is called.

 

Second, do not use the playfield RAM at all. Playfields would be static, but they could be higher resolution.

 

Third, selectively compile in two slightly different kernels, one for PF in RAM and one for PF in ROM. This would eat up space in the ROM (around 256 bytes to be exact) so it wouldn't be automatic. You can't use the same kernel because there's not enough cycles for indirect indexing, nor is there enough free bytes to store the pointers!

 

I'll think about this some more so I can figure out the best solution. At any rate, If I want to include this sort of flexibility, I will wait until Alpha 0.3 or so to get it in.

[bliprob]

I will definitely need something much better for parsing more complex statements - in this case I agree that this will begin to get away from me before long if I don't bite the bullet soon and learn how to use lex/yacc.

892477[/snapback]

 

Take a look at this basic interpreter file. It's been floating around the net for a while (I first compiled in 1993 or so). It's very compatible in some respects (26 vars, etc.) but has loops and a complete expression parser for math. And, it's short enough and simple enough to understand in an hour, something lexx and yacc will never be.

 

I'm happy to help if I can.

BAS_INT.txt

[kisrael]

Third, selectively compile in two slightly different kernels, one for PF in RAM and one for PF in ROM.  This would eat up space in the ROM (around 256 bytes to be exact) so it wouldn't be automatic.  You can't use the same kernel because there's not enough cycles for indirect indexing, nor is there enough free bytes to store the pointers!

 

I'll think about this some more so I can figure out the best solution.  At any rate, If I want to include this sort of flexibility, I will wait until Alpha 0.3 or so to get it in.

892486[/snapback]

 

Well, especially as you add in support for different kernals for title screens and game play and what not, you should strongly consider (and it shouldn't be too hard) dymanic inclusion/exclusion of commands. If a subroutine isn't used, it'd be nice if it wasn't in the ASM at all...I mean I know right now you have a big chunk before and after and then just have dynamic logic in between, but I think doing "includes" for various chunks is going to become a neccesity.

[+batari]

Third, selectively compile in two slightly different kernels, one for PF in RAM and one for PF in ROM.  This would eat up space in the ROM (around 256 bytes to be exact) so it wouldn't be automatic.  You can't use the same kernel because there's not enough cycles for indirect indexing, nor is there enough free bytes to store the pointers!

 

I'll think about this some more so I can figure out the best solution.  At any rate, If I want to include this sort of flexibility, I will wait until Alpha 0.3 or so to get it in.

892486[/snapback]

 

Well, especially as you add in support for different kernals for title screens and game play and what not, you should strongly consider (and it shouldn't be too hard) dymanic inclusion/exclusion of commands. If a subroutine isn't used, it'd be nice if it wasn't in the ASM at all...I mean I know right now you have a big chunk before and after and then just have dynamic logic in between, but I think doing "includes" for various chunks is going to become a neccesity.

892601[/snapback]

I think what I am going to do is have a header file auto-generated that defines compiler flags to tell what will go in and what won't. Alpha 0.2 already auto-generates a header file for variable aliasing, so including such flags in the header would be trivial at this point.

 

Oh, and stay tuned for Alpha 0.2 so you can put it on the web page - I'll post it shortly.

[potatohead]

Very good thought -- don't make things look alike that aren't.

_ and X or something for characters?

 

I'm liking all the ideas so far. As for the characters that define the playfield, you could let the user choose... with any two chars they wanted as args.

 

100 playfield - 0

%-----------------0-------------

 

...etc.

 

Looking forward to 0.2.

 

Re: playfield....

 

I really like the idea of the ram playfield. Makes some things really easy. Of course it does not look that great, but with the language having only the two sprites, it's the difference between being able to actually do something and not.

 

As this develops, choices are good. My only comment in this regard would be trying to avoid locking the user into a particular one. eg:

 

static playfield for title screen, dynamic one for game level screen that changes, static one for bonus level that doesn't...

[+batari]

Ok... here it is. Just built it minutes ago - I hope it's all there.

 

Some changes are:

 

vastly improved parser - not nearly as sensitive to spacing

score calculation improved.

slight kernel improvements

alphanumeric labels allowed, and labels/linenumbers are now optional.

blank lines allowed

indexing (array-like feature) implemented

data statement implemented

fixed bug in inline asm where it was impossible to add labels

one boolean now allowed in an if-then (&&,||)

ability to access individual bits

fixed bug where return command wasn't recognized

for-next loops added

dim statement for alternate variable names

Upon compilation, DASM shows bytes free in ROM

removed exotic illegal opcodes that would cause problems in some emulators, like PCAE

Included files are now in cr/lf format to patch a limitation of DASM

fixed various bugs in pfpixel and pfhline routines

on....goto added

Fixed problem where duplicate labels were created

FAQ and Command reference started.

other things I can't remember.

 

I think this should work quite a bit better. But let me know immedately if you find any fatal bugs that cause it to not work at all.

 

EDIT: Quick fixes on both - the cause of the "bus error" should now be gone, and data statements should work. if you downloaded them before, please do so again.

batari_basic_alpha2.zip

Batari_basic_alpha2_source.zip

Edited July 17, 2005 by batari

[Dan Iacovelli]

Ok... here it is.  Just built it minutes ago - I hope it's all there.

 

Some changes are:

 

vastly improved parser - not nearly as sensitive to spacing

score calculation improved.

slight kernel improvements

alphanumeric labels allowed, and labels/linenumbers are now optional.

blank lines allowed

indexing (array-like feature) implemented

data statement implemented

fixed bug in inline asm where it was impossible to add labels

one boolean now allowed in an if-then (&&,||)

ability to access individual bits

fixed bug where return command wasn't recognized

for-next loops added

dim statement for alternate variable names

Upon compilation, DASM shows bytes free in ROM

removed exotic illegal opcodes that would cause problems in some emulators, like PCAE

Included files are now in cr/lf format to patch a limitation of DASM

fixed various bugs in pfpixel and pfhline routines

on....goto added

Fixed problem where duplicate labels were created

FAQ and Command reference started.

other things I can't remember.

 

I think this should work quite a bit better.  But let me know immedately if you find any fatal bugs that cause it to not work at all.

892626[/snapback]

sounds good batari,

I'll d/l it tomarrow will be at my show all day from 9am to 6pm today

Edited July 16, 2005 by Dan Iacovelli

[attendo]

Actually isn't it supposed to work with z26, or not? I pointed it it to z26, but I always get "file not found...untitled.bin"

 

also, sometimes programs like this open up the last edited program, that's often useful

 

and you really shouldn't have a "clear clipboard" option...no other program does it so it's a little confusion, and who cares about a bit of text stuck in the clipboard anyway?

890870[/snapback]

 

The 2600IDE for 2600Basic is now updated check here for v0.3 It works best with the latest version of Batari's Basic.

 

Removed the clear option, added last file opened and did some other changes.

Tried it again with Z26 but it worked fine here, did the compile and run, etc. Im using V2.13

[bliprob]

Fred -- I'm having trouble with .2 without line numbers.

 

The first line of my program is:

 

rem smartbranching on

 

...and it throws a compilation error:

 

Error: cannot parse line rem

 

Then I got the same thing here:

 

 player0x = 50

Error: cannot parse line player0x

 

So I added a space in front of every line that didn't have a label or line number. Is that right?

 

I'm still getting compilation errors. Do you have some sample code for the new features?

[potatohead]

Got a build problem on Linux:

 

[dougd@feona src]$ make all

cc -O2 -o 2600bas 2600bas.c statements.c keywords.c

/home/doug/tmp/ccZvsD80.o(.text+0x1903): In function `doif':

: undefined reference to `pow'

/home/doug/tmp/ccZvsD80.o(.text+0x2052): In function `let':

: undefined reference to `pow'

/home/doug/tmp/ccZvsD80.o(.text+0x2693): In function `let':

: undefined reference to `pow'

collect2: ld returned 1 exit status

make: *** [2600bas] Error 1

 

I had time to just tweak a little this morning. Removing the (int) let the build continue, but then got this:

 

[dougd@feona src]$ make all

cc -O2 -o 2600bas 2600bas.c statements.c keywords.c

statements.c: In function `let':

statements.c:775: error: invalid operands to binary ^

make: *** [2600bas] Error 1

 

Assuming the above means a type mismatch which is what the (int) was supposed to take care of ?!?!

 

Does this suggest we need a built in pow function that will output an int value? (Will this vary too much per platform?)

 

I'm happy to chip away at getting this to build this afternoon. If I have not provided enough info, and I'll post more, make you an ssh account...

 

(or whack me with the clue stick, and I make the edits and send the changes!!)

Edited July 16, 2005 by potatohead

[bliprob]

I've got another problem here. Firstlt -- my compliation error above was caused whitespace AFTER a keyword (i.e. "return " and "x = rand "). That was hugely frustrating to figure out. Watch out for extra whitespace!

 

New problem is with arrays. Attempting to access a[x] and so on. Output from DASM:

 

/Users/rob/desktop/rand-2.bas.asm (888): error: Syntax Error 'a'.

/Users/rob/desktop/rand-2.bas.asm (889): error: Syntax Error 'a[x]'.

/Users/rob/desktop/rand-2.bas.asm (989): error: Syntax Error 'a'.

/Users/rob/desktop/rand-2.bas.asm (990): error: Syntax Error 'a[x]'.

 

I sort of expected to be able to use a variable as an array index -- am I off base here?

[bliprob]

I sort of expected to be able to use a variable as an array index -- am I off base here?

892759[/snapback]

This is what I'm aiming for:

 

for u=0 to z
 x = u + 10
 pfpixel a[u] a[x] off
next

[bliprob]

Am I doing something wrong? In the .asm file, it has compiled into:

 

.L020;   pfpixel a[u] a[x] off

LDX a[u]
LDY a[x]

 

I don't know anything about 2600 programming, but I have some creaky 6502 assembly somewhere in my brain, so I'll take a look at the C file and see.

[+batari]

So I added a space in front of every line that didn't have a label or line number. Is that right?

yes. You must indent lines without linenumbers.

I'm still getting compilation errors. Do you have some sample code for the new features?

892736[/snapback]

There is some in the help.html file.

[+batari]

Got a build problem on Linux:

 

[dougd@feona src]$ make all

cc -O2 -o 2600bas 2600bas.c statements.c keywords.c

/home/doug/tmp/ccZvsD80.o(.text+0x1903): In function `doif':

: undefined reference to `pow'

/home/doug/tmp/ccZvsD80.o(.text+0x2052): In function `let':

: undefined reference to `pow'

/home/doug/tmp/ccZvsD80.o(.text+0x2693): In function `let':

: undefined reference to `pow'

collect2: ld returned 1 exit status

make: *** [2600bas] Error 1

 

892749[/snapback]

See above - fixed source (problem was the makefile) posted above.

Edited July 16, 2005 by batari

[+batari]

Am I doing something wrong? In the .asm file, it has compiled into:

 

.L020;   pfpixel a[u] a[x] off

LDX a[u]
LDY a[x]

 

I don't know anything about 2600 programming, but I have some creaky 6502 assembly somewhere in my brain, so I'll take a look at the C file and see.

892835[/snapback]

You've run into a limitation - you can assign arrays but currently you can't use then in some functions To fix the above, first reassign the arrays to a fixed variable then call pfpixel. I'll add this to the list for Alpha 0.3.

 

that is,

y=a:z=a[x]:pfpixel y z off

[+batari]

I've got another problem here. Firstlt -- my compliation error above was caused whitespace AFTER a keyword (i.e. "return " and "x = rand "). That was hugely frustrating to figure out. Watch out for extra whitespace!

892759[/snapback]

That's annoying - I'll fix this whitespace problem for Alpha 0.3.