Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
How do you plan on finding the correct addresses? Or are they already documented?
MateoConLechuga wrote:
How do you plan on finding the correct addresses? Or are they already documented?
The process is a combination of educated guesswork and painstaking reverse-engineering. Once you know the location of the some of the bcalls, you can compare the TI-84+ and TI-84+CSE lists, and see if the order and distance between entrypoints appears to be the same. If it is, you have a good idea of where to check for the code for the bcalls; if not, you need to do more searching. Once you have some guesses, you trace the bcall address to a specific address and page in the OS where the code for that bcall resides, and compare it to the code for the same function in the older OS versions. If it appears to match, you can call that a preliminary match, and try to use it. If you're totally lost, you can try to search through the OS for the sequence of bytes that correspond to some unique section of the bcall in question, such as a series of flag reads and sets that probably don't appear in another bcall.
That makes sense. Sounds like it could become quite painstaking as the code was changed in order to change to the new screen size, color and whatnot. Good luck!
MateoConLechuga wrote:
That makes sense. Sounds like it could become quite painstaking as the code was changed in order to change to the new screen size, color and whatnot. Good luck!
Thanks! I checked those equates, and it looks like I got them right. Unfortunately, it also looks like the error handling is not so good, as demonstrated by recompiling BrandonW's "ddemo" program for the TI-84+CSE:

*bump* I spent quite a few hours yesterday working on Graph3DC, focusing in particular on making the Window menu using the TI-OS's DialogContext system. I built a routine that converts my signed 8.8-bit fixed-point numbers to OS real numbers, then spent a number of hours debugging OS issues with _StartDialog. As I debugged, I became increasingly convinced that TI didn't actually try to make these routines work on the TI-84+CSE:
1) Unless you set 5,(iy+$4c) (unknown flag offset?), the OS rampages over 3 bytes starting at $8129, causing any reasonably-large dialog data at $8100 to be corrupted.
2) The callback address and page needs a non-zero page, and because it takes a single byte as a page (and uses $86 as flash page $86 rather than RAM page $06), it's impossible to put a callback in RAM. Therefore, I'd have to change this to an App, or put my code for the callback in an archived AppVar. Ew.
3) The _StartDialog routine generates tons of terrible graphical artifacts when render past six lines (see below).

Therefore, I suspect I may need to use the edit buffer routines and the parser to just handle numeric entry myself. Does anyone have any pointers on where to start with that?

*bump* Thanks to Kirk Meyer, Graph3, and WindowHook documentation on WikiTI, I may have found a solution that works for me, at least for the Window menu. I set up a WindowHook, then invoke the Window menu context. I'm hoping I'll be able to call the Monitor, then use a combination of an AppChangeHook and RawKeyHook to correctly handle quitting from this Window menu back to Graph3DC. I can only hope that the OS won't muck with my safeRAM. To make things more interesting, the TI-84+CSE doesn't handle hooks in RAM well, now that there are 256 possible Flash pages, so I create a tiny AppVar containing .db $83 \ ld hl,(someRAM) \ jp (hl), Archive it, and use that as my "hook" to trampoline to my real hook.

Left: Adapting Graph3's code. Right: My own version.
*bump* Many thanks to Runer112 for putting together a small, fast ConvOP1 replacement today, which ended up being useful for making my Window menu work. I can extract values from my 8.8 fixed-point numbers into my custom Window menu using the windowHook, save them back, and deal with the two fields that are 1-byte ints as well. The biggest current problem is that I:
(1) Set up a windowHook, save SP, and change context to Window
(2) Invoke _Mon to get Window input
(3) Catch an appChange using an AppChangeHook
...but when I regain control and restore SP, it looks like _Mon has unrolled my stack, and some of my safeRAM is trashed. The safeRAM I can deal with by moving my data, but how can I keep _Mon from unrolling the stack? This is an ASM program running until Doors CSE, by the way, and I'd like it to be able to return sanely.

Edit: I was talking about this with BrandonW last night, and discussing the terrible OS hacks I'm working with to make this a functioning ASM program. I was resistant to making it an App, because I wanted it to run under Doors CSE 8, but I suppose I need to ask the question now. Do you want this to be:
1) A program, that runs under Doors CSE, in which you enter equations, edit the window, and graph things? or
2) An app, very much like Graph3, that captures double-taps on Y=, Window, Graph, and so on, and has 3D graphing integrated into the OS?
Please weigh in.
I vote #2
App, definitely an app.

Except I wouldn't intercept doubletap of Y= you should be able to implement it such that it replaces Y= like Graph3 or Inequalz.

Also having it run under DoorsCS sounds pointless to me unless you are using a ton of DoorsCS related routines.
Yeah, #2 sounds much more user friendly.
If the OS integration you plan on doing can't be sanely done using an ASM program, I suppose an app is the only sane option.
Thanks for the feedback, guys. I've been working on converting Graph3DC into an App, which involves lots of code movement. For the sake of my own ego, I'm trying to avoid consulting the Graph3 code as much as possible and just figure things out on my own. Anyway, I'm currently working on how to enable 3D mode in the first place. Originally, I was going to make it a double-tap on Y= (that is, Y= goes to the OS Y= menu, and Y= again goes to the Graph3DC Z= menu). However, I was shocked to discover that in the Y= menu, Y= does not re-initialize the YEqu context, and Y= is not even passed to the YEqualsHook as kYEqu (it's actually kApp, oddly enough). After looking at the Transformation App, I'm thinking of adding "3D Mode" next to Plot1/2/3 in the Y= menu, and then "Y= Mode" or "2D Mode" in my own custom Z= menu. I discovered that the YEqualsHook doesn't do anything when you're in that top bar, but it looks like Transform is hooking into the OS somehow, so I'm looking for that hook. Is it possible the TI-84+CSE and newer have a new hook we haven't found for that top bar? Or maybe it's a menuhook? TIA for any experience with this.
Looking like I'm late to the party, but I would have voted program, personally, with the prime benefit of it being more easily ported to the CE instead of just being on the CSE as an application.

Good luck with figuring out these issues.
tifreak8x wrote:
Looking like I'm late to the party, but I would have voted program, personally, with the prime benefit of it being more easily ported to the CE instead of just being on the CSE as an application.
On the other hand, as a purely educational program, I think it could be a good example of why the community deserves the ability to make third-party Apps, possibly. Smile

Good luck with figuring out these issues.
Thanks! I'm working on understanding what the Transformation App does; so far I've determined that it uses a CursorHook in some fashion for that top menu. BrandonW suggests that the OSes contain some special hooks/code that specifically benefit Transformation and Inequals.
Third-party Apps are all well, but can't offset the fact that Flash memory is twice (even) slower than RAM, sadly. It's not like the platform is so overpowered that all programmers shall be willing to make their programs execute at half the speed they could reach by using another execution choice (standard on TI-68k platforms) Smile

A hybrid FlashApp, executing some chunks from Flash and some chunks from RAM, still requires making third-party FlashApps.
I've been working hard on this; the biggest problem has actually been switching the App's functionality on and off. I did a great deal of research into what Transformation does, and ended up combining a new App context with a CursorHook to create a replacement Plot1...Plot3 line for the Y= menu (just like Tranformation, although with a few fewer obscure OS tricks and integrations). There are many corner cases that make this not work, including Transformation being installed first; I'm working on it.

Edit: For the curious, here's how the main menu looks so far. I'm frustrated that the TI-OS erases fewer pixels behind the text when textInverse is turned off, but I'll deal. In fact, this may have given me a way to remove the need for a fontHook in Doors CSE.

A few new goodies from extensive work I did over the past two days:
- The Zoom menu works, thanks to a new MenuHook and extensive reverse-engineering of quirks and bugs in the OS's MenuHook system. Among other things, it re-uses MenuHook event 0 for when the user selects an item, in such a way that it's hard for the App to distinguish this from when it re-draws the menu. To solve this, I change the MenuCurrent value to a special flag value after the menu is drawn, so my hook knows the next event 0 is a selected item.
- Zooming in and out and ZoomStandard all work. The math was surprisingly simple.

I'll probably have to make some changes to how the OS floats for the X and Y values are translated to Graph3DC's internal coordinates, but it works for now. Next is displaying the graph with a GraphHook, I think. Question: full-screen 3D graphing, only within the OS's graphing area, or inside the OS's graphing area + the border?

Left to right: Switching between the normal and Graph3DC Window menus, toggling the Zoom menu, and testing zooming.

Would it be too much work to make it configurable? If that's off the table, I'm all for full screen.
I'm with merth, configurable, or fullscreen if that can't be done (easily)
Thanks for the opinions, guys. I have modified my code to be able to handle a full-screen mode or a with-status-area mode; the screenshot below demonstrates the latter mode. I've been doing a lot of work to refactor my old program-based graphing code into App-friendly code that will work from inside a GraphHook; the work and debugging continues.

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 2 of 5
» 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