22 replies to this topic

[batari]

Here's Alpha 0.3. I am crossing my fingers that there won't be too many bugs. I haven't had much time to test everything, so it's possible that some of the new features have bugs or even fatal bugs without workarounds.

But the good news is that the Alpha 0.2 bugs have been fixed, or at least I believe they have been.

One thing I should note about porting your 0.2a programs to 0.3a:
bit access now uses {braces} instead of parens because I wanted to use parentheses for user functions, and I couldn't figure out a way to tell the difference. I thought is made more sense that functions should use parens, since this is pretty much standard across the board.

Other bugs, such as the inverted bit operations and collisions, now work as they should. So you need to change these and any other workarounds for the Alpha 0.2 bugs.

I know there will be bugs in the new stuff, and thanks to all for bearing with me until bB matures. The sooner the bugs are found, the sooner they will be fixed. Enjoy!

Attached Files

•  batari_basic_alpha3_source.zip   16.04KB   125 downloads
•  batari_basic_alpha3.zip   235.19KB   158 downloads

Edited by batari, Tue Aug 23, 2005 5:37 AM.

[Random Terrain]

Thanks. Did you say that you only need to make a quick adjustment to the IDE for this to work with it?

[batari]

Thanks. Did you say that you only need to make a quick adjustment to the IDE for this to work with it?

Yes, and I included the new file you need in the zip above. It's the 2600baside.bat file.

I do think that 2600ide should be updated though, as the DOS screen really shouldn't disappear. It not only displays how many bytes are free, but also it now has useful information about any errors it finds. I don't know if there's a workaround for this or not.

I just noticed that the sample.bas file was screwy so I fixed it above. It's still a pretty simple sample but a little bit more complicated - it contains a few weird code sequences for no other reason than to show how they work.

[Random Terrain]

I must be doing something wrong because the screen is flipping or flashing (using Stella), it's hard to tell which. The score looks like it is flashing on and off.

[batari]

I must be doing something wrong because the screen is flipping or flashing (using Stella), it's hard to tell which. The score looks like it is flashing on and off.

I found problems in sample.bas, so I updated the posts above. I think you're the only one who got the funky sample.bas - The screen in this one will indeed flash. In the fixed sample, it only flashes when the two sprites collide, which is what I intended to do.

[Random Terrain]

I should have said that I was using one of my own programs. I'll try your sample program and see what happens.

[Dan Iacovelli]

I noticed the help file has most of the info highlighed in black.
is it only me or does everybody else see this.

Edited by Dan Iacovelli, Tue Aug 23, 2005 9:50 AM.

[Random Terrain]

Here's an example of something that works OK with the old version, but messes up using the new:

 rem * Create alias for each variable.
  dim blockx = a
  dim blocky = b
  dim delay = d

  rem * Setup.
  COLUPF = 90 : delay = 0
  blockx = 16 : blocky = 5


  rem * Main game loop starts here.
gameloop

  scorecolor = 158
  drawscreen

  rem * Begin delay.
  delay = delay + 1
  if delay < 3 then goto gameloop
  delay = 0
  rem * End delay.

  rem * Delete block and move it to new position.
  pfpixel blockx blocky off
  if joy0up && blocky > 1 then blocky = blocky - 1
  if joy0down && blocky < 10 then blocky = blocky + 1
  if joy0left && blockx > 1 then blockx = blockx - 1
  if joy0right && blockx < 31 then blockx = blockx + 1
  if joy0fire then score = score + 1
  pfpixel blockx blocky on

  goto gameloop

It's just a simple thing that lets you move a block around the screen with the joystick and it seems like it would work with either version. Is it just my computer or does the Stella screen mess up when you run that with the new version of bB? This question is for anyone reading this post. Does the code work for you?

Thanks. I'll be back tonight.

Edited by Random Terrain, Wed Sep 7, 2005 11:10 PM.

[vdub_bobby]

My work in progress also wouldn't work under the new bB; I did some playing around trying to isolate the problem and, though I still don't know what is going on, I did discover that this rather simple program does not run correctly. Don't know why:

 rem smartbranching on



  rem init setup
  scorecolor = $0E

MainLoop

  drawscreen


  goto MainLoop

Help?

[Dan Iacovelli]

Here's an example of something that works OK with the old version, but messes up using the new:

 rem * Create alias for each variable.
  dim blockx = a
  dim blocky = b
  dim savex = c
  dim savey = d
  dim delay = e

  rem * Setup.
  COLUPF = 90 : delay = 0
  blockx = 16 : blocky = 5
  savex = 16 : savey = 5

  rem * Main game loop starts here.
gameloop

  scorecolor = 158
  drawscreen

  rem * Begin delay.
  delay = delay + 1
  if delay < 3 then goto gameloop
  delay = 0
  rem * End delay.

  rem * Delete block and move it to new position.
  if joy0up && blocky > 1 then savey = savey - 1
  if joy0down && blocky < 10 then savey = savey + 1
  if joy0left && blockx > 1 then savex = savex - 1
  if joy0right && blockx < 31 then savex = savex + 1
  if joy0fire then score = score + 1
  pfpixel blockx blocky off
  blockx  = savex : blocky = savey
  pfpixel blockx blocky on

  goto gameloop

It's just a simple thing that lets you move a block around the screen with the joystick and it seems like it would work with either version. Is it just my computer or does the Stella screen mess up when you run that with the new version of bB? This question is for anyone reading this post. Does the code work for you?

Thanks. I'll be back tonight.

I don't get anything on it I use Z26.

[Dan Iacovelli]

on side note:
when I tried to do my game in the new version the screen was jumping.

[vdub_bobby]

I think I've found the problem: if missile0height and missile1height are zero or one (edit), the kernel breaks. Zero also happens to be the default value of those two variables, so if you do not define them explicitly, the kernel will break.

This will not work:

 rem smartbranching on
  rem init setup
  scorecolor = $0E
  rem missile0height = 2
  rem missile1height = 2
MainLoop drawscreen
  goto MainLoop

And this will not work:

 rem smartbranching on
  rem init setup
  scorecolor = $0E
  missile0height = 0
  missile1height = 1
MainLoop drawscreen
  goto MainLoop

But this works just fine:

 rem smartbranching on
  rem init setup
  scorecolor = $0E
  missile0height = 2
  missile1height = 2
MainLoop drawscreen
  goto MainLoop

This seems like something worth fixing or at least documenting...I'm assuming it isn't documented, of course

Anyway, moral of story: Make sure to define missile0height and missile1height as greater than one!

Edited by vdub_bobby, Tue Aug 23, 2005 11:26 AM.

[Dan Iacovelli]

the following code gives me screen flicker in the new version DB:

1 rem smartbranching on
5 dim shipx=x
        dim shipy=y
        dim ship2x=a
        dim ship2y=b
6 dim missilex=c
        dim missiley=d
        dim life=l
10 shipx=45: shipy=82
46 player1:
      %00111110
    %01000001
    %00100010
    %00010100
    %00001000
end
50 pfhline 1 1 30

60 drawscreen
70 COLUP1=120 : COLUPF=120:player1x=shipx: player1y=shipy
80 if joy0left then shipx=shipx-1
90 if joy0right then shipx=shipx+1
  goto 60

I erased most of my code from my game but this is the basic.

Edited by Dan Iacovelli, Tue Aug 23, 2005 12:21 PM.

[vdub_bobby]

Just to be clear, you can't do this, correct?

 if FrameCounter & 7 = 0 then Temp = 0

I get all kinds of weird errors when I do this.

Instead, I have to do this:

 Temp2 = FrameCounter & 7
  if Temp2 = 0 then Temp = 0

Is that correct?

[batari]

I think I've found the problem: if missile0height and missile1height are zero or one (edit), the kernel breaks.  Zero also happens to be the default value of those two variables, so if you do not define them explicitly, the kernel will break.

This will not work:

 rem smartbranching on
  rem init setup
  scorecolor = $0E
  rem missile0height = 2
  rem missile1height = 2
MainLoop drawscreen
  goto MainLoop

And this will not work:

 rem smartbranching on
  rem init setup
  scorecolor = $0E
  missile0height = 0
  missile1height = 1
MainLoop drawscreen
  goto MainLoop

But this works just fine:

 rem smartbranching on
  rem init setup
  scorecolor = $0E
  missile0height = 2
  missile1height = 2
MainLoop drawscreen
  goto MainLoop

This seems like something worth fixing or at least documenting...I'm assuming it isn't documented, of course

Anyway, moral of story: Make sure to define missile0height and missile1height as greater than one!

Ouch! That's a pretty bad bug... but I know why it's happening - it was my attempt to save cycles in the kernel. I have fixed it, and I should probably post a quick update because this will break a lot of games. Until then, you can fix it yourself by editing the std_kernel.asm file, and changing the two "dex" instructions near the top of the file (lines 9 and 11) to "inx" and changing the adc #3 on line 170 to adc #4

I've started looking into the problem with bit access that vdub_bobby pointed out, and yes, I have confirmed this bug and I'm looking into the cause.

Edited by batari, Tue Aug 23, 2005 4:24 PM.

[vdub_bobby]

Ouch!  That's a pretty bad bug... but I know why it's happening - it was my attempt to save cycles in the kernel.  I have fixed it, and I should probably post a quick update because this will break a lot of games.  Until then, you can fix it yourself by editing the std_kernel.asm file, and changing the two "dex" instructions near the top of the file (lines 9 and 11) to "inx"

I've started looking into the problem with bit access that vdub_bobby pointed out, and yes, I have confirmed this bug and I'm looking into the cause.

Now that's service!

Thanks, batari

[Random Terrain]

Just to be clear, you can't do this, correct?

 if FrameCounter & 7 = 0 then Temp = 0

I get all kinds of weird errors when I do this.

Instead, I have to do this:

 Temp2 = FrameCounter & 7
  if Temp2 = 0 then Temp = 0

Is that correct?

Shouldn't that be two && not just one &? Oh, you're doing something different.

Edited by Random Terrain, Tue Aug 23, 2005 4:36 PM.

[supercat]

I'll have to download bB and start playing with it. Seems very promising. Biggest limitation I can see at this point is that games don't get much memory for their own use even when using a custom kernel (though I suppose it should be possible to reclaim the memory for the playfield).

Did you see my earlier suggestion (a few weeks ago) about display lists? Did you understand it?

One thing I was just thinking might be an interesting kernel idea would be to do something along the lines of a Stellar Track kernel for people who want to do "hunt the wumpus" and similar games. Because it would be prohibitively expensive to keep an image of the text screen in memory, what Stellar Track does is store the strings in ROM, with a character code 255 to mark newlines and 254 to mark places where something needs to be "inserted" from RAM. The RAM data are then stored consecutively to fill in the inserts. Thus, the starting message is stored in ROM as [something like] "YOUR MISSIONIS TO KILL@## ALIENS@WITHIN ##@STARDATES" [using # to mark code 255 and @ to mark code 254]. Don't know if such a kernel would be worth the effort, but it might be somewhat cute.

[batari]

Did you see my earlier suggestion (a few weeks ago) about display lists?  Did you understand it?

I must have missed this - it doesn't ring a bell.

One thing I was just thinking might be an interesting kernel idea would be to do something along the lines of a Stellar Track kernel for people who want to do "hunt the wumpus" and similar games.  Because it would be prohibitively expensive to keep an image of the text screen in memory, what Stellar Track does is store the strings in ROM, with a character code 255 to mark newlines and 254 to mark places where something needs to be "inserted" from RAM.  The RAM data are then stored consecutively to fill in the inserts.  Thus, the starting message is stored in ROM as [something like] "YOUR MISSIONIS TO KILL@## ALIENS@WITHIN ##@STARDATES" [using # to mark code 255 and @ to mark code 254].  Don't know if such a kernel would be worth the effort, but it might be somewhat cute.

I've thought about this - it would be interesting to add a print statement, but of course the statement would do nothing unless you were using the stellar-track type kernel.

I'll try to find your old post, because the characters need to be in ROM of course, and this was the reason I didn't think about it too hard.

[supercat]

I'll try to find your old post, because the characters need to be in ROM of course, and this was the reason I didn't think about it too hard.

The display-list concept wasn't for character-based games. That's a new idea I just had yesterday when the fact came up that Robinett Basic could do "PRINT" and Batari Basic can't.

The display list concept would allow the user to supply a list giving the height and source address for each playfield "row". Instead of having eleven rows of playfield data that are sixteen pixels high, a programmer could have e.g. one that's 16 high, four that are eight high, one that is 80 high, another four that are eight high, and one that's 16 high (e.g. for a tank-blasting game where the players sit at the top and bottom of the screen behind "shields), or one could have a row that's 16 high, followed by nine that are 8 high, followed by one that's 96 high (e.g. for a "Breakout"-style game).

My preferred implementation would probably be to have the display list contain pairs of numbers where the first item in each pair would be the number of double-lines minus one, and the second would be the RAM address where the data should be found. Specifying the RAM address may or may not be worthwhile; it would allow some extra versatility if non-active rows of display data could be duplicated, and it would allow some interesting special effects, but it might also cause confusion. Having a means of specifying ROM addresses as well might be interesting, but would probably complicate things too much to be useful in-kernel.

I haven't looked at your kernel code, but I would think it should be possible to handle display lists if you used a striped playfield, and if you unrolled one level of looping (so that the first line-pair of a display-list item would use special code), meaning the minimum display-list-item size would be two line-pairs. A game like "Man Goes Down" (but without the pretty colored fruits) could be implemented either by having many display lists in ROM and switching between them, or by putting the display list in RAM.

If your kernel is already using four temp locations to hold the current row of playfield data (I would guess that it probably must) the only extra RAM required for display-list support would be two bytes to hold the display-list pointer. If you can spare that space, adding display lists could greatly improve the versatility of what already seems to be a very promising platform.

[batari]

I'll try to find your old post, because the characters need to be in ROM of course, and this was the reason I didn't think about it too hard.

The display-list concept wasn't for character-based games. That's a new idea I just had yesterday when the fact came up that Robinett Basic could do "PRINT" and Batari Basic can't.

The display list concept would allow the user to supply a list giving the height and source address for each playfield "row". Instead of having eleven rows of playfield data that are sixteen pixels high, a programmer could have e.g. one that's 16 high, four that are eight high, one that is 80 high, another four that are eight high, and one that's 16 high (e.g. for a tank-blasting game where the players sit at the top and bottom of the screen behind "shields), or one could have a row that's 16 high, followed by nine that are 8 high, followed by one that's 96 high (e.g. for a "Breakout"-style game).

My preferred implementation would probably be to have the display list contain pairs of numbers where the first item in each pair would be the number of double-lines minus one, and the second would be the RAM address where the data should be found. Specifying the RAM address may or may not be worthwhile; it would allow some extra versatility if non-active rows of display data could be duplicated, and it would allow some interesting special effects, but it might also cause confusion. Having a means of specifying ROM addresses as well might be interesting, but would probably complicate things too much to be useful in-kernel.

I haven't looked at your kernel code, but I would think it should be possible to handle display lists if you used a striped playfield, and if you unrolled one level of looping (so that the first line-pair of a display-list item would use special code), meaning the minimum display-list-item size would be two line-pairs. A game like "Man Goes Down" (but without the pretty colored fruits) could be implemented either by having many display lists in ROM and switching between them, or by putting the display list in RAM.

If your kernel is already using four temp locations to hold the current row of playfield data (I would guess that it probably must) the only extra RAM required for display-list support would be two bytes to hold the display-list pointer. If you can spare that space, adding display lists could greatly improve the versatility of what already seems to be a very promising platform.

I remember your post now. That could be done without too much trouble because of the way the code is written. The blank line just loads a counter with 8, so instead this could load from an indexed table or something. But since there is no scanline counter in the kernel, the compiler would need to ensure that the total sum of the display list values is correct. I'd just need to find a couple of cycles, really. The display list will not fit in RAM, however, it would have to be hard-coded into ROM at compile time.

Maybe I'll do this soon - it should be easy enough.

But yeah, the display list concept could also work with printed characters on screen.

[batari]

Just testing out the fixed point math... Just by making this simple example using inertia, I found that 4.4 types aren't working quite right so I used 8.8 for everything. It looks like these basically work.

By playing around, though, I can see room for improvement the fixed point math implementation.

Also, include isn't working either... if you use include, your program won't work at all I fixed this - like all bugs so far, it was something simple/stupid. If you need to include something, use an includes file for now.

Attached Files

•  inertia.bas   974bytes   123 downloads
•  inertia.bas.bin   4KB   124 downloads

[potatohead]

I'll have to download bB and start playing with it.  Seems very promising.  Biggest limitation I can see at this point is that games don't get much memory for their own use even when using a custom kernel (though I suppose it should be possible to reclaim the memory for the playfield).

Did you see my earlier suggestion (a few weeks ago) about display lists?  Did you understand it?

One thing I was just thinking might be an interesting kernel idea would be to do something along the lines of a Stellar Track kernel for people who want to do "hunt the wumpus" and similar games.  Because it would be prohibitively expensive to keep an image of the text screen in memory, what Stellar Track does is store the strings in ROM, with a character code 255 to mark newlines and 254 to mark places where something needs to be "inserted" from RAM.  The RAM data are then stored consecutively to fill in the inserts.  Thus, the starting message is stored in ROM as [something like] "YOUR MISSIONIS TO KILL@## ALIENS@WITHIN ##@STARDATES" [using # to mark code 255 and @ to mark code 254].  Don't know if such a kernel would be worth the effort, but it might be somewhat cute.

I'm liking this idea for a more flexible playfield.

You can claim the playfield memory this way:

dim extravariable=playfield+44 {45, 46, 47}

One question I had was this:

Assuming extravariable has been defined as shown above, is extravariable[index] now legal?