Ohhhh. Then the fault is the TI-OS, not Doors CS. The DCS hook can only trigger if the hook is enabled, no? Unless I'm misunderstanding you.

Ah, sorry, I should have mentioned which screenshot I was referring to:
2 in post with link to download: Doors Hooks Off
Screenie with Error: Doors Hooks On

Ah, ok. Well, I'll certainly try to track this down for you. If I load your Exodus game on my calculator, would you expect me to be able to do the same thing that you're doing in your screenshot to replicate it?

Yup, just go to the World Map and press Mode.

I see that you must have taken those screenies on a 15MHz calculator; it's painfully slow on a 6MHz calculator. I can replicate your bug, though; I'll try to track it down.

Edit: DCS is reading your sum()'s first arg as a real ($00), not a list. Very strange.

Bump. Any progress on this?

None at all, I'm afraid; I'm stumped. I'll try to trace backwards to see why Doors CS is mis-guessing. I tried another test program with sum({1,2,3}); sum(L5), sum({1,2,3},1,2), and sum(L5,2,3), and everything worked correctly.

Funny, but I noticed something even weirder.

sum(L5 returns the right values, but sum(L5,[start],[end] either returns 0 (if the sum is zero), 96, or "NS".

"NS" is a Celtic III error (see the SDK PDF):



In other words, Doors CS is definitely trying to process this. I suspect that the problem is that sum() is turning into a Type 3 call (variable argument number) instead of a standard Type 1 or Type 2 call. I'll have to investigate this further, as well as possibly discussing it with BrandonW.

The problem that occurs in Asm WFRNG seems to exist in TI-BASIC as well, although the TI-BASIC glitching is not as bad as the Asm glitching. The problem occurs when Prompt is used on a variable that doesn't exists. Doing so will place "A=?" at the top of the screen instead of where it's supposed to be. Prompt will still return the value correctly when this happens.

I've uploaded the program to mediafire. Make sure to delete the variable A if you want to see the glitch.

http://www.mediafire.com/download.php?ff8zs7wn68vj4v4


Code:

Whoa, that's fascinating. Because I'm somewhat occupied with various things at the moment, could I ask you to temporarily change the Prompt to an Input and see if the same behavior (no failure if A exists, failure if A does not exist) occurs with Input?

When using Input, the location is always glitched (it doesn't seem to matter if the variable already exists).

Fascinating! I'm having a lot of trouble replicating this; I don't suppose you happen to be on the evil OS version 2.53MP, by any chance?

I'm using 2.43 (with a PTT removal patch, but I don't think that should affect anything). I think I'll try running this in Wabbitemu.

EDIT: The glitch does NOT appear in 2.53. It does appear when I use 2.43 (unpatched) in Wabbitemu.

Ah, good to know. I'm surprised this hasn't shown up previously, frankly, but I can only assume it's another awkward set of TI-OS flag interactions.

I've done some more testing, and it seems like whether the variable exists or not doesn't matter. I think the glitch stops appearing if WFRNG already has been run once during the current DCS session. I don't know how this applies to Input.

I tried this with the following program based on the concepts and possible problems that you described, and found the same set of parameters that you described to hold true (notably, non-first runs work correctly).


Code:


I will run a flag comparison to try to track this down.

Oh boy, a new bug has arisen. Remember that emu8x bug I was takling about? Well, turns out it happens with TI-Boy too. As soon as I exit TI-Boy and go to execute a program with homerun, my calc turns off and RAM clears.

Check if Calc84Maniac is doing anything weird with the memory area(s) that the DCS hooks may be using.

@JosJuice: I tracked down the three flags that appeared relevant to your bug, with no luck. The hunt continues.

Kerm, if I get a hold of him I shall. Do you think it is the same problem with emu8x?