Bankswitched Superchip in bB

[SeaGtGruff]

Good news! I finally figured out how to do a bankswitched Superchip-compatible program in bB, which means bB programmers should soon be able to use an extra 128 bytes of RAM in their games! It can be done by modifying a few include files as long as you're going to use 8K, but for 16K or 32K games it will ideally require a modification to the bB compiler itself.

 

Unfortunately, I get a strange display problem if I call drawscreen from bank 2, so I need to do a little more research to see if I can figure out what's causing that, and how to fix it. Then, once I get the details worked out better, I'll send the information to batari so he can see about incorporating it into the next version of bB.

 

Aside from being able to have an extra 128 bytes of RAM for variables, this could open up some very interesting possibilities. For example, one of the things that a few people have asked about is if it's possible to define a player's graphics data in sections, such as if the player shape will be mostly the same except for a few lines being different, could the "fixed" portion of the player shape be defined in one statement, and then could the "changeable" portion of the player shape be defined in another statement. You can't do that with the "player0" and "player1" statements, because of the way they work. But last year I posted a program (in the "Snaze" thread, I think) that wrote the player graphics data to zero-page RAM, and then set the player graphics pointer to look at that RAM area, and set the player's height indicator to tell bB how many lines of graphics data to use for the player-- which is cool, but it uses up valuable zero-page RAM. We could do the same sort of thing by writing the player data to the Superchip RAM area, and then pointing bB to where the data is. You won't be able to use the "player0" or "player1" statements to do that, because of the way they work, but you could use "data" statements to do it. That's one of the things I need to check out in detail (along with the display bug I mentioned) before I post examples and instructions.

 

Another possibility could be to move the RAM-based playfield into the Superchip area, which would free up more zero-page RAM, and should allow smaller playfield pixels for the modifiable version of the playfield. That's something else I'll have to tinker with to see how it goes.

 

Since Superchip RAM is available at CPUWIZ's store, that means bB programmers should be able to develop games using 8K Superchip, 16K Superchip, or 32K Superchip bankswitching, and produce actual cartridges for the games!

 

MR

[+batari]

Good news!

Agreed! Thanks for figuring this out. I've been too busy to participate in the forums lately, but I thought I should at least respond to this... Part of the reason I'm busy is that I have a vacation planned and need to get some things done before I leave next week.

Another possibility could be to move the RAM-based playfield into the Superchip area, which would free up more zero-page RAM, and should allow smaller playfield pixels for the modifiable version of the playfield. That's something else I'll have to tinker with to see how it goes.

This was the idea I had in my head for the first Superchip kernel. It wouldn't be too hard to modify the kernel and support routines to use the 128 bytes of the playfield instead of 48 bytes in normal RAM. There would be no timing issues in the kernel, but one would need to be mindful of the different read and write addresses in the support routines.

 

This would give a 32x32 playfield, which would be quite a bit more useful than the 12x32. Scrolling may be too slow, however, so maybe an unrolled scroll routine could be optionally included to speed things up.

 

The 48 extra bytes in 2600 RAM would be available for general variables. All that's needed here is picking a naming convention for these 48 extra variables, and sticking them in the header file.

 

Or, does anyone else have other ideas about what to do with a whopping 128 extra bytes?

[+atari2600land]

I want to congratulate Batari on reaching 1,500 posts.

 

Also, don't you need some sort of special expensive machine to make your own actual working cartridges?

[SeaGtGruff]

As far as what could be done with 128 bytes of extra RAM, moving the playfield there is a good idea, but I would prefer that it be something the user can select and control, since someone might want to use the Superchip RAM for something else, or might want to use part of it for the playfield, and part of it for other things.

 

Assuming we still use a two-line kernel, just PF1 and PF2 (no PF0), a programmable (RAM-based) asymmetrical playfield, with 4 bytes needed for each playfield row, and with the last 16 lines (or 8 double-lines) of the active video being used for the "score bar," there's no way to evenly divide the scan lines for 32 rows so that each row (other than the score bar) is the same height:

 

128 bytes / 4 bytes per playfield row = 32 playfield rows maximum (numbered 0 through 31)

32nd row (row 31) = score bar, 8 double-lines or 16 single-lines

total screen (NTSC standard) = 96 double-lines, or 192 single-lines

first 31 rows = 192 - 16 = 176 single-lines for the main screen area (i.e., excluding the score bar)

176 single-lines / 31 rows = 5.677 single-lines per row

round to nearest even number (because we use a double-line kernel) = 6 single-lines per row

176 lines / 6 lines = 29.3 playfield rows

 

Of course, we could still have 32 rows (31 plus the score bar) and use varying playfield heights, as long as the heights for the 31 rows add up to 88 double-lines. So we could have a constant that the user can set to specify the number of playfield rows (excluding the score bar), with valid values ranging from 1 to 31-- e.g., "set pfrows 24" to tell bB that the playfield will have 24 rows (plus 1 more row hidden behind the score bar, used for scrolling purposes), which is 4 * (24 + 1) = 100 bytes of RAM, leaving 28 bytes of RAM for other things (not to mention any RAM gained on page 0 by moving the playfield to Supercharger RAM). And then the programmer could use pfheight to set the heights of those 24 rows (any combination of values that add up to 88 double lines).

 

However, the Supercharger RAM could also be used to store the player graphics data, since having to store all of the player data in the last bank seems to be a limiting consideration with bankswitched bB games (since the kernel needs to be able to see the player data so it can load it as the screen is being drawn). The programmer would still need to define the player data in ROM, since you can't set the player RAM data unless you have ROM data to copy it from, but the ROM data could then be put in different banks, since once it's copied to the Supercharger RAM, the kernel will be able to see it (since the Supercharger RAM is visible to all banks). The only trick would be pointing bB to where the player data is in RAM, but that's simply a matter of setting the pointers and heights. For that matter, if moving the playfield to Supercharger RAM (or alternatively using a ROM-based playfield if there's no need to set or clear individual playfield pixels) would free up 48 bytes of page 0 RAM, then the player graphics data could be copied into page 0 RAM-- which would actually have the added benefit of being able to load the player data a little quicker (since LDA zero-page takes 1 less machine cycle than LDA absolute).

 

In any case, there are different ways that the Supercharger RAM-- and any page 0 RAM that gets freed up-- could be used in a program, so it would be good to have different options that could be selected from, or else the programmer could manage things manually if desired. It would be more tedious to manage things manually, but it would be more flexible to do that, assuming the person knows what he or she is doing.

 

On another note, it might be interesting to create a kernel that uses the same data bytes for different things, in those cases where different registers use different bits. For example, bit 0 has no function in the color registers, so bit 0 of the color values could be used for something else that requires only one bit-- e.g., the missile enable/disable, like this:

 

  LDA player0_color_table,X
  STA COLUP0
  ASL
  STA ENAM0

That might not be a good example, since the player0 color would only be loaded and used on lines where player0 is being drawn, hence it would limit missile0 to those lines-- but if a kernel were designed to read some value from a table and use it for each double-line on the screen, then it might be useful to double-up or combine multiple pieces of data into one byte like that. Of course, it would be quickest to combine bits that don't need to be shifted left or right before storing them, such as:

 

  LDA byte,X
  STA NUSIZ0; uses bits --54-210
  STA REFP0 ; uses bits ----3---

Obviously, doing something like that would be harder on the programmer, because he or she would need to combine the values manually and store them in a data table-- not to mention, I don't know how useful it would be to be able to reflect the player bits from one line to another, since you would need to set GRP0 anyway, so why bother with reflecting the GRP0 data on a line-by-line basis (unless maybe you were using the same GRP0 data to draw different copies of a player on different areas of the screen, and wanted one copy to be the reflected image of the other copy, or something of that nature), but maybe the same idea could be used with other registers. Anyway, that has nothing to with Superchip RAM and bankswitching, I was just rambling about other stuff.

 

MR

[SeaGtGruff]

Unfortunately, I get a strange display problem if I call drawscreen from bank 2, so I need to do a little more research to see if I can figure out what's causing that, and how to fix it.

I figured out what was causing the bug when I tried to move my display loop into bank 2. It was something really simple!

 

Then, once I get the details worked out better, I'll send the information to batari so he can see about incorporating it into the next version of bB.

Tomorrow night I'll post instructions on how to modify the include files, and what needs to be done in the bB program, so that anyone who's interested can start playing around with creating Superchip bankswitched games in bB. Keep in mind that this requires bB version 0.99, since bankswitching isn't supported in the pre-0.99 versions (unless you count the unofficial modifications I posted last year for adding M-Network bankswitching in bB version 0.35).

 

I'll also send detailed information to batari, but keep in mind that whenever he adds Superchip support to 0.99, it's liable to work a little differently than my description, as far as the programming rules are concerned, since the changes I've made are essentially just a hack of bB, and the official version will undoubtedly be much better integrated into bB.

 

Right now I have to call it a night.

 

MR

[+batari]

As far as what could be done with 128 bytes of extra RAM, moving the playfield there is a good idea, but I would prefer that it be something the user can select and control, since someone might want to use the Superchip RAM for something else, or might want to use part of it for the playfield, and part of it for other things.

The Superchip RAM-playfield will not be etched in stone. There won't be anything limiting one from using Superchip for something else, and future kernels may take advantage of the RAM in another way. My plan for the first use of Superchip was actually use the standard kernel! I can do so with no real changes to the kernel - just remapping the "playfield" label into Superchip space, changing the index pointer to playfield RAM to optionally count by twos instead of four (trivial) and possibly modify the support routines.

 

I'll have to take a look at some of those other ideas for other kernels (or kernel options in the standard kernel.)

Assuming we still use a two-line kernel, just PF1 and PF2 (no PF0), a programmable (RAM-based) asymmetrical playfield, with 4 bytes needed for each playfield row, and with the last 16 lines (or 8 double-lines) of the active video being used for the "score bar," there's no way to evenly divide the scan lines for 32 rows so that each row (other than the score bar) is the same height:

Ahhh... that's correct, of course. 24 lines would be a good compromise. Then, there is the question of what to do with the extra 32 bytes...

 

I'll have to think of this more when I get back from vacation.

Edited September 9, 2006 by batari

[SeaGtGruff]

Assuming we still use a two-line kernel, just PF1 and PF2 (no PF0), a programmable (RAM-based) asymmetrical playfield, with 4 bytes needed for each playfield row, and with the last 16 lines (or 8 double-lines) of the active video being used for the "score bar," there's no way to evenly divide the scan lines for 32 rows so that each row (other than the score bar) is the same height:

Ahhh... that's correct, of course. 24 lines would be a good compromise. Then, there is the question of what to do with the extra 32 bytes...

You can't evenly distribute 24 lines (i.e., have all 24 lines be the same height) across a total of 176 scan lines (or 88 double-lines). I was just picking that number at random as an example of using a "set pfrows xxx" command where the value of pfrows can be specified by the user. If you want to have a predetermined number of lines, and have bB default to where all lines are equal in height (i.e., unless the user is specifying the pfheights option), then the maximum number of lines you can fit into 128 bytes of RAM is 22, with each line being 4 double-lines tall, or exactly half as tall as the current pf pixels. That would leave 40 bytes of Superchip RAM free for other things-- quite a bit for user purposes, since it's almost double the number of zero-page user variables (a to z).

 

But I still like the idea of the user being able to set the number of pfrows, in case they want to use more than 40 bytes of the Superchip RAM for something else. I haven't looked at the kernel and the pf drawing or pf scrolling routines yet with this in mind, but I would think that it might not be too hard to replace any references to the current max lines (presumably #12) with a variable ($??, where $?? is the zero-page address of a new bB "system variable" called "pfrows").

 

As far as dividing the screen (176 scan lines) into evenly-spaced pf lines, the possibilities are as follows (assuming a double-line kernel, and ignoring RAM limits):

 

88 pf lines, 1 double-line tall (176 bytes for standard pf, or 352 for asymmetrical pf)

44 pf lines, 2 double-lines tall (88 bytes for standard pf, or 176 for asymmetrical pf)

22 pf lines, 4 double-lines tall (44 bytes for standard pf, or 88 for asymmetrical pf)

11 pf lines, 8 double-lines tall (22 bytes for standard pf, or 44 for asymmetrical pf)

8 pf lines, 11 double-lines tall (16 bytes for standard pf, or 32 for asymmetrical pf)

4 pf lines, 22 double-lines tall (8 bytes for standard pf, or 16 for asymmetrical pf)

2 pf lines, 44 double-lines tall (4 bytes for standard pf, or 8 for asymmetrical pf)

1 pf line, 88 double-lines tall (2 bytes for standard pf, or 4 for asymmetrical pf)

 

Any other combinations would require a different number of scan lines, or removing the score bar to get all 192 scan lines-- or pf lines that are variable in height, as long as they all add up to a height of 88 double-lines.

 

As far as those other kernel ideas I'd mentioned, I was mostly brain-farting out loud, because I don't think they would be very useful. On the other hand, I wonder if letting the user specify whether the pf should be asymmetrical or not would be useful, because if you aren't going to have to reload the pf registers in lid-line to get an asymmetrical pf, then there ought to be time enough to load all 3 pf registers and get 40 columns instead of only 32 (with the pf being either mirrored or duplicated).

 

MR

[MausBoy]

22x32 would be fantastic, especially if no_blank_lines was still an option. Double the variables would be fantastic. pf-tables and player tables in every bank too.

 

With a resolution like that, software sprites would be a real possibility, and with the extra ram, combinations of features that were limited to one or the other before.

 

I really can't wait, with just what has been described in this thread, a full featured rpg would be totally possible in bB. Not to mention all the limitations holding me back in most of my projects would be gone forever.

[jrok]

The 48 extra bytes in 2600 RAM would be available for general variables. All that's needed here is picking a naming convention for these 48 extra variables, and sticking them in the header file.

 

I think I am a little confused about the way superchip memory is managed, particularly when it comes to the naming convention used and RAM playfield data storage. For a long while now, I've been working under the assumption that var0-var47 were the named variables representing all the memory available after the 32x24 playfield was stored in SARA RAM. But then this morning I read this:

 

24 lines would be a good compromise. Then, there is the question of what to do with the extra 32 bytes...

 

Which are the read and write addresses that this extra 32 bytes of memory correspond to? I noticed that the values defined in the superchip header seem to all be accessible, but I'm not sure how they correspond to the named variables 0-47, or to the RAM playfield. When I experimented with some of the named variables (w000-127, r000-127) I've yet to find a conflicts with the named vars 0-47. Is there a superchip memory map that illustrates the differences between var0-47, w/r000-127, and the RAM superchip playfield? Sorry if this is a dumb question, but I just can't seem to figure it out, and am afraid I'm not even thinking about it in the correct way.

 

Thanks in advance,

Jarod.

Edited December 1, 2009 by jrok

[RevEng]

While we're waiting for an authoritative response, I'll share what I know from delving into 2600basic.h and the kernel asm's.

 

The bB kernel doesn't use the r000/w000 or var0 variables at all for its playfield drawing. They always point to the same place.

 

The "playfield" pointer the kernel uses varies its position based on the use of pfres and use of superchip ram...

 

ifconst superchip
playfieldbase = $10D0
else
playfieldbase = $A4
endif

; define playfield start based on height
ifnconst pfres
playfield = playfieldbase
else
playfield = playfieldbase-(pfres-12)*4
endif

 

When I wrote the parallax scroll demo, I found it easier just to access things based on "playfield".

 

[edit] if you're wanting to access them in bB code, and not inline asm like my demo, you might have an issue: I expect playfield is a reserved keyword. You'll probably have to define some other variable to the same thing in 2600basic.h and use it instead [/edit]

Edited December 1, 2009 by RevEng

[jrok]

While we're waiting for an authoritative response, I'll share what I know from delving into 2600basic.h and the kernel asm's.

 

The bB kernel doesn't use the r000/w000 or var0 variables at all for its playfield drawing. They always point to the same place.

 

The "playfield" pointer the kernel uses varies its position based on the use of pfres and use of superchip ram...

 

ifconst superchip
playfieldbase = $10D0
else
playfieldbase = $A4
endif

; define playfield start based on height
ifnconst pfres
playfield = playfieldbase
else
playfield = playfieldbase-(pfres-12)*4
endif

 

When I wrote the parallax scroll demo, I found it easier just to access things based on "playfield".

 

[edit] if you're wanting to access them in bB code, and not inline asm like my demo, you might have an issue: I expect playfield is a reserved keyword. You'll probably have to define some other variable to the same thing in 2600basic.h and use it instead [/edit]

 

Thanks for that, RevEng. I guess I'm mainly fuzzy on the difference between the redefs in "2600basic_SC.h" and "superchip.h". They appear to be using different memory locations, and vars 0-47 don't appear to use superchip memory locations at all. Is that because those named vars are replacing ones formally used to store the playfield in the standard kernel? I suppose the big question I really have is this: In the version of the standard kernal modified for the superchip, are named variables var0-47 and w/r000-127 all free for use by default, and what (if anything) limits their usage (other than the obvious read versus write restrictions of the latter)?

Edited December 1, 2009 by jrok

[RevEng]

Thanks for that, RevEng. I guess I'm mainly fuzzy on the difference between the redefs in "2600basic_SC.h" and "superchip.h". They appear to be using different memory locations, and vars 0-47 don't appear to use superchip memory locations at all. Is that because those named vars are replacing ones formally used to store the playfield in the standard kernel?

Interesting - I don't have a s600basic_SC.h. Perhaps that's cruft from an old upgraded version? In my includes dir, r/wXXX and varXX are only defined in one place each.

 

The way I understand it: The var0-47 and w/r000-127 are just convenient ways for you to access that memory from within bB. The kernel doesn't use those vars, nor do they ever change location. If you want to reuse them, it's up to you to make sure you're not overwriting the actual playfield memory the kernel is using. If you have superchip defined, then the playfield is going to be somewhere in the rXXX/wXXX vars. If you don't, it's going to use the varXX vars.

[jrok]

The way I understand it: The var0-47 and w/r000-127 are just convenient ways for you to access that memory from within bB. The kernel doesn't use those vars, nor do they ever change location.

 

Yes, that's my understanding too.

 

If you want to reuse them, it's up to you to make sure you're not overwriting the actual playfield memory the kernel is using. If you have superchip defined, then the playfield is going to be somewhere in the rXXX/wXXX vars. If you don't, it's going to use the varXX vars.

 

That's also what I assumed. But I am currently using a 32x24 playfield in my project, and when I've tried to write to the playfield using *any* of the wXXX vars, nothing happens. There aren't any "pfclears" or anything else taking place before the drawscreen, either.

[RevEng]

Try adding an "include superchip.h" to the top of the source, and of course make sure the romsize has "SC" on the end. Not sure if that's it, but it couldn't hurt.

 

I experienced something similar when I wrote the demo... I think the include fixed it.

 

Unfortunately I've since cleaned and reinstalled my bB, and I can't seem to replicate it. including or not including works equally well. You may want to try cleaning up as well.

 

FWIW, if I add a "w000=$ff" just after the playfield definition in my demo, I *do* get a bar right where you'd expect it, in the top left corner.

[SeaGtGruff]

The 48 extra bytes in 2600 RAM would be available for general variables. All that's needed here is picking a naming convention for these 48 extra variables, and sticking them in the header file.

 

I think I am a little confused about the way superchip memory is managed, particularly when it comes to the naming convention used and RAM playfield data storage. For a long while now, I've been working under the assumption that var0-var47 were the named variables representing all the memory available after the 32x24 playfield was stored in SARA RAM.

They are, but you're thinking "backwards" here. The variables named var0 through var47 aren't located in the Superchip RAM area; they're located in the RIOT ("page zero") RAM area. In a non-Superchip bB game that uses the standard kernel, those 48 bytes of RIOT RAM are used to store the playfield-- 12 rows of playfield pixels, at 4 bytes per row. But in a Superchip bB game, the playfield is moved into the Superchip RAM area, which makes those 48 bytes of RIOT RAM freely available, since they no longer need to be used to store the playfield.

 

But then this morning I read this:

 

24 lines would be a good compromise. Then, there is the question of what to do with the extra 32 bytes...

 

Which are the read and write addresses that this extra 32 bytes of memory correspond to? I noticed that the values defined in the superchip header seem to all be accessible, but I'm not sure how they correspond to the named variables 0-47, or to the RAM playfield. When I experimented with some of the named variables (w000-127, r000-127) I've yet to find a conflicts with the named vars 0-47. Is there a superchip memory map that illustrates the differences between var0-47, w/r000-127, and the RAM superchip playfield? Sorry if this is a dumb question, but I just can't seem to figure it out, and am afraid I'm not even thinking about it in the correct way.

 

Thanks in advance,

Jarod.

I might have it upside-down, but I think the playfield is stored "first" in the Superchip RAM area, so any bytes of Superchip RAM not used by the playfield would come after the playfield. Thus, if you're using a playfield with 24 rows, that would be 24 * 4 = 96 bytes, leaving the remaining 32 bytes free for other things. They could be referenced by r096 through r127 for reading, and w096 through w127 for writing. (Or else it's the other way around, with the playfield coming last, and any extra bytes coming first, so the extra 32 bytes would be r000 through r031 and w000 through w031.)

 

So you'd have the normal 26 variables named a through z, plus 48 more variables named var0 through var47, all in the "page zero" RIOT RAM area, as well as 32 additional variables in the Superchip RAM area.

 

Michael

[jrok]

The 48 extra bytes in 2600 RAM would be available for general variables. All that's needed here is picking a naming convention for these 48 extra variables, and sticking them in the header file.

 

I think I am a little confused about the way superchip memory is managed, particularly when it comes to the naming convention used and RAM playfield data storage. For a long while now, I've been working under the assumption that var0-var47 were the named variables representing all the memory available after the 32x24 playfield was stored in SARA RAM.

They are, but you're thinking "backwards" here. The variables named var0 through var47 aren't located in the Superchip RAM area; they're located in the RIOT ("page zero") RAM area. In a non-Superchip bB game that uses the standard kernel, those 48 bytes of RIOT RAM are used to store the playfield-- 12 rows of playfield pixels, at 4 bytes per row. But in a Superchip bB game, the playfield is moved into the Superchip RAM area, which makes those 48 bytes of RIOT RAM freely available, since they no longer need to be used to store the playfield.

 

But then this morning I read this:

 

24 lines would be a good compromise. Then, there is the question of what to do with the extra 32 bytes...

 

Which are the read and write addresses that this extra 32 bytes of memory correspond to? I noticed that the values defined in the superchip header seem to all be accessible, but I'm not sure how they correspond to the named variables 0-47, or to the RAM playfield. When I experimented with some of the named variables (w000-127, r000-127) I've yet to find a conflicts with the named vars 0-47. Is there a superchip memory map that illustrates the differences between var0-47, w/r000-127, and the RAM superchip playfield? Sorry if this is a dumb question, but I just can't seem to figure it out, and am afraid I'm not even thinking about it in the correct way.

 

Thanks in advance,

Jarod.

I might have it upside-down, but I think the playfield is stored "first" in the Superchip RAM area, so any bytes of Superchip RAM not used by the playfield would come after the playfield. Thus, if you're using a playfield with 24 rows, that would be 24 * 4 = 96 bytes, leaving the remaining 32 bytes free for other things. They could be referenced by r096 through r127 for reading, and w096 through w127 for writing. (Or else it's the other way around, with the playfield coming last, and any extra bytes coming first, so the extra 32 bytes would be r000 through r031 and w000 through w031.)

 

So you'd have the normal 26 variables named a through z, plus 48 more variables named var0 through var47, all in the "page zero" RIOT RAM area, as well as 32 additional variables in the Superchip RAM area.

 

Michael

 

 

Ahhh... It all makes perfect sense, now.

 

Thanks Michael!

[jrok]

I might have it upside-down, but I think the playfield is stored "first" in the Superchip RAM area, so any bytes of Superchip RAM not used by the playfield would come after the playfield. Thus, if you're using a playfield with 24 rows, that would be 24 * 4 = 96 bytes, leaving the remaining 32 bytes free for other things. They could be referenced by r096 through r127 for reading, and w096 through w127 for writing. (Or else it's the other way around, with the playfield coming last, and any extra bytes coming first, so the extra 32 bytes would be r000 through r031 and w000 through w031.)

 

So you'd have the normal 26 variables named a through z, plus 48 more variables named var0 through var47, all in the "page zero" RIOT RAM area, as well as 32 additional variables in the Superchip RAM area.

 

Michael

 

From a few experiments I ran, it seems as though the playfield is stored last in the Superchip RAM, meaning the "first" 32 bytes are free for use.

 

One question I have, if you have the time. In one project I'm working on, I'm using the zero page RAM to store the color table for player 1:

 

  dim p1color = a
 dim p1color_row1 = a 
 dim p1color_row2 = b
 dim p1color_row3 = c
 dim p1color_row4 = d
 dim p1color_row5 = e
 dim p1color_row6 = f
 dim p1color_row7 = g
 dim p1color_row8 = h
 dim p1color_row9 = i
 dim p1color_row10 = j
 dim p1color_row11 = k
 dim p1color_row12 = l
 dim p1color_row13 = m
 dim p1color_row14 = n
 dim p1color_row15 = o
 dim p1color_row16 = p

  asm
  LDA #<p1color
  STA player1color

  LDA #>p1color
  STA player1color+1
end

 

I'd prefer to keep this RAM available for other things, namely fixed point math. Do you think it would it be possible to store these colors in Superchip RAM (with the usual limitations of read and write access)?

 

Thanks again,

Jarod.

[SeaGtGruff]

One question I have, if you have the time. In one project I'm working on, I'm using the zero page RAM to store the color table for player 1:

 

  dim p1color = a
 dim p1color_row1 = a 
 dim p1color_row2 = b
 dim p1color_row3 = c
 dim p1color_row4 = d
 dim p1color_row5 = e
 dim p1color_row6 = f
 dim p1color_row7 = g
 dim p1color_row8 = h
 dim p1color_row9 = i
 dim p1color_row10 = j
 dim p1color_row11 = k
 dim p1color_row12 = l
 dim p1color_row13 = m
 dim p1color_row14 = n
 dim p1color_row15 = o
 dim p1color_row16 = p

  asm
  LDA #<p1color
  STA player1color

  LDA #>p1color
  STA player1color+1
end

 

I'd prefer to keep this RAM available for other things, namely fixed point math. Do you think it would it be possible to store these colors in Superchip RAM (with the usual limitations of read and write access)?

I think you practically answered your own question. With a question of that nature-- "Can I move 'Variable X' from zero-page RAM to Superchip RAM?", or "Can I move the 'Such-and-Such Table' from ROM to RAM?"-- I see the biggest factor as being what kind of addressing mode is being used by the kernel when reading the data from 'Variable X' or the 'Such-and-Such Table.'

 

Data tables that are normally compiled to ROM and read from there can (most likely) always be moved to RAM-- either to zero-page RAM or Superchip RAM-- since you could always write a zero-page address as an absolute two-byte lo/hi address, or (if it uses zero page pointers) set the zero-page lo/hi pointers to the zero-page address where you've stored the table. That's what you're doing above-- setting the pointers so they point to the zero-page starting address of the table. So you could easily move that table to Superchip RAM, as long as you use the write addresses to store data in the table, and then set the pointers to the read addresses so the kernel will read the data from the correct area.

 

The other situation-- moving a variable that's normally in zero-page RAM into the Superchip RAM-- is a different matter, because if the kernel expects it to be in page zero, moving it to a two-byte address might mess up the kernel's timing.

 

Michael

[jrok]

One question I have, if you have the time. In one project I'm working on, I'm using the zero page RAM to store the color table for player 1:

 

  dim p1color = a
 dim p1color_row1 = a 
 dim p1color_row2 = b
 dim p1color_row3 = c
 dim p1color_row4 = d
 dim p1color_row5 = e
 dim p1color_row6 = f
 dim p1color_row7 = g
 dim p1color_row8 = h
 dim p1color_row9 = i
 dim p1color_row10 = j
 dim p1color_row11 = k
 dim p1color_row12 = l
 dim p1color_row13 = m
 dim p1color_row14 = n
 dim p1color_row15 = o
 dim p1color_row16 = p

  asm
  LDA #<p1color
  STA player1color

  LDA #>p1color
  STA player1color+1
end

 

I'd prefer to keep this RAM available for other things, namely fixed point math. Do you think it would it be possible to store these colors in Superchip RAM (with the usual limitations of read and write access)?

I think you practically answered your own question. With a question of that nature-- "Can I move 'Variable X' from zero-page RAM to Superchip RAM?", or "Can I move the 'Such-and-Such Table' from ROM to RAM?"-- I see the biggest factor as being what kind of addressing mode is being used by the kernel when reading the data from 'Variable X' or the 'Such-and-Such Table.'

 

Data tables that are normally compiled to ROM and read from there can (most likely) always be moved to RAM-- either to zero-page RAM or Superchip RAM-- since you could always write a zero-page address as an absolute two-byte lo/hi address, or (if it uses zero page pointers) set the zero-page lo/hi pointers to the zero-page address where you've stored the table. That's what you're doing above-- setting the pointers so they point to the zero-page starting address of the table. So you could easily move that table to Superchip RAM, as long as you use the write addresses to store data in the table, and then set the pointers to the read addresses so the kernel will read the data from the correct area.

 

The other situation-- moving a variable that's normally in zero-page RAM into the Superchip RAM-- is a different matter, because if the kernel expects it to be in page zero, moving it to a two-byte address might mess up the kernel's timing.

 

Michael

 

Ah, I see. I feel a little dumb for asking now, actually. So basically it would be:

 

 dim p1color = w000
dim p1color_row1 = w000
dim p1color_row2 = w001
dim p1color_row3 = w002
dim p1color_row4 = w003
dim p1color_row5 = w004
dim p1color_row6 = w005
dim p1color_row7 = w006
dim p1color_row8 = w007
dim p1color_row9 = w008
dim p1color_row10 = w009
dim p1color_row11 = w010
dim p1color_row12 = w011
dim p1color_row13 = w012
dim p1color_row14 = w013
dim p1color_row15 = w014
dim p1color_row16 = w015

dim p1colorR = r000
dim p1colorR_row1 = r000
dim p1colorR_row2 = r001
dim p1colorR_row3 = r002
dim p1colorR_row4 = r003
dim p1colorR_row5 = r004
dim p1colorR_row6 = r005
dim p1colorR_row7 = r006
dim p1colorR_row8 = r007
dim p1colorR_row9 = r008
dim p1colorR_row10 = r009
dim p1colorR_row11 = r010
dim p1colorR_row12 = r011
dim p1colorR_row13 = r012
dim p1colorR_row14 = r013
dim p1colorR_row15 = r014
dim p1colorR_row16 = r015

  asm
  LDA #<p1colorR
  STA player1color

  LDA #>p1colorR
  STA player1color+1
end

 

Thanks again!

 

Jarod.

[SeaGtGruff]

Ah, I see. I feel a little dumb for asking now, actually.

No need for that! Sometimes you're so close to the problem/question that you can't see the solution/answer. (And boy oh boy, don't I know *that*!) If you would step back and look at the situation from not-so-close-up, sometimes an answer becomes obvious.

 

"Dang, I've been trying for hours and hours, but I just can't seem to walk through this stinking wall!"

 

<Finally gives up and starts to walk away.>

 

"Oh, wait a minute, how long has that doorway been over there to the right?"

 

Michael