The version 8 manual states "Doors CSE displays programs and folders in alphabetically-sorted order, up to sixteen at a time." But the folders aren't sorted, only the programs. I would like to suggest/request that either DCSE sorts the folders or there is an "Arrange Icons" option to allow users some element of choice in the arrangement.

The folders are still sorted to the front of the program list though, correct? The folders are sorted by the order in which they were created, not by name, due to the way folders are encoded in the filesystem. I will take it under advisement; unfortunately, due to the way folders are stored, this might be a bit challenging.

That's OK: I didn't know it might be difficult. It was just an idea, thanks for considering it.

I triggered the Error: ? bug once again.
Before the bug, I transferred a few (5) files to my calculator archived. I transferred the 3 programs to one folder (The other two were AppVars). I did not run any of these programs. I exited the folder and did the following:
From the DCSE8 homescreen, I ran a locked, archived, full Basic program. In the program, it requests an Input. Once I typed anything at the Input, I immediately noticed that "prgmBLOCKDUD" replaced what was supposed to be there: "RADICAND:". I pressed [Clear] once and that cleared the Input. I typed in the number I wanted and pressed [Enter]. Upon this, the calculator threw an Error: Undefined. I selected 2: Goto and a line from my history was displayed. I tried to clear this but the Error: ? screen came up. From here, I met the same symptoms.
This time I did not use the Enhanced Basic Editor.

Out of curiosity, are you able to replicate the issue by repeating those steps? Thank you once more for this detailed report!

Sorry, I am not able to replicate it.

Well, thanks for trying anyway. I'll see what I can make of this.

Kind of not a bug report or a feature request, but related to DCS8 and I couldn't find any more related topic.
Would this work: Instead of sending a program and an appvar, would it be possible to detect if the appvar exists, if not make a new one and paste the contents then archive it, if it does go to the start of the program?

You can have your program create the appvar and dump the contents in to it, but that'll increase the size of the program by that much more. Won't do any good unless there were some kind of compression/decompression system in place.

Yes, but it would be useful if your calculator crashes, the appvar gets corrupted, or for simplified sharing with other calcs. I actually feel like trying to make this a possibility. I'm gonna try this and say something if I get somewhere.
I think it would be possible to make a program that compresses/decompresses strings. The individual programs would have set a compressed string to string1 (for example) and then the user would run the decompression program, which would make the appvar.

I think ultimately, you're better off using a group file on the calculator. Just don't spread group files for others to use.

what is wrong with distributing group files? its an instant backup location for programs killed by a ram clear, as I see it, and a place to contain a large project or game when you want les clutter in the program list.



PuCrunch? it was ported to the monochrome calculator, and even implemented in the CrunchyOS shell. not sure how well it works, though.

Even so, Ti-Basic programs are large enough with what they have, I don't think many users would need this system. this is more of a standalone assembly program someone would write and release, as opposed to including it in a shell like DCSE.

puCrunch does work fine on the CSE, ive used it in several image tests - since its generic z80 code. Would be a good option for some people.

Because TI-Connect doesn't play well with it. If you're going to pass around things on the internet, a group file is not the way to do so for others to try to use.

How big are the routines for it? I'd certainly be willing to provide it as an option in the Doors CSE ASM libraries.

Ill check, i think it could be a few hundred bytes. I dont have an z80-side compressor however, just a decompressor.

Actually from memory the routine was quite large, im pretty sure nearly 600bytes!

PuCrunch decompression lends itself to decompressor size vs. decompression speed tradeoffs. The TI-68k series uses two routines, a fast/larger one (~550 bytes, 60-80+ KB/s) and a very small but much slower one (~220 bytes, <20 KB/s).
Both were ultimately made by Samuel Stearley, in pure ASM, after multiple rounds of optimization by several persons: chronologically, Thomas Nussbaumer (original porter, C code), Greg Dietsche, myself (mainly still on C code), and possibly others.

Bug report: the xLIBC map drawing commands do not work when the map string is archived. In such case, real(3 does nothing at all.

With a smaller string (my original string was 43 KB large so it won't fit in RAM) I tried putting it in RAM and it works fine:



With it in archive this is what happens:

This is a feature request, as I have run into this problem multiple times and it would make programming much more convenient: could dcse create new strings in order to be used in programs? Sometimes 10 isn't enough

You can actually use up to 255 different strings with some sort of old 83+ program, but those strings cannot be sent via TI-Connect unless grouped in 8xg files.