MaxCoderz.org

The bug does seem to be a timing issue (reloading, the commands didn't help). However, on my calculator, MINES, CLOCK, and CUBE all run correctly (as far as I can tell).

Finally, I'm not quite sure how to edit programs like on the regular OS (I can do it line by line)... I tried using the *EXEC with the program (according to the documentation, this is supposed to detokenize the program; it gives lots of syntax errors when I use it), but I'm not entirely sure what to do...

I'll download the new documentation when I get home (at school atm) to see how it is.

I've noticed that bug on my 84+SE too. Sometimes, it creates the files, but reports that the file could not be opened. Then, running LOAD "FILENAME", where FILENAME is the name of the file just created, gives no errors, but doesn't actually load anything.

I've uploaded a new version with a handful of possible fixes in the host interface as well as updated samples. Hopefully the erratic key input and LCD corruption bugs have been fixed.

If you still have problems on the TI-84+, please try using the new *SPEED command to switch down to 6MHz:
...and try again.

You can't, unfortunately. The TI-OS editor stores programs in its own tokenised format and *EXEC loads ASCII text files. On top of that, the TI-OS editor does not allow you to enter particular symbols such as # (which is used on many file-related keywords).

The line-based editor is usable, but I can see how you may find it a bit clunky. You can edit programs externally using the bundled PC program. It may be possible to write something that converts a file from a sensible format (eg DocumentDE), but this will take some doing as BBC BASIC does not expose any routines to tokenise a line of ASCII source.


This baffles me considerably. Sometimes it works, sometimes it doesn't; even more bizarrely, if you enter the full name of the file with an extension (eg, SAVE"TESTBBC.PRG") it always works. Stepping through the code in an emulator the name is converted to TI-OS format identically whether you include the extension or not. It only affects the TI-84+, I have never seen these problems on the TI-83+. I'm looking into it.

Edit: If you had already downloaded it, please try downloading it again - I may (?!) have fixed it. Let me know how it goes for you.

VDU 14 crashes my 84+ SE. Running VDU 14 followed by a LIST command will sometimes cause a RAM clear. Other times, I can restart BBC Basic by holding ON.

I have had a lot of interest on where this project's going and am very happy to see it in a public beta! I mmediately put it on my TI-84+ SE and will also load it on my TI-Nspire to test compatibility.

Overall, I like it a lot. I made a few simple programs do things like convert temperature and draw a box. However, I have noticed a bug in it where loading programmes can be difficult. Unlike what you said on the post a few posts before, it sometimes says "File not found" when I try to load a file and type its extension.
Here's excactly what it looked like:

LOAD "MINES.PRG"

File not found

MINES.PRG was in the memory (Not the ROM). I noticed that this problem was corrected when I archived the programme, resetted the memory, then unarchived it.

I hope this informaton helps.

Also, on my TI website (http://www.lafacroft.com) my friend and I will make a section of the TI-83 Plus archive specifically for BBC Basic files. You can still send them to the site and they will be posted.

Well spotted. I'd accidentally removed a label, which was causing the wait-for-a-key loop to branch back to somewhere much earlier in the code. This unbalanced the stack, so if you left it for a while it would eventually overflow the stack and crash. The new download should have fixed that.

Does SIERPINS now work, and can you type e and d on the TI-84+?

Thank you! I cannot guarantee that it will work properly on the Nspire as there is at least one place where I have used the sl1 instruction (which is not implemented by the Nspire's emulator). Even if I cleaned up my code to remove usage of undocumented instructions, BBC BASIC itself (which I do not have the source code for) may use them.

If you mean "helps to send Ben insane", then yes.

Are you sure you're using the latest version? The "File not found" error was what I was getting on a TI-84+ emulator (and, yes, I found that sometimes .PRG didn't work either). I found that I could sometimes trigger the bug by deleting the files from the TI-84+ then resending them.

It looks like a TI-84+ specific bug, which is really weird, as in all my testing (which is on a TI-83+, either in PindurTI or on real hardware) I've never seen it, but it crops up time and time again on a TI-84+ in Wabbitemu. I tried wrapping _ChkFindSym with a block of code that disables interrupts and preserves registers which appeared to fix it (I can't trigger the bug any more in Wabbitemu). Which version of the TI-OS are you using?

Cheers, sounds good to me.

I'm downloading the new version now; the d and e keys worked fine on my 84+SE the entire time (I don't think anything was ever wrong with them)...

Yeah but you know how your program works...
For example, I've tried a lot of commands that do not exist, and tried command with bad arguments...

I've not tried with the new version (I'm currently loading it), but I've seen that sometimes, when LOAD "MINES" gives an error "File not found", ch."MINES" works correctly.
The other bug I mentionned, was that I tried to open a file that didn't exist. It detected it, but it created the file too (and it was not able to load it). But in fact, since the bug appear, Ram seems corrupted, because it will not work again correctly before a Ram Clear.

I've seen how the SORT program is writen, and that's awesome! That Asm could be included that way in your program and still be drawable on the screen... (Is it interpreted or really compiled??)

I ran the sierpins program and it did not work properly using the run command (I forgot to try with ch). However, after a RAM clear, it worked with ch."sierpins" (it still did not work with run).

84+SE

I have now downloaded the new version and I am not having any issues so far with the failure to detect programmes in the memory.
One thing that would make it a lot easier would be to let it load programmes from the ROM. I do not know whether or not that s possible since I only have experience in TI-BASIC and TI-Nspire BASIC.

OK, I'm really sorry about these TI-84+ issues but I'm finding it very difficult to replicate them. (I believe you when you say that there's a problem, I'm just baffled as to how they're happening, especially as the problems do not show up on the 83+).

It is really compiled. Obviously you need to be careful with the assembler, but it's a powerful feature. For example, most BASIC dialects have UCASE$ and LCASE$ case-conversion functions. BBC BASIC doesn't, but by using the assembler wrapping up the assembly code into BASIC functions you can add fast implementations to BBC BASIC.

I don't know if that's a good thing or a bad thing.
You can open files for reading transparently from the archive - or, rather, you should be able to. Try archiving one of the sample programs and you should be able to run it within BBC BASIC.

You cannot modify files in the archive (open for writing, deleting, updating and so on). One the one hand this is a safety feature (archived files cannot be tampered with) but there is a technical reason for this. When the calculator unlocks the flash memory it re-enables the TI-OS interrupt handler. This interrupt handler modifies the shadow registers. BBC BASIC uses these registers, and so the TI-OS interrupt handler causes a crash.

I've released a new version. There's not much to write home about, though;

• Oddly enough, STRING$ was undocumented.
• *BUILDINFO can be used to output some build information.

I'd be grateful if the build info (especially the SVN revision number) could be included with bug reports if possible as this will help me keep track of problems a bit better.

http://www.benryves.com/bin/bbcbasic/download/latest.php will point to the latest version of BBC BASIC.

I've got no longer problems to detect files, nor the problem of reduction of the screen size with SIERPINS. And now, half time, SIERPINS runs correctly, but half time it displays odd pixels on screen very fast (and, when you push On, you see triangle...)
The 'e' and 'f' are now accessible...

But, sometimes the MINES programs runs slowly. I thinks that's depending on system variables, but it did not happen with the first release.

I've seen too that the computer editor doesn't take files arguments (The right click, open with of Windows XP opens an empty window)

Does the editor I saw on the first releases still exist??

BUG:
The withdrawal of the USB link makes BBC crash. (r777 18/01)
________________________________
(Test with the 17/01 version, TI 84+)

Hurrah!
That sounds like the same bug as before; just a slightly less extreme manifestation. At least it's not accidentally putting the LCD in 6-bit mode (which was what the initial problem was), just writing to the wrong place on the LCD. Escape (On) forces a redraw of the screen (all 768 bytes of the buffer) which is why pressing On to force it to exit displays the triangle correctly. I'll try and fix that (third time lucky).

Interesting. Thanks for reporting that, I'll check my speed throttling code.

Good idea, I'll add that.

Which editor is that? The full-screen file editor on the calculator? If so, no, sorry. I could update it, but it would not be able to edit BBC BASIC files as they are tokenised (and it could only handle ASCII files).

Ah. I don't know anything about the USB hardware, sorry, so I can't tell you why it does that just yet but that is something I definitely need to try and fix. Could you please try running the following code on your calculator for me? (Just type it on the BBC BASIC command-line):

(& is Alpha+B). Once you've run that, try crashing the calculator by unplugging the USB cable. If that doesn't crash, could you then try this?

...and seeing the calculator crashes by playing with the USB cable? (It probably will). This document by BrandonW mentions an interrupt that can be disabled by bit 0 of port &5B.

Just editing the first post to indicate that it is indeed 2009, not 2008.