Haha, much appreciated, that's exactly what I want.

That's great! You'll also be the first person to check the functionality of the half-resolution header field in the Doors CSE header.

So far, b3 has been working pretty a well.

Staying tuned for b4, but I think that after that RC1 should be released.

No rush though, great job!

Beta 4 is in JamesV, Chaldron, and Hjax's PM mailbox. I agree that Release Candidate 1 should come after Beta 4; as long as I can get Runer112's sprite routines and tr1p1ea's new xLIBC code, I'll be set for RC1. And thanks in advance for those bug reports.

Ok one interesting thing I have noticed on Beta 4 while playing with the clock speed program found here: http://www.ticalc.org/archives/files/fileinfo/420/42000.html

When the program is run with mathprint on it apparently breaks and prints out something like:
S6
1
1
1

When mathprint is off and it is run with DCSE it also doesnt work

When run with homerun and mathprint off is also breaks

However if you go into DCSE and run any program and then close it, it goes back into DCSE, from there you can run the clock speed test just fine. If you close DCSE and reopen in the clock tester is broken again.

Clock tester is always broken in homerun with mathprint off regardless of what you run before it however there is still something else strange:

If i go into programs and run Clock with homerun it displays the C6, 1,1,1 on the left side of my screen

If i go into programs and run something, close it, and then right away run clock from programs then the S6,1,1,1 is centered

Anyway I am not sure what to make of it

Ok I have found many bugs with beta 4:

1: When moving basic programs around between folders using the cut and paste, DCSE often fails to move a program at all, moves the wrong program, or in one case managed to mess up the name of a program (in DCSE SUDOKU is now called SUDOKB and in the archive it is called SUDOKu (lowercase u)). It is important to note that I this is only affects BASIC programs as far as i can tell any only works when the source folder contains more than one BASIC file.

2: Create a folder with any name, open it, create a folder inside it with any name. Do not open this new nested folder, instead hit window to return to the parent folder and then hit alpha to bring up the right click menu. The hourglass appears in the center of the screen and remains there after the right click menu loads even though it should disappear. This bug also occurs with deleting a folder that contains another folder and then immediately pressing alpha.

3: Somehow my TETRICA file got corrupted while archived and pieces would disappear as they were placed and the calculator would ram-clear when the program was closed. I need to do some more testing to see if i can replicate this.

4: Sometimes when DCSE crashes (mostly when i end up crashing it over and over to test a bug) some files in the archive get deleted. They do not show up in DCSE or the programs list.

5: Sometimes after a crash/ramclear a program will not appear in DCSE but still appear in the programs list (PGRM button).

I've been unable to replicate this moving BASIC programs between a folder named GAMES and a subfolder of that folder called TEST. Can you give me more precise steps to replicate this, if possible?

Yeah, I know this happens, I just haven't bothered to do anything about it. If I remove the option to disable alpha-sorting programs, which I doubt anyone actually turns off, I might free up enough space to write the fix for this.

Please do. I've tried and failed to replicate it. This sounds like it may be a Tetric A bug rather than a Doors CSE bug.

Did this happen for anything other than the Tetric A issue?

Same question as for #4.

Thank you very much for these in-depth bug reports! This is exactly what I needed.

Edit: I have found the cut/paste bug. In the right circumstances, the recreation of the FLDSV8 AppVar as triggered by backing up the folder structure caused the PasteWord pointer into the VAT to be invalidated. On benryves' excellent suggestion, Doors CSE now records the name of the variable being cut-pasted, not a VAT pointer. Please test the new version!

I found that with the low RAM I mentioned last night in my PM, when I tried to start DCSE (using [ON]+[PRGM]), it went into an infinite loop of "ERR:MEMORY". I turned my calculator off, and then I had to hard reset it to get it back on.

I'm not sure if that's a DCSE related issue or a TI-OS issue. I'll try to recreate it again later, and start DCSE via the standard [APP] menu and see if it still happens.

Just a question, is it supposed to jump to the last program on the screen when you push up at the top row?

I think so, as a "cycle through programs" feature.

Hmm... So kinda like the end button on our computers, yet it seems counter-intuitive.

Menus in the TI-Z80, TI-68k and Nspire series work that way.

That's of concern, thanks for uncovering this. I look forward to hearing more details on this. It sounds like it might have gotten stuck working with the DCSE8 or FLDSV8 AppVar; is that possible? I should really just abort launching the shell if very little memory is available, and I'll check the code paths from the memory errors on those two items out of the shell.

Also, thanks to JamesV for finding a latent bug with processing DCSE8 ASM programs' headers.

As Lionel says, I find that the majority of calculator menus wrap the cursor around from top to bottom and bottom to top. It would be a pain to scroll all the way down from the top screen to the bottom, page by page, instead of just pressing [UP] once!

Edit: Hjax (and anyone else): Please let me know if you're willing to test a new DCSE8-specific version of Tetric A.

Edit #2: Some bugs:
Confirmed bugs
- Silent linking during modified BASIC editor causes a crash
- JamesV's infinite ERR:MEMORY loop (see above)
- If there's space, make the hourglass region get saved/restored

I'll retry the ASM header tonight with the updated build, and then mess around with low RAM again to see if the "ERR:MEMORY" comes up again when loading DCSE8. Like I said, I'll also try loading via the normal [APP] menu method, just on the odd chance that the infinite loop was related to the [ON]+[PRGM] hook executing. I don't have much experience with interrupts and hooks, so that's just me guessing heh.

I'm modifying how and when Doors CSE checks for its AppVars and recreates them, as well as how it escapes from a critical free RAM situation. I'll update the file on Cemetech soon with my fixes; I'll edit this post when I'm happy.

Edit: Okay, JamesV, Hjax, all other beta-testers, a new and updated Beta 4 is now available! Check it out at the usual link. Please especially check all of the properties menu tools.

Edit #2:

Confirmed bugs

Complete
- If there's space, make the hourglass region get saved/restored
- Speed gets set to slow by BASIC editor -> Editor keyhook constantly fixes CPU speed, and alpha sort sets fast mode before sorting.
- [CLEAR] during folder/file name input crashes instantly -> Turned out to be a long-standing stack depth bug masked by shell flow.
- Silent linking during modified BASIC editor causes a crash
- JamesV's infinite ERR:MEMORY loop (see above) (possibly fixed) -> Believed fixed, as below.

I've done some more testing. Spaze Invaders now has a functioning DCSE8 header Also, the [ON]+[PRGM] infinite ERR:MEMORY loop appears to be fixed.

There appears to still be some memory loss problems, unless I'm missing something. Here are the detailed actions & results:

- 3466 bytes free RAM
- Ran DCSE8 fine both with [APPS] and [ON]+[PRGM]
- Ran Calcuzap from DCSE desktop, no problem
- 3425 bytes free RAM, but no new variables? Lost 41 bytes?
- Ran Calcuzap with home run, no problem
- 3416 bytes free RAM (makes sense, 9 bytes for "prgmCALCUZAP" last entry)
- Ran PCSEBALL from DCSE desktop
- 3375 bytes free RAM - lost 41 bytes again?
- Ran Calcuzap from DCSE, no RAM lost this time (still 3375 free)
- Created a dummy matrix to consume RAM, left with 646 bytes free
- Ran DCSE with [ON]+[PRGM], quit, lost 23 bytes? (623 bytes free)
- Ran Calcuzap with home run, no problem (still 623 bytes free)
- Ran Merth's Snake from DCSE desktop, got memory error after welcome screen, pressed goto and went to the line :Text(0,0,"Score: ",0
- Quit back to DCSE, back to TI-OS
- 130 bytes free RAM (463 bytes of variables were created, so 30 bytes lost?)
- Edited matrix to get down to 76 bytes free RAM
- DCSE loads fine from [APPS]
- ERR:MEMORY when using [ON]+[PRGM], but successfully returned to TI-OS
- 35 bytes free RAM (lost 41 bytes again, is this something to do with the [ON]+[PRGM] interrupt hook?)

EDIT (possible DCSE8 half-res mode bug): With the half-res mode setting in the header, this appears to also affect LCD register $03, specifically I think bit 3 of this register (refer here on WikiTI). When I use the DCSE8 half-res setting, my sprites are all drawing sideways, but I can rectify this by setting the default value of $1038 to LCD register $03 at the start of my program. Is this a mistake or working as intended?

Im not sure if this has been mentioned yet, the only annoying thing I have found in beta 4 is that in the program editor (from dcs or home screen using the improve editor) you cant use [on] [stat]

One bug I found with CS 8 is that it doesn't show the programs written in flash, I have a couple games and programs under the app menu, but it doesn't show those, and another which i don't know if the program developer has to do this or you, but I was using scarth (your scorhed earth clone) (it was archived and so was zsct0 1 and 2 and it kept having an error and so I went to the code, and it said that it was zsct0. So I don’t know if there is any way to have CS 8 like bring those programs to the ram, and then when it is done, rearchive it.

I will look into this right now. Other than the half-res issue and the continued lack of new sprite routines and xLIBC code, this is the last known bug.

Edit: Just launching DCSE with ON-PRGM and then quitting seems to make memory disappear. Hmmmm.

I believe this is intended. I use the xLIBC full-res/half-res initialization routines directly, and he uses the $10B0 mode. Would you think it would be saner to set the $1038 mode when enabling half-res for ASM programmers?

I have implemented [ON][STAT] and normal APD in the editor, both from DCSE and from the desktop.

That's not a bug: Apps are stored differently from programs, and cannot be easily displayed on the Doors CSE desktop.
Unfortunately, having the ParserHook running during programs to catch this would slow down BASIC programs a great deal. That's something the developer should deal with using xLIB functions.

I'm not sure if "saner" is the right word; I guess $1038 makes more sense to my mind logically, but that's just the way my mind works. I don't think either way is "wrong" I don't mind if it stays the way it is, it's only a few bytes of code for me to set $1038 at the start of the program to enable all my sprite drawing, etc. to work correctly.

I think left-to-right sprites make more sense for me, so I'll set the $1038 mode myself, and let people who want to use $10B0 mode switch back to that themselves.

Regarding the memory leak problem, [ON][PRGM] seems to be solely responsible for leaking 41 bytes (from the homescreen or Y=) or ~15 bytes (from the homescreen, when you are typing things). I went back and loaded up Doors CS 7.2 on a TI-84+SE version of jsTIfied, and lo and behold, that same 41-byte loss occurs. I'm stumped, though, because my cleanup looks something like:
Code:


Edit: Looks like MathPrint may be the culprit. Turning MathPrint mode to Classic on the TI-84+SE made the leak disappear, and... yup, same thing on the TI-84+CSE. Now I need to find the mysterious BCALL that cleans up after MathPrint.

Edit #2: A very long night of debugging led me through a lot of dead ends and red herrings. I looked into how the homescreen gets torn down when entering the MODE and MemDelete menus when in MathPrint mode and tried to trace it out. I looked for where the MathPrint-related flags that I know about got modified. I used jsTIfied to dump memory state from the homescreen, from Doors CS launched from the ON-PRGM hook, from Doors CS launched from the Applications menu, and from the Mode menu. In the end, there are definitely 41 (or other amounts) bytes of RAM being inserted somewhere above $9D95 but below other RAM variables like # and !. I tried to _NewContext with a=cxExtApps in the hopes that I'd be able to do a valid context change out of cxCmd before calling _ExecuteApp, but I just got a VALIDATION error.

In the end, I realized that the _ExecuteApp call might be as simple as keeping the App name in progToEdit and calling _ExecuteApp with a=cxExtApps. Lo and behold, that seems to do the trick! Namely:
Code:
Please, please let me know if you know of a reason why this is a bad thing to do. It appears to fix my memory leak issues and to not introduce stability problems.

JamesV, tr1p1ea, and calc84maniac, I have specifically email you to notify you of this new version. Other beta testers, you can grab the latest and greatest beta 4 at the same link as before. Build number is 1057. JamesV, I have also dealt with the half-res mode issues, so first and only Doors CSE thing to do tomorrow morning is implement the ExecuteArchivedProg thing from xLIB into Celtic 2 CSE and test it.

Good night!

Edit #3: Thursday morning-ish. Solved problems with half-resolution mode that arose because I didn't check new code that I pulled in. I grabbed a new xlibc.asm from tr1p1ea, and I didn't realize the interface for SetRes_HalfMode and SetRes_FullMode was different than in my version. Special thanks to JamesV for pointing that out. Thanks also to JamesV for uncovering a weakness in my routine to scan for DCSE header fields, which would have forced programmers to put the icon last in future headers. Finally, thanks to whoever reported that the names of hidden BASIC programs were corrupted in the InfoPop view; that has been corrected.

Edit #4: As requested by tr1p1ea, I implemented ExecArcPrgm as det(11,...) in Doors CSE. I also expanded tifreak8x's excellent C2TEST program some more to test the function.