TI84+CE Documentation
» > >
» Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
» View previous topic :: View next topic  
Another parser test, this time TIOS getKey vs ASM lib getkey. All code is the same besides the key function:



I believe the TIOS getKey actually isnt slow, rather its the key-repeat.
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."

Fantastic work tr1p1ea! Looking spiffy. Smile I believe that key input is indeed fast; which is why I prefer to use _KbdScan.

Also, I confirmed that homescreen hooks still work as promised; thanks again to tr1p1ea for addresses. Smile


Code:
_SetHomescreenHook equ 021410h
_ClearHomescreenHook equ 021414h
Quoting from #cemetech:
Quote:
<saxjax> (C) [MateoConLechuga] IT WORKS!
<saxjax> (C) [MateoConLechuga] Yay.
<tr1p1ea> oh cool
<saxjax> (C) [MateoConLechuga] Homescreen hooks are a thing.
<tr1p1ea> nice Very Happy
<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.
<saxjax> (C) *MateoConLechuga added a post in [TI84+CE Documentation] http://cemete.ch/p233686#233686
<debrouxl> The functions of the C API ("Quelles sont les fonctions offertes par UTSRLib ?" section) are documented in English.
<saxjax> (C) [MateoConLechuga] Sounds good; I
<saxjax> (C) [MateoConLechuga] 'll take a look around and see what I can glean. Smile
<debrouxl> Yeah, I think you should Smile
<debrouxl> Kevin Kofler's older EvHk convention certainly has some documentation in English, but if the goal is to design a single convention, I think it's better to start with a more powerful framework.
<debrouxl> I guess I should copy this discussion into the topic.<saxjax> (C) *Lionel Debroux added a post in [TI84+CE Documentation] http://cemete.ch/p233687#233687
<debrouxl> ^
<tr1p1ea> This has been discussed before, however nothing has come to fruition as yet
<saxjax> (C) [MateoConLechuga] Meh, takes work. Razz
<debrouxl> It's not surprising that this was discussed before, indeed Smile
<saxjax> (C) [MateoConLechuga] tr1p1ea: I'm really liking the graphical capabilities on the CE; so many neat programs could be made.
<debrouxl> Over-designing a spec would clearly be bad, but standardizing some things for interoperability, before much non-interoperable code gets written, would be a good thing to do.
<saxjax> (C) [MateoConLechuga] D052C6h looks interesting...
<debrouxl> Multiple programs need event (for you, parser) hooks, fiddling with interrupts, fiddling with the screen mode, etc.
<debrouxl> That's conceivably the job of a "shell" providing some amount of OS / platform abstraction layer, when there is such a shell (i.e. nearly always on the TI-Z80 series and certainly on the brand-new TI-eZ80 series, less frequently on the TI-68k series).
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
As an added note, here are some safeRAM equates. Much obliged again to tr1p1ea for hinting at the address to the first one. Smile


Code:
pixelShadow   equ   0D031F6h
pixelShadow2   equ   0D052C6h
cmdPixelShadow   equ   0D07396h


All are the same 8400 bytes in length. pixelShadow2 is great for TSR programs and hook testing, as it is rarely touched as of right now.

Plus, they are linear, so they provide a total of 25200 free bytes. Which I guess is like nothing now that we have tons of RAM. But hey; now you know where you can actually store data. Smile

Also, here are some important ones that appear to be correct:


Code:
pTemp   equ   0D0259Ah
progPtr   equ   0D0259Dh


NOTE: Ram address appear to also have the same layout as previous versions; but pointers and things are now 3 bytes in length. Very Happy I'm going to try and confirm this in a bit.
MateoConLechuga wrote:
As an added note, here are some safeRAM equates. Much obliged again to tr1p1ea for hinting at the address to the first one. Smile


Code:
pixelShadow   equ   0D031F6h
pixelShadow2   equ   0D052C6h
cmdPixelShadow   equ   0D07396h


All are the same 8400 bytes in length. pixelShadow2 is great for TSR programs and hook testing, as it is rarely touched as of right now.


It seems like it could be useful to have a sizeof() macro for these saferam areas. it could be as simple as some name mangling with additional equates, but having "self documenting" code is always preferable.
<- Please Support on Lego Ideas
elfprince13 wrote:
It seems like it could be useful to have a sizeof() macro for these saferam areas. it could be as simple as some name mangling with additional equates, but having "self documenting" code is always preferable.

Sounds like a good idea! Smile Why not just do a define of the size though; I guess if we were to dynamically allocate the memory, then sizeof() could be useful. Smile
As far as I can tell, the application format is a mix of the 83+ flash header and the 89-style relocatable app. All of the certificate fields are the same as in the 89. I suspect that the protocol for sending the apps over USB is also similar to how the 89TI does it.
That would be my first guess as well, especially given that part of the TI-eZ80 series' OS is known to be written in C, and that as you wrote, the FlashApp + OS computer-side formats used by the TI-eZ80 series are close to those used by the TI-68k series.
Granted, TI EdTech's choices are a mystery to us sometimes, but reinventing their own working wheel isn't too much in their habits. For instance, the Nspire's BASIC and CAS engines fundamentally remain close derivatives of the TI-68k series' BASIC and CAS engines.


We could easily obtain factual data about 83PCE/84+CE <-> TI-Connect CE FlashApp / OS communication. Nowadays, gathering software USB dumps from Windows, and most of all viewing them (using sane tools, that is), is no longer a chore, with the advent of USBPcap ( http://desowin.org/usbpcap/tour.html ), whose dumps can be read by Wireshark Smile
I don't yet have a TI-eZ80 myself. I do have some dumps of e.g. "get infos" communication, but not FlashApp / OS communication.

The USBPcap + Wireshark combo was used for e.g. reverse-engineering the HP Prime's protocol, critor gathered multiple dumps of calculator <-> CK communication and sent them to me.
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.
I just used the timers to record cycle times for the various branching instructions on eZ80 when running in RAM/VRAM. Of course, since this is a pipelined system these instructions don't follow the general waitstate trend of 4 cycles per fetch/read and 2 cycles per write, due to internal cycles or pipeline flushing.

Code:
ADL Mode (executing in RAM):
   JR - 12
   JR cc - 8/13
   DJNZ - 8/13
   JP (HL) - 12
   JP - 17
   JP cc - 16/17
   CALL - 22
   CALL cc - 16/22
   RET - 21
   RET cc - 5/22
   RST - probably 15, based on Z80 mode test
   IM 1 trigger - probably 16, based on Z80 mode test
   IM 2 trigger - 29

Z80 Mode (executing in RAM):
   JR - 12
   JR cc - 8/13
   DJNZ - 8/13
   JP (HL) - 12
   JP - 13
   JP cc - 12/13
   CALL - 16
   CALL cc - 12/17
   RET - 17
   RET cc - 5/18
   RST - 13
   IM 1 trigger - 14
   IM 2 trigger - 23

Mode switches (executing in RAM):
   RET.L to Z80 - 25
   RET.L to ADL - 29
   CALL.IS from Z80 - 22
   CALL.IS from ADL - 24
   CALL.IL from Z80 - 26
   CALL.IL from ADL - 28
Can someone look into what's going on when a TI-basic program switches between FULL and split-screen (Graph up top, home on bottom)? I have a program that seems to stop executing when using these commands, but only if said mode isn't already selected. its aggravating.
Ephesians 1:7, What are you rich in?

Want to give me an Internet? Click here!
Luxen wrote:
Can someone look into what's going on when a TI-basic program switches between FULL and split-screen (Graph up top, home on bottom)? I have a program that seems to stop executing when using these commands, but only if said mode isn't already selected. its aggravating.
Has anyone gotten a chance to look into what's happening with this, and if it's a bug we should be reporting to TI? The program appears to just (silently) break on a Full or G-T/Horizontal command?
Geopipe
I may not be testing what was described exactly (? Do you have an example?), but this appears to work fine for me:

Code:
:Full
:Pause 42
:Horiz
:Pause 9001
:Horiz
:Pause 123456
:Full


Works fine as well if I also add some Output( here and there
For me, the program simply exits, like it reached the end of the program. For now, I've just put in a once-displayed message saying to re-run the program after the screens switch, but it still bothers me.

I'll get a video of it happening.
Also, I am using a few graph setting commands (Axes color, Graph border color) before it.


Code:

::"Some name here"
:ClrHome
:GraphBorder 3             (or whatever blue is)
:AxesOn RED
:Horiz
--Crashes right here, or exits, or whatever you call it--
:~some stuff~
Ephesians 1:7, What are you rich in?

Want to give me an Internet? Click here!
The VAT entries in both RAM and Archive have remained the same. VAT structure is also the same. Here are the particular address that I found that will be useful:


Code:
pTemp equ 0D0259Ah
progPtr equ 0D0259Dh


Rather than having the page as part of the VAT entry now, the 24-bit address is stored oddly into memory, where the highest byte of the address is now stored where the page used to be. Using this, I rewrote the ionDetect routine to search for detectable file types.

Here are the outputs:
; hl->place stopped searching
; de->file data after string
; bc=file size after string
; z flag set if found; nz if not found

I didn't like how iondetect used to copy the program if it was in the archive, so now it just returns the size of the program after the detection string and a pointer to the bytes after the detection string. Which I find a tad more useful. Razz Anywho, enjoy! Hopefully somebody finds use in this.


Code:
;-------------------------------------
; fdetect
; detects appvars, prot progs, and
; progs given a 0-terminated string
; pointed to by ix.
;-------------------------------------
; INPUTS:
; hl->place to start searching
; ix->string to find
;
; OUTPUTS:
; hl->place stopped searching
; de->program data
; bc=program size
; OP1 contains the name and type byte
; z flag set if found
;-------------------------------------
fdetect:
 ld de,(ptemp)
 call _cphlde
 ld a,(hl)
 ld (typeByte_SMC),a
 jr nz,fcontinue
 inc a
 ret
fcontinue:
 push hl
 cp appvarobj
 jr z,fgoodtype
 cp protprogobj
 jr z,fgoodtype
 cp progobj
 jr nz,fskip
fgoodtype:
 dec hl
 dec hl
 dec hl
 ld e, (hl)
 dec hl
 ld d,(hl)
 dec hl
 ld a,(hl)
 call _SetDEUToA
 push de
 pop hl
 cp $D0
 jr nc,finRAM
 push ix
 push de
  push hl
  pop ix
  ld a,10
  add a,(ix+9)
  ld de,0
  ld e,a
  add hl,de
  ex (sp),hl
  add hl,de
 pop de
 ex de,hl
 pop ix
finRAM:
 inc de
 inc de
 ld bc,0
 ld c,(hl)
 inc hl
 ld b,(hl)
 inc hl ; hl -> data
 push bc ; bc = size
 push ix
 pop bc
fchkstr:
 ld a,(bc)
 or a,a
 jr z,ffound
 cp (hl)
 inc bc
 inc de
 inc hl
 jr z,fchkstr
 pop bc
fskip:
 pop hl
 call fbypassname
 jr fdetect
ffound:
 push bc
 pop hl
 push ix
 pop bc
 or a,a
 sbc hl,bc
 push hl
 pop bc
 pop hl ; size
 or a,a
 sbc hl,bc
 push hl
 pop bc
 pop hl ; current search location
 push bc
 call fbypassname
 pop bc
 xor a
 ret
fbypassname:
 push de
  ld bc,-6
  add hl,bc
  ld de,OP1
  push de
   ld b,(hl)      ; Name to OP1 -> For things like archiving/deleting
   inc b
fbypassnameloop:
   ld a,(hl)
   ld (de),a
   inc de
   dec hl
   djnz fbypassnameloop
   xor a
   ld (de),a
typeByte_SMC: =$+1
   ld a,15h
  pop de
  ld (de),a
 pop de
 ret


Call it like this:


Code:

 ld ix,header
 ld hl,(progPtr)
FindNextOneLoop:
 call fdetect
 jr nz,NoneFound
 ;... Do Something With Data ...
 jr FindNextOneLoop
NoneFound:
 ret

header:
 .db $EF,$7B,$C9,$AA,$BB,0
MateoConLechuga wrote:
The VAT entries in both RAM and Archive have remained the same. VAT structure is also the same. Here are the particular address that I found that will be useful:


Code:
pTemp equ 0D0259Ah
progPtr equ 0D0259Dh


Rather than having the page as part of the VAT entry now, the 24-bit address is stored oddly into memory, where the highest byte of the address is now stored where the page used to be. Using this, I rewrote the ionDetect routine to search for detectable file types.

This makes a ton of sense for backwards compatibility, since page+16bits is already functionally a 24bit address.
<- Please Support on Lego Ideas
elfprince13 wrote:
This makes a ton of sense for backwards compatibility, since page+16bits is already functionally a 24bit address.

It does indeed, but the actual storage is odd, as it is stored big-endian, and thus something simple like ld hl,(hl) will fail when loading it like that. Kind of odd, but at the same time it makes things quite nice. Smile
MateoConLechuga wrote:
It does indeed, but the actual storage is odd, as it is stored big-endian, and thus something simple like ld hl,(hl) will fail when loading it like that. Kind of odd, but at the same time it makes things quite nice. :)

Yes, VAT entries are backwards, so it's big-endian not little-endian. However, the VAT entry prefixed to archived variables is not backwards, so the pointer is also little-endian. (Yes, archived variables have a pointer to themselves.)
Is searching the VAT (such as when launching an ASM program using the Asm() command) still as slow as on the 84+/SE/CSE when the RAM is low and the archive clogged with dozens and dozens of programs?
DJ_O wrote:
Is searching the VAT (such as when launching an ASM program using the Asm() command) still as slow as on the 84+/SE/CSE when the RAM is low and the archive clogged with dozens and dozens of programs?

No; searching is quite a bit faster. This is just due to the processor and memory speed; not really much changes to the actual routine.

In addition, my custom version doesn't copy over the program from the archive, so that way it's up to the programmer to copy what they want copied over. It just returns a pointer to the data after the search string, and the size of the file after the search string.
I just timed how long IM 1 and IM 2 take to trigger an interrupt in Z80 mode, as well as IM 2 in ADL mode. I added these to my post above, but I'll put them here as well:

Code:
ADL Mode (executing in RAM):
   IM 1 trigger - probably 16, based on Z80 mode test (2F+3W+2I)
   IM 2 trigger - 29 (2F+3R+3W+3I)
Z80 Mode (executing in RAM):
   IM 1 trigger - 14 (2F+2W+2I)
   IM 2 trigger - 23 (2F+2R+2W+3I)


For what it's worth, IM 1 seems to just be RST plus 1 internal cycle, and IM 2 seems to be IM 1 plus another internal cycle and the address read (2 or 3 bytes read based on the mode).

Edit: Added some likely Fetch/Read/Write/Internal cycle counts.
  
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
TI84+CE Documentation
» Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
» View previous topic :: View next topic  
Page 3 of 7
» 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