Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
The experimental branch of tilibs ( https://github.com/debrouxl/tilibs/tree/experimental ) now contains indirect documentation about the OS send, FlashApp send and FlashApp receive protocols.
The code worked against a 83PCE, but seemingly not against a 84+CE. I don't know why.
Is it safe to assume that the information used to write that code was derived from USB dumps of TI-84 Premium CE communication? Do you have TI-84 Plus CE USB communication dumps for comparison?
Quote:
Is it safe to assume that the information used to write that code was derived from USB dumps of TI-84 Premium CE communication? Do you have TI-84 Plus CE USB communication dumps for comparison?

Yes, the information used to write that code was derived from TI-Connect CE <-> 83PCE communication; no, I don't have TI-Connect CE <-> 84+CE communication dumps for comparison.
Menu( options 8 and 9 appear as ?. is this left over from the CSE?
Luxen wrote:
Menu( options 8 and 9 appear as ?. is this left over from the CSE?
Yes, Menu( had this bug on the TI-84 Plus C Silver Edition as well; unfortunately, it didn't get addressed on the TI-84 Plus CE.
Lionel Debroux wrote:
no, I don't have TI-Connect CE <-> 84+CE communication dumps for comparison.

You do now Smile
And it's confirmed to work (I was able to transfer the SciTools app and the OS, both successfully) with the latest experimental sources.
[quote="Lionel Debroux"]Quoting from #cemetech:
Quote:
<saxjax> (C) [MateoConLechuga] It's really fun to enter in one thing and get a different result. Razz I wonder where the best place to permanently store hooks might be... If we need to, eventually.
<debrouxl> Probably some form of TSR.
<debrouxl> FWIW, on the TI-68k series, a framework for sane handling of multiple, chainable event hooks was developed.
<debrouxl> Not just one, in fact.
<debrouxl> There's at least Kevin Kofler's "EvHk" framework, and Flanker's UTSRLib.
<debrouxl> UTSRLib aims at being more powerful than EvHk, by handling e.g. interrupt handlers, in addition to just event hooks.
<debrouxl> EvHk works in native mode, without installing a so-called "kernel" (usually termed "shells" in TI-Z80 parlance, both terms being equally improper), while UTSRLib leverages the features provided by PreOS.
<debrouxl> There are two good tutorials for EvHk ( http://www.ti-fr.com/?act=66&art=4 ) and UTSRLib ( http://www.ti-fr.com/?act=66&art=11 ), both by the author of UTSRLib... but those aren't written in English.
<tr1p1ea> :S
<debrouxl> The UTSRLib tutorial contains a bit of English text, actually.
Part of the problem is that many Apps use hooks as-is without regard for other Apps, or at best, simply chain or warn of the existence of hooks of the same type. This includes the TI Apps included with the calculator from the factory, so any hook-management scheme would need to take into account the fact that Apps using hooks need to also function without any hook management scheme at all. I think that makes it a much twitchier problem, unfortunately.
Alright. I threw the idea out while it was still (potentially) time to implement something along those lines, but if it can't pan out, so be it Smile

Quote:
<debroux_> Meh. If even TI FlashApps use the hook system without paying attention to other potential users of the hook system, that's no fun.
<Jonimus> debroux_: that has usually been less of an issue on the z80 calcs because of the need to install the hooks where iirc on the 68k calcs they install upon app install.
<debroux_> Yeah, TI-68k FlashApps register themselves into the event handling (cooperative multitasking) system.
<debroux_> And ASM programs using event hook functionality register themselves later, of course.
<Jonimus> yeah so with the z80 calcs if the app doesn't chain it just complete removes the other apps hooks so its less of an issue if they don't play along as the other app never finds out.
Here's something funny that I thought I'd share:


Code:
_cphlde equ 021D98h
_cphlde equ 02013Ch
_cphlde16 equ 021D94h


There are two cphlde's; and they are far less efficient than simply:


Code:
 or a,a
 sbc hl,de
 add hl,de


Thoughts on why these two jump table address point to the same call? This appears to happen multiple times with other instructions as well, for some reason. Also, I'm going to confirm these ram areas at some point:


Code:
D02EC7: textShadow
D006C0: cmdShadow


EDIT: Oh, and here is something that will make you cry a bit:

Code:
_ldHLintoHL:
ld        a, (hl)
inc       hl
ld        h, (hl)
ld        l, a
jr        _ldhl16
...
_ldhl16:
push      af
xor       a
ld        ($D02AD7), hl
ld        ($D02AD9), a
ld        hl, ($D02AD7)
pop       af
ret

Why TI, why? Smile
Yeah that was always bound to happen I suppose Smile.
Well, added a whole slew of system calls to wikiTI; and now I'm working on finding some RAM areas. Here's what I've found so far:


Code:
errNo   equ   0D008DFh
errSP   equ   0D008E0h
tempMem   equ   0D02587h
FPSbase   equ   0D0258Ah
FPS   equ   0D0258Dh
OPBase   equ   0D02590h
OPS   equ   0D02593h

pTemp   equ   0D0259Ah
progPtr   equ   0D0259Dh

begPC   equ   0D02317h
curPC   equ   0D0231Ah
endPC   equ   0D0231Dh

asm_prgm_size   equ   0D0118Ch

kbdScanCode   equ   0D00587h
kbdLGSC   equ   0D00588h
kbdPSC   equ   0D00589h
kbdWUR   equ   0D0058Ah
kbdDebncCnt   0D0058Bh
kbdKey   equ   0D0058Ch
kbdGetKy   equ   0D0058Dh
keyExtend   equ   0D0058Eh

; safeRAM
pixelShadow   equ   0D031F6h ; 8400 bytes
pixelShadow2   equ   0D052C6h ; 8400 bytes
cmdPixelShadow   equ   0D07396h ; 8400 bytes
plotSScreen   equ   0D09466h ; 21945 bytes
saveSScreen   equ   0D0EA1Fh ; 21945 bytes
textShadow   equ   0D006C0h ; 260 bytes
cmdShadow   equ   0D0232Dh ; 260 bytes


I haven't confirmed completely the PC ram areas, but they appear to be correct. If anyone would like to test them, that would be great. Smile

Also, many flags look like they were kept the same.

Code:
res 5,(iy+44h)
set 5,(iy+44h)

Enable and disable CLASSIC mode respectively.
Update, once again, just in case anyone cares:

Here are some nice calls that I found; these ones were really annoying. Could be helpful for cleaning things up. Wink Now that I have this offset, I can find a whole bunch more too. Very Happy Here we go!


Code:
_DrawStatusBar   equ   021A3Ch
_DrawStatusBarInfo   equ   021AB4h


Oh, and some more:


Code:
_DrawBatteryIndicator equ 021A50h
And continuing the escapade, enjoy some more ram addresses and calls:


Code:
winTop   equ   0D02504h
winBtm   equ   0D02505h
winLeftEdge   equ   0D02506h
winLeft   equ   0D02507h

textBGcolor equ 0D02688h
textFGcolor equ 0D0268Ah



Code:
_GetColorValue   equ   021BACh
_SetTextFGBGcolors   equ   021AE4h      ; Sets FGcolor to DE, and BGcolor to HL; sets PutMapUseColor flag
_SetTextBGcolor   equ   021AE8h         ; Sets BGcolor to HL; sets PutMapUseColor flag


Note those last two; I guess they might be useful. They use the same color values as the CSE.

Going to find a lot more; now that I have these offsets. Smile
Keep up the amazing work! I wish I had time to help you; I continue to spend my reverse-engineering time figuring out more about the hooks on the TI-84+CSE for Graph3DC. I guess if the hooks haven't changed much, then this research will still eventually end up being helpful. Smile
The boot code call: 0003B0h will read the status of the battery and place the value in A.

The possible readable modes for the battery are as follows:

Code:
> 75%       ; A=4
50%-75%     ; A=3
25%-50%     ; A=2
5%-25%      ; A=1
< 5%        ; A=0


EDIT: Also, the carry flag will be set if the battery is valid.
Back again for more documentation! Smile So, I have a whole slew of new system calls that I'll be adding to the Wiki soon, and as of right now I am determining the best route for USB discoveries. Going to try and use system calls as much as possible; it appears that all USB functions are written in C. However; assembly programs can call these of course. There seems to be wrappers for it, but I'll keep it updated here. Starting off with this simple boot call here:

Code:
_GetUSBPlugType equ 0003E8h


That returns 0 into a if it is an A-type plug; else it returns 1 in register a. This is a C call; technically. It looks like this:


Code:
char GetUSBPlugType(void);


Note that it doesn't need to be connected to anything to work. There's a whole lot more; but I need to come up with proper names for them Smile


Code:
USBPlugStatus equ 0D1407Bh

TI appears to store the result of the above call in here at some points?

UPDATE: Also, it appears that many OS jump table system calls are actually C calls to affect the behavior of the OS. These will be quite useful; which is why I am also compiling a header file which basically prototypes these functions and equates their addresses in the jump table. Here's a quick section of what it will look like:


Code:
#pragma asm ".nolist"
/* === Type Definitions for ZDS II ============ */
typedef bool char;
/* ============================================ */

/* === Function Prototypes ==================== */
bool GetOnInterrupt(void);  // Retuns onInterrupt
uint16 GetDrawFGColor(void); // 565 color
void SetDrawFGColor(uint16 color); // 565 color
void SetDrawBGColor(uint16 color); // 565 color
/* ============================================ */

/* === Location Equates ======================= */
#pragma asm "_GetOnInterrupt   equ   00057Ch" // Boot Call
#pragma asm "_GetDrawFGColor   equ   021EE8h" // OS Call
#pragma asm "_SetDrawBGColor   equ   021E20h" // OS Call
#pragma asm "_SetDrawFGColor   equ   021E24h" // OS Call
/* ============================================ */
#pragma asm ".list"
Keep up the great work! I hate to impose, but since I have no emulator on which to trace things yet, I was hoping that I might ask for the equates for the following on the TI-84+CE. I will happily provide further documentation from the TI-84+CSE versions of these if necessary. Thanks in advance if anyone can help!


Code:
_FormTime
StatusBarBGColor
_SetRawkeyHook
menuCurrent
progToEdit
_FindApp
_EnableSilentLinkHook
cxCurApp
editTop
editTail
editCursor
editOffset
_FindApp
_FindAppUp
_FindAppNumPages
All you have to do is ask Kerm, and anyone for that matter. Wink Whatever I don't talk about in here I updated on WikiTI. _EnableSilentLinkHook is defined as _SetSilentLinkHook, which I guess I should change... Oops looks like I did that for all the hooks. Bad Mateo. The OS doesn't seem to use it in the manner it once did or somethings, so I will look more into that. The following have been removed, as apps are now using some niffy C functions that I haven't had the time to explore much of yet.


Code:
progToEdit ; Moved or changed, probably
cxCurApp ; Moved or changed, probably
_FindApp ; Hm.
_FindAppUp ; Hm.
_FindAppNumPages ;This... doesn't even make sense anymore.


StatusBarBGColor isn't defined for the CSE, at least not on WikiTI, and neither is progToEdit. What am I missing here... I defined StatusBarBGColor though for the CE. progToEdit will have to wait, at least for now.

Hope this helps! Smile (I really need to explore how apps work, I guess)

EDIT: Oh wait, sorry, I still need MenuCurrent... Hm, hang on.
MateoConLechuga wrote:

Code:
progToEdit ; Moved or changed, probably
cxCurApp ; Moved or changed, probably
_FindApp ; Hm.
_FindAppUp ; Hm.
_FindAppNumPages ;This... doesn't even make sense anymore.
It doesn't make sense, but I was hoping there's an equivalent that gets the App's size. In addition, I'd love to know what the OS calls to get an OS's About string (see the Memory menu).

Quote:
StatusBarBGColor isn't defined for the CSE, at least not on WikiTI, and neither is progToEdit. What am I missing here... I defined StatusBarBGColor though for the CE. progToEdit will have to wait, at least for now.
I have this in Doors CSE:
Code:
StatusBarBGColor =      0A600h
progToEdit =         $8511


Quote:
EDIT: Oh wait, sorry, I still need MenuCurrent... Hm, hang on.
You're the best!
KermMartian wrote:
In addition, I'd love to know what the OS calls to get an OS's About string (see the Memory menu).


What exactly do you mean? I found _DispAboutScreen, which displays the information of the about screen, which I can look more into. What are you looking for?
  
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 7
» 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