- 30 Sep 2013 11:20:01 pm
- Last edited by KermMartian on 01 Oct 2013 03:16:49 pm; edited 6 times in total
CalcGuy123 wrote:
I ran into a bug while quitting Doors where my calc crashed, but I haven't been able to replicate it yet. Also I don't know if this is normal, but the basic programs unlock after the calc crashes.
Can you give me more specific steps for replicating those issues? So far I haven't succeeded.
Quote:
Also I think that when you run a program, the 2nd or enter key is stuck.
What do you mean?
ThatNinja27 wrote:
I am actually really excited for this. I just recently got my TI84 CSE and I was spending hours trying to load Doors 7 on it until i realized they werent compatible. I do wanna be part of the beta, but its fine if i cant. Keep up the good work!
Thanks! I might have enough beta testers for now, but we'll soon get into Release Candidates, which will be available to the public.
merthsoft wrote:
Two issues:
1) Pressing [ALPHA] a second time should close the menu
2) When closing the menu (I've only been able to do it with clear), don't put the cursor back to the upper-left
(1) is solved. (2) is challenging, since sometimes deleting programs means the cursor has to be moved backwards. I'm hesitant to implement this when I have only 80 bytes free on Page 0.
1) Pressing [ALPHA] a second time should close the menu
2) When closing the menu (I've only been able to do it with clear), don't put the cursor back to the upper-left
merthsoft wrote:
A celtic suggestion:
BufSpriteSelectAppVar(<APPVARNAME>,width,X,Y,line
That way we can save the step of pulling the sprite data out of the appvar. The BufSpriteSelect helps with that, but if you have a lot of sprites that might make Str9 get really big really fast.
That's a very reasonable suggestion indeed, but I fear it would be trading speed for size. Searching for the Nth line of an AppVar with a lot of big sprites in it would take a pretty long time, and for the sake of my sanity, I would have to make it only use RAM AppVars anyway. which of course take the same space as strings. I may put this one aside for a future version, if any.
BufSpriteSelectAppVar(<APPVARNAME>,width,X,Y,line
That way we can save the step of pulling the sprite data out of the appvar. The BufSpriteSelect helps with that, but if you have a lot of sprites that might make Str9 get really big really fast.
Hayleia wrote:
-DoorsCS doesn't launch programs starting with Asm84CPrgm properly. It recognizes them as Basic programs and obviously finds an error.
I'm afraid I don't plan to support uncompressed ASM programs.
Anyway, my usual summary:
Unconfirmed bugs
- ON/STAT/PRGM combination causes crash from desktop (16aroth6)
- Two crash bugs from executing and/or listing programs (t.roos)
Confirmed bugs
- Editing some programs or running some programs with low memory causes pieces of programs to get copied into themselves.
- Running DrDnar's CLOCK program from the DCSE desktop causes the LCD to go into panic mode
- Running SPAZE from the DCSE desktop causes the LCD to go into half-resolution panic mode
- Choosing 1:Quit when an ERR:SYNTAX pops up from bad input to Prompt or Input causes HomeRun to be left disabled until DCSE is next run.
Repaired issues
- Desktop selection rectangle no longer erased when opening Properties menu
- All BASIC programs run in 15MHz mode all the time
- ALPHA closes/cancels the Properties menu
- Bad APD mode and hook of some sort left enabled on homescreen when ON-BREAKing programs from inside a Menu(). All homescreen key input is blocked until the calculator is powered off. -> Fixed by setting 0->(MenuCurrent) when BASIC programs are broken.
- Impolite graphscreen/homescreen behavior after quitting from DCSE desktop and/or HomeRun.