Is Multisprite, bank switching and SARA allowable in batari together?

[Gorf]

Hey guys......I think I may be doing a no no here so here goes....

 

The code I am currently playing with works perfectly except is seems,

even though I include the following for SuperChip RAM, multisprite

and switch banking

 

 includesfile multisprite_bankswitch.inc
includesfile superchip.inc
set kernel multisprite
set romsize 32kSC
set screenheight=88

 

I get no errors and the app runs fine.

 

However the minute I try to use the Superchip Ram as I need more memory...like so...

 

wxxx = 1

a = rxxx

 

 

I get this.....

 

--- Unresolved Symbol List
screenheight			 0000 ????		 (R )
w000					 0000 ????		 (R )

Fatal assembly error: Source is not resolvable.

 

DOH!

 

Am I breaking laws batari may not complain about?

Or is this a known issue with batari?

 

Thanks guys....

 

 

Steve

Edited May 8, 2007 by Gorf

[+batari]

Am I breaking laws batari may not complain about?

Or is this a known issue with batari?

I think so. There should be no need to explicitly specify superchip.inc as an includesfile. So just remove that line and it should work.

 

superchip.inc is used automatically when you specify 32kSC as the banking scheme (and this also sets an internal flag in the compiler.) bB checks to see if you're trying to include the same file twice and ignores the second attempt, so what's probably happening is the internal flag isn't being set.

[Gorf]

internal flag in the compiler.) bB checks to see if you're trying to include the same file twice and ignores the second attempt, so what's probably happening is the internal flag isn't being set.

 

 

Actually, my original did NOT use that SC include as I did assume the SC appended to the set

romsize command did it automatically. When I got the unresolved error is when I tried to directly

include the SC include.

 

 

Like I said though, I cant access that SC RAM. When I try to like so.....

 

w000= 1

 

Again, it gets me an error with or with out that SC include.

 

 

Im a little confused as to why I see 'screenheight' unresolveded.

Im am also a little confused as to why I i cant seemingly access the RAM.

 

screenheight 0000 ???? (R )

w000 0000 ???? (R )

 

 

 

Even still...regardless of my troubles...bB totally rocks the stadium Fred!

Its just a blast to mess with.

 

 

And thanks for the help as always!

[SeaGtGruff]

I think part of your problem is with the screenheight. It should be set with "const" instead of "set":

   const screenheight=88

However, the docs say that the only supported values right now are 80 and 84. Also, I think you may have to use pfheight with it.

 

It would be easier to see what's wrong if you post the code you're trying to compile.

 

Michael

[SeaGtGruff]

It looks like the superchip.h file that I had created a while back was left out of bB v1.0. That's the file that defined the variables w000, w001, r000, r001, etc. Also, it looks like 256 bytes aren't reserved for the Superchip when using multisprite bankswitching. So I created a multisprite_superchip.inc includes file, along with a multispritesuperchipheader.asm include, and added back the superchip.h include. All three files are in the attached zip file, and here is a demo to test them-- but I haven't tried using the multisprite players with it yet, so I can't guarantee that it will function 100% correctly.

 

Michael

test_ms_bs_sc.bas

test_ms_bs_sc.bas.bin

multisprite_superchip.zip

Edited May 8, 2007 by SeaGtGruff

[+batari]

It looks like the superchip.h file that I had created a while back was left out of bB v1.0. That's the file that defined the variables w000, w001, r000, r001, etc. Also, it looks like 256 bytes aren't reserved for the Superchip when using multisprite bankswitching. So I created a multisprite_superchip.inc includes file, along with a multispritesuperchipheader.asm include, and added back the superchip.h include. All three files are in the attached zip file, and here is a demo to test them-- but I haven't tried using the multisprite players with it yet, so I can't guarantee that it will function 100% correctly.

 

Michael

You are absolutely right - I was looking into the problem today. I can't believe I wrote all those docs about using r000/w000 and so on, while completely forgetting to include the superchip.h file you created

 

Forgetting those variable definitions is pretty serious, so maybe it's time to work up to a 1.01 release that includes these fixes.

[Gorf]

Did I tell you guys you rock yet? Well if not, you so totally rock!!!

That did it! Woohoo! More memory! I'd post the code but it would

ruin a POSSIBLE fantastic suprise for everyone.

 

Mike and Fred, thanks again.

[Gorf]

I think part of your problem is with the screenheight. It should be set with "const" instead of "set":

   const screenheight=88

However, the docs say that the only supported values right now are 80 and 84. Also, I think you may have to use pfheight with it.

 

It would be easier to see what's wrong if you post the code you're trying to compile.

 

Michael

 

 

No this seems to work too just as it was, with your header and includes. Again

great job and thanks.

 

Again everything was fine till I tried to access SC. Now it works very well, thanks.

 

 

Steve

[SeaGtGruff]

maybe it's time to work up to a 1.01 release

Yipes, if you do that, then if you hold off a little bit, I'll try to finish the keypads routines tonight so you can include them as well if you want. (And regarding the keypads, I think the safest thing is to wait the full 478 cycles/400 useconds.)

 

Michael

[Gorf]

Perhaps you guys should through in a DC reading function while your at it.

 

I know I can use it (I already am using batari's snippet he posted in the

keypad thread(i think it was that thread).)

 

Anyway one more item of interest about SC ram

 

In the batai man pages

 

"To ameliorate Superchip variable use, the 48-bytes previously reserved for the playfield has been placed in Superchip RAM. Therefore 48 bytes of standard RAM has been freed and is not subject to the above limitations. These 48 bytes are named var0-var47. "

 

Now the w and r variables are recognized with that latest include, but the var0-var47

are now giving me the same error the w and r vars gave me.

 

Also are these var0-var47 bytes super ram or are they the 2600's ram? OR is this old text im

reading and this info about var0-var47 is no longer true?

 

Thanks again guys.

 

Steve

[Gorf]

Ok folks...though the code compiles when using wxxx and rxxx

they do not function at all. Perhaps its my fault again.

 

w000 = 240

 

loop

w000 = r000 - 1

if r000 = 0 then w000 = 240 : c = c + 1

drawscreen

goto loop

 

'c' never increments. so I assume it's not working or I am once

again missing something or not obeying certain rules again.

 

 

The rest of the code is fine however and operates normally.

Edited May 8, 2007 by Gorf

[Gorf]

WOOOPSIES!!!!

 

 

Allow me to be ebarrassed for not adding the 'SC' after the set romsize.

 

DOH!

 

Everything is working fine now! It seems you can 'dim' these variable as well. Nice!

 

 

 

 

note: var0-var47 still not recognized though.

Edited May 8, 2007 by Gorf

[SeaGtGruff]

Perhaps you guys should through in a DC reading function while your at it.

 

I know I can use it (I already am using batari's snippet he posted in the

keypad thread(i think it was that thread).)

That sounds like a good idea.

 

Anyway one more item of interest about SC ram

 

In the batai man pages

 

"To ameliorate Superchip variable use, the 48-bytes previously reserved for the playfield has been placed in Superchip RAM. Therefore 48 bytes of standard RAM has been freed and is not subject to the above limitations. These 48 bytes are named var0-var47. "

 

Now the w and r variables are recognized with that latest include, but the var0-var47

are now giving me the same error the w and r vars gave me.

 

Also are these var0-var47 bytes super ram or are they the 2600's ram? OR is this old text im

reading and this info about var0-var47 is no longer true?

var0 through var47 are in zero-page RAM, but I'm not sure if they're available in the multisprite kernel; I'll check.

 

As for the playfield not being moved to Superchip RAM, that is something I had a question about.

 

There is a section of code in the standard header include file that relocates the playfield addresses from zero-page RAM to Superchip RAM if the Superchip option is being used, but I didn't add that code to the multispritesuperchipheader.asm because I was under the impression that the multisprite kernel keeps the playfield in ROM instead of RAM. However, if the Superchip is being used with the multisprite kernel, then I think it might be possible to put the playfield memory in Superchip RAM instead of ROM? I'm not sure if or how that would work out, and keep in mind that the files I posted last night weren't tested thoroughly (because it was so late), so I'll check into it further tonight... and I think these new include files should be tested thoroughly by anyone interested before batari puts together a new release with them.

 

Michael

[SeaGtGruff]

var0 through var47 are in zero-page RAM, but I'm not sure if they're available in the multisprite kernel; I'll check.

They aren't available in the multisprite kernel, with or without the Superchip, because the zero-page RAM that's used for the playfield in the standard kernel is used for other things in the multisprite kernel. However, if you use the Superchip option with the multisprite kernel, then you do have all of the Superchip RAM available to you.

 

There is a section of code in the standard header include file that relocates the playfield addresses from zero-page RAM to Superchip RAM if the Superchip option is being used, but I didn't add that code to the multispritesuperchipheader.asm because I was under the impression that the multisprite kernel keeps the playfield in ROM instead of RAM. However, if the Superchip is being used with the multisprite kernel, then I think it might be possible to put the playfield memory in Superchip RAM instead of ROM? I'm not sure if or how that would work out

The multisprite kernel contains lo-byte and hi-byte pointers for the PF1 and PF2 data (which are set up in their own separate data tables, rather than being intermixed together as in the standard kernel). So there's no way to "automatically" move the multisprite playfield into Superchip RAM using a compiler option, because the batari Basic compiler generates the data tables for PF1 and PF2 in ROM when it's compiling the "playfield:" statements, which automatically sets up the pointers to point to those ROM data tables. *However*, it is definitely possible to set the playfield pointers manually, and point them to addresses within the Superchip RAM area, which means you could have a RAM playfield with the multisprite kernel-- and presumably use the playfield drawing commands with it (if you include the appropriate include file/s)-- although you won't be able to use the "playfield:" command to define the playfield graphics if you do that (you'll have to define and manage the playfield data yourself). And if you want to use the playfield drawing commands, I think you'd need to write special versions of the appropriate include files, since the multisprite playfield has a different pixel width than the standard playfield (16 versus 32), and the data bytes are arranged differently. I'll see if I can put together some new include files for that, and post an example that uses them.

 

Michael

[Gorf]

They aren't available in the multisprite kernel, with or without the Superchip, because the zero-page RAM that's used for the playfield in the standard kernel is used for other things in the multisprite kernel. However, if you use the Superchip option with the multisprite kernel, then you do have all of the Superchip RAM available to you.

 

 

This is good to know and I can make good use of it.

 

There is a section of code in the standard header include file that relocates the playfield addresses from zero-page RAM to Superchip RAM if the Superchip option is being used, but I didn't add that code to the multispritesuperchipheader.asm because I was under the impression that the multisprite kernel keeps the playfield in ROM instead of RAM. However, if the Superchip is being used with the multisprite kernel, then I think it might be possible to put the playfield memory in Superchip RAM instead of ROM? I'm not sure if or how that would work out

 

Is the play field mirrored due to a register setting in the 2600 or becasue the kernel

is controlling it?

 

 

The multisprite kernel contains lo-byte and hi-byte pointers for the PF1 and PF2 data (which are set up in their own separate data tables, rather than being intermixed together as in the standard kernel). So there's no way to "automatically" move the multisprite playfield into Superchip RAM using a compiler option, because the batari Basic compiler generates the data tables for PF1 and PF2 in ROM when it's compiling the "playfield:" statements, which automatically sets up the pointers to point to those ROM data tables. *However*, it is definitely possible to set the playfield pointers manually, and point them to addresses within the Superchip RAM area, which means you could have a RAM playfield with the multisprite kernel-- and presumably use the playfield drawing commands with it (if you include the appropriate include file/s)-- although you won't be able to use the "playfield:" command to define the playfield graphics if you do that (you'll have to define and manage the playfield data yourself). And if you want to use the playfield drawing commands, I think you'd need to write special versions of the appropriate include files, since the multisprite playfield has a different pixel width than the standard playfield (16 versus 32), and the data bytes are arranged differently. I'll see if I can put together some new include files for that, and post an example that uses them.

 

Michael

 

 

Excellent Michael and again thanks.

 

What I want to do is every even frame point to a ROM playfield screen and

every odd frame to a RAM playfield screen. I will need 88 bytes of the 128

bytes to do a 32 pixel wide(mirrored) x 44 pixels high.

 

The real 64 bit question: Is it possible to have a non mirrorred playfield one

frame and a mirrored the next in a multisprite kernal? I understand batari may

not be able to do this but is this possible under asm?

 

I would LOVE to be able to do a ram based non-mirrored 32 x 22 palyfield I

can change on the fly in the odd frames and a mirrored 44 pixel hig rom based

the next frame. Also the ROM based playfields would be an array of such playfields

that would be a set animation. Every thing works fine other wise.

 

Mike, thanks and thanks for the help from everyone else around here.

You foks wont regret it.

 

Edited May 8, 2007 by Gorf

[supercat]

The real 64 bit question: Is it possible to have a non mirrorred playfield one

frame and a mirrored the next in a multisprite kernal? I understand batari may not be able to do this but is this possible under asm?

 

It is possible (see Conquest of Mars) but there tend to be a lot of limitations and complications if you don't want your platfield to appear "striped". For many games having the playfield striped every 2 or 3 pixels may add a "hi-tech" look, but in other cases such appearance would be undesirable.

 

The problem is that positioning a sprite requires executing a RESPxx instruction at a certain precise point in the scan; the required location varies with the desired sprite position. Maintaining a non-symmetrical playfield also requires writing data at certain precise points in the scan. Normally, the RESPxx writes would be handled by performing a WSYNC, followed by a suitable delay, followed by a RESPxx, and followed fairly soon thereafter by a WSYNC and HMOVE. This approach is not suitable for use in a kernel with an assymetric playfield because there's no way the playfield writes will happen at the proper times on the playfield lines.

 

In Caverns of Mars, there are special versions of the cave kernel to handle different RESPxx timings. This is fairly straightforward since none of the objects move. If you want objects that can move, you'll probably need six differnet draw-line routines that hit RESPx in different places about 30 pixels (10 cycles) apart; you can squeeze the appropriate RESPx instructions into the normal asym-playfield kernel. Then to position an object you'll invoke one of those routines and then perform two HMOVEs to move the object to the precise required position.

 

I don't know that any game has gone to such lengths to combine a multi-sprite kernel and an assymetrical playfield. On the other hand, the beauty of the 2600 is that when you need such things and are willing to spend some code space for them, you can often do them.

[+batari]

maybe it's time to work up to a 1.01 release

Yipes, if you do that, then if you hold off a little bit, I'll try to finish the keypads routines tonight so you can include them as well if you want. (And regarding the keypads, I think the safest thing is to wait the full 478 cycles/400 useconds.)

 

Michael

No rush. It's not going to get done that soon - I've got a few things going on this week.

[Gorf]

Hey Supercat,

 

It is possible (see Conquest of Mars) but there tend to be a lot of limitations and complications if you don't want your platfield to appear "striped". For many games having the playfield striped every 2 or 3 pixels may add a "hi-tech" look, but in other cases such appearance would be undesirable.

 

 

 

I just took a look at Conquest of Mars and I am not 100% what is going on.

In the area where all those ships come up at you, are they all sprites?

I dont think i need something this elaborate nonetheless, but again I am a

novice at this.

 

 

The problem is that positioning a sprite requires executing a RESPxx instruction at a certain precise point in the scan; I don't know that any game has gone to such lengths to combine a multi-sprite kernel and an assymetrical playfield. On the other hand, the beauty of the 2600 is that when you need such things and are willing to spend some code space for them, you can often do them.

 

 

Again this would only need to be a (RAM based) asymetrical one frame and a

symetrical(ROM based) the next alternating between the two. I'd use the

symetrical for the backdrop and the asymetrical for essentially stars. I only

need one color for each frame and black for both background colors. Is this

something I might be able to do with batari or will this absolutely require asm?

 

The current MS kernal in batari is almost it if only I can get that one RAM based

asymetrical. I understand i might have to do this with the asm command as well.

 

 

 

And thanks for your help, supercat

 

[+batari]

The current MS kernal in batari is almost it if only I can get that one RAM based

asymetrical. I understand i might have to do this with the asm command as well.

That might be a little tough to do. The problem is that the mid-kernel positioning routine takes a full scanline to run, and so there's not enough time for an asymmetrical playfield in its current form. It might be possible to split the positioning routine into several different chunks to save some time but I haven't yet written any code or even run any numbers to see how well it might work.

[SeaGtGruff]

It seems you can 'dim' these variable as well. Nice!

You can "dim" *any* memory location to give it an additional name. For example, if you would prefer to say "background_color" instead of "COLUBK," then you can "dim background_color = COLUBK."

 

There are at least six reasons why you might want to "dim" a memory location-- be it one of the Atari 2600's registers, one of batari Basic's "system variables," or one of the "user variables," etc.:

 

(1) You might want to create a more self-evident name for referring to a particular memory location. For example, "GRP0" may be readily-understood by veteran programmers of the Atari 2600, but to anyone who isn't already familiar with the names or mnemonics of the various registers, it isn't exactly the most obvious thing in the world. I mean, what is it, "group 0" or something? So you might want to say something like "dim player0_graphics = GRP0."

 

(2) You might want to create a *shorter* name for something. This is essentially the opposite of the first reason. For example, "player0x" is nicely self-evident. Nevertheless, when you use long variable names in program statements-- especially in "if...then" or "if...then...else" statements-- the program lines can become long, potentially making the program more difficult to read, either because you have to keep scrolling back and forth from left to right and right to left as you read through the program, or (if the lines wrap around on the screen or printed page) because you have to be more careful not to let your eyes "jump track" and get off-line, or because the wraparound may mess up carefully-spaced indentation that's being used to give the program a more "structured" appearance. So you might want to say something like "dim p0x = player0x," to help shorten some of the longer lines in the program.

 

(3) You might want to create *additional* names for a memory location that's being used for multiple purposes. For example, if you're using different bits of a particular byte for different things, then you might want to define multiple variable names for that memory location. Unfortunately, you *cannot* do something like "dim octopus_aggression = a{0}" and "dim got_treasure = a{1}," etc.-- but you *can* say "dim octopus_aggressive = a" and "dim got_treasure = a," and then use more self-explanatory statements such as "if octopus_aggressive{0}" or "if got_treasure{1}," instead of obscure statements such as "if a{0}" or "if a{1}." Of course, this reason also applies to using the whole byte for different purposes, such as if variable "z" is being used for two or more things in different parts of the program.

 

(4) If two or more memory addresses are used as a "single" variable, you might want to create names for the individual bytes so it will be easier to use them in statements. The only example I can think of is the "score" variable, which is a 3-byte BCD value. You can set "score" to a 6-digit number, but you can't *check* or *compare* the 6-digit value that's in "score" (at least, not yet). So you might want to say something like "dim s0 = score," "dim s1 = score+1," and "dim s2 = score+2," so you can set an individual byte of the score to a specific 1-byte value, or check the value of one byte of the score, etc. One other example is the "playfield" variable (when the playfield is stored in RAM), which is an array of 48 bytes (in the standard kernel). In earlier versions of batari Basic, the bytes of the "playfield" array weren't redefined as "var0" through "var47," so if you wanted to use the bytes of the last row as four additional variables, you could do something like "dim number_of_lives = playfield+44."

 

(5) The "dim" statement is also used to define "4.4" or "8.8" fixed-point variables.

 

Those are the main reasons that you might want to use "dim." But if you're going to write any custom include files, or use inline assembly, then a sixth reason is (6) you might want to use "dim" to create a sort of "flag" so the program code can compile in different ways depending on whether or not the flag is set. For example, back when I created modified include files to allow M-Network bankswitching to be used with batari Basic 0.35, I used something like "dim mnetwork = y" to tell batari Basic and DASM to compile the program for M-Network bankswitching. And when I added Superchip support (before it was officially incorporated into batari Basic 1.0), I used something like "dim superchip = y." Note that if you want to try something like this, you need to use "compiler directives" using assembly coding, such as saying "ifconst mnetwork"-- so first you'd need to learn about how compiler directives work.

 

Michael

[SeaGtGruff]

Is the play field mirrored due to a register setting in the 2600 or becasue the kernel

is controlling it?

Both, sort of. Although the standard batari Basic kernel has an asymmetrical playfield, the Atari 2600 doesn't have an asymmetrical playfield "by itself." Instead, the playfield is defined by three registers-- PF0, PF1, and PF2-- and these three registers define (or control, or draw, or however you want to say it) only the *left* half of the screen. For the *right* half of the screen (or playfield), the Atari displays either a *copy* of the left half, or a *reflection* of the left half. This is determined by one of the bits of the "CTRLPF" register-- namely, bit 0, or "CTRLPF{0}." If you say "CTRLPF{0} = 0," then the right side of the playfield will be a copy of the left side (i.e., PF0, PF1, PF2, PF0, PF1, PF2). On the other hand, if you say "CTRLPF{0} = 1," then the right side of the playfield will be a reflection of the left side (i.e., PF0, PF1, PF2, PF2, PF1, PF0). So there *is* a register setting that causes the playfield to be mirrored.

 

However, I think what you really meant was if there's a register that controls whether the playfield is asymmetrical or not, and the answer to that is no, there isn't a register setting for that-- it must be accomplished or controlled through the kernel. To create an asymmetrical playfield, you have to write different values to the PF0, PF1, and PF2 registers while the scan line is being drawn. In other words, you write the values for the left side of the playfield into PF0, PF1, and PF2 before the left half of the screen is displayed, and then you write the values for the right side of the playfield into PF0, PF1, and PF2 after the left half of the screen has been displayed, but before the right half is displayed. You can do this with either a copied playfield or a reflected playfield-- as long as you're using all 40 playfield pixels, it doesn't matter which, except it does affect the timing that's required. For example, if you're drawing an asymmetrical *copied* playfield (PF0, PF1, PF2, PF0, PF1, PF2), then you can write a new value into PF0 for the *right* side of the screen anytime after the left copy of PF0 has finished being displayed, but before the right copy starts being displayed. The timing for an asymmetrical copied playfield is less strict than the timing for an asymmetrical reflected (or mirrored) playfield, because if you're drawing an asymmetrical reflected playfield, then you *must* write the value for the right copy of PF2 during a very specific cycle of the scan line, since the left copy of PF2 and the right copy of PF2 are side-by-side on the screen (PF0, PF1, PF2, PF2, PF1, PF0). Note that batari Basic always draws a reflected playfield by default, even when drawing an asymmetrical playfield, because the PF0 register isn't used-- only the PF1 and PF2 registers are used.

 

What I want to do is every even frame point to a ROM playfield screen and every odd frame to a RAM playfield screen. I will need 88 bytes of the 128 bytes to do a 32 pixel wide(mirrored) x 44 pixels high.

You should be able to do that easily. On the even frames, you either use a "playfield:" command to define a new ROM playfield, or you modify the values of the lo-byte/hi-byte pointers for PF1 and PF2 so they point to the section of ROM where you've predefined the playfield data that you want to display. Then, on the odd frames, you modify the values of the PF1 and PF2 pointers so they point to wherever you're storing your RAM playfield. I'm not sure why you'd want to do that, but I guess it could be used for "buffering" the playfield, so that you can be modifying the RAM playfield while a ROM playfield is being displayed.

 

The real 64 bit question: Is it possible to have a non mirrorred playfield one frame and a mirrored the next in a multisprite kernal? I understand batari may not be able to do this but is this possible under asm?

I think supercat and batari have already answered this, but basically, you *can* do this if you create your own kernel, but *not* in batari Basic's "canned" multisprite kernel. And even if you write your own kernel to do this, the timing will have to be very carefully controlled.

 

By the way, if you write your own kernel, you can even mix a copied playfield and reflected playfield on the same screen, by changing bit 0 of the CTRLPF register from one scan line to the next. Note that I'm referring to *symmetrical* playfields, rather than asymmetrical playfields, and this is assuming that all three playfield registers are being used. For example, the Atari 2600 version of "Tutankham" does this to create the maze of passageways, as shown below:

 

 

Michael

[djmips]

In the cart I just did with SARA and bank switching, I also noticed that the r000-r127 and w000-w127 vars documented were missing but it wasn't a big problem because I prefer to define SARA variables as shown in the following code sample (to use an example I just posted in another discussion)

 

dim enemyXW			= $1000
dim enemyXR			= enemyXW + 128
dim enemyVelW		  = enemyXW  + 2
dim enemyVelR		  = enemyVelW + 128

 enemyXW[ii] = enemyXR[ii] + enemyVelR[ii]

 

So, I define the variables as relative to each other. It does take a little bit of care when you are allocating an array and you have to be careful with cut/paste errors but in the end, I prefer this because you can insert/delete variables more easily.

 

In something somewhat related, it would be nice if batari basic would use segments for zero page usage and ds statements for variables. I would like to more easily move stuff around. temp7 and playfieldpos var are inconveniently located between var47 and A. It would have been easier just to move them to after Z by cut/pasting them to the end.

 

The ram used by var0 - var47 may not be available in the multisprite kernel but that doesn't stop you from using them in dim statements. The code might not work but they are defined in 2600basic.h and are always defined.

[SeaGtGruff]

In the cart I just did with SARA and bank switching, I also noticed that the r000-r127 and w000-w127 vars documented were missing but it wasn't a big problem because I prefer to define SARA variables as shown in the following code sample (to use an example I just posted in another discussion)

That's right, as long as you don't try to use the w### and r### variables that I had defined in the superchip.h file (which was left out of bB v1.0), you can still define your own variables.

 

In something somewhat related, it would be nice if batari basic would use segments for zero page usage and ds statements for variables. I would like to more easily move stuff around. temp7 and playfieldpos var are inconveniently located between var47 and A. It would have been easier just to move them to after Z by cut/pasting them to the end.

That sounds like a good idea!

 

The ram used by var0 - var47 may not be available in the multisprite kernel but that doesn't stop you from using them in dim statements. The code might not work but they are defined in 2600basic.h and are always defined.

The 2600basic.h file isn't used with the multisprite kernel. The multisprite kernel uses the multisprite.h file instead of 2600basic.h, and the multisprite.h file doesn't define the var# variables, which is why the var# variable names will result in compile errors.

 

Michael

[Gorf]

LOL!...Pardon me guys will the smoke eminating from my brain clears. Wow....No I

seem to see now that these PF registers are the key to such a task and assembly is

the way to go. Is there any asm examples of this stuff anywhere?

[djmips]

I don't know that any game has gone to such lengths to combine a multi-sprite kernel and an assymetrical playfield. On the other hand, the beauty of the 2600 is that when you need such things and are willing to spend some code space for them, you can often do them.

 

Mega Man would like to have such a kernel.