Jump to content
IGNORED

pfcolors and pfheights together-- in RAM!


SeaGtGruff

Recommended Posts

Okay, I finally figured out what I needed to do to be able to change the pfcolors and/or pfheights while using both options together.

 

To summarize the issue, bB has a pfcolors option that lets you change the playfield color from row to row, as well as a pfheights option that lets you change the playfield pixel height from row to row. As long as you aren't using both options together, you can change the pfcolors or pfheights from frame to frame. But if you use both options together, you *cannot* change the pfcolors and/or pfheights from frame to frame-- you can define them once, and then you're stuck with those values for the rest of your program.

 

The reason for this is because when you use one option without the other, bB uses a 2-byte pointer to point to the desired table in ROM, and each time you execute another pfcolors or pfheights statement, bB updates that pointer to point to the new pfcolors or pfheights table. But there's really only room in RAM for one pointer, not both at the same time-- unless perhaps the "lives" option isn't being used, since it uses a 2-byte pointer that comes right after the 2-byte pfcolortable or pfheighttable pointer. But even if two pointers were used, I don't think there's enough time during the kernel to load the table values using both pointers, due to the addressing mode used. If that's the real problem (as I suspect), then even using just one pointer to the combined playfieldcolorandheight table won't work. So to work within the timing constraints, bB must use an absolute-indexed address mode to read the combined playfieldcolorandheights table-- and unless you're executing modifiable code that's stored in RAM, you can't change the value of that absolute address once your program is compiled.

 

One solution might be to tighten-up the kernel's timing and RAM usage-- possibly requiring us to give up a feature or two-- so there's enough time to read the table using two pointers. But another solution is to copy the combined playfieldcolorandheight table into RAM, and then use the absolute-indexed mode to read the table from the fixed address in RAM, just as if it were at a fixed address in ROM. Then we can change the individual pfcolors and/or pfheights values in the RAM table.

 

There's only one problem with the second solution (which is the one I've used)-- since there isn't enough room in RAM to store the combined playfieldcolorandheight table (let alone either table by itself), we need to use the Superchip option, which means we have to use a romsize of 8kSC, 16kSC, or 32kSC; we can't use this solution with a romsize of 2k, 4k, 8k, 16k, or 32k. That's actually a very small price to pay, so it really isn't a problem-- unless the available supply of Superchips dries up.

 

I've created four custom include files for this solution, as follows:

 

bankswitch_SC.inc -- This is a modification of bankswitch.inc, which lists the include files that bB compiles with when bankswitching is used with the standard kernel. This version has two changes from the original bankswitch.inc file: (1) it uses superchipheader_SC.asm instead of 2600basicheader.asm; and (2) it uses std_kernel_SC.asm instead of std_kernel.asm.

 

superchipheader_SC.asm -- This is a modification of superchipheader.asm, which defines the processor that DASM should assemble for; lists the header files which define the various equates for the TIA, RIOT, and RAM addresses, as well as any equates that are defined by the bB program; includes the various macro routines; sets the beginning address for the assembled ROM image; and reserves the first 256 bytes of the ROM image for the 128 bytes of Superchip RAM. This version has two changes from the original superchipheader.asm file: (1) it includes the superchip.h file that was accidentally left out of bB v1.0; and (2) it uses 2600basic_SC.h instead of 2600basic.h.

 

2600basic_SC.h -- This is a modification of 2600basic.h, which defines the RAM addresses that bB uses for its "system variables' and "user variables," as well as a special RETURN macro that is used to return from a subroutine regardless of which bank it was called from. This version has two changes from the original 2600basic.h file: (1) the extra processor and include lines have been deleted, since they're redundant (they're already listed elsewhere, and listing them again just causes them to be included multiple times within a DASM listing file); and (2) if the RAM_PFcolorandheight constant is found while the program is being assembled, the 48 bytes of RAM where the playfield normally resides (when the Superchip option is not being used) will be defined as a RAMplayfieldcolorandheight table, including some special variable names for changing the color or height of each pfrow.

 

std_kernel_SC.asm -- This is a modification of std_kernel.asm, which is the bulk of bB's standard display kernel. (The standard overscan is in a file of its own.) This version has only one change from the original std_kernel.asm file: if the RAM_PFcolorandheight constant is found while the program is being assembled, the height and color values are read from the RAMplayfieldcolorandheight table instead of the ROM-resident playfieldcolorandheight table.

 

To use this customization, you first need to download and unzip the attachment, and move the enclosed files into the folder where all of your other bB include files are located. In addition to the four modified diles (described above), I included the superchip.h file that got left out of bB v1.0.

 

Next, you'll need to place the following lines at the beginning of your bB program:

 

   includesfile bankswitch_SC.inc
  set romsize 8kSC
  set kernel_options pfcolors pfheights
  const RAM_PFcolorandheight = 1

 

Obviously, you can change the romsize to 16kSC or 32kSC if you want, and you can use additional kernel_options.

 

Somewhere in your program, *after* you've performed the pfheights and pfcolors statements, you must copy the ROM-resident playfieldcolorandheight table into RAM. The code to do this must be placed in the last bank, since that's where bB puts the ROM-resident playfieldcolorandheight table. In my sample program, I use the following code to do the copy:

 

   rem * This should be performed after pfheights and pfcolors have
  rem * been defined, but it can be placed in any bank.

  a = 0 : gosub copy_to_RAM bank2

  rem * You can use some other variable besides a, including one of
  rem * the temp variables, but you must set it to 0 before you call
  rem * the subroutine.

  rem * You can also use a different subroutine name, but your
  rem * subroutine must be placed in the last bank.

 

   rem * This is the subroutine, which must be in the last bank.

  bank 2

  rem * If you're using a different variable than a, don't forget to
  rem * change it in the subroutine.

  rem * RAMplayfieldcolorandheight and playfieldcolorandheight must
  rem * not be changed, unless you've used a dim statement to assign
  rem * other names to them.

copy_to_RAM

  RAMplayfieldcolorandheight[a] = playfieldcolorandheight[a]

  a = a + 1
  if a <> 40 then copy_to_RAM

  return otherbank

 

By the way, there are three things I'd like to mention about using the pfcolors and pfheights options, which have nothing to do with this modification per se:

 

(1) bB doesn't actually store the first pfcolors or pfheights value in the table when it compiles your program. Instead, it puts them in the program wherever the pfcolors or pfheights statement is located. This has two consequences: (A) If you don't perform the pfcolors statement in your display loop, then the color of your first pfrow won't get set properly, and the top row will just be the same color as the bottom row (which isn't a problem if you'd wanted them to be the same color, anyway). You can fix this either by putting the pfcolors statement inside your display loop, or by setting COLUPF inside your display loop-- or by using a goto or gosub to branch to wherever the pfcolors statement is, and then goto or return back into your display loop. And (B) since the first pfcolors value isn't stored in the table, it follows that it won't get copied into our RAMplayfieldcolorandheight table, so there's no special variable for changing the color of the first pfrow; you'll just have to set COLUPF to do that.

 

(2) Although you can change the heights of the other pfrows, the first pfrow must always have a height of 8, because any other value will mess up the display, causing the screen to roll like crazy. I would classify this as a bug in bB, and hopefully it will be fixed eventually.

 

(3) When you use the pfcolors and pfheights options together, you must give the pfheights statement before you give the pfcolors statement, otherwise you'll get a compile error.

 

When you're using this modification, you can use some special variable names to change the color or height of any pfrow on the fly, with the exception of the first pfrow. The new variables are as follows:

 

pfrow1height through pfrow10height -- These ten variables let you change the height of pfrow 1 through pfrow 10, respectively.

 

pfrow1color through pfrow10color -- These ten variables let you change the color of pfrow 1 through pfrow 10, respectively.

 

Note that these variables can't be indexed very simply, even though they're in a table, due to the way the table is arranged:

 

pfrow 1 -- height, color, dummy, dummy

pfrow 2 -- height, color, dummy, dummy

pfrow 3 -- height, color, dummy, dummy

etc.

 

This is the arrangement that bB uses, so we can't do anything about it without major changes to the kernel and compiler. If you want to use the new variables with an index, you'll need to calculate the correct value to use for the index, as follows:

 

index = 4 * pfrow_number - 4

pfrow1height[index] = desired_height

pfrow1color[index] = desired_color

 

For example, if you want to change the height and color for pfrow 5, then index would have to be 16 (4 * 5 - 4 = 20 - 4 = 16):

 

pfrow1height[16] = desired_height

pfrow1color[16] = desired_color

 

Obviously, it's easier to just use the correct variable name for the desired pfrow, especially if you want to change just one pfrow. But if you want to change all of the heights and colors in a loop-- such as if you're getting ready to draw a new screen, and you have the heights and colors for the new screen defined in a data table-- then you could use a loop like the following:

 

display_loop
  if changing_screens then gosub new_screen
  drawscreen
  goto display_loop

new_screen
  index1 = 0 : rem * This index is for the RAM table.
  index2 = 11 * screen_number - 11 : rem * For the data tables.
new_screen_loop
  pfrow1height[index1] = new_screen_height[index2]
  pfrow1color[index1] = new_screen_color[index2]
  index1 = index1 + 4 : rem * Be sure to add 4 to the RAM index!
  index2 = index2 + 1 : rem * But add 1 to the data index.
  if index1 <> 40 then new_screen_loop
  COLUPF = new_screen_color[index2]
  return

  data new_screen_height
  8,8,8,8,8,8,8,8,8,8,8
  1,2,3,4,5,11,12,13,14,15,8
  15,13,11,10,9,7,6,5,3,1,8
end

  data new_screen_color
  $12,$22,$32,$42,$52,$62,$72,$82,$92,$A2,$02
  $12,$14,$16,$18,$1A,$1C,$1E,$2E,$2C,$2A,$10
  $22,$44,$66,$88,$AA,$CC,$EE,$12,$24,$36,$00
end

 

In the example above, each row of data corresponds to one screen, so each row of data should have 10 values (for pfrow 1 through pfrow 10). But I added an 11th color value on the end of each row, which I used for setting COLUPF after all of the pfrows had been set (because the color for pfrow 0 isn't stored in the table, but we can set it by setting COLUPF). The reason I put it at the end (instead of at the beginning) is so I can go ahead and set the RAM table values in the loop, and then set COLUPF after the loop is finished. As mentioned previously, the height of pfrow 0 can't be changed-- it must always be set to 8-- but I had to tack on an extra value at the end of each row of pfheights data, so the data in the table could be properly indexed by the index2 variable. If I had left off the 11th color value (for pfrow 0), then I would have used index2 = 10 * screen_number - 10, and each row of the two tables would contain only 10 values.

 

There's one last thing you should know about using this modification. When using the Superchip option, the playfield is automatically moved into Superchip RAM, which normally frees up an additional 48 user variables (var0 through var47). However, since this modification puts the RAMplayfieldcolorandheight table in that spot, and the table is 40 bytes long, some of those extra user variables are no longer available. Fortunately, since each row of the table is padded with 2 dummy bytes, only 20 bytes are actually needed for the table. Consequently, the remaining 28 bytes are defined as 28 extra user variables (var0 through var27), some of which are inside the table (where the dummy bytes are), and some of which come after the table. So if you use this option to put the color and height table into RAM, var28 through var47 will no longer be available.

 

My example program is rather dumb and simple, because I wrote it while I was still trying to get this modification working. :)

 

Michael

std_kernel_SC.zip

test_pfcolors_with_pfheights_SC.bas

test_pfcolors_with_pfheights_SC.bas.bin

Edited by SeaGtGruff
  • Like 1
Link to comment
Share on other sites

Very cool, Michael! :cool: Thank you!... this is exactly what I need for my latest project!

 

I wonder if the data could also be put in the extra 2k space for the supercharger (assuming you have a 4K game)... hmmm...

 

How hard is it to get a superchip cartridge made, I wonder?... that question is for a different forum, I guess...

 

Thank you again! :)

 

Mike

Edited by lord_mike
Link to comment
Share on other sites

The biggest obstacle preventing me from implementing pfcolors and pfheights together, without Superchip RAM and without both being fixed is cycles. At the bare minimum, and without going into a long technical explanation (unless you really want me to) I'd need 3 more cycles to do so, which aren't there (and believe me, I've looked.)

 

Doing a kernel rewrite might get the cycles, but doing so has other implications that could "break" current code (aside from it being a lot of work for me :)

Link to comment
Share on other sites

Very cool, Michael! :cool: Thank you!... this is exactly what I need for my latest project!

I'm glad it will be useful. :) Several people had expressed a desire for this enhancement-- MausBoy for one, if I remember correctly-- and I looked into it a while back, but couldn't get it to work. I think I was trying to copy the PF height/color table into Superchip RAM at that time, although I don't think that would have made a difference, as long as the Superchip playfield RAM and Superchip PF height/color table didn't overlap each other. When I was trying it again in zero-page RAM, it took me a few days to finally figure out what I was doing wrong *this* time. The absolute,X address mode takes 4+ cycles, and takes 3 bytes. I could have just used the zeropage,X address mode, which takes 4 cycles, since the ROM table is positioned to avoid page-wrapping, hence the absolute,X addressing will always take only 4 cycles, so the timing would still be exactly the same if using the zeropage,X addressing. But the zeropage,X addressing takes only 2 bytes, which would have made the kernel 2 bytes shorter, and I didn't want to risk throwing anything off and causing a page-wrapping issue in the kernel (I didn't think it would matter, but I wasn't sure). So I decided to use LDY.w and LDA.w to force the compiler to use an absolute address instead of a zero-page address. It looked fine in the assembly listing-- each of the instructions took 3 bytes, like I'd wanted, so I couldn't figure out why it wasn't working. I even stepped through the program with the Stella debugger, and then stepped through the version of the program that used the ROM table for comparison. What the heck, the RAM table contains the correct values, but the program is loading the wrong values into Y and A! Then, after going crazy for a day trying to figure it out, I compared the assembly using the ROM table with the assembly listing using the RAM table-- and noticed that the load instructions weren't the same. When I looked up the hex codes, I saw that it was using absolute addressing, instead of absolute,X addressing. But the assembly listing showed X being used as an index in the code! I finally looked in the DASM documentation, and figured out that to force absolute,X addressing I needed to use LDY.wx and LDA.wx, instead of just LDY.w and LDA.w! As soon as I made that correction, it worked like a champ.

 

I wonder if the data could also be put in the extra 2k space for the supercharger (assuming you have a 4K game)... hmmm...

I don't know what you mean about the extra 2K of space for the Supercharger. Oh, never mind, you said Supercharger, not Superchip. D'oh! I'm afraid I can't help with that question, because I haven't learned how to program for the Supercharger yet. If the Supercharger has 6K of RAM, but 4K of that RAM must hold a 4K ROM image that's been loaded in from a tape (or CD), then where does that extra 2K reside in the Atari's memory architecture? Does the Atari see it within the 4K cartridge area, and you have to use some kind of bankswitching technique to switch between 2K of the ROM image and the extra 2K of RAM? The Supercharger is something I need to learn about one of these days.

 

How hard is it to get a superchip cartridge made, I wonder?... that question is for a different forum, I guess...

As long as CPUWIZ still has Superchips available in his store, I think it's a simple matter to get an 8K, 16K, or 32K Superchip game made.

 

I was wondering about the availability of the Superchip. If the available stock ever gets used up, and can't be replenished, would it be possible to create a similar sort of RAM chip with modern parts? I know that modern RAM chips have a *lot* more memory than a Superchip does, so I suppose it would probably be next to impossible to get a modern RAM chip made that contained only 128 bytes, or 256 bytes, and that was configured to be able to plug into a Superchip-compatible board-- even if it were feasible, it would probably be *way* too expensive to make that kind of custom RAM chip. However, based on what John/supercat discovered about "magic writes" or whatever, it seems like if you could attach a modern 256-byte RAM chip to a Superchip-compatible board (since the Superchip takes up 256 bytes of ROM space-- 128 bytes for the write addresses, and 128 bytes for the read addresses), then we ought to be able to read/write at all 256 addresses.

 

Ah well, it would make more sense to just develop for a 4A50 cart, with its 128K ROM and 32K RAM. :D That's yet another bB project I need to finish eventually.

 

Michael

Link to comment
Share on other sites

The biggest obstacle preventing me from implementing pfcolors and pfheights together, without Superchip RAM and without both being fixed is cycles. At the bare minimum, and without going into a long technical explanation (unless you really want me to) I'd need 3 more cycles to do so, which aren't there (and believe me, I've looked.)

That's what I figured-- it isn't that you don't have room for two pointers (since you really only need one pointer anyway if the tables are combined the way they are), then the only issue would have to be the difference in the timing of the instructions:

 

; current code with the ROM table - 15 cycles
  ldy playfieldcolorandheight-87,x; 4+ (or just 4, since page-wrap is carefully avoided)
  sty COLUPF; 3
  lda playfieldcolorandheight-88,x; 4+ (or just 4)
  sta.w temp1; 4

; modified code with the RAM table - 15 cycles
  ldy.wx RAMplayfieldcolorandheight-87,x; 4+ (or just 4)
  sty COLUPF; 3
  lda.wx RAMplayfieldcolorandheight-88,x; 4+ (or just 4)
  sta.w temp1; 4

; using pointers to two ROM tables - 18 cycles (3 too many)
  tay; 2
  lda (pfcolortable),y; 5+ (or just 5)
  sta COLUPF; 3
  lda (pfheighttable),y; 5+ (or just 5)
  sta temp1; 3

 

Doing a kernel rewrite might get the cycles, but doing so has other implications that could "break" current code (aside from it being a lot of work for me :)

That's why I chose the solution of copying the combined table into the zero-page RAM that's freed up by relocating the playfield into the Superchip RAM. It isn't a perfect solution, but I believe the people who had expressed a desire for this enhancement were using Superchip bankswitching in their game projects, anyway.

 

By the way, if there's anything you need from me before wrapping up bB v1.01 (or v1.1, whichever it's going to be), just let me know so I can try to get it to you in a hurry. I sort of put aside my work on reading the keypads, but it might not take long to finish; I was almost done with it, anyway, except for wanting to figure out how to still allow for vblank routines, an checking to see how many keys can be read simultaneously. I never did anything about trying to split up the score-- I think I got hung up on trying to decide how the score could be stored and loaded (if the digits would be 4 pixels wide instead of 8 pixels wide). But I did create a multisprite_superchip.inc and multispritesuperchipheader.asm for using the Superchip with the multisprite kernel, as well as some PF drawing routines for drawing to a RAM playfield in the multisprite Superchip kernel (assuming that would be of much use with a mirrored playfield, that is).

 

Michael

Link to comment
Share on other sites

I wonder if the data could also be put in the extra 2k space for the supercharger (assuming you have a 4K game)... hmmm...

I don't know what you mean about the extra 2K of space for the Supercharger. Oh, never mind, you said Supercharger, not Superchip. D'oh! I'm afraid I can't help with that question, because I haven't learned how to program for the Supercharger yet. If the Supercharger has 6K of RAM, but 4K of that RAM must hold a 4K ROM image that's been loaded in from a tape (or CD), then where does that extra 2K reside in the Atari's memory architecture? Does the Atari see it within the 4K cartridge area, and you have to use some kind of bankswitching technique to switch between 2K of the ROM image and the extra 2K of RAM? The Supercharger is something I need to learn about one of these days.

The Supercharger has 3 2k RAM banks and 2k ROM bank, any two of which can be swapped into the 2600's 4k of address space at any time. I released the source code to Twisty Passages a while ago, which is the only Supercharger bB game out there. Among other things, RAM writes were all done with asm, as they are really convoluted on the Supercharger.

 

How hard is it to get a superchip cartridge made, I wonder?... that question is for a different forum, I guess...

As long as CPUWIZ still has Superchips available in his store, I think it's a simple matter to get an 8K, 16K, or 32K Superchip game made.

 

I was wondering about the availability of the Superchip. If the available stock ever gets used up, and can't be replenished, would it be possible to create a similar sort of RAM chip with modern parts? I know that modern RAM chips have a *lot* more memory than a Superchip does, so I suppose it would probably be next to impossible to get a modern RAM chip made that contained only 128 bytes, or 256 bytes, and that was configured to be able to plug into a Superchip-compatible board-- even if it were feasible, it would probably be *way* too expensive to make that kind of custom RAM chip. However, based on what John/supercat discovered about "magic writes" or whatever, it seems like if you could attach a modern 256-byte RAM chip to a Superchip-compatible board (since the Superchip takes up 256 bytes of ROM space-- 128 bytes for the write addresses, and 128 bytes for the read addresses), then we ought to be able to read/write at all 256 addresses.

I think I read that CPUWIZ acquired several hundred NOS Superchips. But if more are needed, they can be harvested from common SC games, like Dig Dug, Jr. Pac Man, etc.

 

But even if those run out, a replacement board could be designed with the same chip count, except instead of a Superchip, use a garden-variety SRAM chip and a few passive components (like diodes) to free up enough macrocells in the PLD to control the SRAM as if it were Superchip RAM (or use a CPLD.)

Edited by batari
Link to comment
Share on other sites

This is very cool, and I might have some applications for it. I'm not sure though that it is as useful as it might have been; I'm more likely to choose 32x32 superchip with 40 extra variables, than 32x11 superchip with no extra variables. It dosn't seem to me that there would be any way to expand this alteration to allow for 32x32, and even then it would have to be combined with a hack that allows color tables in any bank or it's usefulness would still be limited by space.

 

I'll have to play with this, it might be a useful way to create high resolution background graphics (that only take up 11 or less pixels veritically) without using the large amount of rom space required for a 32x32 playfield and color table.

 

 

What I still yearn for, that would be almost universally useful, is a command that splits the background color on a specific line. So that I can use the background for ie the sky and the ground, or the sky and the ocean, and still have a multicolored playfield in front of it. I would be able to use that in pretty much every project I have.

Link to comment
Share on other sites

Would it be possible if, maybe, when both the pfcolors and pfheights are both defined allowing us to redifine only one of the two options? In other words, could we have heights static, but be able to redifine colors, or vice versa?

It should work that way already, as long as you redefine one without the other. That is, you would initially define your playfield heights and playfield colors, and copy them into RAM. After that, you're free to change just the colors, or just the heights. When you're changing the colors, you can change just one row, or two rows, or three, etc.-- all you have to do is change the appropriate byte in the RAM table. But if you're changing the heights, you'll need to change at least two rows at the same time, since the heights of all the rows must add up to 88-- so if you reduce a row by 2 lines, you'll either have to increase another row by 2 lines, or increase two other rows by 1 line each, to keep the total equal to 88.

 

On the other hand, when I was making the modification, I *had* considered adding a couple of other directives so that the colors could be read from either RAM or ROM, and the heights could be read from either RAM or ROM. This wouldn't be something you could change on the fly in your program-- once you compiled it, it would be set that way for good (unless you changed your code and recompiled it). The only advantages to doing it that way would be (1) you wouldn't need to copy both the colors and the heights into RAM, just the one that is changeable; and (2) since the kernel wouldn't be reading one of them (colors or heights) from RAM, those bytes of RAM would be free to use as other variables.

 

I can make that modification to the modification if you want; it will be easy to do! :)

 

Michael

Link to comment
Share on other sites

Hi Michael! Thanks for replying! :)

 

It was late at night when I wrote this question, so I didn't communicate exactly what I wanted to say... What I was wondering was if it was possible to make only one paramater dynamic (either pfcolors or pfheights, but not both) in the standard kernel without the superchip... In other words, could that option be possibly implemented without the need for the superchip.

 

I'm glad I brought it up, though 'cos I assumed that both parameters were dynamic in the superchip option... I think it would be great to have both parameters changeable in the superchip modification...

 

Thanks for all your work with Batari Basic and other Atari programming chores! You've been more than helpful to so many people here... I'm sure I can speak for everybody when I say that we all greatly appreciate it!

 

Thanks,

 

Mike

Link to comment
Share on other sites

  • 1 year later...

Hi Michael,

 

I was trying to implement your pfcolors/heights method in a game I'm designing. I know this thread hasn't been active for awhile, but when I copied over your includes to bB and tested your attached sample file, my DASM compiler fails, reporting the following errors:

2600basic_SC.h (68): error: EQU: Value mismatch.
old value: $00a4  new value: $00a6
2600basic_SC.h (69): error: EQU: Value mismatch.
old value: $00a5  new value: $00a7
2600basic_SC.h (70): error: EQU: Value mismatch.
old value: $00a6  new value: $00aa
2600basic_SC.h (71): error: EQU: Value mismatch.
old value: $00a7  new value: $00ab
2600basic_SC.h (72): error: EQU: Value mismatch.
old value: $00a8  new value: $00ae
...

I'm using batari Basic 1.0 and DASM V2.20.07... maybe something changed in either one between then and now?

Link to comment
Share on other sites

Hi Michael,

 

I was trying to implement your pfcolors/heights method in a game I'm designing. I know this thread hasn't been active for awhile, but when I copied over your includes to bB and tested your attached sample file, my DASM compiler fails, reporting the following errors:

2600basic_SC.h (68): error: EQU: Value mismatch.
old value: $00a4  new value: $00a6
2600basic_SC.h (69): error: EQU: Value mismatch.
old value: $00a5  new value: $00a7
2600basic_SC.h (70): error: EQU: Value mismatch.
old value: $00a6  new value: $00aa
2600basic_SC.h (71): error: EQU: Value mismatch.
old value: $00a7  new value: $00ab
2600basic_SC.h (72): error: EQU: Value mismatch.
old value: $00a8  new value: $00ae
...

I'm using batari Basic 1.0 and DASM V2.20.07... maybe something changed in either one between then and now?

I see if I can check it out this evening before I head out of town.

 

Michael

Link to comment
Share on other sites

Hi Michael,

 

I was trying to implement your pfcolors/heights method in a game I'm designing. I know this thread hasn't been active for awhile, but when I copied over your includes to bB and tested your attached sample file, my DASM compiler fails, reporting the following errors:

2600basic_SC.h (68): error: EQU: Value mismatch.
old value: $00a4  new value: $00a6
2600basic_SC.h (69): error: EQU: Value mismatch.
old value: $00a5  new value: $00a7
2600basic_SC.h (70): error: EQU: Value mismatch.
old value: $00a6  new value: $00aa
2600basic_SC.h (71): error: EQU: Value mismatch.
old value: $00a7  new value: $00ab
2600basic_SC.h (72): error: EQU: Value mismatch.
old value: $00a8  new value: $00ae
...

I'm using batari Basic 1.0 and DASM V2.20.07... maybe something changed in either one between then and now?

I see if I can check it out this evening before I head out of town.

 

Michael

 

Quick update:

 

I decided to abandon pfheights & colors in my game, but something interesting happened. I ran into some trouble with the standard bankswitch.inc, since turning it on seemed to mess up my pf drawing routines. Out of curiousity, I included your bankswitch supercharger file instead of the standard. It wouldn't compile at first, but then I altered it to point to the standard 2600basic.h file (instead of 2600basic_SC.h). Not only did the program compile, but it somehow fixed the drawing functions that bankswitch.inc were screwing up!

 

I tried ding the same thing with your sample file, ("test_pfcolors_with_pfheights_SC.bas"), but it failed on the following:

 

RAMplayfieldcolorandheight 0000 ???? (R )

pfrow5height 0000 ???? (R )

pfrow4height 0000 ???? (R )

pfrow3height 0000 ???? (R )

pfrow2height 0000 ???? (R )

pfrow1color 0000 ???? (R )

 

Sorry if that's not very helpful, but I thought I'd report it just in case. Hope your trip went well.

 

J

Link to comment
Share on other sites

  • 3 months later...
Just curious if anyone was ever able to get Michael's sample program to compile. If so, what versions of of bB and DASM were you using with his superchip kernel mods? I've tried several combinations of both without any luck.

 

Thanks in advance,

Jarod.

I just downloaded my original files (from post #1 in this thread)-- just in case I'd made some changes on my computer since then-- and then I recompiled the sample, using the bB v1.01 compiler and DASM v2.20.07. It works fine for me-- but you *will* get a lot of "errors" when it compiles:

 

---------- Capture Output ----------
> "C:\Atari2600\bB\2600bas.bat" "C:\Atari2600\bB\Projects\test_pfcolors_with_pfheights_SC_0.bas"
batari Basic v1.01 (C)2005-2007
User-defined bankswitch_SC.inc found in the current directory
User-defined banksw.asm found in the current directory
2600 Basic compilation complete.
User-defined superchipheader_SC.asm found in current directory
User-defined std_kernel_SC.asm found in current directory
User-defined startup.asm found in current directory
User-defined pf_drawing.asm found in current directory
User-defined pf_scrolling.asm found in current directory
User-defined std_routines.asm found in current directory
User-defined std_overscan.asm found in current directory
User-defined score_graphics.asm found in current directory
User-defined banksw.asm found in current directory
User-defined 2600basicfooter.asm found in current directory
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
2600basic_SC.h (68): error: EQU: Value mismatch.
old value: $00a4  new value: $00a6
2600basic_SC.h (69): error: EQU: Value mismatch.
old value: $00a5  new value: $00a7
2600basic_SC.h (70): error: EQU: Value mismatch.
old value: $00a6  new value: $00aa
2600basic_SC.h (71): error: EQU: Value mismatch.
old value: $00a7  new value: $00ab
2600basic_SC.h (72): error: EQU: Value mismatch.
old value: $00a8  new value: $00ae
2600basic_SC.h (73): error: EQU: Value mismatch.
old value: $00a9  new value: $00af
2600basic_SC.h (74): error: EQU: Value mismatch.
old value: $00aa  new value: $00b2
2600basic_SC.h (75): error: EQU: Value mismatch.
old value: $00ab  new value: $00b3
2600basic_SC.h (76): error: EQU: Value mismatch.
old value: $00ac  new value: $00b6
2600basic_SC.h (77): error: EQU: Value mismatch.
old value: $00ad  new value: $00b7
2600basic_SC.h (78): error: EQU: Value mismatch.
old value: $00ae  new value: $00ba
2600basic_SC.h (79): error: EQU: Value mismatch.
old value: $00af  new value: $00bb
2600basic_SC.h (80): error: EQU: Value mismatch.
old value: $00b0  new value: $00be
2600basic_SC.h (81): error: EQU: Value mismatch.
old value: $00b1  new value: $00bf
2600basic_SC.h (82): error: EQU: Value mismatch.
old value: $00b2  new value: $00c2
2600basic_SC.h (83): error: EQU: Value mismatch.
old value: $00b3  new value: $00c3
2600basic_SC.h (84): error: EQU: Value mismatch.
old value: $00b4  new value: $00c6
2600basic_SC.h (85): error: EQU: Value mismatch.
old value: $00b5  new value: $00c7
2600basic_SC.h (86): error: EQU: Value mismatch.
old value: $00b6  new value: $00ca
2600basic_SC.h (87): error: EQU: Value mismatch.
old value: $00b7  new value: $00cb
2600basic_SC.h (88): error: EQU: Value mismatch.
old value: $00b8  new value: $00cc
2600basic_SC.h (89): error: EQU: Value mismatch.
old value: $00b9  new value: $00cd
2600basic_SC.h (90): error: EQU: Value mismatch.
old value: $00ba  new value: $00ce
2600basic_SC.h (91): error: EQU: Value mismatch.
old value: $00bb  new value: $00cf
2600basic_SC.h (92): error: EQU: Value mismatch.
old value: $00bc  new value: $00d0
2600basic_SC.h (93): error: EQU: Value mismatch.
old value: $00bd  new value: $00d1
2600basic_SC.h (94): error: EQU: Value mismatch.
old value: $00be  new value: $00d2
2600basic_SC.h (95): error: EQU: Value mismatch.
old value: $00bf  new value: $00d3
2600basic_SC.h (245): error: EQU: Value mismatch.
old value: $00a4  new value: $10d0
2600basic_SC.h (252): error: EQU: Value mismatch.
old value: $00a4  new value: $10d0
Possible duplicate label: L08 d141				  
  2292 bytes of ROM space left in bank 2
  3601 bytes of ROM space left in bank 1
  2292 bytes of ROM space left in bank 2
Complete.

> Terminated with exit code 0.

DASM should be able to resolve these "errors" by the time it makes its final pass through the code, in which case the compilation should end with the number of bytes free in each bank, "Complete.", and "> Terminated with exit code 0."

 

What happens when you compile it?

 

Michael

Link to comment
Share on other sites

Just curious if anyone was ever able to get Michael's sample program to compile. If so, what versions of of bB and DASM were you using with his superchip kernel mods? I've tried several combinations of both without any luck.

 

Thanks in advance,

Jarod.

I just downloaded my original files (from post #1 in this thread)-- just in case I'd made some changes on my computer since then-- and then I recompiled the sample, using the bB v1.01 compiler and DASM v2.20.07. It works fine for me-- but you *will* get a lot of "errors" when it compiles:

 

---------- Capture Output ----------
> "C:\Atari2600\bB\2600bas.bat" "C:\Atari2600\bB\Projects\test_pfcolors_with_pfheights_SC_0.bas"
batari Basic v1.01 (C)2005-2007
User-defined bankswitch_SC.inc found in the current directory
User-defined banksw.asm found in the current directory
2600 Basic compilation complete.
User-defined superchipheader_SC.asm found in current directory
User-defined std_kernel_SC.asm found in current directory
User-defined startup.asm found in current directory
User-defined pf_drawing.asm found in current directory
User-defined pf_scrolling.asm found in current directory
User-defined std_routines.asm found in current directory
User-defined std_overscan.asm found in current directory
User-defined score_graphics.asm found in current directory
User-defined banksw.asm found in current directory
User-defined 2600basicfooter.asm found in current directory
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
2600basic_SC.h (68): error: EQU: Value mismatch.
old value: $00a4  new value: $00a6
2600basic_SC.h (69): error: EQU: Value mismatch.
old value: $00a5  new value: $00a7
2600basic_SC.h (70): error: EQU: Value mismatch.
old value: $00a6  new value: $00aa
2600basic_SC.h (71): error: EQU: Value mismatch.
old value: $00a7  new value: $00ab
2600basic_SC.h (72): error: EQU: Value mismatch.
old value: $00a8  new value: $00ae
2600basic_SC.h (73): error: EQU: Value mismatch.
old value: $00a9  new value: $00af
2600basic_SC.h (74): error: EQU: Value mismatch.
old value: $00aa  new value: $00b2
2600basic_SC.h (75): error: EQU: Value mismatch.
old value: $00ab  new value: $00b3
2600basic_SC.h (76): error: EQU: Value mismatch.
old value: $00ac  new value: $00b6
2600basic_SC.h (77): error: EQU: Value mismatch.
old value: $00ad  new value: $00b7
2600basic_SC.h (78): error: EQU: Value mismatch.
old value: $00ae  new value: $00ba
2600basic_SC.h (79): error: EQU: Value mismatch.
old value: $00af  new value: $00bb
2600basic_SC.h (80): error: EQU: Value mismatch.
old value: $00b0  new value: $00be
2600basic_SC.h (81): error: EQU: Value mismatch.
old value: $00b1  new value: $00bf
2600basic_SC.h (82): error: EQU: Value mismatch.
old value: $00b2  new value: $00c2
2600basic_SC.h (83): error: EQU: Value mismatch.
old value: $00b3  new value: $00c3
2600basic_SC.h (84): error: EQU: Value mismatch.
old value: $00b4  new value: $00c6
2600basic_SC.h (85): error: EQU: Value mismatch.
old value: $00b5  new value: $00c7
2600basic_SC.h (86): error: EQU: Value mismatch.
old value: $00b6  new value: $00ca
2600basic_SC.h (87): error: EQU: Value mismatch.
old value: $00b7  new value: $00cb
2600basic_SC.h (88): error: EQU: Value mismatch.
old value: $00b8  new value: $00cc
2600basic_SC.h (89): error: EQU: Value mismatch.
old value: $00b9  new value: $00cd
2600basic_SC.h (90): error: EQU: Value mismatch.
old value: $00ba  new value: $00ce
2600basic_SC.h (91): error: EQU: Value mismatch.
old value: $00bb  new value: $00cf
2600basic_SC.h (92): error: EQU: Value mismatch.
old value: $00bc  new value: $00d0
2600basic_SC.h (93): error: EQU: Value mismatch.
old value: $00bd  new value: $00d1
2600basic_SC.h (94): error: EQU: Value mismatch.
old value: $00be  new value: $00d2
2600basic_SC.h (95): error: EQU: Value mismatch.
old value: $00bf  new value: $00d3
2600basic_SC.h (245): error: EQU: Value mismatch.
old value: $00a4  new value: $10d0
2600basic_SC.h (252): error: EQU: Value mismatch.
old value: $00a4  new value: $10d0
Possible duplicate label: L08 d141				  
  2292 bytes of ROM space left in bank 2
  3601 bytes of ROM space left in bank 1
  2292 bytes of ROM space left in bank 2
Complete.

> Terminated with exit code 0.

DASM should be able to resolve these "errors" by the time it makes its final pass through the code, in which case the compilation should end with the number of bytes free in each bank, "Complete.", and "> Terminated with exit code 0."

 

What happens when you compile it?

 

Michael

 

I get the exact same output, except the compile fails, and no BIN is created. Instead of the exit code, I just get "2600 Basic Compilation Failed!" (see below)

 

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
2600basic_SC.h (68): error: EQU: Value mismatch.
old value: $00a4  new value: $00a6
2600basic_SC.h (69): error: EQU: Value mismatch.
old value: $00a5  new value: $00a7
2600basic_SC.h (70): error: EQU: Value mismatch.
old value: $00a6  new value: $00aa
2600basic_SC.h (71): error: EQU: Value mismatch.
old value: $00a7  new value: $00ab
2600basic_SC.h (72): error: EQU: Value mismatch.
old value: $00a8  new value: $00ae
2600basic_SC.h (73): error: EQU: Value mismatch.
old value: $00a9  new value: $00af
2600basic_SC.h (74): error: EQU: Value mismatch.
old value: $00aa  new value: $00b2
2600basic_SC.h (75): error: EQU: Value mismatch.
old value: $00ab  new value: $00b3
2600basic_SC.h (76): error: EQU: Value mismatch.
old value: $00ac  new value: $00b6
2600basic_SC.h (77): error: EQU: Value mismatch.
old value: $00ad  new value: $00b7
2600basic_SC.h (78): error: EQU: Value mismatch.
old value: $00ae  new value: $00ba
2600basic_SC.h (79): error: EQU: Value mismatch.
old value: $00af  new value: $00bb
2600basic_SC.h (80): error: EQU: Value mismatch.
old value: $00b0  new value: $00be
2600basic_SC.h (81): error: EQU: Value mismatch.
old value: $00b1  new value: $00bf
2600basic_SC.h (82): error: EQU: Value mismatch.
old value: $00b2  new value: $00c2
2600basic_SC.h (83): error: EQU: Value mismatch.
old value: $00b3  new value: $00c3
2600basic_SC.h (84): error: EQU: Value mismatch.
old value: $00b4  new value: $00c6
2600basic_SC.h (85): error: EQU: Value mismatch.
old value: $00b5  new value: $00c7
2600basic_SC.h (86): error: EQU: Value mismatch.
old value: $00b6  new value: $00ca
2600basic_SC.h (87): error: EQU: Value mismatch.
old value: $00b7  new value: $00cb
2600basic_SC.h (88): error: EQU: Value mismatch.
old value: $00b8  new value: $00cc
2600basic_SC.h (89): error: EQU: Value mismatch.
old value: $00b9  new value: $00cd
2600basic_SC.h (90): error: EQU: Value mismatch.
old value: $00ba  new value: $00ce
2600basic_SC.h (91): error: EQU: Value mismatch.
old value: $00bb  new value: $00cf
2600basic_SC.h (92): error: EQU: Value mismatch.
old value: $00bc  new value: $00d0
2600basic_SC.h (93): error: EQU: Value mismatch.
old value: $00bd  new value: $00d1
2600basic_SC.h (94): error: EQU: Value mismatch.
old value: $00be  new value: $00d2
2600basic_SC.h (95): error: EQU: Value mismatch.
old value: $00bf  new value: $00d3
2600basic_SC.h (245): error: EQU: Value mismatch.
old value: $00a4  new value: $10d0
2600basic_SC.h (252): error: EQU: Value mismatch.
old value: $00a4  new value: $10d0
Possible duplicate label: L08 d141				  
  2292 bytes of ROM space left in bank 2
  3601 bytes of ROM space left in bank 1
  2292 bytes of ROM space left in bank 2
Complete.
2600 Basic compilation Failed!

Link to comment
Share on other sites

Just curious if anyone was ever able to get Michael's sample program to compile. If so, what versions of of bB and DASM were you using with his superchip kernel mods? I've tried several combinations of both without any luck.

 

Thanks in advance,

Jarod.

 

Ahhhhh... my apologies, Mr. Rideout. I just realized that, despite the "compilation Failed" report, it actually did compile... just not where I expected it to. I was looking for the BIN in my default compilation directory, but for some reason it created the file one level up (in the same folder as my source).

 

Thanks!

Jarod.

Edited by jrok
Link to comment
Share on other sites

Ahhhhh... my apologies, Mr. Rideout. I just realized that, despite the "compilation Failed" report, it actually did compile... just not where I expected it to. I was looking for the BIN in my default compilation directory, but for some reason it created the file one level up (in the same folder as my source).

 

Thanks!

Jarod.

How are you compiling? Are you using 2600IDE, Crimson Editor, Visual bB, or something else?

 

Michael

Link to comment
Share on other sites

Ahhhhh... my apologies, Mr. Rideout. I just realized that, despite the "compilation Failed" report, it actually did compile... just not where I expected it to. I was looking for the BIN in my default compilation directory, but for some reason it created the file one level up (in the same folder as my source).

 

Thanks!

Jarod.

How are you compiling? Are you using 2600IDE, Crimson Editor, Visual bB, or something else?

 

Michael

 

I started out on Crimson, but for the last few weeks I've been using VisbB. I think that there is a step in the batch that cuts/pastes the final BIN to my output directory, and that for some reason that final step is being cut off, but so far I can't figure out where that's happening.

 

Thanks again for the help,

Jarod.

Link to comment
Share on other sites

I started out on Crimson, but for the last few weeks I've been using VisbB. I think that there is a step in the batch that cuts/pastes the final BIN to my output directory, and that for some reason that final step is being cut off, but so far I can't figure out where that's happening.

 

Thanks again for the help,

Jarod.

 

Well, that "2600 Basic compilation Failed!" message isn't a DASM message, and I don't *think* it's from the bB compiler, so it may be coming from Visual bB. Perhaps Visual bB looks for certain words or phrases in the output to determine if there was a problem while compiling and assembling the program?

 

Michael

Link to comment
Share on other sites

I started out on Crimson, but for the last few weeks I've been using VisbB. I think that there is a step in the batch that cuts/pastes the final BIN to my output directory, and that for some reason that final step is being cut off, but so far I can't figure out where that's happening.

 

Thanks again for the help,

Jarod.

 

Well, that "2600 Basic compilation Failed!" message isn't a DASM message, and I don't *think* it's from the bB compiler, so it may be coming from Visual bB. Perhaps Visual bB looks for certain words or phrases in the output to determine if there was a problem while compiling and assembling the program?

 

Michael

I think you are correct because it vbB sees an error in the compilation it thinks it failed. I should be able to fix that.

 

-Jeff

Link to comment
Share on other sites

Hi Michael,

 

I have two quick questions about your superchip version of 2600basic. From what I can gather, it is using var28-47 to store the colors and row heights for rows for ten rows if the RAM_PFcolorandheight constant is set, with the rest of the superchip RAM available for general use. If I wanted to increase the pfres and number of rows stored in RAM to 12, could I use these to do it instead of, say, using $F1-$F4? I mean, if I didn't want lives or pfscores. What about $F6-$F9 in the stack?

 

Also, would I have to reserve new rows in 2600basic_SC.h, or could I DIM them in my bB file? And if I did the latter, would it just use up consecutive variables (i.e. $A6, $A7, $AA...). EDT: And if I dimmed them, would I dim them consecutively (i.e. var0 = pfrow11height, var1 = pfrow11color, etc).

 

Thanks,

Jarod

Edited by jrok
Link to comment
Share on other sites

  • 1 year later...

Hi Michael,

 

I have two quick questions about your superchip version of 2600basic. From what I can gather, it is using var28-47 to store the colors and row heights for rows for ten rows if the RAM_PFcolorandheight constant is set, with the rest of the superchip RAM available for general use. If I wanted to increase the pfres and number of rows stored in RAM to 12, could I use these to do it instead of, say, using $F1-$F4? I mean, if I didn't want lives or pfscores. What about $F6-$F9 in the stack?

 

Also, would I have to reserve new rows in 2600basic_SC.h, or could I DIM them in my bB file? And if I did the latter, would it just use up consecutive variables (i.e. $A6, $A7, $AA...). EDT: And if I dimmed them, would I dim them consecutively (i.e. var0 = pfrow11height, var1 = pfrow11color, etc).

 

Thanks,

Jarod

Dang, I guess I never replied to this. icon_sad.gif I'll try to reply after work tonight.

 

Michael

 

Edit: Also, I might need to revisit the include file changes I'd made to see if they need to be "ported" into any newer versions of the include files.

Edited by SeaGtGruff
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...