bB with native 64k cart support - 1.1d.reveng

[RevEng]

Looks good!

[+Random Terrain]

When scrolling just the playfield colors, is it possible to have the colors come back on the screen without a solid block of black? No matter how many colors I use, there is always a black area:

 

dpctest.bin

[RevEng]

If seems that DPC+ bkcolors: and pfcolors: always worked with 192 lines of color, no matter how many lines of data you actually specified. This worked fine prior to the introduction of scrolling, but not so much now.

 

I changed DPC+ bkcolors: and pfcolors: to use the exact amount of lines listed in the data, up to a maximum of 255 lines. If you need to specify the full 256 lines of data, you need to split it up into 2 entries with a pfscroll inbetween. e.g.

 

 pfcolors:
 $00
 $02
 [... 124 more values]
 $fc
 $fe
end
 pfscroll 128 4 4
 pfcolors:
 $00
 $02
 [... 124 more values]
 $fc
 $fe
end

Version 31 is in the first post.

[+Random Terrain]

Thanks. Speaking of background colors, do you think they will ever be able to scroll?

[RevEng]

bkcolors scrolling (queue #6) works in this one.

 

That said, I just wrote up a short test and noticed my last update had an off-by-1 bug in the bkcolors. I fixed it and re-uploaded it, so please re-download it if you already grabbed it.

[+Random Terrain]

Thanks. I tried the very latest and using fewer than 256 colors leaves a black area by however many colors you delete from the list. For example, using 255 colors leaves a thin black line in the scroll. Removing 20 colors from the list leaves a larger black area.

[RevEng]

There are 256 colors, but DPC+ limits the color update to 255 entries. I won't be able that change that.

 

See my example above with "pfscroll" between two 128 color entries as a work around. If you use that there's no black zone.

[+Random Terrain]

Here's a stripped down example with 255 colors:

 

dpcpfscroll_stripped_01.bin

 

dpcpfscroll_stripped_01.bas

[+Random Terrain]

Here's one with 189 colors:

 

dpcpfscroll_stripped_189_colors.bin

 

dpcpfscroll_stripped_189_colors.bas

[RevEng]

scrolling only works with the whole 256 byte queue, so black (uninitialized color entries) are expected if you define less than 256 entries. See my above work-around for how to enter 256 colors despite the 255 DPC+ pfcolor/bkcolor limitation.

 

Here's a version with 256 colors in the queue.

 

dpcpfscroll_stripped_01-rev.bas

dpcpfscroll_stripped_01-rev.bas.bin

[+Random Terrain]

scrolling only works with the whole 256 byte queue, so black (uninitialized color entries) are expected if you define less than 256 entries. See my above work-around for how to enter 256 colors despite the 255 DPC+ pfcolor/bkcolor limitation.

 

Here's a version with 256 colors in the queue.

 

dpcpfscroll_stripped_01-rev.bas

dpcpfscroll_stripped_01-rev.bas.bin

 

Thanks. I misunderstood what you said below to mean that 256 was optional and that bB would scroll the exact amount of lines listed (up to 255) with no black lines:

 

"I changed DPC+ bkcolors: and pfcolors: to use the exact amount of lines listed in the data, up to a maximum of 255 lines. If you need to specify the full 256 lines of data, you need to split it up into 2 entries with a pfscroll inbetween. e.g."

 

So for scrolling, if we want continuous color with no black lines, we need to use the split trick to have 256 colors. Anything less than 256 will cause black lines.

[+Random Terrain]

Looks like we lost some data when the web site went down today. Can you repost that asm code?

[iesposta]

I wasn't clear on what he meant:

 

The background color isn't adjusted in the score kernel, so nothing the usual way.

 

Sticking the following in the first bank changes the background to 0...

  asm
minikernel
  stx COLUBK ; x is always 0 at this point
  rts
end

Unfortunately it looks like if you try to use a custom background color, the extra statement pushes the change into the visible area, causing a stair step.

[+Random Terrain]

I wasn't clear on what he meant:

 

If you stick something like "ldx $6A" above "stx COLUBK" you'll see a bit of a stair step or a notch taken out of the score background.

 

Here is an example without the asm code:

 

dpcpfscroll_256_both_colors.bin

 

dpcpfscroll_256_both_colors.bas

 

Notice how irritating it is to have the color constantly changing behind the score.

 

 

Now here's the same example with RevEng's asm added:

 

dpcpfscroll_256_both_colors_asm.bin

 

dpcpfscroll_256_both_colors_asm.bas

[iesposta]

Got it. Thanks.

I thought it was cycling the colors of the score digits.

It is the color behind the digits.

[RevEng]

Version 32 is in the first post.

 

I found a long-standing bug... whenever there was 2 or more complex statements in an if...then ( e.g. "if (a+b)=3 && (c+d)=5 then ...") then the result was incorrect.

 

The bB infix interpreter is super complex, so thankfully batari was able to figure out the problem and provide the fix to us.

 

I also adjusted the minikernel call under DPC+, so it turns fast fetch on/off before handing to the minikernel. (thanks to batari's code comment indicating this wasn't done). Also, now there's enough time to load a color variable/value and change the background color in your minikernel on the first scanline, without the stair-step.

 

I also took the opportunity to update the included dasm. It may help with the odd compile issue with assembly modules.

[+Random Terrain]

Version 32 is in the first post.

 

I found a long-standing bug... whenever there was 2 or more complex statements in an if...then ( e.g. "if (a+b)=3 && (c+d)=5 then ...") then the result was incorrect.

 

The bB infix interpreter is super complex, so thankfully batari was able to figure out the problem and provide the fix to us.

 

I also adjusted the minikernel call under DPC+, so it turns fast fetch on/off before handing to the minikernel. (thanks to batari's code comment indicating this wasn't done). Also, now there's enough time to load a color variable/value and change the background color in your minikernel on the first scanline, without the stair-step.

 

I also took the opportunity to update the included dasm. It may help with the odd compile issue with assembly modules.

 

Thanks. I'm glad that the stair-step is gone. I just tried the score background color with a variable and now I can change the color to whatever I want as the program runs. That's exactly what a DPC+ version of Seaweed Assault would need.

 

Do you think batari Basic will ever be able to look inside of the sed folder so we don't have to keep telling people to move sed.exe?

[RevEng]

Well, the sed-in-a-folder thing is a license thing, rather than a technical issue. batari is concerned that someone will try to claim his source is GPL licensed due to being distributed with other GPL software.

 

That said, bB uses sed as a simple text filter. It wouldn't take much time to code a simple non-GPL replacement...

[+Random Terrain]

That said, bB uses sed as a simple text filter. It wouldn't take much time to code a simple non-GPL replacement...

 

That would be nice. Every step removed from the 'installation' process makes bB more attractive and user-friendly.

[+Gemintronic]

Version 32 is in the first post.

 

I found a long-standing bug... whenever there was 2 or more complex statements in an if...then ( e.g. "if (a+b)=3 && (c+d)=5 then ...") then the result was incorrect.

 

The bB infix interpreter is super complex, so thankfully batari was able to figure out the problem and provide the fix to us.

 

I also adjusted the minikernel call under DPC+, so it turns fast fetch on/off before handing to the minikernel. (thanks to batari's code comment indicating this wasn't done). Also, now there's enough time to load a color variable/value and change the background color in your minikernel on the first scanline, without the stair-step.

 

I also took the opportunity to update the included dasm. It may help with the odd compile issue with assembly modules.

 

Just to be clear this doesn't effect standard kernels. I have some games (including my current project) that use the trick where you can change the background color of the first row of playfield even if using pfcolors pfheights.

 

UPDATE: nevermind. That "feature" is safe

[+Random Terrain]

Just to be clear this doesn't effect standard kernels. I have some games (including my current project) that use the trick where you can change the background color of the first row of playfield even if using pfcolors pfheights.

 

I thought he was just talking about the asm code that he recently posted to change the color behind the score in the DPC+ kernel:

__

asm
   minikernel
   ldx z
   stx COLUBK
   rts
end

__

It had a stair-step problem before he fixed it. Below is an example. Press the fire button to change the score background color:

 

dpcpfscroll_256_both_colors_asm_with_score_background_color.bin

 

dpcpfscroll_256_both_colors_asm_with_score_background_color.bas

[RevEng]

Version 33 is in the first post.

 

I updated dasm with some more fixes, so I thought I'd push out another update here with it.

 

I added "bbfilter" which now takes the place of sed. It's in the same directory as the other bB binaries, so there's no more moving things around.

 

I also added an "install_win.bat" file. Double-clicking this will set your bB variable to the directory the batch file is in, and add this location to your user's PATH variable, if necessary. install_win.bat requires SETX, which comes with Windows XP SP2 and later versions of Windows. If you don't have SETX on the system the batch file will let you know and explain the situation.

 

Switching back into bugfix-only mode now...

[+Random Terrain]

I updated dasm with some more fixes, so I thought I'd push out another update here with it.

 

I wonder if that might fix the weird crashes I get once in a while when I make some goofy mistake.

 

 

 

I added "bbfilter" which now takes the place of sed. It's in the same directory as the other bB binaries, so there's no more moving things around.

 

Thanks. I'll remove any sed instructions from the bB pages.

 

Update: When I tried to compile a program, VbB gave me this error message:

 

Could not locate sed.exe. Please copy sed.exe to [my bB folder]. This will improve DASM error reporting.

Precompilation failed, aborted at 1/26/2014 03:45:42

 

Is that VbB itself checking for sed.exe? If so, I hope jwierer will be able to post an update in the VbB thread.

 

 

 

I also added an "install_win.bat" file. Double-clicking this will set your bB variable to the directory the batch file is in, and add this location to your user's PATH variable, if necessary. install_win.bat requires SETX, which comes with Windows XP SP2 and later versions of Windows. If you don't have SETX on the system the batch file will let you know and explain the situation.

 

Thanks. That's another nice thing to have. I see that if you double click on it, it tells you to restart Visual batari Basic or whatever else you are using, so that's good.

[RevEng]

Update: When I tried to compile a program, VbB gave me this error message:

 

Could not locate sed.exe. Please copy sed.exe to [my bB folder]. This will improve DASM error reporting.

Precompilation failed, aborted at 1/26/2014 03:45:42

 

Is that VbB itself checking for sed.exe? If so, I hope jwierer will be able to post an update in the VbB thread.

I'm pretty sure it is vbb. Does it go away if you add a dummy "sed.exe" to the bB folder? If so, I'll just do the same so vbb can continue to work as intended with older versions.

[+Random Terrain]

I'm pretty sure it is vbb. Does it go away if you add a dummy "sed.exe" to the bB folder? If so, I'll just do the same so vbb can continue to work as intended with older versions.

 

I just made a blank text file and named it sed.exe. The error went away after that. That was an easy fix. Thanks.