Robert M's Blog

neato

Recommendations for improving bBasic:

-> The language really needs an ON...GOSUB statement in addition to the ON...GOTO. I was forced to use a clumsy system of gotos to get back to the mainloop of code from the frame setup routines. The resulting code is brittle and harder to read. Plus I can't reuse my frame routines in a different on...goto statement.

I think Fred/batari is going to have "on...gosub" in the next version, because it turns out that it's easy to implement. However, in the meantime there *is* a way to reuse your routines in other "on...goto" statements. First, put your "on...goto" statements in their own subroutines, so you can "gosub" to the one you want. But you do *not* need to put a "return" after each "on...goto" statement. (On the other hand, putting a "return" after each one *would* keep you from falling through if none of the "goto" branches are taken.) Then end each *frame* subroutine with "return":

 

   rem * Example 1
loop
  rem * some stuff
  if this then gosub here else gosub there
  drawscreen
  goto loop
here
  on something goto frame1 frame2 frame3
  return : rem * just to prevent unwanted fall-through
there
  on somethingelse goto frame1 frame2 frame3
  return
frame1
  rem * some stuff
  return
frame2
  rem * some stuff
  return
frame3
  rem * some stuff
  return

 

   rem * Example 2
loop1
  rem * some stuff
  gosub here
  drawscreen
  if this then goto loop2
  goto loop1
loop2
  rem * some stuff
  gosub here
  drawscreen
  if that then goto loop1
  goto loop2
here
  on something goto frame1 frame2 frame3
  return : rem * just to prevent unwanted fall-through
frame1
  rem * some stuff
  return
frame2
  rem * some stuff
  return
frame3
  rem * some stuff
  return

 

By the way, I concur with SpiceWare-- neato!

 

Michael

I think Fred/batari is going to have "on...gosub" in the next version, because it turns out that it's easy to implement.

Yeah, the code is in place and working, though not officially released yet. I remember making a DOS/Windows build with this functionality and sent it to someone in a PM but I may have posted it to the forum as well.

I think Fred/batari is going to have "on...gosub" in the next version, because it turns out that it's easy to implement.

Yeah, the code is in place and working, though not officially released yet. I remember making a DOS/Windows build with this functionality and sent it to someone in a PM but I may have posted it to the forum as well.

 

 

That's great news. I think ON...GOSUB will prove very useful. Do you have a planned release date?

I think Fred/batari is going to have "on...gosub" in the next version, because it turns out that it's easy to implement.

Yeah, the code is in place and working, though not officially released yet. I remember making a DOS/Windows build with this functionality and sent it to someone in a PM but I may have posted it to the forum as well.

 

 

That's great news. I think ON...GOSUB will prove very useful. Do you have a planned release date?

I quit planning release dates when I found I always underestimated how long everything took

 

That said, I've been meaning to release a 1.01 version that includes the changes since 1.0, which mostly consist of bugfixes and minor additions. The only thing stopping me is laziness at this point, as it will probably just take a couple of evenings to put all of the files together, modify the web site and write documentation for the new commands (there are 3 of them, I think.)

 

I also saw what you wrote in another entry about using custom kernels with bB. I think that's great and I wish more people would do that. bB can work well witg a custom kernel, allowing you to fill out the game logic with bB code. Compiled code will almost certainly be larger and slower than pure assembly, but I don't think it's that bad, and as long as you have the space and enough cycles in your overscan and vblank areas, it should work quite well.

 

Using custom kernels in bB isn't necessarily difficult. The easiest way is to simply paste one in as inline asm, but this is the least efficient way to do it and it probably isn't as useful as modularizing an existing kernel to be called with drawscreen by making your own includesfile, and use your own headers but modify them just enough so bB will build.

 

Doing so may require adding some variable equates or changing some to match those that bB expects. I can't think of all that is needed offhand, but bB will let you know if it tries to access an equate that doesn't exist (by failing in the assembly stage.) You don't need a-z, as bB can use any equate you specify, but you will probably want, at the very least, the score variables and pointers, temp variables (temp1-temp7, though not all are strictly needed) and maybe the random number variable, rand (and rand16 to use a 16-bit LFSR.))

First, put your "on...goto" statements in their own subroutines, so you can "gosub" to the one you want. But you do *not* need to put a "return" after each "on...goto" statement. (On the other hand, putting a "return" after each one *would* keep you from falling through if none of the "goto" branches are taken.) Then end each *frame* subroutine with "return"

 

That's a good work around. Thanks!