I would say just experiment with the values of those ports, but there's absolutely no guarantee that the maximum setting will be enough for the Presentation Link. You'd think that if it were, the TI-OS would just modify that instead of wasting more CPU cycles. But then again, this is TI we're talking about.

I don't think it would be too hard to modify xLIB to do this if it comes to that.

Wow, nice video!  I hope you get some more info on it.  What has the different delay?  The Presenter link or the Presenter itself?

I would say it's the USB Presentation Link adapter, as the OS is coded to allow for more LCD delays when it detects that it's attached. The ViewScreen calculators run exactly the same OS as normal calculators and therefore don't have more delays.


It's impossible to really say, though...delays could be happening in the hardware in one or both situations.

I intend to make real clips of the thing in action.

I'm open to doing streams whenever.

I doubt they would accept it, but I'd be willing to offer free hosting indefinitely with my own host, unlimited space and bandwidth. I think it's very important to keep TI community sites up for as long as humanly possible, and I have no problem spending money to make it happen.

I believe I've tracked down the bug with For( loops being very slow when the first line is a lone If block with a false condition and there's no ) or newline between the For( and the If.

It's complicated and hard to explain, but basically the code that handles the For( token assumes that you've put the ) on the end of the For( line, and so when it executes the For block, instead of jumping to the start of the line containing the If, it jumps to the If token itself.

Normally this isn't a problem, but it's important for the parser to handle the start of the line because it removes a byte from the operator stack that always gets pushed when beginning parsing of the line. Because an If block with a false condition will jump over the next line (including the newline), this never gets canceled out at the beginning of the loop, and so with every iteration you lose bytes of the operator stack. This in turn causes memory leaks and confuses the parser about what temporary variables should be cleaned up, and it's forced to near-constantly "garbage collect".

Or at least that's my theory.

In any case, the For( code shouldn't be making that stupid assumption, so I patched my OS to see if I could fix it, and it appears successful. I uploaded it to http://brandonw.net/crap/84P_OS2.41_BASICFixed.8xu if anyone wants to try it.

So we could be happy with this, or we could write an oncalc patch that does this in an OS version-independent way, or we could just live with the fact that you need a ).

Thoughts?

It'll be at 9PM Eastern if anyone wants to see.

Again, BrandonW's proven how much he can do to fix TI's errors.  Thanks Brandon!
Do you mind telling us what you had to change?

It's on brandonw.net. They basically re-arranged a lot of code in the parser and broke what happens when canceling from the parser hook (which is what xLIB does when it handles a real( token). They set numOP1,(iy+ParsFlags2) when they really shouldn't be, which confuses the parser because it's looking for a result in Ans/OP1 when xLIB didn't return one (or returned garbage).

It's highly dependent on how parser hook-using programs are coded -- this is why Celtic III (coincidentally) doesn't have the problem.

I sent an e-mail to TI explaining the bug and how to fix it, but they'll probably either ignore it or it won't make it to someone who can actually fix it.

Yay! I tested it on Age of Culture II and it worked great! Thanks a lot!

And also, does this also fix the Omnicalc problems? I didn't dare try it on my calc...

I don't know specifically what the Omnicalc problems are, but I doubt it.