Can you give me more specific steps for replicating those issues? So far I haven't succeeded.

What do you mean?

Thanks! I might have enough beta testers for now, but we'll soon get into Release Candidates, which will be available to the public.

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

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.

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.

Eh, okay.

Maybe:
BufSpriteSelectAppVar(<APPVARNAME>,width,X,Y,length,line
Where length is the length of each sprite? That way you can, I assume, just seek there without having to do any line counting, just length*line+line or something. This means all sprites have to be the same size, but for something like Minesweeper, that's ideal. What challenges does ROM introduce?

Additionally, will you be changing the detection to det([[1337 and returning 80, 81, 90, etc.?

I've been assuming that sprites can be variable-size because of the G optimization. The ROM introduces the challenge that I'd have to do more clever page-swapping to move the relevant pages into Bank A, although I guess now that the sprite routine gets copied to $8000 anyway, this isn't as big of a problem.

I already changed it to det([[20 -> 80, 81, 90, etc. Cf. the documentation.

I think it's up to the programmer to trade speed and size. If it's an AppVar in ROM size might not be too terribly important, so I wouldn't optimize with the G option. If I need to keep things small, I'll use G. Basically, if you're using BufSpriteSelectAppVar(<APPVARNAME>,width,X,Y,length,line you're making the conscious decision to not optimize the size. Even using the BufSpriteSelect routine would be a lot of work if you have variable-size sprites (you'd need a list or something that keeps track of the sprite size, and you'd have to update it any time you change your sprites).

Okay, I found a more concrete reason not to add BufSpriteSelectAppVar(), at least for archived AppVars. Because I need to keep swapping the page in Bank A between the RAM page used for the graph buffer and the ROM page holding the AppVar in question, as I need to keep RAM $8000 to $BFFF in Bank B for the RAM copy of the sprite code, various safeRAM variables and a palette, and so on. That swapping would be expensive, or at least annoying. Should I go ahead anyway?

On the bug front, I managed to find my way through some vague bug reports that CalcGuy123 gave me on SAX to come up with these two:
(1) Holding 2nd or ENTER while launching a program will cause the program you launch to get a keypress when you release the key.
(2) Using FROGGER.8xp (archived), as an example, right-clicking and choosing Edit will occasionally cause the program to display oddly, including suddenly re-launching Doors CSE from inside itself, leading to a crash when you quit DCSE.

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.

Repaired issues
- 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
- Using FROGGER.8xp (archived), as an example, right-clicking and choosing Edit will occasionally cause the program to display oddly, including suddenly re-launching Doors CSE from inside itself, leading to a crash when you quit DCSE. This only happens after you power off and on from DCSE, edit a program (the cursor will misbehave), then quit back to the desktop and edit again. Solved by finding that one set of hook backups around program editing was getting saved in the wrong safeRAM area, one that presumably was getting overwritten somewhere. I'm not sufficiently clear what was happening to feel confident that this is gone forever, but it seems likely that cmdShadow gets trashed while the edit buffer is in use.
- Holding 2nd or ENTER while launching a program will cause the program you launch to get a keypress when you release the key. -> Solved by improving ThoroughDebounce routine, at the cost of a few bytes.
- "Press ENTER" text when paused at the end of a BASIC program -> reverse-engineered how the OS draws status bar text; sadly, not exposed as a BCALL. It did give me the exact color and coordinates for the text, though, as well as the RAM buffer the OS uses for RAM copies of strings, and the word where the status bar background color is stored.
- PROGRAM:NAME text in fullscreen BASIC editor -> Implemented
- 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. -> Fixed silly OS behavior with equally-silly hook and stack abuse.

Would it be slower to do that than to just read the line in Str9 each time? If so, then it's not worth it. If not, then it is.

Is it too late or can I beta test?

I think he is referring to the bug in Beta 2 where the 2nd key did not work in some assembly programs.

Anyway, Beta 3 looks great! I have not found any problems with it so far that have not already been reported.

To be honest, I'm not exactly sure. I think it might be slightly faster to just do the constant page-swapping, given the overhead of the OS deleting and re-creating Str9 each time.

I'm afraid that I already have enough beta testers. However, the public Release Candidates will be starting very soon, and once that phase is underway, I'll need as many people as possible to make sure that there are no glaring bugs in the shell.

Thanks, and awesome! Please let me know if that changes.

Also, here are two screenshots of two new features I added, both of which include drawing some text to the status area. I did some reverse-engineering to find out where the OS puts the text and what colors it uses, but sadly, that reverse-engineering didn't yield me a BCALL to write text to the status bar. The first screenshot shows how I solve displaying the program name in the full-screen editor, and the second shows how I clarify that Doors CSE has not frozen when it is paused at the end of running a BASIC program (a feature that allows you to copy homescreen output from BASIC programs before DCSE regains control).

No that's not it. When you use it to enter a program, it presses once while it is running

Indeed, I replicated the problem and solved it by shoring up my debouncing routine.

In my attempts to get at the bug you asked me to, I had under 1kb of free RAM, then tried to edit BTetris (~2500 bytes) and got an 'ERR: Archive'. Pressing ENTER caused a RAM clear. :<

I had another crash, I haven't managed to replicate but here is what I remember doing before the crash.
I had one program, archived, (it was tetrisA), and I went into the options and turned on the "always launch Doors CSE". Retuned to home screen, tuned off the calc, turned on, testing to see if doors opened, which it did.
Made a new folder, "test", went into options turned off the "always launch...etc".
Turned calc off and back on, opened doors, alpha clicked on my test folder and tried deleting it. Nothing happened, so I tried deleting again and this time my calc screen went gray and white, and crashed.
Turned calc back on, opened doors, "your calc has crashed... Etc", alpha clicked my "test" folder, which deleted without a problem this time.
I haven't any idea what it means, and I've been trying to replicate it.

Unconfirmed bugs
- 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.
- Debounce problem from DCSE desktop persists

Resolved issues
- Editing archived programs with low free memory causes a crash (tifreak8x)
- Homescreen edit hook fails because OS doesn't open edit buffer properly -> solved by setting (cxCurApp) to cxCmd before launching new context.
- Homescreen editing of archived programs in a low-RAM condition causes a crash after the 506 Archived error is displayed.
- HomeRun execution of archived BASIC programs in a low-RAM condition causes an immediate crash. Desktop execution of archived BASIC programs in a low-RAM condition causes a freeze.
- Running ASM program with low RAM from HomeRun causes 504 error (not found): prgmecsasmex. Same error from DCSE desktop. No crash or freeze occurs. -> Changed to err 505, not enough mem.
- Celtic 2 CSE bug with single-pixel noise in transparency, as evidenced in Jezzball. -> Solved by fixing LCD reads that were missing dummy reads

Edit: I'm tossing out the unconfirmed bug "ON/STAT/PRGM combination causes crash from desktop (16aroth6)", because I can't for the life of me replicate it.

I will try it again... I did get my calc to do it four times.

Oh, excellent. Thanks in advance for the more detailed set of steps to replicate the problem.

Edit: Got my hooked OS program editor working! It provides editing of archived programs, full-screen editing, the program name in the status area, and sane fast (ALPHA) scrolling. Thanks to a suggestion from Shaun, it also will display a * next to the name of archived programs in the status area.

This looks wicked nice!

Thanks, Shaun! Can I trust that you and tifreak8x and others will test it very thoroughly in Beta 4, which I hope is the last beta before we begin Release Candidates?

Unconfirmed bugs
- Two crash bugs from executing and/or listing programs (t.roos)

Confirmed bugs

Resolved issues
- Editing archived programs with low free memory causes a crash (tifreak8x)
- Homescreen edit hook fails because OS doesn't open edit buffer properly -> solved by setting (cxCurApp) to cxCmd before launching new context.
- Homescreen editing of archived programs in a low-RAM condition causes a crash after the 506 Archived error is displayed.
- HomeRun execution of archived BASIC programs in a low-RAM condition causes an immediate crash. Desktop execution of archived BASIC programs in a low-RAM condition causes a freeze.
- Running ASM program with low RAM from HomeRun causes 504 error (not found): prgmecsasmex. Same error from DCSE desktop. No crash or freeze occurs. -> Changed to err 505, not enough mem.
- Celtic 2 CSE bug with single-pixel noise in transparency, as evidenced in Jezzball. -> Solved by fixing LCD reads that were missing dummy reads
- Editing some programs or running some programs with low memory causes pieces of programs to get copied into themselves. -> Fixed, after many years! I always blamed it on the OS, and that was sort of right, but my code was part of the problem. I urge everyone to try editing archived programs (and unarchived programs) with very little RAM free to make sure it's gone.
- Debounce problem from DCSE desktop persists

*bump* As you can see from that excellently empty "Confirmed Bugs" section in the previous post, things are looking rather up for Doors CSE 8.0. In fact, Beta 4 is now ready, but to save you guys extra PMs if you don't have the time to beta-test this version, please PM me or post here to confirm that you're in for beta-testing Beta 4. Here are some things I recommend trying:

- Running TI-BASIC programs from RAM and Archive, from the homescreen using HomeRun and from the Doors CSE desktop. Please try with low RAM and/or low Archive and/or low batteries if you have a chance.
- Running ASM programs under the same circumstances, including half-res and full-res programs.
- Messing with all the settings and making sure they all works and don't interact crashily.
- Try out the Hybrid BASIC libaries, which are now documented on the Doors CS/Doors CSE wiki.

Thanks in advance!

I didn't get a lot of time to test Beta 3 (short of double checking that the Calcuzap speed related key issue was fixed), but I will have some time this week to test Beta 4. I'll do whatever I can to attempt to "break" it

I'll also turn Spaze Invaders into a Doors CSE program and see how that goes.