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.

(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:


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.

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.

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?

... 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:









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]

Would you mind grabbing a screenshot or a photograph of this if you're able? I haven't run into this issue before.

I'm sorry to hear that. 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

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

Bumping that.

Also, can we get something that lets us bump the brightness back and forth 1 level?

Bump.






Other bump.

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:
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.

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.

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).

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.