Jump to content
RevEng

Official Home for batari Basic

Recommended Posts

5 hours ago, Random Terrain said:

 

Except not backwards (horizontal) and more like this, vertical:

 

https://www.randomterrain.com/atari-2600-memories-tia-color-charts.html

color_charts.png.eb28467eb979eb3e399c5a03fb6286fe.png

 

Will take a look with the next update to the editor (i've raised in issue in Github).  Please feel free to raise any further suggestions in the Atari Dev Studio announcement post so we can keep Mike's post for bB 👍

  • Thanks 1

Share this post


Link to post
Share on other sites
On 1/19/2020 at 2:39 PM, RevEng said:

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

This is good news! I've submitted a Pull Request with several changes that come from a cleanup I did a while ago and posted on GitHub.

 

The PR I submitted contains many of those changes. It modifies the code to use consistent indentation and adds some extra functions and macros that make the code more concise and the formatting of the 6502 Assembler output fully consistent. Rather than just paste my updated code over the current code I applied the changes manually so they are up to date with any changes since "version 1.0" of bAtariBASIC. I'll follow up periodically with more fixups, and I will also produce a C++ version as part of the refactoring effort.

 

I've also started writing VSCode extensions (i.e., "Auto Build Marlin") and it would be interesting to write a Javascript version of the compiler that could be integrated into Atari Dev Studio. Just the part that produces the Assembler output so you can quickly verify that it's what you expect. And then the extension could do other tricks like highlight lines that it can't figure out how to compile, and so on.

 

From my bAtariBASIC page on GitHub:

 

image.thumb.png.0e756e75294438d120b3bce3f39d1a3b.png

Edited by thinkyhead
  • Like 3

Share this post


Link to post
Share on other sites

Much appreciated! I saw the pull requests, I'm just waiting for some free time to throw at reviewing. They sound pretty straightforward, so I don't expect an issue.

  • Like 1

Share this post


Link to post
Share on other sites

Shorthand operators would be a nice addition 👍

Share this post


Link to post
Share on other sites

Incidentally, what is your preferred indentation? For C/C++ I've tended to favor 2 spaces instead of tabs since it doesn't fly off the right, GitHub displays it correctly, and editor settings don't matter.

However, for the PR I went with the most traditional: 4-column wide Tabs since that seemed to fit the existing code best (although it had a mixture of tabs and spaces).

Share this post


Link to post
Share on other sites

We're not allowed to discuss religion here. ;)

 

My preference is tabs, but I'm adaptable to spaces. The code has had a few different hands in it over the years, and some of it copied and pasted, which will often convert the tabs to spaces. I usually try to fix that up, but I've probably missed a few times.

Share this post


Link to post
Share on other sites

I'm trying to update batari Basic on my Mac (not using Atari Dev Studio, just a text editor and the Terminal). When I try to compile with the new version, I get the same error EvoMike was getting (### ERROR: couldn't find bB binaries for Darwin(x86_64). Exiting.) There are Darwin files in the directory for my old version of bB, but they aren't there in the new one. Is there a step I missed to create those?

Share this post


Link to post
Share on other sites

Assuming you're using the latest release, have you run the accompanying "install_ux.sh" script?

 

If you downloaded the darwin specific packages (or any specific OS packages) the binaries are just named "2600basic", "optimize", etc., without the OS specific extensions. The 2600basic.sh script uses these binaries first, before it resorts to searching for ones with OS specific naming.

Share this post


Link to post
Share on other sites

I just updated dev studio for the first time since 4.4 I think, how come my pfcolors are now one row further down in the DPC+ kernel then what they were before?

If I fix it the top color is wrong.

 

It's as if this isn't working anymore?

 

 

Share this post


Link to post
Share on other sites
Posted (edited)

@RevEng  Out of curiosity, do you remember how much ROM is left on the bB DPC+ ARM side in main.c?

 

Might be nice to have the ARM handle common math calculations. For instance, in theory pfread makes a lot of sense as is; in usage, not so much.  Devs are often polling a VCS object's coordinates and the ARM can handle ((foo-16)>>2) much faster.

 

If space allows, maybe I can add little something. With additional functionality dropped into main.c, should be able to drop new commands into commands.c.

 

Anyhow, just got to thinking when I saw another post about the playfield.

Edited by orange808

Share this post


Link to post
Share on other sites
2 minutes ago, orange808 said:

@RevEng  Out of curiosity, do you remember how much ROM is left on the bB DPC+ ARM side in main.c?

It's pretty badly stuffed. For the last few DPC+ additions I did, I needed to squeeze a bunch of the existing code over and over to get it to fit.

 

  • Thanks 1

Share this post


Link to post
Share on other sites

Heads up that I've put out v1.6 of bB github releases page. Here are the main updates...

  • number of def's increased to 500 (overflow detection in place)
  • number of constants increased to 80000, overflow detection added
  • allow variable as argument to stack command. (thx kdgarris!)
  • add QT multiplexer support to standard, multisprite and DPC+ kernels. (thx kdgarris!)
  • DPC+ priming reads (thx Lillapojkenpåön!)
  • multiply by 154 hang fix
  • preparser bug fix - symbols ending with _[bB statement]

Enjoy!

 

[NOTE: some anti-virus software hates open-source compiler produced binaries. If you download a package and can't get it working, check your quarantine list]

  • Like 4
  • Thanks 1

Share this post


Link to post
Share on other sites
5 hours ago, RevEng said:

 

  • preparser bug fix - symbols ending with _[bB statement]

 

I updated the bB page with this:

 

Quote

It also helps to capitalize the first letter of each word in case one of them turns out to be a valid bB statement name. For example, to avoid problems you'd use something like _Reptilian_Spider_Data instead of _reptilian_spider_data.

 

But I guess I can remove that now.

Share this post


Link to post
Share on other sites
39 minutes ago, Random Terrain said:

I updated the bB page with this:

 

But I guess I can remove that now.

Ah, sorry to make you do that extra work - my fault for saying earlier that I wasn't working on it. I saw that we had a number of fixes queued up since the last release, and figured I might as well push through the ennui and put out a release.

 

Correct - there shouldn't be a need to avoid variables or labels ending in _data or any other statement, with the latest release.

  • Like 3

Share this post


Link to post
Share on other sites

Heads up that I've put out v1.7 of bB github releases page. Just one update...

  • DPC+ priming read bug fix

N.B. - Some anti-virus software hates open-source compiler produced binaries. If you download a package and can't get it working, check your quarantine list.

N.B. - Compilation of source code from older versions of bB isn't guaranteed with each new bB release.

  • Like 3

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.
Note: Your post will require moderator approval before it will be visible.

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...