Official Home for batari Basic

[RevEng]

The batari Basic programming language now has a new home at github.

 

I discussed this change with @batari prior to making this move. We both felt it was important to give bB an official home again. At github batari basic gets backed up, changes are tracked, bugs are tracked, other programmers can easily contribute, it can be forked easily, etc. batari even suggested we go a step further and license the bB source code under the GPL, so we did! (your games are still your games, and the GPL doesn't attach to them)

 

For the latest batari Basic (v1.2 at the time of this writing) you can visit the batari Basic release page. The page where I hosted the now-defunct "reveng" fork now points to that release page.

 

A special thanks goes out to @Karl G who helped with OS X testing, and to @Nathan Strum who provided a monochrome version of his "built with bB" logo, which was used for the project logo.

 

Feel free to comment or ask questions about this change. If you have bug reports, I'd ask that they be submitted to either github or the AA bB bug report thread, and not brought up in this thread. I'd prefer github issues be used (since everything is tracked, conversations about bugs are threaded, etc) but I completely understand that not everybody wants to have a github account.

 

Lastly, 7800basic will be getting the same treatment. I just need a break, as the cleanup and prep for the bB move took more effort than expected.

 

[Omegamatrix]

Great job! This is an important step for BB's future. It's going to be so good to have it all consolidated to one place, and GitHub is the goto repository for most code development these days.

[+Random Terrain]

Here are a few questions:

 

Is the Unofficial MacOS 64-bit bB build included?

 

Should the bB page at my web site link to GitHub instead of the bB with native 64k cart support - 1.1d.reveng thread?

 

Should you change the title of this thread from "official home for batari Basic to "Official Home for batari Basic" so it will look better?

 

Is bataribasic.com going away?

 

Should most of the info from the bB page at my web site be moved there?

[+mksmith]

Great stuff @RevEng ?

 

I'll also update Atari Dev Studio once I get back from holidays.

[RevEng]

Thanks for the support, Omegamatrix and mksmith!

 

I capitalized this thread title as requested, RT. Here are the answers you seek...

 

• Is the Unofficial MacOS 64-bit bB build included? There are 32-bit and 64-bit binaries for each supported OS. (Windows, OS X, and Linux) The unofficial OS X 64-bit build that Karl G built isn't needed.
• Should the bB page at my web site link to GitHub? Yeah, that would be best.
• Is bataribasic.com going away? I'm not sure. Can you comment @batari?
• Should most of the info from the bB page at my web site be moved there? Nope. I added your site URL to the README.txt as the source of the official bB documentation. Your site is the home of the bB and 7800basic docs, and I don't intend for that to change, at least not until it doesn't suit you anymore.

 

[+Random Terrain]

Thanks. I'll make the link changes tonight or tomorrow and also remove the link to the Unofficial MacOS 64-bit bB build.

[+Muddyfunster]

11 hours ago, mksmith said:

Great stuff @RevEng ?

 

I'll also update Atari Dev Studio once I get back from holidays.

I really need to transition properly to this now DD is done.

[TwentySixHundred]

Just wondering if anyone else is have issues setting score fonts after the 1.2 update?

It's throwing me this compile error

segment:  1864          eqm       vs current org: 1894
 free ram: 0
 DPC free RAM= 603

score_graphics.asm.retroputer (3): error: Origin Reverse-indexed.

Errors were encountered during assembly.

 

[RevEng]

Entirely possible it's an issue, since that code was updated.  I'll look into it, but please use the bB bug thread for reports. (Or github)

[+Random Terrain]

Is this included in the latest version of bB or do people still need to download it if they want to use it?

 

atariage.com/forums/topic/230707-modifying-score-display/?do=findComment&comment=3109081

 

[RevEng]

For some reason that one wasn't on my radar. I knew that @Omegamatrix had mentioned producing a bB split score for cybearg, but I didn't know it was made public. When I get a chance, I'll have to compare and see if it can be rolled into the official dist.

 

Until then, It replaces the score_graphics.asm and DPC+ kernel, so it should stil work same as before.

[+mksmith]

Atari Dev Studio has been updated to the latest v1.2 release.

[RevEng]

I've updated github with the 1.3 release, which mainly incorporates:

 

• the DPC+ custom-score bug fix
• a few extra bytes of breathing room for the first DPC+ bank
• an updated DPC arm file (posted by SpiceWare in the forums) which should help with compatibility with old-firmware Encore carts

 

I wasn't able to incorporate Omegamatrix's split score for DPC+... a lot of the operations he changed to scrounge the required space weren't the same anymore. You can still, of course, use his custom files in your project directory, which will replace the official files.

[RevEng]

Hold off on updating to 1.3 for now. TwentySixHundred found a show-stopper bug. Thanks 

[RevEng]

Ok, I've reverted the byte scrounging for DPC+ for now, which was causing the bug. I've released v1.4.

 

A big thanks to TwentySixHundred for finding the bug in the first place, and helping with QA testing for v1.4. ?

[+mksmith]

Atari Dev Studio has been updated to use the bB 1.4 and 7800basic 0.7 releases.  

[RevEng]

I've put out a new release (v1.5) up at github.

 

mksmith found a longstanding bB and 7800basic bug with for...next using a step of -1 and end value of 0. The code to catch the loop going past zero wasn't sufficient.

I also took the opportunity to update to v2.20.13 of dasm, which has it's own extensive list of fixes from the previous version, many from yours truly.

 

Enjoy!

 

 

[EvoMikeUK]

Hello bB team, as development is now underway on this, could you please add 128kb Support for the Strandard Kernel please please please? Save Gaia is getting dangerously close to the 64KB limit and I have so much more I would to give the players?

Is this possible do you think?

Kindest thanks, Michael @ Generation2

[RevEng]

"development is now underway" is overstating the thing. The truth is I've been in bB bugfix mode for a while, and don't have intention to start adding enhancements, and introduce another round of bugfixing. Part of the reason for my setting up bB in a github organisation, instead as a personal github project, is I can add anyone to the organisation who demonstrates the desire and ability to enhance bB, and they'll be on equal footing to me.

 

I've moved on with other interests, like the 7800, and a hobby project shouldn't be a life sentence. As it is, the time I spend fixing bB is almost completely due to a sense of kinship with bB developers, and the happy circumstance that bB and 7800basic share the same underlying code for basic language constructs.

 

If 128k support were just a simple tweak or two, I'd do it. But the current bB bankswitching return code is based on the bank being encoded in the high nibble of the return address. This is very economic for stack bytes - otherwise you'd need to push the current bank onto the stack too, during a gosub operation. Doing this would also complicate the possible return cases that bB supports. On top of it all, extending the current EF/F8/F6/F4 scheme would waste twice the bytes in each bank for hotspots, and you'd still be stuck with less than 4k in the last bank for kernel and graphics. None of this is an argument against different bankswitch code being implemented, but rather, it's a lot more than I'm willing to take on.

 

TLDR? I'm not looking to do major rewrites to the bankswitch routines. If someone wants to do so, without breaking the majority of existing bankswitched games, they can do so and be welcomed to the bB team.

[EvoMikeUK]

4 hours ago, RevEng said:

"development is now underway" is overstating the thing. The truth is I've been in bB bugfix mode for a while, and don't have intention to start adding enhancements, and introduce another round of bugfixing. Part of the reason for my setting up bB in a github organisation, instead as a personal github project, is I can add anyone to the organisation who demonstrates the desire and ability to enhance bB, and they'll be on equal footing to me.

 

I've moved on with other interests, like the 7800, and a hobby project shouldn't be a life sentence. As it is, the time I spend fixing bB is almost completely due to a sense of kinship with bB developers, and the happy circumstance that bB and 7800basic share the same underlying code for basic language constructs.

 

If 128k support were just a simple tweak or two, I'd do it. But the current bB bankswitching return code is based on the bank being encoded in the high nibble of the return address. This is very economic for stack bytes - otherwise you'd need to push the current bank onto the stack too, during a gosub operation. Doing this would also complicate the possible return cases that bB supports. On top of it all, extending the current EF/F8/F6/F4 scheme would waste twice the bytes in each bank for hotspots, and you'd still be stuck with less than 4k in the last bank for kernel and graphics. None of this is an argument against different bankswitch code being implemented, but rather, it's a lot more than I'm willing to take on.

 

TLDR? I'm not looking to do major rewrites to the bankswitch routines. If someone wants to do so, without breaking the majority of existing bankswitched games, they can do so and be welcomed to the bB team.

Ok, I understand. Thank you for all you have done to date to enable us to make these games!

[EvoMikeUK]

Hello, I've just bought a MacBook and moving development over to this. As you can probably tell from this, I am a little confused how to compile on a Mac, I haven't used a Mac for a decade. I am getting the error:

 

### ERROR: couldn't find bB binaries for Darwin(x86_64). Exiting.

 

I have downloaded the bBasic files from the GitHub, do I need to just link in the extension compiler path settings to a file in here? Thank you, sorry for the n00b question.

[RevEng]

There's an "install_ux.sh" script you can run to setup the path info. In most cases it should be enough to run that, and following any instructions the script provides (covered in the README.txt)

 

To run the script, open a terminal window, and type "cd /your/path/to/bB/here" and then "./install_ux.sh" (without the quotes, hitting ENTER after each line)

 

[EvoMikeUK]

10 minutes ago, RevEng said:

There's an "install_ux.sh" script you can run to setup the path info. In most cases it should be enough to run that, and following any instructions the script provides (covered in the README.txt)

 

To run the script, open a terminal window, and type "cd /your/path/to/bB/here" and then "./install_ux.sh" (without the quotes, hitting ENTER after each line)

 

Ok thank you. It has now said this

 

To test the new setup...

 

  1. open another terminal window.

     (the bB and PATH variables will now be active in any new terminal window)

  2. type:  cd "$bB/samples"

  3. type:  2600basic.sh zombie_chase.bas

 

This should create a zombie_chase.bas.bin binary file in the samples directory

that will work on real hardware, in stella, or any other emulator.

 

but it does not compile, do I need to change anything in Visual Studio Code? Sorry again.

[RevEng]

Nah, don't be sorry. A new setup on a less familiar OS is always an adventure.

 

So when you say "Visual Studio Code", do you mean you're trying to compile with Atari Dev Studio? If not, when you open a new terminal window, and follow steps 1, 2, and 3 from the script output, where is it failing, and with what error? The same error as before, on step 3, or? 

[EvoMikeUK]

4 minutes ago, RevEng said:

Nah, don't be sorry. A new setup on a less familiar OS is always an adventure.

 

So when you say "Visual Studio Code", do you mean you're trying to compile with Atari Dev Studio? If not, when you open a new terminal window, and follow steps 1, 2, and 3 from the script output, where is it failing, and with what error? The same error as before, on step 3, or? 

Thank you, it's taking time to adjust to the Mac but it's very nice to use. 

 

Yes correct, when I hit the compile button in Atari Dev Studio (which is excellent btw!) it comes up with that initial error I posted:

 

### ERROR: couldn't find bB binaries for Darwin(x86_64). Exiting.