Jump to content
RevEng

bB with native 64k cart support - 1.1d.reveng

Recommended Posts

Excellent!

 

I had another dasm update, so I'll probably update bB with the dummy "sed.exe" and the new dasm version (assuming it sticks) later today.

  • Like 1

Share this post


Link to post
Share on other sites

Version 35 is in the first post.

  • fixed a bug where dim and const would screw up if you used a : command separator after them.
  • enhanced install_win.bat so it works if you try to switch back and forth between one bB directory and another.
  • dropped in the latest dasm.
  • Like 3

Share this post


Link to post
Share on other sites

Version 35 is in the first post.

  • fixed a bug where dim and const would screw up if you used a : command separator after them.

 

 

Does that mean we can use rems after dims now:

.

  dim _Monkey_Brains = a : rem Keeps track of how many brains have been eaten.

Share this post


Link to post
Share on other sites

Yup. That's exactly what I was trying to do when I ran into the bug.

 

I'm sure at some point I learned to avoid rems after dim's, and eventually forgot again.

  • Like 1

Share this post


Link to post
Share on other sites

Yup. That's exactly what I was trying to do when I ran into the bug.

 

I'm sure at some point I learned to avoid rems after dim's, and eventually forgot again.

 

Seems like we've been waiting a long time for that ability. Nice that it's finally here.

 

I have a question. Is it correct to use a semicolon in place of a colon and rem after some code? For example, this compiles:

.

   a = 5 ; I Like Pizza

.

If that is a legal use of a semicolon, then maybe we could use this too:

.

  dim _Monkey_Brains = a ; Keeps track of how many brains have been eaten.

Share this post


Link to post
Share on other sites

Yup, your usage of ";" is spot on, and it definitely works.

 

Fixing dim and const separators was mostly for consistency, but it's worth mentioning there's a subtle difference between the two commenting styles. When you use ";" and "/* */" comments, the comments don't show up in the generated assembly code. When you use "rem" they do.

 

So I personally tend to use "rem" for single-line comments, even though ";" is a lot easier to type.

  • Like 1

Share this post


Link to post
Share on other sites

Yup, your usage of ";" is spot on, and it definitely works.

 

Fixing dim and const separators was mostly for consistency, but it's worth mentioning there's a subtle difference between the two commenting styles. When you use ";" and "/* */" comments, the comments don't show up in the generated assembly code. When you use "rem" they do.

 

So I personally tend to use "rem" for single-line comments, even though ";" is a lot easier to type.

 

Thanks. I'll update the bB page with that info and do some rearranging while I'm at it. I think this section should be deleted and the stuff from it should be moved here.

Share this post


Link to post
Share on other sites

Version 36 is in the first post.

  • fixed a bug where ; comments would sometimes eat the line below, and always threw off the line number used for error reporting.
  • added var0->var8 variables to DPC+ include file. Your DPC+ programs can now use these variables.
  • increased sub-statement size and count limits. this should push back the on...goto/gosub limits and allow for very long variable names.
  • Like 3

Share this post


Link to post
Share on other sites

Thank again, RevEng!

I've starting saying that the batari Basic DPC+ kernel has 35 variables.

(Now if only "stack" use routines, other than what is documented, could be programmed. ;) )

Share this post


Link to post
Share on other sites

My pleasure, guys!

I love more variables. I keep hoping that one day you'll find a way to have var0-var47. If that ever happens, I'll be able to make just about any game I can think of.

Share this post


Link to post
Share on other sites

I love more variables. I keep hoping that one day you'll find a way to have var0-var47. If that ever happens, I'll be able to make just about any game I can think of.

 

Bah! Real men only use boolean values and scrape bytes from the joystick ports :P

  • Like 2

Share this post


Link to post
Share on other sites
  • added var0->var8 variables to DPC+ include file. Your DPC+ programs can now use these variables.

See if you guys like the wording in these two sections:

 

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

 

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

 

  • Like 1

Share this post


Link to post
Share on other sites

 

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

I know this is anal but you specifically asked about the wording.. I think you changed the tone to be too much like a conversation. I'm not sure if I should be taking the information as a personal comment or instruction fact :)

Share this post


Link to post
Share on other sites

I think the tone of the whole site is pretty informal, so I don't think it's out of place. But I found it was harder to parse than it might otherwise be because of historic information (Reveng found) being included in the good/bad distinction, and as someone learning the language I just want to know the current state of affairs. I also think it's a bit easier to read if you group good and bad together...

 

The bad news is that there are only 35 variables - a to z, and var0 to var8 - though you may free up more memory by killing off sprites with dpcspritemax. Another slight bit of bad news is that we can't put data values directly into playfield variables. DPC+ uses ARM memory for the playfield and bB can't access the playfield without using playfield:, pfpixel, pfvline or pfhline.

 

The good news is that pfpixel, pfvline, pfhline, pfread, pfclear, and pfscroll are now supported by the DPC+ kernel. Also, the DPC+ kernel has an ARM-based 32-bit LFSR for improved random numbers, so "dim rand16 = <var>" is no longer needed when using this kernel. That's one variable we don't have to waste.

 

...its also worth mentioning that both iesposta and bogax have been updating the DPC+ playfield without the pf functions. It's not exactly direct PF memory access like we have with the non-DPC+ kernels, but it's close. Hopefully one of them can provide a brief example.

  • Like 2

Share this post


Link to post
Share on other sites

I think the tone of the whole site is pretty informal, so I don't think it's out of place. But I found it was harder to parse than it might otherwise be because of historic information (Reveng found) being included in the good/bad distinction, and as someone learning the language I just want to know the current state of affairs. I also think it's a bit easier to read if you group good and bad together...

 

The bad news is that there are only 35 variables - a to z, and var0 to var8 - though you may free up more memory by killing off sprites with dpcspritemax. Another slight bit of bad news is that we can't put data values directly into playfield variables. DPC+ uses ARM memory for the playfield and bB can't access the playfield without using playfield:, pfpixel, pfvline or pfhline.

 

The good news is that pfpixel, pfvline, pfhline, pfread, pfclear, and pfscroll are now supported by the DPC+ kernel. Also, the DPC+ kernel has an ARM-based 32-bit LFSR for improved random numbers, so "dim rand16 = <var>" is no longer needed when using this kernel. That's one variable we don't have to waste.

 

...its also worth mentioning that both iesposta and bogax have been updating the DPC+ playfield without the pf functions. It's not exactly direct PF memory access like we have with the non-DPC+ kernels, but it's close. Hopefully one of them can provide a brief example.

 

Thanks. Here's the updated section:

 

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

 

 

Does this also need to be changed:

 

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

  • Like 3

Share this post


Link to post
Share on other sites

Yeah, I think it probably should be changed similarly.

 

I really do appreciate that you try to attribute everything. In this case since it's a language feature we can skip it. :)

  • Like 1

Share this post


Link to post
Share on other sites

About the direct PF updating.

pfpixel probably compiles to what we are doing, although our advantage is doing a bit more a little faster, probably due to the fact you can change a whole byte, 8 pixels, at a time.

Both ways use the ARM routines, and doing too much playfield at once will run over cycle and crash.

Also our technique and pf[pixel] routines use lots of cycles and ROM space.

You also have to remember that the 2nd & 4th PF columns are backwards in hardware, bBasic hides that by reversing bytes when needed.

Share this post


Link to post
Share on other sites

Check out the getting started section of Random Terrain's bB site.

 

There's little more to installing than double-clicking the included batch file, but keep in mind bB is a command line program. RT's site also has info on the vbb GUI front-end IDE.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...