427 replies to this topic

[attendo]

Batari is it possible to remove the code from the generated .asm (or kernel) for the score counter because Im not using it in the game im making and I gues by removing it it will save some cycles. Now I just am giving the score the same color as the background to make it invisible

What code do I need to remove and how much cycles would It save?

greets.

[Tom]

batari, on Wed Jul 27, 2005 3:32 AM, said:

Just curious if you think that all I need to include is the input file to lex in the source, or if the generated lex.yy.c file should be in there too for those who don't have lex?  I.e. what's the "normal" thing to do?

The normal thing would be to distribute the grammar file, but not the generated code. Nothing that can be generated needs to be distributed (or even more silly, put under version control. I've seen people do that before...)

[batari]

attendo, on Fri Jul 29, 2005 11:03 AM, said:

Batari is it possible to remove the code from the generated .asm (or kernel) for the score counter because Im not using it in the game im making and I gues by removing it it will save some cycles. Now I just am giving the score the same color as the background to make it invisible

What code do I need to remove and how much cycles would It save?

greets.

You would remove everything from the comment ";6 digit score routine", down to, but not including "lda temp2"

You would then need to change the lda #43 just below to something larger to compensate for the removed scanlines. I'm not sure what it should be offhand, maybe lda #56 would suffice. This should give an additional 750 cycles for your bB code.

I think the above should work, but I haven't tested it.

[attendo]

@batari

Excellent it works ive attached the modified 2600basic.asm for others who dont need to use the score and spare some cycles. At first my game started to flicker (3 copied sprites(with NUSIZ1) + 1 sprite + pfpixels, etc.) but now its ok.

Attached Files

•  2600basic_asm_noscore.zip   2.31K   53 downloads

Edited by attendo, Fri Jul 29, 2005 2:09 PM.

[batari]

JLsoft, on Thu Jul 28, 2005 3:49 PM, said:

batari,

Please consider renaming the files for alpha 0.3 to 8.3 format...since it -is- a DOS program, it should be usable in pure DOS (without having to hex-edit the EXE ) 

I called it a DOS program because it must be run at the Windows Command Prompt. 8+3 is SO limiting and outdated, I don't think I should change the expanding set of files to conform to this. I think a better solution is to quit calling it a DOS program but instead call it a Win32 command-line program.

[Luigi301]

Is 0.3 going to have ball and/or paddle support? I'm pretty far along in making a Breakout-style game and you can't have Breakout without a ball or paddle.

[JLsoft]

Quote

I called it a DOS program because it must be run at the Windows Command Prompt.  8+3 is SO limiting and outdated, I don't think I should change the expanding set of files to conform to this.  I think a better solution is to quit calling it a DOS program but instead call it a Win32 command-line program.

...it is an actual DOS program at the moment though, and runs just fine under pure DOS (except for the part about trying to call the variable redef file, which has a long filename)



[EDIT] Annnnnd, never mind...I was thinking that it was packed along with the DOS port of DASM, but it's the Win32 console version...ignore!

Edited by JLsoft, Sun Jul 31, 2005 4:50 PM.

[Luigi301]

Is there a command to check whether a playfield pixel is on or not?

[batari]

Luigi301, on Sun Jul 31, 2005 4:18 PM, said:

Is there a command to check whether a playfield pixel is on or not?

No, but there will be soon...

[kisrael]

that would be great...I have a few ideas where not having the screen memory be "write only" would be very useful, I'd have to keep track of less stuff using other variables...

[JLsoft]

Luigi301, on Sun Jul 31, 2005 2:18 PM, said:

Is there a command to check whether a playfield pixel is on or not?

Attached is a (cycle-wasting, cringe-worthy) way I wrote up earlier to check for the playfield status...you can probably make it much better and use it in the meantime until an actual command is added

Attached Files

•  PFTEST.TXT   2.9K   67 downloads

[Luigi301]

I'm wasting enough scanlines as it is

If you want to get into a scanline wasting war...

  rem row 1-1 - all bit reads except 6 and 7 are inverted
  if a(7) then pfhline 0 4 2 on
  if a(6) then pfhline 3 4 5 on
  if !a(5) then pfhline 6 4 8 on
  if !a(4) then pfhline 9 4 11 on
  if !a(3) then pfhline 12 4 14 on
  if !a(2) then pfhline 15 4 17 on
  if !a(1) then pfhline 18 4 20 on
  if !a(0) then pfhline 21 4 23 on
  rem row 1-2 - only 7-5 are used, 4-0 are ignored
  if !a(5) then pfhline 24 4 26 on
  if a(6) then pfhline 27 4 29 on
  if a(7) then pfhline 30 4 31 on

[Random Terrain]

Labels and Numbers

While trying to finish the first version of my personal help file, I noticed that it might be nice to know if a label must start with a letter of the alphabet. I think at least one BASIC I used said that a label must not start with a number. Numbers could be mixed in anywhere after the first character though. Is Batari BASIC the same in that area?

[batari]

Random Terrain, on Thu Aug 4, 2005 2:41 AM, said:

Labels and Numbers

While trying to finish the first version of my personal help file, I noticed that it might be nice to know if a label must start with a letter of the alphabet. I think at least one BASIC I used said that a label must not start with a number. Numbers could be mixed in anywhere after the first character though. Is Batari BASIC the same in that area?

There is no such limitation for labels in bB. A label can have any combination of letters or numbers, even as the first character. You can use underscores too. The only limitations I can think of is that a label must not match a known keyword or any labels internal to bB (like start, kernel, etc.) For example, you can't name a label "next" or "pfpixel"

A variable alias (i.e. with the dim statement), however, does need to start with a letter.

[Random Terrain]

batari, on Thu Aug 4, 2005 2:59 AM, said:

There is no such limitation for labels in bB.  A label can have any combination of letters or numbers, even as the first character.  You can use underscores too.  The only limitations I can think of is that a label must not match a known keyword or any labels internal to bB (like start, kernel, etc.) For example, you can't name a label "next" or "pfpixel"

A variable alias (i.e. with the dim statement), however, does need to start with a letter.

Thanks. That will make things even more clear.

[Random Terrain]

Indenting

To make sure I understand correctly, are labels, line numbers and end the only things that are not indented?

[batari]

Random Terrain, on Sat Aug 6, 2005 12:41 AM, said:

Indenting

To make sure I understand correctly, are labels, line numbers and end the only things that are not indented?

I think so. Though eventually I may remove the requirement for "end" so it can be intended or not.

[Random Terrain]

batari, on Sat Aug 6, 2005 1:26 AM, said:

Random Terrain, on Sat Aug 6, 2005 12:41 AM, said:

Indenting

To make sure I understand correctly, are labels, line numbers and end the only things that are not indented?

I think so. Though eventually I may remove the requirement for "end" so it can be intended or not.

Thanks. That will be easy to remember.

[attendo]

Perhaps its an ID to create a command to be placed in the beginning of the code which selects a kernel (like rem smartbranching on)
For example:

"rem kernel <default>" To select the default kernel
"rem kernel <hi_res>" To select the hi_res_2600basic.asm & hi_res_2600basicfooter.asm

Or something like that, this makes switching, using, trying out different kernels easier.

[kisrael]

I'd like to mention I'm not a big fan of sneaking in smartbranching via a comment; if it impacts the code, it deserves to be its own command, same (even more so) for kernals.

[attendo]

Well without the rem statement then
that makes:

"kernel <default>"
"kernel <hi_res>"
etc.

Edited by attendo, Mon Aug 8, 2005 2:39 PM.

[potatohead]

kisrael, on Mon Aug 8, 2005 3:32 PM, said:

I'd like to mention I'm not a big fan of sneaking in smartbranching via a comment; if it impacts the code, it deserves to be its own command, same (even more so) for kernals.

I'll second that.

How about a general keyword for this kind of thing, followed by a list of arguments?

config
kernel <x>
smartbranching on
memorymodel 4k
end

That sort of fits with some other things in the language, cutting down on the number of different structures one has to know at least...

[batari]

potatohead, on Mon Aug 8, 2005 11:09 PM, said:

kisrael, on Mon Aug 8, 2005 3:32 PM, said:

I'd like to mention I'm not a big fan of sneaking in smartbranching via a comment; if it impacts the code, it deserves to be its own command, same (even more so) for kernals.

I'll second that.

How about a general keyword for this kind of thing, followed by a list of arguments?

config
kernel <x>
smartbranching on
memorymodel 4k
end

That sort of fits with some other things in the language, cutting down on the number of different structures one has to know at least...

I can see the logic in not using smartbranching in a rem, but I'm still thinking of the best way to do things.

Includes and some other compiler directives (like dim) do not affect the bB-to-asm compilation. smartbranching does affect the bB-to-asm, as will a future directive (a few revisions away) to specify optimization for speed or space, or to build an 8k bankswitched ROM (a few more revisions away).

I like the idea of dim and include on their own rather than in a config block, and the others above could be passed as command-line arguments or allowed to be defined as special settings. Maybe a "set" command could be used to define things, kind of like setting an envorinment variable:

set smartbranching off/on
set romsize 2k/4k/8k
set optimization size/speed

If it's done this way, you can actually turn these on and off on the fly. For instance, if you want some code optimized for speed and some for space, you could change the optimization several times.

[potatohead]

batari, on Tue Aug 9, 2005 1:07 AM, said:

potatohead, on Mon Aug 8, 2005 11:09 PM, said:

kisrael, on Mon Aug 8, 2005 3:32 PM, said:

I'd like to mention I'm not a big fan of sneaking in smartbranching via a comment; if it impacts the code, it deserves to be its own command, same (even more so) for kernals.

I'll second that.

How about a general keyword for this kind of thing, followed by a list of arguments?

config
kernel <x>
smartbranching on
memorymodel 4k
end

That sort of fits with some other things in the language, cutting down on the number of different structures one has to know at least...

I can see the logic in not using smartbranching in a rem, but I'm still thinking of the best way to do things.

Includes and some other compiler directives (like dim) do not affect the bB-to-asm compilation. smartbranching does affect the bB-to-asm, as will a future directive (a few revisions away) to specify optimization for speed or space, or to build an 8k bankswitched ROM (a few more revisions away).

I like the idea of dim and include on their own rather than in a config block, and the others above could be passed as command-line arguments or allowed to be defined as special settings. Maybe a "set" command could be used to define things, kind of like setting an envorinment variable:

set smartbranching off/on
set romsize 2k/4k/8k
set optimization size/speed

If it's done this way, you can actually turn these on and off on the fly. For instance, if you want some code optimized for speed and some for space, you could change the optimization several times.

I'm liking the set operator for all of these options. Being able to do things on the fly makes perfect sense where the 2600 is concerned. Games with different screens could use different kernels, for example. In this way bb might really make managing all of that quite easy actually.

For what it's worth, both syntax ideas allow for these things, but your use of the set operator is less overall parsing and typing / formatting for the developer. Better overall, IMHO.

Come to think of it, the overall concept of an environment is making a lot of sense actually. Set is familiar and easy. Why not? However it works, I would love to see everything necessary be part of the program source code file. Nice and self-documenting and easily packaged, etc...

Edited by potatohead, Tue Aug 9, 2005 1:23 AM.

[danwinslow]

I'd vote for the set method too.