One obnoxious thing about OpenLib is that on the 84+, IIRC, it requires the application name to be 8 characters, and entirely uppercase letters and digits. I don't know if that's been fixed on the 84+C.
FloppusMaximus wrote:
One obnoxious thing about OpenLib is that on the 84+, IIRC, it requires the application name to be 8 characters, and entirely uppercase letters and digits. I don't know if that's been fixed on the 84+C.


If it's not, before the official release is a good time for Kerm to report it and get it fixed to encourage use (and maybe some of the other known bugs with MP that BrandonW posted about, with fixes, on 4/14/10).
Multiple people have suggested writing the unlock flash code to a privileged sector so we can easily unlock flash whenever we want. The primary reason programs might want to unlock flash is not to write directly to flash, but rather to unlock all of RAM for execution. I propose the following:

The unlock flash code should be written to 1FF:7FF0. The code should read

Code:
   nop
   nop
   im 1
   di
   out (14h), a
   ret
(00 00 ED56 F3 D314 C9)

This sequence is minimal and 8 bytes long, a nice round number. It allows you to load either 1 or 0 before calling, allowing it both to lock and unlock flash. The use of the boot page makes it unlikely TI will ever go out of its way to undo the change. The end of the page makes it unlikely future boot code versions will use the space. Alternatively, 1FD:4000 would also be a good place to stash to the code, since TI is unlikely to change the secondary boot sector. We want to support relocking flash easily because it's probably good practice to relock flash when you're done making changes.

Unlocking flash is easy, then, for both RAM programs and applications:

Code:
   (di) ; needed if you haven't already done so
   in a, (6) / in a, (7) ; RAM program / flash app
   push af
   in a, (0Eh) / in a, (0Fh)
   push af
   ld a, 7Fh
   out (6), a / out (7), a
   out (0Eh), a / out (0Fh), a
   (xor a) ; for locking flash
   call 7FF0h / call 0BFF0h
   pop af
   out (0Eh), a / out (0Fh), a
   pop af
   out (6), a / out (7), a
   ret
RAM program: DB06 F5 DB0E F5 3E7F D306 D30E (AF) CDF07F F1 D30E F1 D306 C9
App: DB07 F5 DB0F F5 3E7F D307 D30F (AF) CDF0BF F1 D30F F1 D307 C9

Note that resetting the high bits of A is necessary for neither the port 0Eh/0Fh nor the port 14h write.
Elfprince13: Since I have the opportunity to report some bugs, would you mind adding that and any other related issues you can think of to my TI-84+CSE bugs thread?

DrDnar: That seems like a great idea to me, especially the option to use the extra RAM pages for buffering graphics. I think we'll need that for the new screen...
*bump* So, we seem to have nearly forgotten this thread. I've been toying at a few random projects, and they all require that I find myself at least an appBackupScreen-sized chunk of safeRAM. Has anyone made strides into figuring out what all the RAM from $8000 to UserMem is being used for, like calc84 or Floppus or DrDnar or BrandonW?
The include file on WikiTI has the most recent list of memory locations in it. There's no word on the address of _DelRes, so statVars isn't an option yet. But there's a tentative address on _maybe_FillBasePageTable, so you should be able to use at least 1024 bytes starting at 8000h. Also, cmdShadow and textShadow are each 260 bytes now. And there appears to be a monochrome screen buffer starting at 0A03Ah that's more than 1400 bytes in size.
Thanks, DrDnar, that helps a lot.

DrDnar wrote:
And there appears to be a monochrome screen buffer starting at 0A03Ah that's more than 1400 bytes in size.
That sounds fascinating; I am definitely going to try using that for one or two (or all, more likely) of my projects. And another good reminder that I should always be sure to check WikiTI.
I've made some limited progress on finding RAM areas - I should update the include file DrDnar mentioned.

8798h, I think, is a 768-byte scratch area - it's where saveSScreen used to be and may still have the same name, though obviously not the same purpose. The former plotSScreen might be lurking somewhere in the 9800s.

8B8Ch is statVars - I assume it's the same size and layout as on the 83+? _DelRes is 4A0Bh.

tempSwapArea might be 82B3h.

I assume appData (8000h) can still be used as scratch memory, and ramCode (8100h) is as volatile as ever.

A03Ah is a one-byte variable that (I think) stores the current color index for drawing on the graph. DrDnar, maybe what you're thinking of is on a different RAM page?

As you can all imagine, it's harder to identify RAM areas that the OS generally doesn't use, than to find the ones it does. Smile
Hehe, of course. That's seems quite odd that they would keep the old 768-byte areas while adding new larger areas; that seems like cutting off TI-BASIC programmers' nose to spite App writers' faces (or something along those poor-analogized lines). Smile
Based on Benjamin's most recent update to WikiTI, it looks like most of RAM pages 2 and 3 can be used as scrap. I suggest using ports 27 and 28 to perform partial RAM remapping. The entirety of 6 and 7 (or is it 4 and 5?) can also be used as scrap, and 4 and 5 if you don't mind clobbering the graph buffer. You really need to start thinking about RAM as pagable. You don't need to maintain TI-83+ support anymore.
Any updates on the program header format debate? I'm still rooting for my suggestion (or hoping for thoughts on it).
Here's an update on flash unlocking: TI has gone back to using the flash chip's internal locking mechanism, which can only be undone by applying 12 V to a specific pin on the flash chip. (Get the wrong pin and you probably fry it.) So we won't be patching the boot code anytime soon. Instead, we think we can patch a new B_CALL into the OS. We can do this either by patching the OS computer-side (the boot code is easily tricked into not processing the 2048-bit key) and sending a modified OS to the calc, or patching it in-system.
DrDnar: That doesn't limit the ability to unlock Flash from user code using one of the several known methods so that (for example) an App could tack on some pages to itself, correct? That only applies to boot code rewriting, which doesn't interest me personally?

elfprince13: That's an excellent question. I'd like to get the header design as least tentatively hashed out soon so that I can start thinking about the rest of the structure and features of the TI-84+CSE edition of Doors CS.

DrDnar on RAM pages 2 and 3: From my exploration, parts of 4, 5, 6, and 7 are all used for the graph buffer slash image buffer. I guess it's not the end of the world to clobber the image buffer, as long as we find the flag to mark it for rerendering.
*bump* To return to the polyglot header idea, I'm considering this format:

Code:
OpenLib("DoorsCS8
ExecLib
Return
Asm84CPrgm
<hex data, including header and code>
I like this instead of passing the header information as a string or list to ExecLib, because it will allow a much more compact header. I'm thinking of the following header format after the Asm84CPrgm part:

Code:
.db NUMSECTIONS
.dw SECTIONSIZE ;(including type byte)
.db SECTIONTYPE
.db ...data...
.dw SECTIONSIZE ;(including type byte)
.db SECTIONTYPE
.db ...data...
ASMStart:
    ...code...

For the sections, I believe the following would be a good minimum:

Code:
Type 1: Description: Data is a zero-terminated string
Type 2: Required library: Data is a numeric code (?) identifying some library or shell.
Type 3: 16x16 indexed-color icon (using default colors): followed by 128 bytes for a 16x16 4-color palettized icon
Type 4: 16x16 indexed-color icon (using custom colors): followed by 32 bytes for a 16-color 16-bit table and 128 bytes for a 16x16 4-color palettized icon.
This seems reasonable as a starting point, but shouldn't those section types be 0->3, not 1->4?

I think the syntax for OpenLib( omits the quote, and if you have any inkling of any plans whatsoever to include support for other Basic libraries through the ExecLib command, you should mandate that it be prefixed by 0: or some other flag value in Ans, to allow for passing data in and specifying function calls.

Also, since description is the only variable-length field, you could probably omit the SECTIONSIZE in favor of SECTIONTYPE only, but mandate that the description be the last section in the header. Furthermore, you could speed up loading by including a pointer to ASMStart prior to the NUMSECTIONS entry.

In addition to the "Required library" header types, you should also include header types that specify version-compatibility for Doors CS itself.

Additionally, to support the sort of flexible environment that will be needed for a minimalist shell to be successful, DoorsCS should allow for the display and organization of the builtin variable types (including AppVars, but excluding programs) which are known to be openable by a particular program in a special "Documents" folder, which can then be organized into further subfolders according to the user's wishes. I then propose an additional type of section header, which must be a VAT Object Type, followed by some kind of filter expression to limit which variables of that type are openable (for example a magic-number).

There should also be defined some sort of standard for argument vectors to be passed into programs, including for specifying files that the shell wishes the program to try and open as a datafile.

Furthermore, I propose that nothing which is not intended to be executable directly from the home-screen be stored as a program. Libraries should be stored as Applications and/or AppVars (and possibly Groups?). Data files should be stored as AppVars or one of the other built-in variable types.

I also propose that Doors CS should treat groups as read-only folders which can have programs executed out of them from within the shell (and other data files and libraries read from them).

All of this still leaves the question of how to properly and uniquely identify libraries to be loaded (and header formats for libraries), as well as of header formats for shell-extensions and Basic programs, but it is a good start.
elfprince13 wrote:
This seems reasonable as a starting point, but shouldn't those section types be 0->3, not 1->4?
I wanted to leave out type 0 in case we decide that 0 should be a signal for end-of-header.

Quote:
I think the syntax for OpenLib( omits the quote, and if you have any inkling of any plans whatsoever to include support for other Basic libraries through the ExecLib command, you should mandate that it be prefixed by 0: or some other flag value in Ans, to allow for passing data in and specifying function calls.
Sounds reasonable enough. I just hope they've fixed the lowercase letter limitation.

Quote:
Also, since description is the only variable-length field, you could probably omit the SECTIONSIZE in favor of SECTIONTYPE only, but mandate that the description be the last section in the header. Furthermore, you could speed up loading by including a pointer to ASMStart prior to the NUMSECTIONS entry.
I seriously doubt it will be the only variable-length header field, so I want to include the size to allow any shell to parse any future header field type without knowing what the fields mean.

Quote:
In addition to the "Required library" header types, you should also include header types that specify version-compatibility for Doors CS itself.
That was intended to be folded into the required library field. Perhaps something like .dw library number, .db minimum library version?

Quote:
Additionally, to support the sort of flexible environment that will be needed for a minimalist shell to be successful, DoorsCS should allow for the display and organization of the builtin variable types (including AppVars, but excluding programs) which are known to be openable by a particular program in a special "Documents" folder, which can then be organized into further subfolders according to the user's wishes. I then propose an additional type of section header, which must be a VAT Object Type, followed by some kind of filter expression to limit which variables of that type are openable (for example a magic-number).
This sounds a lot like the AP (Associated Program) feature in Doors CS 6/7, which I'm going to be omitting for now. I'll worry about this after the core features are in place.

Quote:
There should also be defined some sort of standard for argument vectors to be passed into programs, including for specifying files that the shell wishes the program to try and open as a datafile.
See above. Smile

Quote:
Furthermore, I propose that nothing which is not intended to be executable directly from the home-screen be stored as a program. Libraries should be stored as Applications and/or AppVars (and possibly Groups?). Data files should be stored as AppVars or one of the other built-in variable types.
If libraries are external, that seems reasonable enough. That's not something I've figured out yet, though.

Quote:
I also propose that Doors CS should treat groups as read-only folders which can have programs executed out of them from within the shell (and other data files and libraries read from them).
Also something I'm willing to consider, but the fact that I'd have to unpack the group's entire contents would be a severe challenge.

Quote:
All of this still leaves the question of how to properly and uniquely identify libraries to be loaded (and header formats for libraries), as well as of header formats for shell-extensions and Basic programs, but it is a good start.
Indeed, that's something else I haven't considered yet.
KermMartian wrote:
I wanted to leave out type 0 in case we decide that 0 should be a signal for end-of-header.

Ah, fair enough.

KermMartian wrote:
I seriously doubt it will be the only variable-length header field, so I want to include the size to allow any shell to parse any future header field type without knowing what the fields mean.

Okay, makes sense. I think this reasoning would make even more sense if the OpenLib( call was to a generic shell name that could be configured to pass the program along to a user specified default shell. Is there a clean method to transfer control between apps? This would mean that (a) the polyglot portion of the header was always a fixed size regardless of which shell was being used (and make parsing easier), and (b) that programs wouldn't have to be released in 5 different editions for different shells.

I also think my suggestion if including a pointer to ASMStart: before any of the other header fields would be helpful.

Quote:
That was intended to be folded into the required library field. Perhaps something like .dw library number, .db minimum library version?


Something like that. But perhaps a library name rather than number?

Quote:
This sounds a lot like the AP (Associated Program) feature in Doors CS 6/7, which I'm going to be omitting for now. I'll worry about this after the core features are in place.

I strongly believe that having some kind of flexible "open with" system is important to a shell which aims for minimalism in libraries. There's nothing wrong with a minimalist approach, but there has to be a tradeoff for well-designed extensibility. Having neither is problematic. I'm not suggesting you need a pre-built UI for file open/save/save-as, etc, just that you need a way of mapping data files to programs which are capable of opening them. If you don't believe me, consider briefly the fact that Windows is still using ambiguous 3 character file extensions 3 decades later, when other operating systems have content-aware file management.

Quote:
There should also be defined some sort of standard for argument vectors to be passed into programs, including for specifying files that the shell wishes the program to try and open as a datafile.

Even if you start off without an AP-like system, you really strongly need to consider providing argument vectors. This doesn't need to be anything fancier than a standard for (int argc, char * argv[]), but not having this simple mechanism will really hinder the extensibility of the shell.

Quote:
If libraries are external, that seems reasonable enough. That's not something I've figured out yet, though.

I thought the whole point of this exercise was that you were encouraging other developers to provide external libraries so that you could focus on core features?

Quote:
Also something I'm willing to consider, but the fact that I'd have to unpack the group's entire contents would be a severe challenge.

Wait, really? How does GroupTool work?
elfprince13 wrote:
I also think my suggestion if including a pointer to ASMStart: before any of the other header fields would be helpful.
In terms of the shell finding the executable code, it would certainly make things easier, so I see no reason not to have it. But would it be better to have a header size field or a start-of-code pointer?

Quote:
Quote:
That was intended to be folded into the required library field. Perhaps something like .dw library number, .db minimum library version?


Something like that. But perhaps a library name rather than number?
Either one would be fine with me.

Quote:
Quote:
There should also be defined some sort of standard for argument vectors to be passed into programs, including for specifying files that the shell wishes the program to try and open as a datafile.

Even if you start off without an AP-like system, you really strongly need to consider providing argument vectors. This doesn't need to be anything fancier than a standard for (int argc, char * argv[]), but not having this simple mechanism will really hinder the extensibility of the shell.
Where would those arguments be coming from?

Quote:
Quote:
If libraries are external, that seems reasonable enough. That's not something I've figured out yet, though.

I thought the whole point of this exercise was that you were encouraging other developers to provide external libraries so that you could focus on core features?
It's one of the points; another is an extensible header format that actually makes sense. I have time to keep working on that aspect while I get the features to just run BASIC and nostub ASM programs in place.
KermMartian wrote:
elfprince13 wrote:
I also think my suggestion if including a pointer to ASMStart: before any of the other header fields would be helpful.
In terms of the shell finding the executable code, it would certainly make things easier, so I see no reason not to have it. But would it be better to have a header size field or a start-of-code pointer?

Presumably you could have both, since they both simplify their associated tasks, but I think you probably only need one, and the start-of-code pointer is more space/time efficient. At program startup, it allows you to execute immediately without parsing header fields (assuming they were already parsed by the UI prior to program startup), and if you expect that any variable-length fields will contain only null-terminated strings, I don't think it saves you much time (assumming you parse all headers at once). But you may have different behavior in mind, in which case you should evaluate in terms of reasonable behavior for model of shell behavior. One other thing that comes to mind though, is you can achieve essentially random-access (i.e. O(1)) performance for headers if all variable length fields are indirected and stored elsewhere. (i.e. in a data-segment). Which actually leads me to something else, as I'm typing this. A sane way to disambiguate data and code would more easily allow for relocatable executables and make more efficient use of memory layout limitations (i.e. $C000 execution limits).

Quote:
Quote:

Even if you start off without an AP-like system, you really strongly need to consider providing argument vectors. This doesn't need to be anything fancier than a standard for (int argc, char * argv[]), but not having this simple mechanism will really hinder the extensibility of the shell.
Where would those arguments be coming from?

If you provide a mechanism to begin with, you can pretty much ignore it, except to pass (0, NULL). But it would allow other authors to hack on support for terminal-like behavior as well as for file-association features. You could even specify that any three consecutive arguments with the format $2d,$6f,$00, char*, char* should be interpreted as an optional "open request" followed by a type specifier and filename, without actually implementing any routines to provide such arguments yourself.
Elfprince, I've added the offset-to-code field, which should be very helpful (see ASM Header (Color) on the DCS Wiki). I've also slightly rearranged the rest of the header, including removing the field count field and replacing it with an end-of-header field. I still need to see what is going to happen with lowercase letters in the App name once I test on-calc.

Quote:
Quote:

Even if you start off without an AP-like system, you really strongly need to consider providing argument vectors. This doesn't need to be anything fancier than a standard for (int argc, char * argv[]), but not having this simple mechanism will really hinder the extensibility of the shell.
Where would those arguments be coming from?

If you provide a mechanism to begin with, you can pretty much ignore it, except to pass (0, NULL). But it would allow other authors to hack on support for terminal-like behavior as well as for file-association features. You could even specify that any three consecutive arguments with the format $2d,$6f,$00, char*, char* should be interpreted as an optional "open request" followed by a type specifier and filename, without actually implementing any routines to provide such arguments yourself.[/quote] I think there therefore needs to be either a standard register or memory location that points to the argument list (consider it a word of argv* and a byte of argc, perhaps).
  
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 3 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