Yay xLIBC support!

Im hoping to complete the last of the critical functions this weekend.

Still needs implementation
- Fast scrolling in BASIC editor (incomplete)

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
- Quite a few Celtic 2 CSE functions are wacky
- Need to automatically put programs with no valid folder in the root
- Editing some programs or running some programs with low memory causes pieces of programs to get copied into themselves.

Implemented/Fixed
- New DCS ASM header field that sets half-res mode
- Fix LCD back to full-res mode after BASIC and ASM programs
- Set black text at beginning
- Moved InfoPop buffer to RAM page 6 so that graphscreen dpes not need to be invalidated after InfoPop
- Solved 2: Goto sometimes goes to the wrong place. I blame temporary programs; I have verified that (nextParseByte) and (basic_start) are at weird places when this happens.

Did I miss anything? By the way, tr1p1ea, I have some other functions that might help you with those last features, including a much better ldirROMRAM.

Edit: Further investigation on the bad 2:Goto issue. I discovered while working on Trig Finder v3.0 that those temporary variables I saw tifreak8x's BTetris game creating are the bodies of conditionals, stored with a one-byte size prefix followed by the body of the conditional. If X=1/0 would have the "X=1/0" stored separately prefaced by an $05. (nextParseByte) is offset from (basic_parse) relative to that chunk, not the original program. Since the OS can still handle 2:Goto in this case, the requisite state must be there somewhere, but I know not where.

Edit #2: I finally found the OS code that handles updating (errOffset) on a 2:Goto, and I managed to write a smaller and faster version of my own, which more importantly, is functional! So now Goto should work properly, including when there's an error in the RAM copy of an Archived program. I urge Zeldaking and tifreak8x and other BASIC coders to make sure I didn't make an error.

I would love to Beta-Test.
I still remember when Doors CS first came out on ticalc.org.

I imagine he does not want to give me access to the beta?

Oh, I sure hope you fixed it! That bug was one of the most frustrating ones in DCS7. To identify it exactly, it was where if you break a TI-Basic program while at a "pause", like Pause, Input, or Prompt, it would work, but if you broke it at something like a For loop, it would nearly never work, only dumping you at the top of the program (and I've had it corrupt the program at that point too, if it is a large one).

The program-corruption bug is a separate issue that I have been able to replicate even with just the OS editor and no Doors CS/CSE hooks. However, I'm still going to try to track that issue down. I need to find the original bug reports in the Doors CS 7 Bug Reports thread and see if I can replicate the issue with Doors CSE 8. If one of you would mind scanning the topic and finding the relevant post(s), that would be grand. Edit: Found it myself: starts here.

Great, I look forward to you both testing Doors CSE 8.0 Beta 3, which I hope to release tonight or tomorrow morning to the beta-testers. Don't worry, I haven't forgotten anyone, it's just been hectic trying to track down bugs.

Also, here's an update incomplete bug/feature list:

Still needs implementation
- Fast scrolling in BASIC editor (partially written, incomplete)

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
- Quite a few Celtic 2 CSE functions are wacky
- 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.

If you guys could help replicate the unconfirmed bugs and/or get more specific details on them, that would be great.

In the BASIC editor, can alpha+up/down scroll 10 lines?

Also, DCS7 bug: it scrolls 7 not 8 lines in the fullscreen editor

Feature requests:

edit archived programs from OUTSIDE DCS
full screen editor outside DCS

Annoyances (in DCS7.2)
Make Asm(prgmARCHIVED also work
run archived/asm inside basic progs
archived programs show "Done" even if last line of program set Ans
pressing 2nd+Quit in an input/menu does nothing whatsoever, need to press ON

Parrotgeek, thanks for those bug reports. I'll see what I can do in terms of limiting whether those are also in Doors CSE 8, and if I ever get the time and inclination, I may go back and backport some of my fixes to Doors CS 7.2.

This morning I fixed the Celtic 2 CSE sprite routine to work properly in Doors CSE. It gets 5 sprites/second at 6MHz, and 12.5 sprites a second at 15MHz. Question: how do you guys feel about TI-BASIC programs tagged with Doors CSE icons always starting in 15MHz mode, but the xLIBC functions to step down to 6MHz or up to 15MHz still being available? Does that sound reasonable?

Up next: fixing the rest of Celtic 2 CSE, then finishing the alpha-arrows hook for the BASIC editor.

Edit: By not loading a massive string into Str9 every time I display a sprite, and instead using sub(), I cut the sprite time down to 1/20th of a second per sprite. The OS overhead is now far greater than how much det(9...) costs.

I fully endorse this idea.

-Daniel Thorneycroft
-Silly BASIC programmer

</infomercial>

I think that's a good idea.

Could I beta test it?

Do you have a TI-84 Plus C Silver Edition? Do you agree not to distribute the beta to any of your peers, no matter how much they want it? It's very important to me that only stable, mostly bug-free release candidate versions make it into the wild.

Yes and yes.

If i may.

I would also like to beta test this version of doors cs on my ti 84 c se.

great work !

When I try Spaze Invaders CSE from the DCSE menu, my LCD becomes LSD and the only way to fix the calc is to press CLEAR (to quit the game) then wait a few seconds, then turn OFF the calc. Afterward, I land back in the DCSE menu, although it sometimes exits.

If I try the game from the home screen using Homerun features, it works fine.

I haven't had any issues between Spaze / DCSE, however Kerm if you want a copy of the source let me know and I'd be more than happy to send it over. I'll do some more testing today and see if I come across this problem DJ_O has mentioned here.

So, how goes the Beta?\

Slowly. The bugs (and features) I'm working on are rather challenging indeed.

I'll test the Spaze version in James's topic against my latest version, and I'll send you Beta 3 tonight or tomorrow, JamesV; we'll see if it works.

K. Sounds like its going to be awesome.

Thanks! Because I want to get ALPHA-scrolling in the BASIC editor fixed/finished before I ship Beta 3 to you guys, I will delay releasing Beta 3 until tomorrow morning or mid-day. In the meantime, though, I completely cleaned up the Celtic 2 CSE libraries, and the output for my modified version of C2TEST by the illustrious tifreakx8 now matches the reference implementation. I also created a new C2CSE sprite routine, det(10,....), that is very fast. How fast? Well, at 15MHz, I can use BASIC tricks to get det(9,....) up to 19 sprites per second ish, and with det(10,....), 22 Mario sprites per second, and switching up which Mario, too.