KermMartian wrote:
qazz42 wrote:
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.
I don't use any RAM except the save appvar(s) in user memory, appbackupscreen, and OP1. I do use extra ram pages, though (as does Emu8x). So maybe something could be up with the DCS base page table?
I always carefully reconstruct the appbasetable when Doors CS regains control from running an assembly program, but that shouldn't be an issue for TI-Boy, since it's an App, right? Qazz42, can you find any variables towards the expression of the bug? For example, if you disable [blah] does the reset not happen?
Yea, if I disable homerun the calc does not reset after entering anything (weather it be a program or an eqation) after playing some TI-boy
qazz42 wrote:
Yea, if I disable homerun the calc does not reset after entering anything (weather it be a program or an eqation) after playing some TI-boy
Well, that tells me that Doors CS is reaching its hook, that the hook is in the right place, and that the $AE byte that is expected is there. Does TI-Boy do any reordering of ROM, by any chance?
Yep, I think it does. From what I last heard (remember), TI Boy sets up so that app page 1 is on the first page it can be, and each other page in order after that. That way it's easier on the math and such. (I think)
Wait, which TI-Boy? I was talking about the official release version, but I forgot qazz had a copy of my WIP version. And TI-Boy doesn't rebuild the base page table anyway, since it has no reason to use it.
calc84maniac wrote:
Wait, which TI-Boy? I was talking about the official release version, but I forgot qazz had a copy of my WIP version. And TI-Boy doesn't rebuild the base page table anyway, since it has no reason to use it.
So is _player incorrect then? You don't do any page reordering? And Qazz, can you try a different non-WIP version, then?
nope, I don't have the extra RAM pages
qazz42 wrote:
nope, I don't have the extra RAM pages
So TI-Boy relies on the extra pages, and you don't have the extra pages... 
the WIP version was made to not have to use the extra ram pages, so I think his was fine. (Was I right?)
yeah, the WIP version I can use, the non-WIP one I cant
Does the WIP run games? Or does it crash? (Never used it before)
Edit: Run games on your calculator
qazz42 wrote:
yeah, the WIP version I can use, the non-WIP one I cant
Gotcha, that makes sense. Is it therefore possible that the WIP version has bugs, then, which could be causing this odd crash?
Rather, the WIP version was designed to use only one page of extra RAM (so it can run on the newer 84+). It does use extra RAM, just not the RAM that TI removed.
calc84maniac wrote:
Rather, the WIP version was designed to use only one page of extra RAM (so it can run on the newer 84+). It does use extra RAM, just not the RAM that TI removed.
That makes perfect sense then, thanks calc84. So where does that leave us on hints and possible resolutions of this conflict, then?
Well, does your parser hook use bcalls to other pages of DCS without making sure the base page table is intact?
calc84maniac wrote:
Well, does your parser hook use bcalls to other pages of DCS without making sure the base page table is intact?
Ooooh, you make an excellent point. It sounds to me like it would be pretty expensive to re-generate the base table every time the hook is invoked, though, especially when it's getting invoked for real(), identity(), det(), and sum() commands. Any suggestions?
I noticed this bug when I hit the on key to stop the program and goto its current location. Here is the differences between the files. Original on top and Different one after editing using Doors CS 7 on the bottom:
What the program originally looked like:
Code: :Disp "Ah, so your name"
:Disp "is",Str0
:Disp "What"
:If Str0="KEITH" or Str0="Keith"
:Then
:Disp "an AMAZING name!"
:Else
:Disp "a great name."
:End
After editing:
Code: :Disp "Ah, so your name"
:Disp "is",Str0
:Disp "What"
:If Str0="KEITH" or Str0="Kei1-PropZTest(:
*****This is the weird part, it repeats the program from the very beginning until it reaches the same part here*****
:If Str0="KEITH" or Str0="Keith"
:Then
:Disp "an AMAZING name!"
:Else
:Disp "a great name."
:End
I am not really sure how else to explain or show this bug, but whenever I edit a program, it chooses a spot in the program to add some weird drawing thing like PropZTest and then repeats the program from the beginning until it reaches the point that it repeats itself. It then continues normally.
If you need me to elucidate on anything, please ask. Thanks.
Aha, I'm glad you're getting this! Believe it or not, this is a TI-OS bug to the best of my figuring, not a Doors CS bug. I have confirmed that everyone who has gotten this so far is running TI-OS 2.53MP, and it happens regardless of Doors CS presence. Are you running 2.53MP? Also, are you running BrandonW's patched 2.53MP?
