427 replies to this topic

[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]

batari, on Thu Jul 14, 2005 4:20 PM, said:

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

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.

Attached Thumbnails

• 

[batari]

Serguei2, on Thu Jul 14, 2005 4:44 PM, said:

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

Quote

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.

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

Example: COLUPF = $2E

[Serguei2]

Quote

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

I'll try it.

Quote

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.

Quote

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.

Quote

20 COLUPF = $2e : COLBK = $90

Edited by Serguei2, Thu Jul 14, 2005 6:09 PM.

[supercat]

Serguei2, on Thu Jul 14, 2005 7:05 PM, said:

I have a problem with COLBK.

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

Attached Thumbnails

• 

[Serguei2]

Dan Iacovelli, on Thu Jul 14, 2005 9:49 PM, said:

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   1.59K   41 downloads

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

potatohead, on Fri Jul 15, 2005 11:35 AM, said:

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.

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]

skeezix, on Fri Jul 15, 2005 2:25 PM, said:

Anyone talked to Retro Gamer about this yet?

jeff

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]

skeezix, on Fri Jul 15, 2005 3:54 PM, said:

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

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]

bliprob, on Fri Jul 15, 2005 2:56 PM, said:

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.

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]

vdub_bobby, on Fri Jul 15, 2005 4:13 PM, said:

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.

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]

vdub_bobby, on Fri Jul 15, 2005 3:13 PM, said:

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.

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?