Hello,

For a few days now I have my first Voyage 200 ever and I'm absolutely impressed by it. Nevertheless, TI Basic isn't always the same, I see at least three flavors on my desk: In the Nspire series, the TI-83 Plus, and the Voyage 200. So I wrote a program with a recursion function which runs fine on the others but not on the V200.

This is the V200 code, the starter program first, then the recursive program:


Code:


When I start with a value of 51 for a, the program runs fine until the end. When I enter 52 instead, a memory error occurs, just the word Memory in the error box. At first sight I thought it might be a problem with the stack of recursion addresses but there are 255, so that's not the reason. It seems as if the V200 runs out of memory. But it says that there are 188292 bytes RAM free. On TI-82 or TI-83 Plus I can use much higher values than 52 without problems.

So, my first question is: Have I made a mistake in my program code?

Thanks a lot for your help,
cheers!

Four things :(1) ClearHome is unavailable for the voyage 200. (2) "a:" is incorrect, just Impute a. (3) recur() is a loop with no exit. (4) I am not certain, but you may have exceeded the I/O screens display limit, not system or ram memory.

I'm pretty sure every single thing you posted is incorrect, I'm sorry to say. There's a ClrHome, Input "string",variable is valid, the bottomless recursion is an intentional test, and the screen will scroll if you fill it up.

Retrotron, I did spot in the Voyage 200 manual where it says recursion is limited to 255 levels deep. However, do note that if the parser on the 68k calculators is like the one on the z80 calculators, each copy of the program executed does incur the cost of a bunch of additional memory for the state that is maintained to track a program being executed. With 188KB of RAM free, I definitely don't expect that to be the limiting factor, so I'm not sure why you're running into this.

My TI-89 Titanium also succeeds at up to 51 levels of recursion with 35632 bytes free (in particular, under 64 KiB just in case some data structure was limited to that) but raises a memory error on the 52nd, so it does not seem like the total RAM is the limiting factor in this case. I also tried different code (just incrementing until it fails, using a function with the depth count as a parameter, adding a local variable), & none affected the number of levels.

It seems likely that the claim in the manual that it supports 255 levels is based on using a 1-byte field somewhere that gets incremented each time a program is run, since otherwise 255 would be a suspicious number to come up with. 255/51 is 5, so perhaps each level (except maybe the first) takes five of the thing being counted (entries in some stack used by BASIC?) instead of just one, & whoever said 255 thought it only took one entry per level.

Thank you for your suggestions, an additional overhead could be the reason for the limit. I'll investigate further in this direction!


That's interesting! I have only TI-82's and TI-83's for a comparison but they have another architecture. The TI-89 Titanium is nearly the same thing, right?

So I do know by now, that my V200 is perfectly fine and that there is some limit hidden in the details of its architecture.



Thanks for testing this out, great! Very interesting facts, really.



Unfortunately, I don't have the necessary hacking skills to analyse this further but I'll give it a try. It's a pity that the original TI manual is still the best documentation source afaik.

Thanks to all of you for your thoughts and ideas

Here's an idea - what if you lengthen or shorten the recur() program name? Does that change anything?

Nice idea
Tried it with shortened name "r", but that didn't change anything.

Edit: And a name like recursio doesn't change anything, too. So, namelength doesn't play a role.

Okay, in a way I'm glad that didn't do it, because program names should be either (length + 1) for a size byte (which would be 6, and thus a depth of 42 rather than 51) or a solid 8, and thus an even smaller depth. However, it makes more sense to me that the recursion stack would store the names of the variables that have been recursed into than some sort of per-program-instance state, e.g. variables, since as far as I know even 68k TI-BASIC doesn't have scoped variables.

Edit: Please don't double- or multi-post. Rather, please edit your posts if no one has responded to you and it has been less than 24 hours.

Okay, thx!

I've rewritten the programs a bit and found out that the program size does play a role:


Code:


Now the program works fine up to a start value of 44 and its last execution is registering the value for b given by the user. Give it 45 and it throws the memory error.

Edit: Meanwhile I have put two really big dialog boxes into the recursion part but the limit of 44 seems to be stable now. I have no clue what's going on here and what it is exactly which defines the number of possible recursions.

With single-character string arguments for the Title and Request commands, 45 does not throw the memory error, but 46 does. Adding dozens of spaces impacts the program size but not the number of possible recursions.
On V200 AMS 3.10, the ER_Throw(ER_MEMORY) is at 2a921a, part of short subroutine 2a9202.

My V200 has been updated to 3.10. Do these addresses which you could identify (2a921a, 2a9202) shed any light on the reasoning of this behavior? And how did you find out these addresses, btw?

I blew the recursion-part up with five huge dialog boxes but it kept its limit of 44. Since you said that shortening the title and the request commands did have an impact, it's becoming more and more unclear what's going on.

I found these addresses by setting a breakpoint on the A-Line vector in TIEmu, because it is documented that in AMS, these Error: Memory dialogs are triggered by 0xAnnn instructions, which are nonexistent on that model, and emulated in software. This gave me the address of the A29E instruction, (0xA000 + 670), and I disassembled upwards to find the beginning of the function.
TIEmu is the only TI-68k emulator with both V200 emulation and integrated debugger capability:
* Virtual TI (VTI), and JM's improved versions thereof, only really emulate 92+ HW1 and 89 HW1 (for the most part, but it's not very accurate), with a sprinkling of HW2 emulation code which misses important hardware features, such as the RAM execution protection, even if it has a debugger;
* Patrick Davidson's JS TI-68k emulator, and its improved derivative thereof mostly made by myself a decade ago, emulate V200 but don't have a debugger.

Alone, these addresses do not shed any light on this behaviour. AFAIK, there's no advanced, commented disassembly for V200 AMS 3.10. The test could easily be replicated on 89T AMS 3.10, for which there's a (private, obviously) advanced disassembly.

Today I got a second Voyage 200. I tested the recursion test program, of course, and found out: The new machine goes up to 61 recursions without a problem. And this, although it came with a ton of pre-installed software and had all memory parameters lower than the first machine.

There's one difference though, the new machine's OS (I know, not really an OS) version is 3.01. And 3.10 on the first machine is patched by xpand. But removing xpand by a new installation of the OS didn't change a thing anyway.