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 
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.
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.
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
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?
Yeah that was always bound to happen I suppose
.
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.
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.
Now that I have this offset, I can find a whole bunch more too.
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.
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.
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!
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
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.
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! (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
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
