whats the difference with running programs at userMem+2 instead of userMem-2?

but i agree with the last one, cause some arcade games arent meant for writeback. they expect that the program remain unchanged, and it may speed up the exit time from previous DCS7.

The only problem with this is if our headers are quite large. Although there's nothing stopping the header format from putting the header at the end of the program, with some pointer at the beginning.

In my experience, shells are more likely to disable APD, turning off via the OS interrupt, and silent linking than try to handle those events. Do you see a particular advantage of letting the OS retain semi-control?

That seems like a reasonable feature for the new header.

It means the entire contents of the program are in one place, instead of 4 bytes high in memory and the rest at $9D95.

More specifically, it applies to programs that perform SMC (have self-modifying code).

why would you want to split the program into two? wouldnt that make it harder to writeback, if need be? or is it to help shells run such a program?

I guess you're saying this because of concerns about the C000h limit? You're right, it would make sense for stuff like icons and description strings to be placed at or near the end of the program if that is a concern.

On the other hand, maybe it would make sense, given the even-more-cramped-than-before code space, for shells to automatically swap RAM page 0 with one of the other executable pages, for programs that need it. That kind of conflicts with my point about making putaway simpler and keeping full BCALL compatibility, though.

(Somebody's probably going to bring up the idea of unlocking Flash to disable the RAM protection; I don't think it's a good idea to make that a core requirement for a shell, although I confess it sounds more attractive than having programs try to do it themselves.)


Yes, I see many advantages. Using GetKey, and keeping consistency with the user interface of the OS and TI's apps, is good UI design. 2nd+Off turning off the calc is expected behavior. APD saves battery life. Silent link allows for screenshots and remote control.

Moreover, for some programs it's useful or even necessary to be able to call _JForceCmdNoChar, _Mon, _NewContext, _ExecuteApp, the BASIC parser, dialog/small edit routines, etc. etc. On the 83+, programs that do those things have to be FlashApps (or else risk memory leaks or worse), which is a silly limitation.

Obviously some programs will still want to run in a bubble where they keep complete control (disabling APD, not using GetKey or taking special steps to block 2nd+Off and silent link, etc.) That's fine, but the shell shouldn't be designed in a way that makes it impossible to write programs that *do* integrate with the OS.


Maybe, but note that I said "at run-time". Even among those programs that sometimes want data written back, it's not something that needs to happen every time the program is run; rather, I think in many cases it's a fairly rare occurrence (e.g., when you get a new high score.) An IY flag would be an easy way to do this: clear the flag initially, and the program must set the flag itself if it wants write-back.

(On a side note, it might make sense - in terms of making life easier for shell authors - to say that if a program exits non-locally (i.e., via PutAway), that the writeback flag will not necessarily be honored.)


The way Ion works - because it was designed to be partially compatible with Asm( - is that it leaves the first four bytes (the length word and the asmCmp token) in place, moving the rest of the program to 9D95h. When the program exits, it has to be moved back to its original position in RAM, which is what causes all the problems I'm complaining about.

The way Venus and SNG work is to move the *entire* program to the start of memory, so that the memory state remains fully consistent and (at least on the 82/83) no cleanup is necessary. On the 84+C, some cleanup would still be required if the original program was archived, but it should be less messy (if the program isn't modified / doesn't need writeback, just delete it; otherwise, swap VAT pointers, DelVarArc the old one, and Arc_Unarc the new one.)

You either mis-phrased your question or you misinterpreted the answer. Starting at userMem+2 lets the program run without it being split up into two parts.

This might make the polyglot header I suggested in the other thread a bit easier to parse. If the BASIC data between the Open and Exec lib calls consists only of pointers, there's even less need to figure out how to represent variable length data.

Also, don't I remember reading that we know how to manipulate the $C000 limit, or am I mixing up my definitions here?

This sounds interesting, which thread are you talking about? (Sorry, there have been a few of them and I haven't really been keeping up.)


You're right, but that requires unlocking Flash.

read this post and the couple posts after it with discussion between myself and calc84maniac.


And we're reliant on OS exploits to do that? It would be a handy feature for a shell to have.

It would be, and it'd be better for that code to be in the shell rather than having lots of buggy copies scattered around. On the other hand, I'm leery of making the, er, "arms race" even worse than it already is.

While I'm thinking about this stuff, another feature that might be useful for shells would be to automatically delete the VAT entries of all archived programs to free up space, and restore them after the program exits. The shell could provide library routines for reading the archive directly (replacements for ChkFindSym, FindAlphaUp/Dn, etc., would be nice, as well as a simple way to iterate over all archived files.)

That was essentially my thought process as well. Thought that it was at least worth mentioning in brainstorming, even if we ultimately decide against it.

Instant Goto will definitively be a must.

Also if possible, could it be possible to modify the way the program menu works, so that when we scroll with Alpha or Enter, instead of scrolling line by line it scrolls instantly? That would solve most of the scrolling issues.

Another thing that would be nice is if the DCS8 program editing mode was triggered everytime instead of just when an error occurs.

Isn't that something that has to be supported by the OS? Unless the shell would be capable of searching the program for GOTOs upon load and closing any loops and jumping to that point. But that would require loading and parsing the program into RAM then executing. I think searching for GOTOs would be faster in the end.

He means the Goto option when an error occurs. By default, it scrolls down from the top of the program to the point of the error, which can already take a long time on the 84+SE calcs. Just imagine how slow it will be on the 84+CSE given how slow the OS scrolls.

When I hit Goto after an error occurs (ERR:BREAK, for instance), it takes 11 seconds to scroll through a 1.5 KB large program on the TI-84 Plus Silver Edition. Scrolling through an Illusiat 13 boss event program will take close to 2 minutes.

This is why some TI-BASIC programmers abused the ":" token to put every line of code in a single one, since it took less time to scroll through.

And it's why Doors CS 7 includes a feature called Instant Goto, which overrides the scrolling behavior by doing all of the edit buffer scrolling off-screen. It can only work when Doors CS is responsible for running a program, though, hence one of the reasons why HomeRun was handy. I can see this being a very popular feature in DCS8.

Yeah I know about that feature. I was saying it would be nice if it was implemented for when DCS isn't responsible of running programs as well, but of course it depends if it is possible at all.

I agree, but I don't think it's very possible. Also, I was explaining Instant Goto to ComicIDIOT, who seemed unfamiliar with the feature.

Aw too bad. I guess in such case that maybe a custom program editor (preferably one that works exactly like the current one, except with some improvements) that can be installed as standalone app might be in order then?

if we do that, any chance we can also add some kind of clipboard? i get tired of typing some code into one program, and then simply using a program RCL when i need it. saves about 2 seconds of time. or at least make said app expandable, like how DCS is?

While typing out and viewing tokenized text is doable from ASM programs with the bcalls that we know (at least on the older calculators), one of the sticky wickets I'm aware of is getting into the menus. I'm not sure how an independent editor would handle the many menus and pasting of tokens into such an editor. Then again, the OS doesn't offer many options to hook into text entry, so I don't think we'll be able to modify the behavior of the existing BASIC editor to do what we want either.