+Gemintronic Posted September 29, 2010 Share Posted September 29, 2010 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 29, 2010 Share Posted September 29, 2010 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? Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted September 29, 2010 Author Share Posted September 29, 2010 Thanks for taking a look. I don't think so. I rem'ed out those lines and it still barfed on the superchip variables. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 29, 2010 Share Posted September 29, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted September 29, 2010 Author Share Posted September 29, 2010 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 29, 2010 Share Posted September 29, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 29, 2010 Share Posted September 29, 2010 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 29, 2010 Share Posted September 29, 2010 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. 1 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 29, 2010 Share Posted September 29, 2010 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted September 29, 2010 Share Posted September 29, 2010 Yup, it looks to be there too! Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted September 29, 2010 Share Posted September 29, 2010 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. 1 Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted September 30, 2010 Share Posted September 30, 2010 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 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted September 30, 2010 Author Share Posted September 30, 2010 Thanks guys! I was able to start compiling some of those RAM sprite examples now. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted September 30, 2010 Share Posted September 30, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.