Jump to content


Bug Report Thread

308 replies to this topic

#301 orange808 OFFLINE  


    Space Invader

  • 48 posts

Posted Sat Sep 15, 2018 3:27 PM

I have a fresh install of bB and Visual Basic on this Win 10 machine (no previous installations to pollute my registry). I followed the instructions. I have the latest versions. I am familar with coding and Windows. The environment variables aren't an alien concept and they are right. Running as admin. So, when I look at the DPC+ examples, they run well enough. But, if I add a set romsize command, they all break. I tried multiple examples. I can change the romsize on Tinkernut all I want. Any suggestions?

#302 orange808 OFFLINE  


    Space Invader

  • 48 posts

Posted Sat Sep 15, 2018 3:30 PM

Also, will add that this is an Intel x64 machine. Not an AMD or the new ARM x86 Windows emulation. Not an exotic environment.

#303 RevEng ONLINE  


    Bit Player

  • 5,073 posts
  • Location:bottom of the stack

Posted Sat Sep 15, 2018 3:36 PM

bB DPC+ is only 32k. You can't change the romsize.

#304 orange808 OFFLINE  


    Space Invader

  • 48 posts

Posted Sat Sep 15, 2018 5:38 PM

bB DPC+ is only 32k. You can't change the romsize.

​Fair enough.  I found the documentation to be somewhat ambiguous about this.  It declares that the romsize is automatically set for you, but I didn't understand that sentence was implying that the romsize could not be changed at all.

​How about the multikernel framework with multiple DPC+ 32k parts?

​Edit:  Apologies.  Answered my own question.  That won't work.  The DPC+ kernel alone is too big to fit inside "containers" of 4k.

Edited by orange808, Sat Sep 15, 2018 5:49 PM.

#305 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,811 posts
  • Controlled Randomness
    Replay Value
  • Location:North Carolina (USA)

Posted Sat Sep 15, 2018 6:52 PM

Be sure to refresh the bB page.

#306 bogax OFFLINE  



  • 787 posts

Posted Tue Oct 2, 2018 9:41 AM

Not really a bug


I am frequently frustrated by having constant macro parameters treated as immediate values.

Not really sure how to deal with that.

How hard would it be to perhaps escape a constant to suppress emission of the "#" ?

(best I could think of)

#307 Karl G ONLINE  

Karl G


  • 648 posts

Posted Mon Dec 3, 2018 1:04 PM

There is a display problem with the rightmost digit of the score that can be exposed with a wide enough score font that I've reproduced on Stella and real hardware.  Here's a simple example with the "husky" font with the score = 100.  The problem goes away if the player objects are positioned one more pixel to the right (HMP0 = #$D0 and HMP1 = #$E0).


Screen Shot 2018-12-03 at 2.03.43 PM.png


Attached File  husky.bas   139bytes   12 downloads


Attached File  score_graphics.asm   68.45KB   13 downloads


Attached File  husky.bas.bin   4KB   11 downloads

#308 freshbrood OFFLINE  


    Star Raider

  • 81 posts

Posted Tue Dec 4, 2018 6:36 PM

Is there a way to get rid of the "waterfall effect" when using colored sprites and a colored playfield in the standard kernel?


If it were static I wouldn't mind, but it moves and ripples as the player objects move. 

#309 iesposta OFFLINE  


    River Patroller

  • 3,876 posts
  • Retro-gaming w/my VCS
  • Location:Pennsylvania

Posted Wed Dec 5, 2018 5:25 AM


This optimization I do that the bB compile passes should. 

It is faster assembly and uses less ROM.


Can the compile stage find (between anything more complex than “=“) and put all the same value variables together regardless if they are on one line or four, and output more efficient & ROM saving assembly like this?



Player0x=0: r=0 s=0 t=0


Compiles to this:

lda #0
sta Player0x
sta r
sta s
sta t




And this same thing:


Compiles to this:
lda #0
sta Player0x
lda #0
sta r
lda #0
sta s
lda #0
sta t



Another example is this one line compiles more efficiently over one value each line:


0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users