Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
Following jaredtb00's post, I am able to constantly produce this Error: ?.


In fact, if you open DoorsCSE while in any TI-OS menu and run a program that has a Prompt or Input, you will run into the error.
Electromagnet8 wrote:
In fact, if you open DoorsCSE while in any TI-OS menu and run a program that has a Prompt or Input, you will run into the error.
(Using ON-PRGM, right?). I'm still working on this, but I have the following bits of further debugging under my belt:

- Reset calculator, ran and quit Doors CSE from the Apps menu, ran Doors CSE, started prgmRADICAL, and took a snapshot of the calculator's RAM at the Input prompt. Entered "36", finished and quit the program and Doors CSE, started Doors CSE again via ON-PRGM, started prgmRADICAL, took another RAM snapshot.

- Compared the two memory snapshots, a 963-line (byte) diff, more or less. Most of the differences were offsets of $1B or -$1B (27 bytes up or down). After a few hours of debugging and comparing the VAT, symbol tables, user mem, and flags, I found that the 27-byte difference was due to the variables A, B, and Y that were created after the first time prgmRADICAL was run.

- Performed the same steps to get another pair of RAM snapshots. This time, I ran prgmRADICAL once before the first snapshot so that no new variables should appear between the first and second snapshots. The results from my analysis so far:
-- There are differences in the stack from $ffec down to $ff50
-- A few differences scattered between $83f6 and $8c23
-- Two flags that might be relevant: bit 4 reset at $8b26 (iy+0) and bit 0 reset at $8b4c (iy+$26)
-- One bit set at $9250
-- 8 single bytes changed between $9bde and $9fa9
-- Bits reset at $a024 and $a69c

Further analysis will be forthcoming.

Edit: Repeating the later analysis making sure that the InfoPop did not trigger yielded an even shorter diff, short enough to post (the format is address: value with Apps menu -> value with ON-PRGM):

Code:
ff50: 0 -> 81
ff52: 0 -> 60
ff54: 0 -> 81
ff56: 0 -> 60
ff57: 0 -> b8
ff58: 0 -> fe
ff59: 0 -> 48
ff5a: 81 -> 1
ff5b: 0 -> bd
ff5c: 60 -> 45
ff5d: 0 -> e8
ff5e: 81 -> 9b
ff5f: 0 -> 9e
ff60: 81 -> 7
ff61: 0 -> d0
ff62: 60 -> 7
ff63: 0 -> 40
ff64: 81 -> 1
ff65: 0 -> 44
ff66: 60 -> 50
ff67: b8 -> 89
ff68: fe -> ac
ff69: 48 -> 8
ff6a: 1 -> 40
ff6b: bd -> 80
ff6c: 45 -> 18
ff6d: e8 -> c0
ff6e: 9b -> 1
ff6f: 9e -> 98
ff70: 7 -> e0
ff71: d0 -> 43
ff72: 7 -> 59
ff73: 40 -> 80
ff74: 1 -> 3
ff75: 44 -> 40
ff76: 50 -> 0
ff77: 89 -> 0
ff78: ac -> 20
ff79: 8 -> 43
ff7a: 40 -> 59
ff7b: 80 -> 44
ff7c: 18 -> 20
ff7d: c0 -> 50
ff7e: 1 -> 5e
ff7f: 98 -> 5
ff80: e0 -> 1
ff81: 43 -> e8
ff82: 59 -> 9b
ff83: 80 -> 58
ff84: 3 -> 84
ff85: 40 -> 0
ff86: 0 -> 9
ff87: 0 -> fe
ff88: 20 -> ff
ff89: 43 -> 5c
ff8a: 59 -> 20
ff8b: 44 -> 4e
ff8c: 20 -> 84
ff8d: 50 -> 0
ff8e: 5e -> 9
ff8f: 5 -> 18
ff90: 1 -> 0
ff91: e8 -> f3
ff92: 9b -> 78
ff93: 58 -> 2a
ff94: 84 -> 0
ff95: 0 -> 58
ff96: 9 -> 84
ff97: fe -> 5c
ff98: ff -> 9
ff99: 5c -> 18
ff9a: 20 -> 0
ff9b: 4e -> fb
ff9c: 84 -> 49
ff9d: 0 -> da
ff9e: 9 -> 28
ff9f: 18 -> 77
ffa0: 0 -> 1
ffa1: f3 -> f5
ffa2: 78 -> 4
ffa3: 2 -> 19
ffa4: 0 -> 53
ffa5: 58 -> c
ffa6: 84 -> 64
ffa7: 5c -> da
ffa8: 9 -> 28
ffa9: 10 -> 78
ffaa: 2 -> 1
ffab: fb -> 4e
ffac: 49 -> 45
ffad: da -> 0
ffae: 28 -> 0
ffaf: 77 -> fc
ffb0: 1 -> 44
ffb1: f5 -> 3a
ffb2: 4 -> 74
ffb3: 19 -> 4c
ffb4: 53 -> 58
ffb5: c -> 68
ffb6: 64 -> 1
ffb7: da -> 0
ffb8: 28 -> 0
ffb9: 78 -> 0
ffba: 1 -> 0
ffbb: 4e -> ed
ffbc: 45 -> ff
ffbd: 0 -> a0
ffbe: 0 -> e3
ffbf: fc -> 27
ffc0: 44 -> 4b
ffc1: 3a -> 4a
ffc2: 74 -> 58
ffc3: 4c -> fc
ffc4: 58 -> 53
ffc5: 68 -> df
ffc6: 1 -> 51
ffc7: 0 -> 5c
ffc8: 0 -> 6
ffc9: 0 -> da
ffca: 0 -> 28
ffcb: ed -> 3
ffcc: ff -> 0
ffcd: a0 -> 9b
ffce: e3 -> 7
ffcf: 27 -> 93
ffd0: 4b -> 0
ffd1: 4a -> 93
ffd2: 58 -> 3
ffd3: fc -> bb
ffd4: 53 -> 59
ffd5: df -> 93
ffd6: 51 -> 0
ffd7: 5c -> da
ffd8: 6 -> 28
ffd9: da -> 63
ffda: 28 -> 1
ffdb: 3 -> 4
ffdc: 0 -> 71
ffdd: 9b -> da
ffde: 7 -> 28
ffdf: 2 -> 5
ffe2: 3 -> 7c
ffe3: bb -> 59
ffe4: 59 -> b
ffe5: 2 -> 19
ffe6: 58 -> 1
ffeb: 2 -> 4b
ffec: 7 -> 5

83f6: 87 -> 77

8458: 11 -> 29

86a9: 0 -> 3
86ac: 1 -> 3
86ad: 2 -> 1
86b2: 14 -> 6
86b3: 44 -> 52
86b4: 6f -> 41
86b5: 6f -> 44
86b6: 72 -> 49
86b7: 73 -> 43
86b8: 43 -> 41
86b9: 53 -> 4c
86ba: 45 -> 0
86bd: 14 -> 6
86be: 0 -> 52
86bf: 0 -> 41
86c0: 0 -> 44
86c1: 0 -> 49
86c2: 0 -> 43
86c3: 0 -> 41
86c4: 0 -> 4c

8785: bb -> c4
878a: c7 -> b7

8aa0: 4 -> 6
8aa4: 5 -> 7

8ad2: 4 -> 6
8ad6: 5 -> 7
8ae3: 6 -> 8

8b4c: 1 -> 0

8b65: 40 -> 60

9250: 80 -> c0
9bde: dd -> 66
9fa9: 0 -> 1

a024: f9 -> f8
a5c0: 2 -> a
a69c: c7 -> b7


Edit #2: After noticing the (MenuCurrent) difference, I tried un-commenting the xor a \ ld (MenuCurrent),a I had commented out from code from Doors CS, something I swear I had tried before. So far it looks like it might be working.

Edit #3: Testing on jsTIfied and a real calculator shows that this is probably repaired. I will be releasing a Release Candidate this evening.
Using DCSE 8.1 (build 1544, if that helps), I was editing my program, and I used the multiple line skip thing with Alpha Lock and then hitting down. When the arrow got to its destination, my calc whitescreened, with a bunch of random boxes appearing that were alternating white pixels and black ones. Nothing was lost, and I got out of it by waiting then turning the calc off.
123outerme wrote:
Using DCSE 8.1 (build 1544, if that helps), I was editing my program, and I used the multiple line skip thing with Alpha Lock and then hitting down. When the arrow got to its destination, my calc whitescreened, with a bunch of random boxes appearing that were alternating white pixels and black ones. Nothing was lost, and I got out of it by waiting then turning the calc off.
Are you able to replicate this by performing those same steps again? If you are, please send me the program you were editing.
Feature request/bugfix: compatibility with BASIC programs that don't use xLIBC and use real() for its real purpose. The best solution that comes to my mind is to only enable xLIBC features the first time that real() is invoked with multiple arguments. All non-xLIBC programs would then function properly, and all xLIBC programs that invoke some multi-argument real() command as the first library command would also function properly. And seeing that the only single-argument xLIBC command (for now) is UpdateLCD, which doesn't make much sense to invoke before setting up and drawing something, all well-formed xLIBC programs should function properly.

Letting programs access the real usage of real() when they're using xLIBC could be considered as well. It would always work for all numbers other than 9, which seems functional enough that it would be worth adding. It would probably even work for 9 (or any other number that coincides with a one-argument xLIBC command) in practice, as the fact that the real() is being used means the source of the value probably involved complex math, so the argument would really be a complex 9, which can be differentiated from a real 9.
Runer112 wrote:
Feature request/bugfix: compatibility with BASIC programs that don't use xLIBC and use real() for its real purpose. The best solution that comes to my mind is to only enable xLIBC features the first time that real() is invoked with multiple arguments. All non-xLIBC programs would then function properly, and all xLIBC programs that invoke some multi-argument real() command as the first library command would also function properly. And seeing that the only single-argument xLIBC command (for now) is UpdateLCD, which doesn't make much sense to invoke before setting up and drawing something, all well-formed xLIBC programs should function properly.

Letting programs access the real usage of real() when they're using xLIBC could be considered as well. It would always work for all numbers other than 9, which seems functional enough that it would be worth adding. It would probably even work for 9 (or any other number that coincides with a one-argument xLIBC command) in practice, as the fact that the real() is being used means the source of the value probably involved complex math, so the argument would really be a complex 9, which can be differentiated from a real 9.


QFT x9000.

See also: https://www.cemetech.net/forum/viewtopic.php?p=216544#216544

See also: http://www.cemetech.net/forum/viewtopic.php?p=208404#208404
What about an OpenLib/ExecLib interface with DCE8 to enable/disable the various hooks?
tr1p1ea wrote:
What about an OpenLib/ExecLib interface with DCE8 to enable/disable the various hooks?



... still breaks normal math program that aren't targetting DCSE specifically, and doesn't help the situation on DCS7. At least on DCSE, there aren't non-DCS xlib programs, so you should really just disable the libraries entirely for Basic programs with a DCSE header. Still leaves things a mess on the B/W calcs, and TI still hasn't patched OpenLib( to even work with lowercase letters.
Didn't want to derail the current news topic, but frustrating ironies abound:
KermMartian wrote:
I urge you, my fellow calculator programmers, to continue to explore some educational calculator programs alongside your usual excellent games and utilities, so we can raise awareness in math and science classrooms about how valuable of a teaching tool graphing calculator programming can be.


elfprince13 wrote:
tr1p1ea wrote:
What about an OpenLib/ExecLib interface with DCE8 to enable/disable the various hooks?



... still breaks normal math program that aren't targetting DCSE specifically, and doesn't help the situation on DCS7. At least on DCSE, there aren't non-DCS xlib programs, so you should really just disable the libraries entirely for Basic programs with a DCSE header. Still leaves things a mess on the B/W calcs, and TI still hasn't patched OpenLib( to even work with lowercase letters.







On a less-complaining-y note, I think it would be awesome to support executing program bundles directly out of groups. You could check the group for the existence of a DCS-specific AppVar with information about what program to treat as the main program, and then auto-extract the resources, execute, and clean up afterwards. This would be fantastic for BASIC developers (and for managing games with lots of levels).
As for my last post, Kerm, it happens every once in a while.

My calculator froze when unplugging it while viewing the InfoBox on a program (box that pops up after you wait a fair amount of time, shows size of current object).
I can't hit any buttons, and after plugging it back in and waiting for a good half-hour, it was still frozen.
[cue]Frozen "Theme song" aka Let it Go :P[/cue]
123outerme wrote:
As for my last post, Kerm, it happens every once in a while.
123outerme wrote:
Using DCSE 8.1 (build 1544, if that helps), I was editing my program, and I used the multiple line skip thing with Alpha Lock and then hitting down. When the arrow got to its destination, my calc whitescreened, with a bunch of random boxes appearing that were alternating white pixels and black ones. Nothing was lost, and I got out of it by waiting then turning the calc off.
Would you mind grabbing a screenshot or a photograph of this if you're able? I haven't run into this issue before.

Quote:
My calculator froze when unplugging it while viewing the InfoBox on a program (box that pops up after you wait a fair amount of time, shows size of current object).
I can't hit any buttons, and after plugging it back in and waiting for a good half-hour, it was still frozen.
[cue]Frozen "Theme song" aka Let it Go Razz[/cue]
I'm sorry to hear that. Sad I'll do my best to replicate this and find a workaround for it, which might be as simple as disabling the USB interrupts when DCSE is not running programs.
Kerm (and anyone else who's interested), I finally found the Alpha Skip bug I was talking about. I documented the glitching screen: http://youtu.be/leuoj6AiHtc
123outerme wrote:
Kerm (and anyone else who's interested), I finally found the Alpha Skip bug I was talking about. I documented the glitching screen: http://youtu.be/leuoj6AiHtc
Do you have any idea how I can trigger that? Does one particular program cause it? Does scrolling to a particular place in the program (top? bottom?) cause it?
KermMartian wrote:
123outerme wrote:
Kerm (and anyone else who's interested), I finally found the Alpha Skip bug I was talking about. I documented the glitching screen: http://youtu.be/leuoj6AiHtc
Do you have any idea how I can trigger that? Does one particular program cause it? Does scrolling to a particular place in the program (top? bottom?) cause it?

As far as I know, the trigger is random. I think that repeatedly hitting the down or up arrow does it somehow, but I can't really prove it.
Feature Request: After pressing enter in editor, replace the real(, etc. with their respective command as xLib, etc. sees it. Like Axe does.
Hhhmm... not so sure about that one, some kind of context menu or something might help. What if you make a mistake and have to change the function number?
This is really weird.
If you type a number into the home screen and don't hit enter (just leave it there while the cursor is blinking), open DCSE using On+PRGM, and quit, there will be a bunch of empty characters on screen.

I tried to purposefully do that and inputted 111 (a random number at the time). I opened DCSE using On+PRGM, but accidentally turned the calculator off. When I turned it back on, my calc crashed. I turned my clac back on, and when I looked around my folders, things were in the wrong folders. Even some programs that were erased when my Archive was cleared were restored Shock
tifreak8x wrote:
Request:

det(13,SEARCHPARAM

SEARCHPARAM:

1- All programs/appvars
2- All programs
3- All appvars

Stored back to Str9, names separated via symbol of your choosing (As in you, Kerm, not the user)

This function would be good for programs/games to verify all sub programs are installed, and allow for games to check for level packs.


Bumping that.

Also, can we get something that lets us bump the brightness back and forth 1 level?
elfprince13 wrote:
Didn't want to derail the current news topic, but frustrating ironies abound:
KermMartian wrote:
I urge you, my fellow calculator programmers, to continue to explore some educational calculator programs alongside your usual excellent games and utilities, so we can raise awareness in math and science classrooms about how valuable of a teaching tool graphing calculator programming can be.


elfprince13 wrote:
tr1p1ea wrote:
What about an OpenLib/ExecLib interface with DCE8 to enable/disable the various hooks?



... still breaks normal math program that aren't targetting DCSE specifically, and doesn't help the situation on DCS7. At least on DCSE, there aren't non-DCS xlib programs, so you should really just disable the libraries entirely for Basic programs with a DCSE header. Still leaves things a mess on the B/W calcs, and TI still hasn't patched OpenLib( to even work with lowercase letters.


Bump.





elfprince13 wrote:
On a less-complaining-y note, I think it would be awesome to support executing program bundles directly out of groups. You could check the group for the existence of a DCS-specific AppVar with information about what program to treat as the main program, and then auto-extract the resources, execute, and clean up afterwards. This would be fantastic for BASIC developers (and for managing games with lots of levels).

Other bump.
elfprince13 wrote:
tr1p1ea wrote:
What about an OpenLib/ExecLib interface with DCE8 to enable/disable the various hooks?
... still breaks normal math program that aren't targetting DCSE specifically, and doesn't help the situation on DCS7. At least on DCSE, there aren't non-DCS xlib programs, so you should really just disable the libraries entirely for Basic programs with a DCSE header. Still leaves things a mess on the B/W calcs, and TI still hasn't patched OpenLib( to even work with lowercase letters.
Did you mean disable the libraries entirely for BASIC programs without a DCSE header? Unfortunately, people still make programs that use the xLIBC libraries but don't have the DCSE header and icon. With that being said, I bump my previous proposal:
KermMartian wrote:
Doors CS 7.2 and Doors CSE 8 both have this. I can detect it and return valid values for complex and imaginary numbers and for all reals except integers 1-14, but dealing with the integers 1-14 properly is harder. tr1p1ea, I recommend we do something about this for Doors CSE 8 ASAP, and figure out what kind of fix to backport later (since it seems not to be a bug people encounter daily (????)). The biggest problems are reals 6, 8, 11, and 14 on the monochrome calculators, and real(9) on the color calculator, since those are the functions that take a single argument. Is there some function that all xLIB-using programs run in practice before using the other real() functions?
In other words, make DCS and DCSE use the normal OS functionality for real() until the first time it is called with multiple arguments, then use the hooked version until the program ends. Honestly, the hardest part would be finding some very safe RAM to store a bit (ie, a binary digit) of state about this. For Doors CS 7 on the monochrome calculators, reals 14, 11, and 8 are the only ones that might be called before a multi-argument real. Doors CSE would be much easier: the online single-argument real() can never be the first xLIBC command called.

elfprince13 wrote:
On a less-complaining-y note, I think it would be awesome to support executing program bundles directly out of groups. You could check the group for the existence of a DCS-specific AppVar with information about what program to treat as the main program, and then auto-extract the resources, execute, and clean up afterwards. This would be fantastic for BASIC developers (and for managing games with lots of levels).
It would be very cool, but a pretty complex thing to implement. Even manipulating levels from user programs is pretty hard, given that the OS bcalls to work on these tasks are incompletely reverse-engineered and poorly documented. I'd say this is firmly on my long-term feature requests list, unfortunately.

tifreak8x wrote:
Request:

det(13,SEARCHPARAM

SEARCHPARAM:

1- All programs/appvars
2- All programs
3- All appvars

Stored back to Str9, names separated via symbol of your choosing (As in you, Kerm, not the user)

This function would be good for programs/games to verify all sub programs are installed, and allow for games to check for level packs.
I'd prefer to make this a function, as in Doors CS, that would list all programs, appvars, or both that started with a certain series of bytes or with a name starting in a certain sequence. I feel like that might be better suited for games, and less suited to silly beginners making halfhearted BASIC shells (not you, of course).

TIFreak8x wrote:
Also, can we get something that lets us bump the brightness back and forth 1 level?
It would be more versatile to let programmers set the brightness to an arbitrary value, but I'm hesitant about the ways that that could be abused.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3 ... 7, 8, 9 ... 12, 13, 14  Next
» View previous topic :: View next topic  
Page 8 of 14
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement