DPC+ Kernel Info Page?

[disjaukifa]

Hey Guys,

 

Trying to work with the DPC+ kernel at the moment and I can make heads or tails of some of it but other pieces are confusing to me. So far I've figured out the following and REMEMBER this could be wrong, this is just want I'm seeing on my machine:

 

1st. You can't use an of the var variables, meaning var0 ~ var47, just returns a compilation error.

2nd. It seems that pfclear do not work on the DPC+ kernel as well.

 

How do you clear the playfield? Also how to you define var0 ~ var47? Are they just not available or am I missing something? Does anyone have a reference page to DPC+ kernel (Random I'm thinking of you at the moment )

 

Thanks

[+Random Terrain]

There are random things mentioned in batari's blog and in this thread:

 

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

 

When batari has everything figured out and has the time, I assume he'll send me a bunch of new text to add to the bB page.

[disjaukifa]

Ok I read most of that and it did answer one of my questions about the variable. How do I draw the playfield and how do I clear the playfield? I'd like to use this kernel because of the increase in graphics and the stack is awesome, but it seems . . . picky I guess would be the correct term. Trying to just add something small to the code seem to cause un-expected things.

Edited September 12, 2011 by disjaukifa

[+Random Terrain]

Trying to just add something small to the code seem to cause un-expected things.

That's why I'm waiting until the official release before I use it. Trying to make a program that works without going over 262 scanlines is hard enough with the regular version of bB. I don't need more mysterious errors and unexpected things happening to make it even harder.

[disjaukifa]

Trying to just add something small to the code seem to cause un-expected things.

That's why I'm waiting until the official release before I use it. Trying to make a program that works without going over 262 scanlines is hard enough with the regular version of bB. I don't need more mysterious errors and unexpected things happening to make it even harder.

 

 

Then I think I'll stick with the other kernel till this on has been hammer out some more. Thanks for the information Random! Other question for you Random. If I used lets say var47 and dim it 8 times, can I use it for 8 booleans? I know a nibble is for if you only need to go to 15, then you can have one variable act as two, I just wanted to be sure that I could use a on variable as 8 separate ones.

 

 

Thanks

[+Random Terrain]

If I used lets say var47 and dim it 8 times, can I use it for 8 booleans? I know a nibble is for if you only need to go to 15, then you can have one variable act as two, I just wanted to be sure that I could use a on variable as 8 separate ones.

If you mean you want to use 8 different aliases for 8 bits of one variable, then yes. Here's an example:

 

  rem  ================================================================
  rem  -
  rem  -  Player0/Player1 direction bits.
  rem  -
  rem  ----------------------------------------------------------------

  dim BitOp_P0_P1_Direction = u
  dim Bit0_Player0_Direction_Up = u
  dim Bit1_Player0_Direction_Down = u
  dim Bit2_Player0_Direction_Left = u
  dim Bit3_Player0_Direction_Right = u
  dim Bit4_Player1_Direction_Up = u
  dim Bit5_Player1_Direction_Down = u
  dim Bit6_Player1_Direction_Left = u
  dim Bit7_Player1_Direction_Right = u



  if Bit0_Player0_Direction_Up{0} then blah blah blah

  if Bit2_Player0_Direction_Left{2} then blah blah blah

 

Check out the code for this example program:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#maze_32x23

Edited September 13, 2011 by Random Terrain

[disjaukifa]

If I used lets say var47 and dim it 8 times, can I use it for 8 booleans? I know a nibble is for if you only need to go to 15, then you can have one variable act as two, I just wanted to be sure that I could use a on variable as 8 separate ones.

If you mean you want to use 8 different aliases for 8 bits of one variable, then yes. Here's an example:

 

  rem  ================================================================
  rem  -
  rem  -  Player0/Player1 direction bits.
  rem  -
  rem  ----------------------------------------------------------------

  dim BitOp_P0_P1_Direction = u
  dim Bit0_Player0_Direction_Up = u
  dim Bit1_Player0_Direction_Down = u
  dim Bit2_Player0_Direction_Left = u
  dim Bit3_Player0_Direction_Right = u
  dim Bit4_Player1_Direction_Up = u
  dim Bit5_Player1_Direction_Down = u
  dim Bit6_Player1_Direction_Left = u
  dim Bit7_Player1_Direction_Right = u



  if Bit0_Player0_Direction_Up{0} then blah blah blah

  if Bit2_Player0_Direction_Left{2} then blah blah blah

 

Check out the code for this example program:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#maze_32x23

 

That answer my question! Ok one more question though, when you have the following:

 

if Bit0_Player0_Direction_Up{0} then blah blah blah, what is the value of that bit to be true? 1 or 0? My guess is 1, but I want to be sure.

 

Thanks

[+Random Terrain]

That answer my question! Ok one more question though, when you have the following:

 

if Bit0_Player0_Direction_Up{0} then blah blah blah, what is the value of that bit to be true? 1 or 0? My guess is 1, but I want to be sure.

Right. Check out the Did You Know? box here for more information:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#bit

[ScumSoft]

1st. You can't use an of the var variables, meaning var0 ~ var47, just returns a compilation error.

2nd. It seems that pfclear do not work on the DPC+ kernel as well.

 

How do you clear the playfield? Also how to you define var0 ~ var47? Are they just not available or am I missing something? Does anyone have a reference page to DPC+ kernel (Random I'm thinking of you at the moment )

1) Nope can't use them, they existed in the original to keep the playfield in ram and are now used for the virtual sprites stuff.

2) pfread, pfclear and pfscroll aren't implemented yet. To define a playfield either build it with pfpixel, pfvline x(start) y x(end), pfhline x(start) y x(end) or:

 

rem always set the DF#FRACINC at least once before attempting to draw
rem the playfields or backgrounds
 DF0FRACINC     = 16 ;16 = 11 rows of playfield, 32 is 22 ect
 DF1FRACINC     = 16 
 DF2FRACINC     = 16
 DF3FRACINC     = 16
 DF4FRACINC     = 32 ;PFcolors table, Always double the playfields
 DF6FRACINC     = 32 ;BKcolors table

bkcolors:
$1E
$2E
$3E
$4E
$5E
$6E
$7E
$8E
$9E
$AE
$BE
end
pfcolors:
$02
$04
$06
$08
$02
$04
$06
$08
$02
$04
$06
end
playfield:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

 rem and to clear the playfield just define an empty playfield:
playfield:
...............................
end

 

For defining multiple things to a variable for bit operations it's as easy as:

dim MULTIVAR = a

def Switch7=MULTIVAR{7}
def Switch6=MULTIVAR{6}
def Switch5=MULTIVAR{5}
def Switch4=MULTIVAR{4}
def Switch3=MULTIVAR{3}
def Switch2=MULTIVAR{2}
def Switch1=MULTIVAR{1}
def Switch0=MULTIVAR{0}

rem then to test if the switch is on
if switch1 then goto SWITCH1_is_on 

rem to test if a switch is off
if !switch1 then goto SWITCH1_is_off

rem be sure to watch your capitals, because a label with the same
rem spelling in it as a variable will confuse the compiler

SWITCH1_is_on ;is different then Switch1 and switch1

rem however
Switch1_is_on ;Will confuse the compiler since Switch1 is the same as the var Switch1
             ;and it will try to convert the label into an invalid instruction

 

Hope this helped.

Edited September 13, 2011 by ScumSoft

[disjaukifa]

1st. You can't use an of the var variables, meaning var0 ~ var47, just returns a compilation error.

2nd. It seems that pfclear do not work on the DPC+ kernel as well.

 

How do you clear the playfield? Also how to you define var0 ~ var47? Are they just not available or am I missing something? Does anyone have a reference page to DPC+ kernel (Random I'm thinking of you at the moment )

1) Nope can't use them, they existed in the original to keep the playfield in ram and are now used for the virtual sprites stuff.

2) pfread, pfclear and pfscroll aren't implemented yet. To define a playfield either build it with pfpixel, pfvline x(start) y x(end), pfhline x(start) y x(end) or:

 

rem always set the DF#FRACINC at least once before attempting to draw
rem the playfields or backgrounds
 DF0FRACINC     = 16 ;16 = 11 rows of playfield, 32 is 22 ect
 DF1FRACINC     = 16 
 DF2FRACINC     = 16
 DF3FRACINC     = 16
 DF4FRACINC     = 32 ;PFcolors table, Always double the playfields
 DF6FRACINC     = 32 ;BKcolors table

bkcolors:
$1E
$2E
$3E
$4E
$5E
$6E
$7E
$8E
$9E
$AE
$BE
end
pfcolors:
$02
$04
$06
$08
$02
$04
$06
$08
$02
$04
$06
end
playfield:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

 rem and to clear the playfield just define an empty playfield:
playfield:
...............................
end

 

For defining multiple things to a variable for bit operations it's as easy as:

dim MULTIVAR = a

def Switch7=MULTIVAR{7}
def Switch6=MULTIVAR{6}
def Switch5=MULTIVAR{5}
def Switch4=MULTIVAR{4}
def Switch3=MULTIVAR{3}
def Switch2=MULTIVAR{2}
def Switch1=MULTIVAR{1}
def Switch0=MULTIVAR{0}

rem then to test if the switch is on
if switch1 then goto SWITCH1_is_on 

rem to test if a switch is off
if !switch1 then goto SWITCH1_is_off

rem be sure to watch your capitals, because a label with the same
rem spelling in it as a variable will confuse the compiler

SWITCH1_is_on ;is different then Switch1 and switch1

rem however
Switch1_is_on ;Will confuse the compiler since Switch1 is the same as the var Switch1
             ;and it will try to convert the label into an invalid instruction

 

Hope this helped.

 

Scumsoft thank you for the example of how to get the playfield to appear on the screen. I'll mess with it tonight to see if I can get it working. Question for you guys, unlike a sprite that has to be in your main game loop, once a playfield has been drawn, you don't need to have it draw again in the main loop right? You only need to call it once from what I'm seeing in testing. Thanks!

Edited September 13, 2011 by disjaukifa

[ScumSoft]

Yup unlike the normal kernals the DPC+ remembers what your objects and playfield are.

Edited September 13, 2011 by ScumSoft

[disjaukifa]

Yup unlike the normal kernals the DPC+ remembers what your objects and playfield are.

 

!!!!!! You mean I don't have to have the sprite data in the main loop?

[+Random Terrain]

Yup unlike the normal kernals the DPC+ remembers what your objects and playfield are.

 

!!!!!! You mean I don't have to have the sprite data in the main loop?

The regular kernel doesn't need to have playfield data or sprite data in the main loop. Whatever you tell the playfield or sprites to look like before the main loop starts is what they'll look like forever until you tell them to look differently.

[disjaukifa]

Yup unlike the normal kernals the DPC+ remembers what your objects and playfield are.

 

!!!!!! You mean I don't have to have the sprite data in the main loop?

The regular kernel doesn't need to have playfield data or sprite data in the main loop. Whatever you tell the playfield or sprites to look like before the main loop starts is what they'll look like forever until you tell them to look differently.

 

. . . . Somehow . . . somehow . . . . I completely missed that fact when I started all of this . . .

 

Lets just say this . . . this is a major game changer for me. Major!

[+Random Terrain]

. . . . Somehow . . . somehow . . . . I completely missed that fact when I started all of this . . .

Next time I go to edit the bB page, I'll try to remember to add a Did You Know? box that mentions that.

[disjaukifa]

. . . . Somehow . . . somehow . . . . I completely missed that fact when I started all of this . . .

Next time I go to edit the bB page, I'll try to remember to add a Did You Know? box that mentions that.

 

Now your just trying to make me feel special