problem getting 2600IDE started

[Scorp.ius]

Hi!

 

I have tried to code something (just a smily on the screnn and stuff) but have a problem with 2600IDE or bBasic itself...

 

 

when i hit compile a screen opens that says "ERROR: unknown keyword XXX" where XXX is the first command in my program.

 

what am i doing wrong?

 

this is the code and it says Error unknown keyword romsize

set romsize 4k

player0:

%00101100

%01000010

%10100101

%10000001

%10100101

%10011001

%01000010

%00111100

end

COLUBK = 84

COLUP0 = 22

100

player0x = 100

player0y = 50

goto 100

[SeaGtGruff]

Hi!

 

I have tried to code something (just a smily on the screnn and stuff) but have a problem with 2600IDE or bBasic itself...

 

 

when i hit compile a screen opens that says "ERROR: unknown keyword XXX" where XXX is the first command in my program.

 

what am i doing wrong?

 

this is the code and it says Error unknown keyword romsize

set romsize 4k

player0:

%00101100

%01000010

%10100101

%10000001

%10100101

%10011001

%01000010

%00111100

end

COLUBK = 84

COLUP0 = 22

100

player0x = 100

player0y = 50

goto 100

I can't tell for sure from the code you posted, but my guess is that you didn't leave any spaces in front of the bB commands. All bB commands must be indented by at least one space. If you put a line label at the beginning of the line, then the line label must *not* be indented, it must begin at the left margin, but then the first bB command in that line of code must be separated from the line label by at least one space. (Personally, I prefer to put the line labels on lines by themselves, and I like to indent the code lines by three spaces-- or multiples of three if for...next loops are involved-- but other bB programmers will undoubtedly have their own [different] preferences.)

 

Naturally, there *is* an exception to the "always indent bB commands" rule (since every rule is made to be broken). Specifically, the "end" keyword must *not* be indented, but must instead begin at the left margin just like the line labels do.

 

Try adding the indentation and see if that fixes it!

 

MR

 

PS-- If you don't indent "set romsize 4k" by at least one space, then bB thinks that "set" is supposed to be a line label (since it begins at the left margin), and therefore the "romsize" keyword will be mistaken for a command that's been placed after a line label, instead of being recognized as an option of the "set" command. So I'm 99.9% sure that you didn't indent your bB commands!

[+atari2600land]

BTW, you don't have to say "set romsize 4k", I think it's automatically 4k. When you get past 4k, you need to bankswitch.

[SeaGtGruff]

Also, you need to include the "drawscreen" command inside your loop, otherwise bB will never draw the screen. The "player0" command is used to define the shape of player0, but it doesn't actually tell the Atari 2600 to draw player0. First you set up all the graphics you want to draw on the screen-- the shapes, positions, and colors of the playfield, the players, the missiles, and ball-- and then you use the "drawscreen" command to tell the Atari to display the resulting screen. Also, the "drawscreen" command needs to be in a loop, so the Atari keeps drawing the screen over and over-- about 60 times a second, if you're making an NTSC game.

 

Furthermore, you should set the value of COLUP0 inside the loop, so it keeps getting set before the Atari draws the screen. This is because bB uses the two players to draw the score at the bottom of the screen, and the values of COLUP0 and COLUP1 get wiped out (i.e., set to the "scorecolor") when bB draws the score.

 

And one last thing... bB draws the players upside-down, so you should flip the player0 bytes around. That might seem strange, but it's because of the way Atari 2600 programmers usually draw graphics on the screen in assembly language (e.g., if you look at the player graphics in games like Pac-Man, you'll see that the player shapes are defined upside-down).

 

As for "set romsize 4k" being unnecessary, that's true, but it doesn't hurt anything (i.e., it doesn't add any extra code to your program), so you can leave it in.

 

So your modified program might look something like the following. Notice how similar it looks to your original code-- you were very, very close to success! And now that you know what to watch out for, you can start writing some games for us to play!

 

  set romsize 4k
  player0:
  %00111100
  %01000010
  %10011001
  %10100101
  %10000001
  %10100101
  %01000010
  %00111100
end
  COLUBK = 84
100
  COLUP0 = 22
  player0x = 100
  player0y = 50
  drawscreen
  goto 100

[Scorp.ius]

aha! i allways wondered what "indented" means, and to be honest i dont know it yet. but i understand it as "do a space in front of the line"

 

now the compilation runs

[SeaGtGruff]

aha! i allways wondered what "indented" means, and to be honest i dont know it yet. but i understand it as "do a space in front of the line"

 

now the compilation runs

Yep, that's about right. I like to indent 3 spaces instead of just 1, because I think it makes it more obvious that the line is supposed to be indented, as opposed to a line that got accidentally typed with a space at the beginning. And when I use a "for...next" loop, or a statement like "player0" that has data following it, I like to indent another 3 spaces, because it helps make those lines stand out-- e.g.:

 

  player0:
  %11111111
  %10000001
  %10000001
  %10000001
  %11111111
end
  for i = 1 to 10
  for j = 1 to 5
	 k = i + j : rem * just some silly code
	 l = i - j
	 m = i * j
	 n = i / j
  next
  next

MR