Atari 2600 BASIC compiler is here!

[+batari]

Hello all,

 

Alpha 0.2 is nearly done. Should be released tomorrow.

 

Tonight I'm preparing a FAQ and a help file, but I need your help with the help file

 

Please let me know what topics you'd like to see in there, or at least what else should be there. I've thought of several topics but I'm sure there are many I'm forgetting. The list so far is:

 

arrays

indexing

data statement

score keyword

linenumbers

labels

asm statement

inline assembly

kernel

spacing

gosub statement

return statement

for-next statement

next keyword

drawscreen command

rand function

random numbers

bits, accessing

on ... goto statement

whitespace

playfield

pfpixel statement

pfvline statement

pfhline statement

pfscroll command

boolean operators

variables

addition

subtraction

multiplication

bitwise and, or, xor

division

negative numbers

TIA registers

collisions

collision() function

sound

sprites

player graphics

missiles

ball

dim statement

if-then statements

rem statement

loops

timing

let statement

memory

RAM

ROM

limitations

[Dan Iacovelli]

Hello all,

 

Alpha 0.2 is nearly done. Should be released tomorrow.

 

Tonight I'm preparing a FAQ and a help file, but I need your help with the help file

 

Please let me know what topics you'd like to see in there, or at least what else should be there.  I've thought of several topics but I'm sure there are many I'm forgetting.  The list so far is:

 

arrays

indexing 

data statement

score keyword

linenumbers

labels

asm statement   

inline assembly 

kernel

spacing

gosub statement

return statement

for-next statement

next keyword

drawscreen command

rand function 

random numbers

bits, accessing

on ... goto statement

whitespace

playfield

pfpixel statement

pfvline statement

pfhline statement

pfscroll command 

boolean operators

variables

addition

subtraction 

multiplication

bitwise and, or, xor

division

negative numbers

TIA registers

collisions

collision() function

sound 

sprites 

player graphics

missiles

ball

dim statement

if-then statements

rem statement

loops

timing 

let statement

memory

RAM

ROM

limitations

891856[/snapback]

I think that pf commands should be listed in it

It took me some time to figure x y coridants

(try to base it on hchar and Vchar on the TI (ie call hchar row, column)

besides that I can't think of anything else)

[Serguei2]

I can't wait for the next release of 2600 basic.

 

I have problem with playfields. I'd like making this one (see screenshot) using basic but I can't make it to work properly.

 

Another thing. I noted that all variables are decimals but setting colors are difficult because the color chart uses hex not decimal to choose a color. I need a calculator

to convert hex to decimal.

[+batari]

I can't wait for the next release of 2600 basic.

 

I have problem with playfields. I'd like making this one (see screenshot) using basic but I can't make it to work properly.

Due to tight kernel timing, there is only limited access to the left and right tenth of the screen. The best you can do to make something like that is to set the background color to the red you have shown, then PF0 = 128 : pfhline 0 0 31 on : pfhline 0 10 31 on

Another thing. I noted that all variables are decimals but setting colors are difficult because the color chart uses hex not decimal to choose a color. I need a calculator

to convert hex to decimal.

891876[/snapback]

No need to convert - Batari Basic accepts hex numbers by putting a $ before them.

 

Example: COLUPF = $2E

[Serguei2]

PF0 = 128 : pfhline 0 0 31 on : pfhline 0 10 31 on

 

I'll try it.

 

 

No need to convert - Batari Basic accepts hex numbers by putting a $ before them.

 

Great.

 

 

And thanks for the help.

[Serguei2]

I have a problem with COLBK.

 

12 references to unknown symbols.

17 events requiring another assembler pass.

- Expression in mnemonic not resolved.

- Label defined after it has been referenced (forward reference).

 

Unrecoverable error(s) in pass, aborting assembly!

Complete.

 

--- Unresolved Symbol List

COLBK                    0000 ????         (R )

NO_ILLEGAL_OPCODES       0000 ????         (R )

--- 2 Unresolved Symbols

 

Fatal assembly error: Source is not resolvable.

 

 

I found this command in the Batari users guide.

 

20 COLUPF = $2e : COLBK = $90

Edited July 15, 2005 by Serguei2

[supercat]

I have a problem with COLBK.

891946[/snapback]

 

The correct register spelling is COLUBK.

[Serguei2]

I tried it. I got the same error.

[Dan Iacovelli]

you have to watch the spacing in the commands I kept getting null errors on that

so I had just moved it down to next line (Idid double lines commnad : command and some how it gave me errors)

anyways after trial and error I'm proud to show you the first level screen of Laserman.

it's not a perfect trianagle but it close.

next up is the player sprites

[Serguei2]

you have to watch the spacing in the commands I kept getting null errors on that

so I had just moved it down to next line (Idid double lines commnad : command and some how it gave me errors)

 

Thanks. It works this time.

[potatohead]

Good morning all,

 

I had a bit of time to play this morning. The problem with the ooze leaving left over pixels that cannot be destroyed (until the ooze reaches that level of course ) it solved by doing all the math, then drawing the ooze fresh each time. Once things are sorted out, it should all work nicely. Handling the ooze at the time of collision or growth just allows for too many timing issues and requires too much logic to sort out. (Maybe it's me.)

 

Because we are in the alpha stage, I cannot easily clear the playfield without assembly code. Can't branch yet because the labels are yet to be fixed. (I know all that is coming, I just wanted to explain this next bit of code.)

 

I decided to just brute force fill the playfield bytes with zeros. The length of this routine exceeds the 6502 branch capability however and causes a problem for the compiler in that this length condition isn't handled properly. I'm attaching this batari as an extreme example that probably should be addressed at some point. I'm not sure this case is going to come up very often, once we can do loops and set reset pixels properly.

 

branch_bug.zip

 

...back to work.

 

Batari: --sorry no work on docs. The dental trip just hosed me schedule. I'll have some time this afternoon / weekend however. Shoot me an example and a list of what you can use help with and I'll get some done. Looking forward to the next release! (Hoping I'm not too big of a pain in the arse!)

[Dan Iacovelli]

Progress report on my laserman game:

got the player graphics and control working good

just have to work an the other stuff (I have to this after work on sunday though

too much time working on VGS'05 for tomarrow)

[skeezix]

(Please forgive my ignorance of this thread.. I've been following events, but not this thread.. just checked alienbills site and thought I'd better ask..)

 

Does anyone need a mailing list or message board for this project? Or are there some already? Evidently AA is the place to do it, but if anyone needs some web space to post some files, or a mailing list or the like, I can host 'em if no one else is setting up something.

 

I've not had time to keep up, but I do want to help out with such a cool project in what minimal way I can squeeze in

 

(mail me at skeezix@skeleton.org)

 

jeff

[skeezix]

Anyone talked to Retro Gamer about this yet?

 

jeff

[+batari]

I decided to just brute force fill the playfield bytes with zeros.  The length of this routine exceeds the 6502 branch capability however and causes a problem for the compiler in that this length condition isn't handled properly.  I'm attaching this batari as an extreme example that probably should be addressed at some point.  I'm not sure this case is going to come up very often, once we can do loops and set reset pixels properly.

892243[/snapback]

I found the same branch bug in one of my programs, and I fixed it - apparently the compiler was generating duplicate labels. Also, I did notice a few bugs unrelated to the branching but still causing errors nonetheless, from these lines:

 

1312 if k > h then pfvline 11 a on : a = a + 1

 

1320 if k > h then pfvline 13 g on : g = g + 1

 

1340 if k > h then pfvline 15 c on : c = c + 1

 

1360 if k > h then pfvline 17 d on : d = d + 1

 

1380 if k > h then pfvline 19 e on : e = e + 1

 

There are only three arguments specified for pfvline when it expects four. The error that this generates is somewhat cryptic: "Undefined symbol: on" or something of that sort, but most errors in the compiler are.

 

I've worked up a quick help file to go along with the other docs. I just need to update the readme and write a quick FAQ, and I'll release the next version tonight.

[+batari]

Anyone talked to Retro Gamer about this yet?

 

jeff

892335[/snapback]

Not that I'm aware of... But if you want to, please do! The more coverage the better.

 

Also, Batari Basic is free and will always be free, and it's fully redistributable for non-commercial purposes, so you can host any/all files on your website if you want.

[skeezix]

.. and you're including the C source, so I'm sure linux/freebsd/mac-osx ports will pop up in no time

 

I've no contacts at RG, but perhaps someone here does? Our man of AA has some ears there I'm sure

 

jeff

[bliprob]

Batari, I'm eager for the next release. I've run into a problem in my current game and I'm curious to see if the new compiler makes things any easier for me.

 

Also, I've made a little IDE for Mac users, to go along with my Mac-compiled 2600bas and dasm files. I made it in RealBasic so I can build it for Linux and Windows too. Here's a screenshot.

 

[bliprob]

.. and you're including the C source, so I'm sure linux/freebsd/mac-osx ports will pop up in no time

892353[/snapback]

 

Jeff -- a Mac port is back on page 8 of this thread. After I compile the new release, I'm going to give it to Kisrael to host on the official page.

[vdub_bobby]

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.

[+batari]

Batari, I'm eager for the next release. I've run into a problem in my current game and I'm curious to see if the new compiler makes things any easier for me.

 

Also, I've made a little IDE for Mac users, to go along with my Mac-compiled 2600bas and dasm files. I made it in RealBasic so I can build it for Linux and Windows too. Here's a screenshot.

 

892355[/snapback]

Hello,

 

A Mac OSX IDE would be great! I will use it myself on my iBook.

 

There is a bug in Alpha 0.1 that would prevent the program from compiling. Apparently, the compiler will attempt to compile the statements after a colon in a rem statement. This has been fixed in Alpha 0.2.

 

Also, only simple statements are supported right now. For instance, a = 49 & 128 + 50 will cause problems - break up the statement into simpler parts, by a = 49 & 128 : a = a + 50

 

Maybe by Alpha 0.3, I'll figure out a good way to parse something like this.

[kisrael]

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

[Serguei2]

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]

I agree

[skeezix]

Writing a full shift-reduce parser is tricky work; you could always take a stab at using yacc/lex to do it for you, but you'd end up spending some time learning them rather than writing code. But they do make life easy for big platforms

 

Still, rolling your own isn't too too bad..

 

jeff

[+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?