Next version of bB

[+batari]

Maybe this should go in the bugs thread?

 

(1) "if switchreset then reboot" doesn't work, because the parser treats "reboot" as a label instead of as a command.

 

The following works as an alternative:

 

  if !switchreset then goto loop
  rem - or just "if !switchreset then loop" if "loop" is near enough or smartbranching is on
  reboot

 

(2) "if switchreset" and "if !switchreset" could be shortened by 2 bytes:

 

; currently compiles like this:
  lda #1
  bit SWCHB
; then checks with BNE or BEQ

; this saves 2 bytes:
  lsr SWCHB
; then check with BCC or BCS

 

(3) If batari Basic will always set the IRQ/BRK vector the same as the RESET vector, "reboot" could also be shortened by 2 bytes:

 

; currently compiles like this:
  JMP ($FFFC)

; this saves 2 bytes:
  BRK

(Thanks, Omegamatrix!)

 

Michael

#1 is a bug (the problem is a carriage-return character messing up the keyword detection.) I'm looking into a fix.

 

I've considered #2. The issue is that you are writing to a read-only register and I'm not sure if it's totally safe.

 

A BRK on #3 will work. I didn't make it permanently this way because I wasn't sure if future versions of bB were going to use the IRQ vector for other purposes. Since I still haven't used the IRQ vector, it may be safe to go ahead and change it.

[SeaGtGruff]

#1 is a bug (the problem is a carriage-return character messing up the keyword detection.) I'm looking into a fix.

I thought it probably was, because I seemed to recall it used to work fine that way.

 

I've considered #2. The issue is that you are writing to a read-only register and I'm not sure if it's totally safe.

I figured you might have thought of this, and I wasn't too sure about "LSR SWCHB" myself. But SWCHB isn't read-only, is it? Can't you configure the individual pins to be either input or output using SWBCNT? At least in theory, if not in actuality on the 2600 (since the "Stella Programmer's Guide" says it's hardwired for input only).

 

A BRK on #3 will work. I didn't make it permanently this way because I wasn't sure if future versions of bB were going to use the IRQ vector for other purposes. Since I still haven't used the IRQ vector, it may be safe to go ahead and change it.

On second thought, maybe you should leave "reboot" as "JMP ($FFFC)" in case you ever want to add a "break" command-- it would compile to just "BRK," obviously, but the compiler could set the IRQ vector to a user-defined address based on whether or not some equate has been declared, such as "brkvector." In fact, maybe "reboot" could compile to either "JMP ($FFFC)" or "BRK" based on whether or not that same equate has been declared?

[Master_Programmer]

I have one more question......what's a drawscreen wrapper?

 

even if i call drawscreen from a subroutine in the first bank, all i get is yellow blocks in the center of the screen.

[SeaGtGruff]

I have one more question......what's a drawscreen wrapper?

 

even if i call drawscreen from a subroutine in the first bank, all i get is yellow blocks in the center of the screen.

I'm not sure what you mean by "a drawscreen wrapper." What context did you hear it in?

 

What you describe about the yellow blocks sounds like it might be the dreaded "I made a multi-banked Superchip game but Stella doesn't know it" syndrome! If your game doesn't have some kind of entry that tells Stella what its properties are supposed to be, Stella will try its best to guess what the cartridge format is. However, it seems that Stella has a difficult time distinguishing between F8 and F8SC, or between F6 and F6SC, or between F4 and F4SC. So if you start up your game in Stella and get a bunch of yellow blocks, you should hit the TAB key, go to GAME PROPERTIES, and change the cartridge type from AUTO-DETECT to whatever it's supposed to be. After you've done that and returned to the game screen, press the BACKSLASH key and restart the game. As long as you don't modify and then recompile your game, Stella will remember your game's properties and will execute it properly the next time you play it. But if you do change your program-- even just a tiny bit-- and recompile it, it won't look the same to Stella anymore, and Stella will go back to using AUTO-DETECT for it, and you'll have to set the game properties all over again.

 

Michael

 

Edit: Or maybe you're specifically talking about DPC+ games, in which case you should just ignore everything I said and pretend it was the sound of the wind!

Edited April 28, 2011 by SeaGtGruff

[Master_Programmer]

I have one more question......what's a drawscreen wrapper?

 

even if i call drawscreen from a subroutine in the first bank, all i get is yellow blocks in the center of the screen.

I'm not sure what you mean by "a drawscreen wrapper." What context did you hear it in?

 

What you describe about the yellow blocks sounds like it might be the dreaded "I made a multi-banked Superchip game but Stella doesn't know it" syndrome! If your game doesn't have some kind of entry that tells Stella what its properties are supposed to be, Stella will try its best to guess what the cartridge format is. However, it seems that Stella has a difficult time distinguishing between F8 and F8SC, or between F6 and F6SC, or between F4 and F4SC. So if you start up your game in Stella and get a bunch of yellow blocks, you should hit the TAB key, go to GAME PROPERTIES, and change the cartridge type from AUTO-DETECT to whatever it's supposed to be. After you've done that and returned to the game screen, press the BACKSLASH key and restart the game. As long as you don't modify and then recompile your game, Stella will remember your game's properties and will execute it properly the next time you play it. But if you do change your program-- even just a tiny bit-- and recompile it, it won't look the same to Stella anymore, and Stella will go back to using AUTO-DETECT for it, and you'll have to set the game properties all over again.

 

Michael

 

Edit: Or maybe you're specifically talking about DPC+ games, in which case you should just ignore everything I said and pretend it was the sound of the wind!

 

I was talking about my 32k DPC+ secret project. DX

[Master_Programmer]

[*]You can't call drawscreen from another bank when using the DPC kernel, due to the DPC setup using a plain jsr. (workaround by creating a drawscreen wrapper function in bank1, and use "gosub drawwrapper bank1" instead of a drawscreen)

[RevEng]

[*]You can't call drawscreen from another bank when using the DPC kernel, due to the DPC setup using a plain jsr. (workaround by creating a drawscreen wrapper function in bank1, and use "gosub drawwrapper bank1" instead of a drawscreen)

 

I have one more question......what's a drawscreen wrapper?

 

A wrapper is program code that exists solely for the purpose of interfacing to other program code.

 

I was talking about a structure that looks something like the following...

 

rem bank 1
rem ** some program initialization goes here
goto mainloop bank2

drawwrapper
drawscreen
return otherbank

bank 2

mainloop
if joy0up then player0y=player0y-1
rem ** call our wrapper instead of directly calling "drawscreen"
gosub drawwrapper bank1
goto mainloop

 

But since you say that drawscreen isn't working for you in the first bank, a lack of wrapper isn't the problem you've run into.

[SeaGtGruff]

[*]You can't call drawscreen from another bank when using the DPC kernel, due to the DPC setup using a plain jsr. (workaround by creating a drawscreen wrapper function in bank1, and use "gosub drawwrapper bank1" instead of a drawscreen)

Okay, what that's saying is to create a subroutine in bank1. All you need in the subroutine is "drawscreen : return" and you can call the subroutine whatever you like.

 

screendraw
draw_screen
drawthescreen
drawthestupidscreenalready
    drawscreen
    return

Then you just call that subroutine from some other bank:

 

    gosub drawthestupidscreenalready bank1

Michael

 

PS -- I guess I forgot to put "otherbank" on that "return." It should still work as just "return," but will take longer.

Edited April 28, 2011 by SeaGtGruff

[Master_Programmer]

[*]You can't call drawscreen from another bank when using the DPC kernel, due to the DPC setup using a plain jsr. (workaround by creating a drawscreen wrapper function in bank1, and use "gosub drawwrapper bank1" instead of a drawscreen)

 

I have one more question......what's a drawscreen wrapper?

 

A wrapper is program code that exists solely for the purpose of interfacing to other program code.

 

I was talking about a structure that looks something like the following...

 

rem bank 1
rem ** some program initialization goes here
goto mainloop bank2

drawwrapper
drawscreen
return otherbank

bank 2

mainloop
if joy0up then player0y=player0y-1
rem ** call our wrapper instead of directly calling "drawscreen"
gosub drawwrapper bank1
goto mainloop

 

But since you say that drawscreen isn't working for you in the first bank, a lack of wrapper isn't the problem you've run into.

 

then what is?

 

*posts sourcecode*

PSYCHO.BAS

[Master_Programmer]

[*]You can't call drawscreen from another bank when using the DPC kernel, due to the DPC setup using a plain jsr. (workaround by creating a drawscreen wrapper function in bank1, and use "gosub drawwrapper bank1" instead of a drawscreen)

Okay, what that's saying is to create a subroutine in bank1. All you need in the subroutine is "drawscreen : return" and you can call the subroutine whatever you like.

 

screendraw
draw_screen
drawthescreen
drawthestupidscreenalready
    drawscreen
    return

Then you just call that subroutine from some other bank:

 

    gosub drawthestupidscreenalready bank1

Michael

 

PS -- I guess I forgot to put "otherbank" on that "return." It should still work as just "return," but will take longer.

 

it doesn't matter.

i just get a black screen.....

 

...i have one more thing to try.......hang on......

[Master_Programmer]

okay, everything works, except the background is ALL YELLOW.

 

but even then, i think i know why that is.

[Master_Programmer]

okay, the background is completely screwed up.

 

the playfield is white lines, with a yellow background.

 

even when i set it otherwise.

[Byte Knight]

I'm having some difficulty understanding the push, pull, and stack functions of the latest beta. How exactly does this give you extra variables if you still only have a-z? Is there an example (like storing a sprite's offscreen x and y coordinates) that someone could post?

 

Thanks!

[+batari]

I'm having some difficulty understanding the push, pull, and stack functions of the latest beta. How exactly does this give you extra variables if you still only have a-z? Is there an example (like storing a sprite's offscreen x and y coordinates) that someone could post?

 

Thanks!

My thoughts were that it could be most useful for storing variables that don't change very often. Player coordinates probably wouldn't be the best use of the stack. Some examples could be a player's inventory, which might change only when items are used or found. Then, you could push your more volatile variables to the stack, and swap in your inventory.

 

It might work like this:

 push a-z
 stack 214 ; second set of a-z
 pull a-z

; do stuff with second a-z

 push a-z
 stack 241
 pull a-z

; regular variables recovered

The above will take some time - I'm not sure how much offhand but it would be best to not do anything else during that particular frame. Also, reducing the number of variables swapped out would be better.

 

Also, if you only need 6 variables at a time, you could use the temp variables to swap them in and wouldn't need to swap the main variables in. This assumes you've already initialized 6 variables and pushed them to the stack:

 pull temp1-temp6
 ; work with variables
 push temp1-temp6

I think temp1-temp6 will work - if not, they should, so let me know and I can fix it.

 

EDIT: A few corrections above.

Edited May 12, 2011 by batari

[Byte Knight]

I suppose another way to get more variables would be to use some of the extra player#x and player#y variables and just not define the sprites...

[Byte Knight]

So I've managed to get a simple playfield picture up on the screen, but the left side is shifted one pixel. Any idea why? I'm using the 1.1 beta release B...

 

 

dpc.bas

[jwierer]

So I've managed to get a simple playfield picture up on the screen, but the left side is shifted one pixel. Any idea why? I'm using the 1.1 beta release B...

 

dpc.bas

Try sticking to these resolutions

 

http://www.atariage.com/forums/topic/176401-next-version-of-bb/page__view__findpost__p__2253460

 

 

-Jeff

[RevEng]

The alignment thing was reported in this post. batari just hasn't rolled out an update with all of his fixes yet.

[Byte Knight]

Try sticking to these resolutions

 

http://www.atariage.com/forums/topic/176401-next-version-of-bb/page__view__findpost__p__2253460

 

I did, using a resolution of 36 and a DF(0-3)FRACINC of 52.

 

The alignment thing was reported in this post. batari just hasn't rolled out an update with all of his fixes yet.

 

Ah, I assumed since batari said it was "fixed" that it was in his latest version... Thanks - I'll plow ahead with some uneven lines.

[Byte Knight]

Here is my latest problem - I've modified a game that I've been working on in the Superchip kernel to DPC+. When I try to compile I get this:

 

-467 bytes of ROM space left in graphics bank

segment: 7fd4 eqm vs current org: 81a7

game.bas.asm (9267): error: Origin Reverse-indexed.

 

It appears that there is not enough space in the graphics bank. What exactly goes in this bank and how can I free up more space?

[Byte Knight]

Don't know if this is a bug, but I can't even get it to display the ball...

 

dpctest.bas

Edited May 15, 2011 by Byte Knight

[RevEng]

The ball is embedded in the castle - try bally=90 and you'll see it.

 

Don't forget that you have twice the y resolution as the other kernels.

[+Gemintronic]

This might sound obvious but I've yet to hear it from a definitive source..

 

If someone manages to get a complete game working on the DPC+ kernel can Al make a cartridge now?

[cd-w]

This might sound obvious but I've yet to hear it from a definitive source..

If someone manages to get a complete game working on the DPC+ kernel can Al make a cartridge now?

 

Yes - it can be made using a Melody board.

 

Chris

[+Random Terrain]

Yes - it can be made using a Melody board.

Speaking of that, the bB page mentions and links to the Melody board page:

 

www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#harmony