Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
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.
FloppusMaximus wrote:
The one thing I've been wishing for years that 83+ shells had done in the first place: start programs at userMem+2, not userMem-2!

Do Venus-style relocation (forget about trying to keep compatibility with crazy programs like Ion), and make it safe for programs to use GetKey, and APD, and look themselves up in the VAT, and resize themselves, and use any other system routines they like. Smile
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.

Quote:
Relatedly, it would also be nice for the shell to provide an easy way for programs to register their own putaway handlers (MirageOS does this, sort of, but it should be properly integrated with the OS's putaway system so that 2nd+Off and silent link DTRT.)
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?

Quote:
Also, provide a way for programs to declare explicitly, at run-time, whether they should be written back to archive upon exiting.
That seems like a reasonable feature for the new header.

LuxenD wrote:
whats the difference with running programs at userMem+2 instead of userMem-2?
It means the entire contents of the program are in one place, instead of 4 bytes high in memory and the rest at $9D95.

Quote:
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.
More specifically, it applies to programs that perform SMC (have self-modifying code).
KermM wrote:

LuxenD wrote:

whats the difference with running programs at userMem+2 instead of userMem-2?
It means the entire contents of the program are in one place, instead of 4 bytes high in memory and the rest at $9D95.

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?
KermMartian wrote:
FloppusMaximus wrote:
The one thing I've been wishing for years that 83+ shells had done in the first place: start programs at userMem+2, not userMem-2!

Do Venus-style relocation (forget about trying to keep compatibility with crazy programs like Ion), and make it safe for programs to use GetKey, and APD, and look themselves up in the VAT, and resize themselves, and use any other system routines they like. Smile
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.

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

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

Quote:

Quote:
Relatedly, it would also be nice for the shell to provide an easy way for programs to register their own putaway handlers (MirageOS does this, sort of, but it should be properly integrated with the OS's putaway system so that 2nd+Off and silent link DTRT.)
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?

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.

Quote:

Quote:
Also, provide a way for programs to declare explicitly, at run-time, whether they should be written back to archive upon exiting.
That seems like a reasonable feature for the new header.

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

LuxenD wrote:

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?

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.)
LuxenD wrote:
KermM wrote:

LuxenD wrote:

whats the difference with running programs at userMem+2 instead of userMem-2?
It means the entire contents of the program are in one place, instead of 4 bytes high in memory and the rest at $9D95.

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?


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.
FloppusMaximus wrote:
KermMartian wrote:
FloppusMaximus wrote:
The one thing I've been wishing for years that 83+ shells had done in the first place: start programs at userMem+2, not userMem-2!

Do Venus-style relocation (forget about trying to keep compatibility with crazy programs like Ion), and make it safe for programs to use GetKey, and APD, and look themselves up in the VAT, and resize themselves, and use any other system routines they like. Smile
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.

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.

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?
elfprince13 wrote:

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.

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

Quote:

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

You're right, but that requires unlocking Flash.
FloppusMaximus wrote:
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.)

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

Quote:
You're right, but that requires unlocking Flash.

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

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.)
Quote:
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.

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.
DJ_O wrote:
Instant Goto will definitively be a must.


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.
comicIDIOT wrote:
DJ_O wrote:
Instant Goto will definitively be a must.


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.
DJ_O wrote:
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. Smile
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?
DJ_O wrote:
I guess in such case that maybe a custom program editor...


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?
DJ_O wrote:
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?
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.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 4 of 18
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement