Did superchip variables get wonked?

[+Gemintronic]

I tried to compile this:

 

 set romsize 8kSC

const p0_lo = <r000
const p0_hi = >r000
player0pointerlo = p0_lo
player0pointerhi = p0_hi
player0height = 7
player0x = 76
player0y = 44
loop
w000 = rand
w001 = rand
w002 = rand
w003 = rand
w004 = rand
w005 = rand
w006 = rand
w007 = rand
COLUP0 = rand
drawscreen
goto loop

 

and I got this:

Compile started at 9/29/2010 2:48:24 PM
Compiling C:\Documents and Settings\Administrator\My Documents\ramsprite.bas
DASM V2.20.07, Macro Assembler (C)1988-2003
     bytes of ROM space left in bank 1
     bytes of ROM space left in bank 2
     3507 bytes of ROM space left in bank 1
     2386 bytes of ROM space left in bank 2
     3507 bytes of ROM space left in bank 1
     2386 bytes of ROM space left in bank 2
--- Unresolved Symbol List
p0_lo                    0000 ????         (R )
p0_hi                    0000 ????         (R )
w000                     0000 ????         (R )
w001                     0000 ????         (R )
w002                     0000 ????         (R )
w003                     0000 ????         (R )
w004                     0000 ????         (R )
w005                     0000 ????         (R )
w006                     0000 ????         (R )
w007                     0000 ????         (R )
r000                     0000 ????         (R )

Fatal assembly error: Source is not resolvable.
Errors were encountered during assembly.
2600 Basic compilation completed.
Compilation completed at 9/29/2010 2:48:25 PM
view output file:///C:/Documents and Settings/Administrator/My Documents/bin
Post compilation files deleted

[+Random Terrain]

const p0_lo = <r000
const p0_hi = >r000

I haven't used SC or constants much, but isn't that the spot that is messed up?

[+Gemintronic]

Thanks for taking a look. I don't think so. I rem'ed out those lines and it still barfed on the superchip variables.

[+Random Terrain]

Thanks for taking a look. I don't think so. I rem'ed out those lines and it still barfed on the superchip variables.

I ran it with them looking like the following and didn't get any errors:

 

 const p0_lo = r000
 const p0_hi = r000

 

Problem is that I don't know what you are trying to do. Are you trying to use const like it's def or macro?

Edited September 29, 2010 by Random Terrain

[+Gemintronic]

Well, I tried actually reading the topic you pointed me too regarding changing sprite graphics around here:

http://www.atariage.com/forums/topic/161923-help-with-ram-sprites/

 

SeaGtGruff posted some examples that put sprite graphics in RAM. I suspect that the code was from a way earlier version of bB though

[+RevEng]

Problem is that I don't know what you are trying to do. Are you trying to use const like it's def or macro?

He's adapting an example from SeaGtGruff, and it should work as he's written it. The < and > symbols are supposed to return the lo and hi bytes of the address r000.

 

In my environment I'm completely missing the definitions for r000, r001, ..., and w000, w001, etc.

 

I think theloon has the same problem.

Edited September 29, 2010 by RevEng

[+Random Terrain]

He's adapting an example from SeaGtGruff, and it should work as he's written it. The < and > symbols are supposed to return the lo and hi bytes of the address r000.

 

In my environment I'm completely missing the definitions for r000, r001, ..., and w000, w001, etc.

 

I think theloon has the same problem.

That's weird. Maybe batari sneezed and hit the delete button by mistake.

[+RevEng]

I grabbed the zip file from this post and unzipped it into the bB includes directory.

 

Then I edited the file "superchipheader.asm" and added the line include "superchip.h" under include "vcs.h".

 

theloon's example compiled and ran for me then, even with the lo/hi byte symbols.

[+Random Terrain]

I grabbed the zip file from this post and unzipped it into the bB includes directory.

Do you think that stuff is included here too:

 

http://www.atariage.com/forums/topic/133529-updated-bb-files-to-download/

 

That's the stuff I have and his program works for me too.

[+RevEng]

Yup, it looks to be there too!

[+Random Terrain]

Yup, it looks to be there too!

That's good because that's where I've been telling people to go on the bB page:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#gettingstarted

 

 

Thanks.

[SeaGtGruff]

The batari Basic compiler itself doesn't have anything to do with the Superchip variable names, so I doubt that any changes to the 2600basic.exe file would have affected the Superchip variables.

 

The Superchip variable names-- w000, r000, w001, r001, etc.-- are defined in the superchip.h file. Make sure that this file still exists in whichever folder you keep your bB include files in.

 

Furthermore, the superchip.h file must actually be included somewhere in the include files that are being used to compile your game, otherwise the Superchip variable names won't be "automatically defined" (although you could still define them yourself-- or, for that matter, you could define *different* Superchip variable names).

 

Since the 2600basic.h file gets included when compiling the majority of bB programs, the simplest (safest?) place to include the superchip.h file would be in the 2600basic.h file, inside the ifconst statement (near the end of that file) that defines the location of the playfield:

 

  ifconst superchip
playfieldbase = $10D0
  include "superchip.h" ; <-- add this line here
  else
playfieldbase = $A4
  endif

However, the 2600basic.h file is *not* used with the multisprite kernel-- instead, the multisprite.h file is used-- so it would also be good to add the following lines at the very end of the multisprite.h file (after the lines that define the RETURN macro):

 

  ifconst superchip ; <-- add this line
  include "superchip.h" ; <-- add this line
  endif ; <-- add this line

Aside from those two files, there are other places the superchip.h file can be included-- e.g., inside one of the .asm files-- but probably the most convenient place for a programmer to include it manually would be inside the bB program itself:

 

  include superchip.h

Michael

 

 

 

[+Gemintronic]

Thanks guys! I was able to start compiling some of those RAM sprite examples now.

[SeaGtGruff]

I should add that you don't need the superchip.h file at all if you define your own Superchip variables. (I guess I did say you could always just define your own, but I didn't give an example how.) To do this, just dim a variable name to the Superchip address you want to use for it-- and remember, you'll need both a write address and a read address. I naturally want to think "read/write," so my natural inclination is to expect the read addresses to come first, but it's the other way around-- the write addresses come first, then the read addresses. The way I remember it is that you have to write to a variable before you can read back what you wrote! The Superchip write addresses are $F000 through $F07F (128 bytes), and the Superchip read addresses are $F080 through $F0FF (128 bytes). Since these are actually the *same* 128 bytes of RAM, but with the read addresses being offset from the write addresses by 128 bytes, a given variable's read address should be exactly 128 bytes after its write address.

 

For example, let's say you want to define a variable named cat_whiskers, which will be the first byte of the Superchip's RAM. Using Random Terrain's PEEK and POKE terminology, you would say

 

  dim POKE_cat_whiskers=$F000
  dim PEEK_cat_whiskers=$F080

  rem * use POKE_cat_whiskers to write to the variable
  POKE_cat_whiskers=18

  rem * use PEEK_cat_whiskers to read from the variable
  POKE_cat_whiskers=PEEK_cat_whiskers+1
  if PEEK_cat_whiskers>20 then POKE_cat_whiskers=0

Then again, I'm not sure if I like using PEEK and POKE here, because it might get confused with using PEEK and POKE in connection with nibble variables, and the syntax is different for POKE (POKE_superchipvariable needs an equal sign, but with POKE_nibblevariable you must leave out the equal sign). So maybe a different terminology would be better to keep things separate?

 

Actually, it's probably more common to use a Superchip variable's "read name" than its "write name," since you'd use its "read name" in if statements or math formulas:

 

  if superchipvariable=something then...
  if something>superchipvariable then...
  regularvariable=superchipvariable+8

So maybe it would be okay to use a normal-looking variable name for the Superchip variable's "read name," and have a longer version for just the "write name"?

 

  dim cat_whiskers=$F080
  dim WRITE_cat_whiskers=cat_whiskers-$80

  WRITE_cat_whiskers=23
  if cat_whiskers=14 then goto somewhere
  puppy_love=cat_whiskers+spilt_milk
  WRITE_cat_whiskers=cat_whiskers-rat_tails

Or it might be a good idea to have a special prefix in front of the "read name," to stress that it's a Superchip variable:

 

  dim SC_cat_whiskers=$F080
  dim WRITESC_cat_whiskers=SC_cat_whiskers-$80

  WRITESC_cat_whiskers=SC_cat_whiskers+32

Michael

Edited September 30, 2010 by SeaGtGruff