Hurray, glad that this finally got released; I have been watching its progress with great interest. I'm particularly intrigued by its versatility.

Fr0st p0st?

needs a lot more icicles to be a fr0st p0st.

BBC Basic BETA was actually released a couple of weeks ago on the Max Coderz web site.

That is true, but I wanted to start off with a more limited release to iron out some of the show-stopping bugs (in this case, graphical glitches and keypad issues on the TI-84+) before making a more general beta release.
This is still a beta release, however; there are at least two known bugs and no doubt more to find, as well as missing or incomplete features. The software is, however, pretty usable in its current state.

This is awesome, at least finally an alternative to TI-BASIC and ASM that is both complete enough and still progressing nicely. It appeared to run a bit slow for tilemaps (according to a MaxCoderz screenshot) but it was still much faster than TI-BASIC. I am curious about what program size it allows and if it has sub-program support

The screenshots run rather slowly if you're using IE, I'm afraid, but recent versions of Opera/Firefox should render them at the correct speed. I will admit that there are some speed issues, such as the rather sluggish triangle filler, that could do with some work.

Program size is limited by available RAM; on a TI-83+ with 24,312 bytes of free RAM I could set aside 21,389 for BASIC's memory (which would include your program, variable heap and stack) with careful use of *HIMEM. Resources (graphics, text strings and so on) can be stored externally and read transparently from flash ROM, which can save space in your program. In any case, this is still more memory than the original BBC Micro!

You can CHAIN other programs from your own, with the caveat that this CLEARs the heap. The static variables (@%, A%-Z%) are left intact after a CLEAR, though, which may be useful.

And I know it's off-topic but I am curious when the POTY results will be announced?

What an awesome program!

Many thanks for the feature!

I've had a couple of reports that the documentation isn't displayed correctly. This is the result of downloading the file using IE or Firefox then extracting the files with the Windows built-in unzipper. If you are having difficulties right-click the .chm, go into "Properties" and click the "Unblock" button at the bottom. (Most other browsers and unzipping utilities will be unaffected by this security "feature").

The documentation is also available online (see the Web Site link on this post).

I'm having trouble running any sort of program from the command line. I have a TI-84+SE with OS 2.43. Is the correct syntax to run a program CH."filename"? This consistently returns "bad program". I have the same issue with RUN "filename". Also, the catalog feature in the documentation hasn't been working. Has anyone else had similar problems or is there just a simple solution I'm missing?

Are you using the latest version? This seems to be a TI-84+-specific issue that I was convinced I had fixed, but evidently not. :|

Any information on how the variable manipulation routines differ on the TI-84+ would be appreciated; it appeared that ChkFindSym fails under certain conditions on the 84+.

The catalogue feature was removed before the first betas were released due to it interfering with the text input and display routines, I just forgot to remove it from the documentation.

I'm running r627, not sure if that is the latest.

It is. Curses.

I had reports previously that resetting RAM fixed the issue, but that's not a very good solution.

All registers (including shadow registers and IY) are used within the BBC BASIC interpreter which has caused problems with the TI-OS in the past (enabling IM 1 is a quick and easy way to crash BASIC as the TI-OS ISR doesn't preserve shadow registers). The previous fix I had implemented was to wrap up ChkFindSym, ensuring IY was the value it was when the app was started.

What puzzles me is that I have not seen this problem on the regular TI-83+ at all (where I do 99% of my testing).

Sorry for replying to myself, but if you click the Web Site link on this post there's a new version that may - or may not - help TI-84+ users. TI-83+ users may be interested anyway as it adds some useful functionality!

are us 83+ers gonna get a new category in the archives for BBC Basic programs?

Excellent question. I'm sure Mr. Directory Organizer will add it shorty.

*shortly

Okay, well, if you have any BBC Basic files, just upload them to “TI-83/84 Plus BBC Basic Files”, and I'll create the needed subdirectories as they're needed.

(I wonder if we need to have Magnus make new Progclass codes for this type of file? I don't know what, if anything, the system uses the codes for.)

Fantastic work Ben!

BBC BASIC is the future and is certain to become a great replacement for TIBASIC and even TIBASIC+Asmlibs.

Sorry, but I'm going to have to LOL here... BBC Basic is literally 29 years old, and calling it "The Future" just seems so wonderfully ironic.

maybe but at least it will be much better than the current TI-BASIC. It's not like he said it would be the future of ASM

Well, it may have an impact on the future as it is another programming language for the TI83 Plus (or 84 Plus). This could create programs in a different style and they could eventually become masterpieces like Desolate and Super Mario.

Also, I have now put up an archive dedicated to BBC-Basic programs for the TI-83 Plus on my site, http://www.lafacroft.com.

True, knowing it's from Ben it might become faster and faster as he does updates. At least it will make calc programming progress, the opposite of what TI is doing right now (I got the proof by running a "For(varname,1,9e99:Disp varname:End"-like command on both my TI-83+ and my TI-Nspire and it barely ran any faster on my Nspire. Isn't the Nspire processor at like 75+ MHz?

With regard to speed, there are several areas - especially in regard to graphics - that could be optimised significantly. Part of the problem is that I'm trying to keep everything robust and flexible (ensuring that all drawing is clipped to the graphics viewport, supporting the different logical plotting modes &c) that have prevented me from making assumptions and therefore optimisations. On top of that all graphics routines go via the VDU emulator, so the command is first encoded into a series of VDU statements then decoded before the actual drawing routine can be invoked. Then there's the stuff that's just lazy, such as all the triangle filling being done with slow 16-bit arithmetic instead of using an optimised 8-bit version where possible.

In short; hopefully it will get faster. I am working on making the source code for the host interface available, but it's still a bit of a mess in places at the moment.

I wouldn't say it's a replacement for anything, but it may be a viable alternative. Straight assembly will still be the clear winner where you want performance and power; the built-in programming language where you want maths and integration with the operating system.