Hello All,

Ive started a small initiative to look into the possibility of creating a set of standards for programming the upcoming TI-84+CSE calculator. Its called the "TI-84 Plus C Silver Edition Consortium" or 84CC for short.

I was thinking that it could be of benefit to the community to discuss possible guidelines or standards for programming in ASM (which would also influence BASIC libs and shells and such).

Some ideas to throw around:

Standard ASM header for shells (with room for shell specific features if required)
Standard and community accepted safeRAM areas (if possible)
Standard configurations for graphics (sets of modes (possibly even community defined) that routines should target ie; 4-bit, 8-bit user pal, half-resolution etc) *hypothetical and dependent on more information
Standards for hooks to allow easy chaining etc

Just to get the ball rolling.

Either way i was just wondering what anyone thinks? Is this an idea worth discussing at the very least?
Well, Consortium often means a separate ruling or governing group, and I think we can all agree that the community is already as fragmented for the number of active users as it can stand right now. However, if you're suggesting that we discuss standardizations in here to be documented on WikiTI and other places (ticalc.org document published by major 84+CSE coders? Doors CS wiki?), then I'm all for that. As you know, I've already been tossing around a lot of ideas for a standardized set of shell headers, as I'm hoping to make Doors CS 8 the best TI-84+CSE shell that anyone could possibly want. You know that we've also been discussing TI-84+CSE graphics routines (and non-graphics, but of course we all focus on the graphics overhaul first) that coders might want, so I think a standardized set of routines would be great. Can you explain more about the hook idea? tl;dr: I certainly support the idea of a document or agreement of standards. I think a group creating standards is extraneous.
yeah perhaps the name sounds too political Smile.

Basically i just wanted to get some community input on standards for the things you have covered. In my opinion i think for ASM coders it would be *very* beneficial to define what is accepted as far as safeRAM areas go and the like.

As far as the details go i think we will have to wait for more information on the calc itself. Was just seeing if the interest was there - would hate for programs to be breaking each other upon release.

I do think that WikiTI is probably the best place for such information to live once proposed if at all).
I totally agree; it would be especially useful for porting attempts as well as optimization.
tr1p1ea wrote:
yeah perhaps the name sounds too political Smile.

Basically i just wanted to get some community input on standards for the things you have covered. In my opinion i think for ASM coders it would be *very* beneficial to define what is accepted as far as safeRAM areas go and the like.
I agree. As I said in the Doors CS 8 and ASM Brainstorming topics, we are starting with essentially a blank slate, and we have an opportunity to be free of the shackles of backwards-compatibility. Let's make the most of it.

Quote:
As far as the details go i think we will have to wait for more information on the calc itself. Was just seeing if the interest was there - would hate for programs to be breaking each other upon release.

I do think that WikiTI is probably the best place for such information to live once proposed if at all).
Probably. And of course that information can be linked lots of places such as our general TI-84 Plus C Silver Edition reference page. I think the interest is definitely there.
Quote:
Was just seeing if the interest was there - would hate for programs to be breaking each other upon release.

As a user of Omnicalc & Symbolic who almost never uses xlib-based games for this reason, I whole heartedly agree.
WikiTI is definitely a good place to put accepted standards. Anyway, given the range of possible color depth, palette, transparency, and sizes, it might prove impossible for shells to provide for all the possible needs of various softwares in an efficient manner. I think our best bet is to provide basic routines that aren't as fast but more versatile, and leave the coding of super-fast routines to game coders, who have many different needs.
DrDnar wrote:
I think our best bet is to provide basic routines that aren't as fast but more versatile, and leave the coding of super-fast routines to game coders, who have many different needs.
I agree. Take a look at this topic for a few of the ideas that I was tossing around. I think it's going to be interesting to see how everyone shifts their thinking to see the screen as something you need to deal intimately with, rather than something connected to the graph buffer that you never really have to worry about. Also, based on those preliminary frames-per-second numbers that will appear somewhere soon, I think we'll see a lot of games that put action in the center and scores, hearts, bullets, level numbers, around the edges in a rarely-updated border.
Kerm you keep teasing with information!
tr1p1ea wrote:
Kerm you keep teasing with information!
I'll be able to do less teasing and more telling once a special delivery arrives today. Smile
Just threw some ideas down for a simple header format, has anyone considered what would be necessary for a standard header?


Code:
#include "ti84pc.inc"                   ; general TI-84PCSE include file
#include "shell.inc"                    ; shell specific include file
        .org ORIGIN                     ; origin address
        .db 2_BYTE_ASMPRGM_TOKEN        ; asmprgm token
        ret                             ; tios handler
        .db START-ORIGIN                ; offset to code start from origin (necessary?)
        .db 'C'                         ; identifier byte
        .db NN                          ; program type (prgm, lib, data, image etc)
        .db NN                          ; colour mode (nibble), screen mode (nibble)
        .dw ICON_POINTER                ; pointer to icon (in a standard 16-colour palette?)
        .db "Program Desription",0      ; null-terminated description string
START:

colour mode: {0,1,2...15} - {16-bit, 8-bit, 4-bit etc}
screen mode: {0,1,2...15} - {320x240, 256x240, 160x120 etc}
program types to have extra information after header, for example 'image' type
could have information on what compression scheme/image format utilised etc
I think we need something more modular than what we're used to working with. For example, from this thread:

Quote:
I think that since everything will have to be ported from scratch and all of the legacy requirements will be thrown out, we can totally support this by making the dependency requirements part of the program header: a program that doesn't have a particular dependency simply won't run by DCS [or any shell], without the program having to do this check itself.


Someone (calc84?) also suggested putting a .bss region-equivalent in the standard header. I think we need a header that consists of (variable) N regions, each region following a set format like type, length, data. We could have description regions, icon region, required library regions, required capability regions, etc.
Ahh now we're talking, i believe that idea could prove very valuable going forward.

I wonder how we can organise the process as to allow for wide-spread community input into such ideas (which should aid acceptance)?
tr1p1ea wrote:
Ahh now we're talking, i believe that idea could prove very valuable going forward.

I wonder how we can organise the process as to allow for wide-spread community input into such ideas (which should aid acceptance)?
Well, even if we use a byte for the region type, I think we're not likely to find 256 different things we want to use for header regions. I vote that we document the header format on WikiTI, as we have discussed, but we have some sort of voting or veto process. Perhaps we could pick a panel of five or ten well-known community ASM programmers, and if a majority of them vote to accept or veto a given header region/format, it becomes standard? With input from the rest of the community, of course.
Can we employ ticalc.org to handle the voting process (with a poll) i wonder?
tr1p1ea wrote:
Can we employ ticalc.org to handle the voting process (with a poll) i wonder?
I suspect that's a little more technical of a question than they generally care to solve with a poll. I'm more than willing to do polls here at Cemetech, if no one has objections to that. Smile (/me runs to creates aliases like 84color.com/vote Cool )
With FileSyst, I have a section of the header that is variable sized and is meant to hold extra information. It holds data in "fields" that have a 1-byte ID, followed by a 2-byte size, followed by the data. There is a call in FileSyst so that you can search for a field by number, the z flag is returned if it exists, along with appropriate pointers. We could use something similar and define field 0 as a name, field 1 as comments, field 2 as a file type, field 3 as a 16x16 icon, et cetera. To omit a field, do just that-- omit it. If field 3 doesn;t exist, the shell can use a default icon.

As well, we should make sure that when assembly programs have such a header, we don't copy the header or any associated data like that to UserMem, just the actual code. We could then define a field as the "code" section and just load that when the user tries to run the program.

I think if we do this, we should also have it so that a field holds the names of needed sub-programs and a field for indirection. This way instead of having the program data itself, it can point to the actual program to run. This would be useful if you want to make a header for a BASIC program so it appears in a shell list. We could define a token so that BASIC programs can place it as the first byte and have it be ignored by the shell. That way it only shows up by the header program instead of appearing twice in a list of programs.
Xeda112358 wrote:
With FileSyst, I have a section of the header that is variable sized and is meant to hold extra information. It holds data in "fields" that have a 1-byte ID, followed by a 2-byte size, followed by the data. There is a call in FileSyst so that you can search for a field by number, the z flag is returned if it exists, along with appropriate pointers. We could use something similar and define field 0 as a name, field 1 as comments, field 2 as a file type, field 3 as a 16x16 icon, et cetera. To omit a field, do just that-- omit it. If field 3 doesn;t exist, the shell can use a default icon.
Isn't that pretty much what I suggested a few posts ago? If you're agreeing with that and I'm misreading, I'm glad you agree. Smile

Quote:
As well, we should make sure that when assembly programs have such a header, we don't copy the header or any associated data like that to UserMem, just the actual code. We could then define a field as the "code" section and just load that when the user tries to run the program.
Agreed. It's kind of silly that we've been doing that all along, come to think of it.

Quote:
I think if we do this, we should also have it so that a field holds the names of needed sub-programs and a field for indirection. This way instead of having the program data itself, it can point to the actual program to run. This would be useful if you want to make a header for a BASIC program so it appears in a shell list.
Doors CS has always supported having subprograms unarchived with a main program; I think this is a good way to expand on that idea.

Quote:
We could define a token so that BASIC programs can place it as the first byte and have it be ignored by the shell. That way it only shows up by the header program instead of appearing twice in a list of programs.
Also supported by DCS - Ans was my token of choice. Smile
I have not really done anthing extensive in TI-83/84 ASM programming before, but I have done quite a bit of assembly programming for other CPUs.

A thought I have about safe-RAM is maybe a system of distribution. A program request the shell that it needs a chunk of RAM of a given size, and the shell then allocates (if possible) an appropriate chunk of a RAM pool. Then it returns the address of the allocated chunk to the program. When the program is closed, the shell then frees up that chunk of allocated RAM.

In the most simplest form, the shell only needs to keep track of the memory pool and a table of how it's allocated. The problem is then of course fragmentation, and in situations a program may eventually quit without it's allocated memory being unallocated (say, the program crashes for example). There must be systems in place that looks for those things, and performs garbage collecting or defragmentation of the pool whenever nessecary.
olav_nordmann wrote:
In the most simplest form, the shell only needs to keep track of the memory pool and a table of how it's allocated. The problem is then of course fragmentation, and in situations a program may eventually quit without it's allocated memory being unallocated (say, the program crashes for example). There must be systems in place that looks for those things, and performs garbage collecting or defragmentation of the pool whenever nessecary.
One thing that CompyNerd has been suggesting repeatedly is that shells offer a common memory management system, like malloc(), which it sounds like is essentially what you're describing. I think that could be a very good way to do things, rather than assume you can always put your data in the same place. Among other things, this opens up the possibility that shells could add task-switching without requiring much or any changes to programs, for example.

Edit: Tr1p1ea, since you seem to be well-organized with this, in case there's any discussion on other sites on this topic that we're missing, would you mind making sure the participants there get a chance to read through this thread? Smile
  
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 1 of 4
» All times are UTC - 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