What are the differences between det(9 and det(10?

- det(9,width,x,y) displays a sprite with data in Str9 and width width at (x,y) onto the LCD while also copying it into the graph buffer. It copies the old contents of the graph buffer under that sprite back into Str9, so you can call det(9,...) again to erase the sprite. Sort of like XORing.
- det(10,width,x,y,offset,size) displays a sprite with data at offset offset in Str9 (and sprite data length size) at (x,y). It does not save the old contents of the graph buffer, but it does write to both the LCD and graph buffer. This is mostly faster because you can put a bunch of sprites into Str9, and you don't have to keep re-loading Str9 because det(9) erased its contents if you're not planning to XOR things.

tl;dr: det(9) is good for things like a player sprite or selector. det(10) is good for boards and maps and such. Both routines are best suited for when you want your sprites to go to the graph buffer or interact well with Text() and Line() and other OS drawing output.

Can't wait for the Beta.
But alas, I must.

I want the beta so bad.

Okay, Doors CSE 8 Beta 3 is ready for testing! I will be sending it along to you guys shortly; if I forget anyone, please let me know. As with the previous two betas, it is of utmost importance that you share this file with no one, not even your closest friends. Final release versions will soon be ready, and it will be much, much better if those are the versions that end up in the wild. Thanks for your help in advance. I look forward to all bug reports; here's what I already have (and please help clarify all the bugs listed, if you have experienced them):

Unconfirmed bugs
- ON/STAT/PRGM combination causes crash from desktop (16aroth6)
- Two crash bugs from executing and/or listing programs (t.roos)
- Bad APD mode and hook left enabled on homescreen when ON-BREAKing programs from inside a Menu()?
- Impolite graphscreen/homescreen behavior after quitting from DCSE desktop and/or HomeRun.

Confirmed bugs
- Editing some programs or running some programs with low memory causes pieces of programs to get copied into themselves.

Repaired issues
- Need to automatically put programs with no valid folder in the root -> Solved by performing a FldSave when a folder is deleted.
- Quite a few Celtic 2 CSE functions are wacky -> Celtic 2 CSE functions all fixed
- Alpha-scrolling in BASIC editor implemented
- Need to redraw starting colon before _DispEOW with alpha-scroll.

I found a very reliable way to crash my calculator when it is running the newest beta (Beta 3):

From the desktop, use alpha to right click on any menu item. Press alpha a second time when the right click menu appears. Now choose either delete or archive (I'm sure others cause the crash too, but these are the ones that I have tested) from the right click menu and hit 2nd.

You will get an error like:
Error # 503
prgm
File Not Found

Hit the On key and the calculator will turn off
Hit the On key again and the calculator will turn on a wipe your ram.

Great find! I have replicated this bug, and I have fixed it.

Is there a reason why TI-Basic programs run significantly slower when launched through homerun/doorscse as opposed to launching them from the programs menu with homerun off?

That has not been something I noticed, mine ran a bit faster than it had previously.

Hjax is actually right; the OS always runs programs at 15MHz, which I did not expect. I will take out my code that switches programs without DCSE headers into 6MHz mode.

hmm thats strange, if i run a significantly complex basic program, like scarth 2.0 for example, of some of the simple games that my friends wrote it is pretty must unplayable due to the performance hit that I am seeing

Edit:
Thanks Kerm!

Yes, I was able to reproduce this issue on my own calculator, and it is now repaired in the source.

Are we to assume beta 4 is going to be launched soon? Gosh this is exciting!(;

Not until I can replicate and repair the issues to which t.roos alluded. I need more specifics on that, and based on how things go, I'll have to decide whether the next version will be Beta 4 or Release Candidate 1. It will probably be Beta 4.

I am not sure if this is expected behavior or not (I do not believe it to be)
But hitting On + Clear from the desktop turns off the calculator but doesn't clear the ram (I do not think it should turn the calculator off, unless I am missing something)

That is expected behavior. [ON] in general is the key to turn off the calculator from the Doors CSE desktop; it doesn't matter what other keys you press with it.

Ok last thing and I will stop bugging you

These are just some small usability suggestions that I have
1: When you open the right click menu for an item in the desktop, could the item that we are right clicking on stay selected so there is some visual cue that we right clicked on the correct application?
2: Could unnecessary menu items be hidden? So if i select an ASM program I don't really need the edit button, or if i select nothing in an empty folder I don't really need rename, cut, or copy
3: Would a new program button to quickly start writing something in basic be a bad idea? Just add it to the right click menu

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.

Also I think that when you run a program, the 2nd or enter key is stuck.

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!

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

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.