Ahh, yes, that was what I meant. And...huh, there isn't a stand-alone implementation is there? I feel like accessing basic libraries without a header should be considered unsupported behavior, at least on the 84+CSE, since you don't need to emulate support for pre-DCS xLib programs here.


If you get this working reliably, it would be great. It would need to work even in the face of reals 14/11/8 to restore functionality for math applications, or for my data structure implementations that use complex numbers to store tuples of pointers (e.g. for left/right tree-node children).


Oh well =(


Also bump of a previous proposal:

I was just thinking it would be easier to let them bump it up and down instead of having to know what level the brightness is and such, that way a programmer could set it up and down via the - and + keys or something in their project, or call it multiple times to do some form of effect for a game.

I think that could work; the only issue that I can think of is you might have to know what the starting brightness was, in case it was already at the lowest and you wanted to fade out and in...

The fix is now in place for Doors CSE 8, and it will be released as Doors CSE 8.1.2. Because this is just a change in the dev version (..2) and not the minor version (.1), I can't add any new functions to the xLIBC / Celtic 2 CSE libraries, but I haven't forgotten about those suggestions. I ended up storing the bit to indicate whether Doors CSE should catch real() or not as 0,(iy+asmflags3); xLIBC and Celtic 2 CSE do not currently use asmflags3.

Awesome!

Thanks! Can I get any volunteers who use math and/or hybrid BASIC programs on the TI-84+CSE to help me do some sanity-testing to make sure my changes are stable and correct?

My math programs could probably run unaltered, but I don't have a CSE.

I'm not sure if I've asked this before, but I have a feature request: Reading binary data out of an appvar of any length from any location into another appvar. Like readline, but with more control. This would make packing image and other data into a single appvar easier.

This feature request makes me think that over a decade ago, Thomas Nussbaumer (TICT) defined the TTArchive format for packing data into TI-68k files:
https://github.com/debrouxl/gcc4ti/blob/next/trunk/tigcc/tools/ttarchive.h
It was used in e.g. TICT ebooks, for splash screen images + text.

A TTArchive file contains a "tta\0" magic, followed by two bytes containing the number of entries (big endian), followed by entries pointing to data.
Compression of data (with PuCrunch) is mandatory, and obviously, the ttarchive tool can't be used as is for generating TI-Z80 files.

Maybe there are some ideas and code (LGPLv2.1+ with exception allowing redistribution of binaries resulting from building pristine source code) to cribble from there, which is why I'm mentioning TTArchive.

This is something that is very much needed. It would have made the STEM Behind Hollywood activities much easier; I'm using an ASM stub to essentially do exactly this. One problem: the maximum value for Real arguments that xLIBC/C2CSE can parse is 9999, but the max offset we might want is 2^16-1. How do you propose that programmers specify offsets (and sizes) above 9999?

This certainly seems like a cool way to handle things, but I worry about the potential complexity of wrapping data in even more metadata. In particular, the second Doors CSE page has only about 1KB free space left, and if we include both new xLIBC/C2CSE functions and CALCnet, it's very likely that we'll have to make Doors CSE 8.2 be a 3-page App. If that happens, we'll of course have tons of space for new functions, but I always try to keep the Doors CS[E] apps to as few pages as possible.

Without knowing exactly why this is the case, I don't know. A couple thoughts, in order of what I like as a consumer of the API:
1) Change the way you're doing parsing so you can do >9999
2) Use Ans/Another variable
3) A string parameter
4) Limit it to 9999, but allow the user to append the data to the end of an appvar so it just takes multiple calls
5) Make it so the passed-in variable in 2^X, so if you pass is 4 it reads 16 bytes, but allow the user to append the data to the end of an appvar so it just takes multiple calls

You should do the second part of #4 anyway, an option to overwrite, and an option to append.

*Bump* Also the ability to enumerate AppVars and Programs would be helpful for custom level sets and such. Especially if built into the API call could be a "Search for this header" parameter.

I believe it's a limitation of _ConvOp1, if I recall correctly, so it would require writing a custom version of _ConvOp1 to go past the first two mantissa bytes.
All of those would work. Actually, my primary concern is a function that will read arbitrary data at an arbitrary offset from an AppVar first; I feel like writing into another AppVar is a secondary concern, since we could technically use InsertLine for that task.
I know that this is something tifreak8x wants as well, especially if (opposite of your "especially" clause) it can be told to enumerate all programs and/or AppVars.

Is this hard to do? Is it worthwhile?
I don't understand. What would you do with the read-in data other than put it somewhere usable? InsertLine has limitations.
I think supporting both modes would be ideal. But being able to parse out ones with a custom header makes it the most useful to me for searching for level sets.

Yes, and no, respectively. Iambian did it for one of his projects, and based on the size and complexity of the code, I feel like a different solution would be better. Of course, I could always try to use his code, with his permission. This would incidentally also simplify the DispColor call, which breaks its 16-bit arguments into two 8-bit halves. I believe the reason _ConvOP1 works this way is that a 4-digit number is guaranteed to fit into a 16-bit register, while a 5-digit number greater than 65535 would not fit.

Put it into a string, just like ReadLine. InsertLine's limitations would be irrelevant if you were using it to insert a single string of data into an otherwise empty AppVar (to, for example, create an xLIBC spritesheet or background image AppVar).
Makes sense; I think I can manage to let the user pass a zero-length string ("") as the custom header to search for. This particular request is not really technically challenging in any way, just a pain to code.

If you can borrow his code, I think this is the right approach. It simplifies it for the consumer of the API, which should be the end goal of any API writer. If this doesn't work, then another though I had was variable number of arguments.

This only works if we can do any number of bytes, and aren't limited to 9999. If that limit exists, we'll need an append. Putting binary data into a string seems silly to me--what will that be used for other than something like this? Why would you ever want that data in a string unless it's actually a string, in which case Read/Insert line work just fine.

Works for me.

Just some wishes:
1: PC to Calc API/Protocol
2: View apps and programs on same screen
3: Background options for home screen
4: Button options
5: Notification icon API

Again, just ideas, but I really would like to emphasize #2. It's really annoying to have all my projects on one screen, and apps on another. It really would be nice to have all of that integrated together.

I've got a problem with doors cse...
Basically, when I tried to transfer a program on my calc to my computer, it says Error: ?. No matter what I do, it will not leave that error and I really dont want to reset because i think one of my larger projects might be cleared.

EDIT: I just checked, and I am using build 1547

Note to self: Add a Hybrid function to check the amount of free RAM, at least; being able to check the amount of free Archive would also be nice. This would have been extremely handy for Zombie Apocalypse Part II. Adding a command to execute a hex string would be really great too.

CALCnet/gCn will fulfill this request.
This is too technically difficult to be worth it.
It would be cool, but not worth it.
What would that be?
What would that be?

Unfortunately, this is one of the hardest things to do. I barely think it's worth having Apps be displayed within Doors CSE in the first place, but the people kept asking, so I delivered.

Were you able to resolve this? Do you know what caused it?

Not sure if this would be considered a *bump* on my last post, but I do have some more feature requests. With CALCnet, would it be possible to install apps and programs from within Doors CSE? I had to make a program to receive apps. With this being fulfilled, within Doors itself you could create a "Download Management" button (probably remap button 15 to do this, remap button 13 to create the menu, and an icon for installing apps. Also, could horizontal scrolling be implemented? Finally, can the scrollbar be lot smaller? It takes up about 1/15 of the screen.
Oh, and following up on the Notification API, I finally finished it. I'll upload the programs (when I can figure out how to) and instructions on how to make custom notification icons for Doors programs.
EDIT: added my programs to the archive queue. Will post a link if/when accepted.