30

PpHd (./29) :
Report sent. Currently not a bug.

Seen, thx for your test, I look at that this afternoon.
PpHd (./29) :
Could you test again? It seems to work but an awful rate (2s or more repeat!). Could you confirm?

Confirmed, it works on 89 HW2 ! Sorry for the false report... (first repeat delay seems to be ~5 sec, then 2 secs)
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

31

Folco (./30) :
Confirmed, it works on 89 HW2 ! Sorry for the false report... (first repeat delay seems to be ~5 sec, then 2 secs)


Well, don't get me wrong. I really consider this as a bug. The delays are too big!

32

As said by email, the bad behavior of pexeclib seems due to a not official binary of kpack for Win32. You're right, there is no bug. I have tested different ramcalls using the dynamic linker and libraries, all seems to work fine now. top
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

33

Feature request : would it be possible to increase the size of the command line buffer ? When using a soft which uses a lot of args, the 40 bytes are quickly filled. 60 bytes would be sufficient for me. I could use a script, but editing it every time to perform tests is a bit boring...
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

34

Folco (./33) :
Feature request : would it be possible to increase the size of the command line buffer ? When using a soft which uses a lot of args, the 40 bytes are quickly filled. 60 bytes would be sufficient for me. I could use a script, but editing it every time to perform tests is a bit boring...

Done.

35

Thanks !
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

36

Executing 'clean|' results in a protected memory violation... (RC4)
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

37

Folco (./36) :
Executing 'clean|' results in a protected memory violation... (RC4)

I confirm. In fact, it occurs for clean| anything
It is because clean deletes the handle which was created to handle the pipe.
I don't know how to fix this so let's keep it for 0.82
It is not so bad for the user.

38

It is not so bad for the user.

Exact, I discovered that doing a typo. grin This should never happen.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

39

I can't link my calc with Ti-Connect 1.6 (Windows). I get the error "Link : reset".
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

40

Try again. It should work after a while grin

41

Indeed, I can get connected when I press "ESC" when the dialog box appears. Then Ti-Connect find my calc, but fails to explore it. I also get the "Link : Command ?" error when I ask Ti-Connect to check the version of my OS to know if it needs an update. (grin) While checking that, it does the home screen to scroll in the same way that if I press "ENTER".
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

42

Folco (./41) :
Indeed, I can get connected when I press "ESC" when the dialog box appears. Then Ti-Connect find my calc, but fails to explore it. I also get the "Link : Command ?" error when I ask Ti-Connect to check the version of my OS to know if it needs an update. (grin) While checking that, it does the home screen to scroll in the same way that if I press "ENTER".

Does somebody know how this check is done? Maybe sending some commands through the link port?

43

I don't know.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

44

Folco (./41) :
Indeed, I can get connected when I press "ESC" when the dialog box appears. Then Ti-Connect find my calc, but fails to explore it. I also get the "Link : Command ?" error when I ask Ti-Connect to check the version of my OS to know if it needs an update. (grin) While checking that, it does the home screen to scroll in the same way that if I press "ENTER".

I have made some changes in the link code which should make the link more reliable. Well, let's hope for it...

45

PpHd (./31) :
Folco (./30) :
Confirmed, it works on 89 HW2 ! Sorry for the false report... (first repeat delay seems to be ~5 sec, then 2 secs)


Well, don't get me wrong. I really consider this as a bug. The delays are too big!


I get it! I get it!
I get this fucking bug!
The bug wasn't in the int 1, neither in the repeat code, neither in the get code.
It was....
in the idle function!!!

The idle function doesn't wake up if auto int 1 is trigered on PedroM.
Which makes the idle function to wake up only for the first press on the keyboard (auto int 2), and then to wake up only if the auto int 5 is triggered, which explains the slow rate (In fact, the counter was near the counter of int 5 which makes senses).

AMS does the same thing (don't wake up the CPU if auto int 1 is triggered) except if some keys are in the key buffer, in which case, it wakes up if Auto Int 1 is triggered...

Here is the patch:
--- a/src/Boot.asm
+++ b/src/Boot.asm
@@ -239,7 +239,7 @@ OSCont2     lea     (SSP_INIT).w,sp                 ; Setup Supervisor Stack
 
        ; Init Key System
        jsr     GKeyFlush
-       move.w  #50,(a7)
+       move.w  #24,(a7)
        jsr     OSInitBetweenKeyDelay
        move.w  #130,(a7)
        jsr     OSInitKeyInitDelay
--- a/src/Vectors.asm
+++ b/src/Vectors.asm
@@ -326,7 +326,11 @@ Trap_5:    ; Trap_5 really turns off the calc.
 Trap_0:        ; Idle
        move.w  #$2700,SR
        move.w  #$280,$600018
-       moveq   #$1E,d0
+       moveq   #$1E,d0          ; Default: Wake up only for auto int 2, 3, 4, 5, 6 or 7
+       tst.w   (KEY_PREVIOUS).w ;      Check if a key is currently processed by the Auto int 1 (in which case the auto int 1 has to handle the auto repeat feature ==> The calculator
+       beq.s   \DontWakeUpIfAutoInt1
+               moveq   #$1F,d0          ; Wake up only for auto int 1, 2, 3, 4, 5, 6 or 7
+\DontWakeUpIfAutoInt1:
        ifd     PEDROM_92
                bsr.s   IdleRam         ; For 92+ & V200; shut dowwn flash
        endif

(I have also increased the default repeat rate).
A RC5 should come soon.

46

The RC5 has been released with:
+ some changes in the link code. I hope it will make it more stable.
+ the fix for the auto repeat keys,
+ some other minor fixes
+ some changes in the system variables.

47

Congratulations PpHd smile
Folco (./32) :
As said by email, the bad behavior of pexeclib seems due to a not official binary of kpack for Win32.

Genre embarrassed

48

Nice ! Very nice !

(just a little bug : "shut downn the flash" take only one 'n' #triutile#)

I test the transfert on real calc now ! Did you change anything to "install tib" ?

lol grin
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

49

Transfert sucessful, it boots normally. The auto-repeat feature works normally. Delays set by default seem to be ok. Is the cursor displayed each time it moves ? Or isn't it displayed if it's blinking and hasn't to be displayed, when moving ? Would it be possible to reinit its display tempo when it moves, to make it more visible ?

I reboot on Win and test the link with Ti-Connect now. smile

edit -> when starting Ti-Connect, I get the "Link : Command" twice, instead of the previous error.
Ti-Connect reports it has detected a TI89, but can't get its status.

-> when trying to get informations on the calc, PedroM throws errors : "Link format/reset/command".
-> the screen capture works
-> I can't broswe the calc from my PC, but the behavior seems better with this RC (calc detection, screen capture).
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

50

Folco (./49) :
Delays set by default seem to be ok. Is the cursor displayed each time it moves ? Or isn't it displayed if it's blinking and hasn't to be displayed, when moving ? Would it be possible to reinit its display tempo when it moves, to make it more visible ?

What do you mean?
Do you want to always display the cursor when there is the auto repeat feature?
Folco (./49) :
I reboot on Win and test the link with Ti-Connect now. smile.gif

What about tilp wink ?
Folco (./49) :
edit -> when starting Ti-Connect, I get the "Link : Command" twice, instead of the previous error. -> when trying to get information on the calc, PedroM throws errors : "Link format/reset/command".

Link: Command: TIConnect has sent an unrecognized command to PedroM (or there is some desyncho between the calc and the pc).
Link: Format: TiConnect has requested some variable name which are too long (> 8 bytes or > 17 bytes) in a REQ / VAR / RTS command. Strange... Someone has an idea?
Link: Reset: It means the calc has sent a Link error while in receive mode (Bit 7) so it resets the link. Try keeping your finger on the cable wink
Link MID : It means an unsupported calculator/pc try to connect to the calc.
Folco (./49) :
-> I can't broswe the calc from my PC, but the behavior seems better with this RC (calc detection, screen capture).

Does the same happen with tilp?
Does tilp still crash when you try to get a file from PedroM?

51

After checking again the link protocol, the following commands are not implemented by PedroM:
CID=2Dh Silent - Request Versions (VER) None fixed in RC6 --> To test.
CID=78h Continue (CONT) Seems to be used only by the calculator: won't be implemented.

CID=36h Skip/Exit (SKIP/EXIT) is broken : fixed in RC6 --> To test.

For the Var Header, the support of the local directory through 1Bh like 1Ah is unsupported, list content of a given folder (local dirlist) : fixed in RC6 --> To test.

52

PpHd (./50) :
What do you mean? Do you want to always display the cursor when there is the auto repeat feature?

Je la fais en français, c'est plus simple :
Le curseur est successivement allumé et éteint. Quand il défile (touche droite ou gauche), j'ai l'impression qu'il continue à respecter son cycle d'allumage/extinction. Ce qui fait qu'il n'est plus très visible, quand il défile et qu'il est en phase de non-affichage. A moind qu'il n'attende l'int 5 suivante pour être dessiné, ça doit être un de ces deux trucs-là qui se passe.

Dans mon éditeur de texte, je réinitialisais la temporisation quand le curseur bougeait, et j'imposais son dessin. Comme ça, il était très visible, même en défilant. Si dans ton cas, ça doit attendre l'int 5 suivante, on ne le verra pas si la répétition de touche intervient avant, ou alors que très peu. En tout cas, c'est ptêt pour ça qu'on le voit mal quand il défile.

Ca, c'est la boucle infinie, qui réinitialisait le curseur juste avant d'attendre un appui :
MainLoop:
	bsr	EnableCursor
	bsr	GetKey					|wait a key
	move.w	%d0,-(%sp)
	bsr	DisableCursor

Et là, on réinitialise les données du curseur en le dessinant systématiquement : on attend pas l'int5, qui normalement s'en charge, on lui dit juste que le curseur est déjà affiché :
|=======================================================
|	EnableCursor
|=======================================================
FunctionSection EnableCursor
	bsr	DrawCursor			|draw the cursor
	lea.l	CursorTimer,%a0
	move.w	#CURSOR_DEFAULT_TIMER,(%a0)	|set the timer
	lea.l	OptionsFlag1,%a0
	bset.b	#CURSOR.Status,(%a0)		|set it to "currently displayed"
	bset.b	#CURSOR.Enabled,(%a0)		|enable the auto-int
	rts					|and quit

Et ça marchait très bien, curseur toujours très visible.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

53

Folco (./52) :
PpHd (./50) :
What do you mean? Do you want to always display the cursor when there is the auto repeat feature?

Je la fais en français, c'est plus simple :
Le curseur est successivement allumé et éteint. Quand il défile (touche droite ou gauche), j'ai l'impression qu'il continue à respecter son cycle d'allumage/extinction. Ce qui fait qu'il n'est plus très visible, quand il défile et qu'il est en phase de non-affichage. A moind qu'il n'attende l'int 5 suivante pour être dessiné, ça doit être un de ces deux trucs-là qui se passe.

Dans mon éditeur de texte, je réinitialisais la temporisation quand le curseur bougeait, et j'imposais son dessin. Comme ça, il était très visible, même en défilant. Si dans ton cas, ça doit attendre l'int 5 suivante, on ne le verra pas si la répétition de touche intervient avant, ou alors que très peu. En tout cas, c'est ptêt pour ça qu'on le voit mal quand il défile.

Ca, c'est la boucle infinie, qui réinitialisait le curseur juste avant d'attendre un appui :
MainLoop:
	bsr	EnableCursor
	bsr	GetKey					|wait a key
	move.w	%d0,-(%sp)
	bsr	DisableCursor

Et là, on réinitialise les données du curseur en le dessinant systématiquement : on attend pas l'int5, qui normalement s'en charge, on lui dit juste que le curseur est déjà affiché :
|=======================================================
|	EnableCursor
|=======================================================
FunctionSection EnableCursor
	bsr	DrawCursor			|draw the cursor
	lea.l	CursorTimer,%a0
	move.w	#CURSOR_DEFAULT_TIMER,(%a0)	|set the timer
	lea.l	OptionsFlag1,%a0
	bset.b	#CURSOR.Status,(%a0)		|set it to "currently displayed"
	bset.b	#CURSOR.Enabled,(%a0)		|enable the auto-int
	rts					|and quit

Et ça marchait très bien, curseur toujours très visible.


Done and fixed in the released RC6. Keep going tester. I'll feed you! smile

54

Nice !!!
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

55

OS transfered and cursor feature tested : it's really nicer now ! Thanx. smile

The RC6 now seems to work well with TiLP : I haven't got any error when :
- transfering the OS
- browsing the calc
- sending it vars
- picked vars from the calc to the PC
- getting a screen shot

TiLP doesn't crash anymore, and PedroM doesn't report any error. I'll try tomorrow with Ti-Connect.

Good job !
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

56

Thanks.
Please try getting the rom & bios versions: it is a new command introduced in RC6.

57

Test with TiConnect :

Using TiDevice Informations : I get an error 'Link : Command', then TiConnect detects a titanium. When it tries to get info about the calc (HW, AMS, mem, BIOS version, device ID, language, batteries, ID list and installed applications), I get a 'Link : format'. No data are transmitted to the PC, TiConnect reports the error.

Using Ti-Device Explorer : my calc is always seen as a Titanium.
- Getting a screenshot works properly (without any error)
- folders are detected !
- no file are seen in the folder, but they really exist...
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

58


When it tries to get info about the calc (HW, AMS, mem, BIOS version, device ID, language, batteries, ID list and installed applications), I get a 'Link : format'. No data are transmitted to the PC, TiConnect reports the error.

Something seems broken in the implementation of the VER command. Don't know what...

Using Ti-Device Explorer : my calc is always seen as a Titanium.
- Getting a screenshot works properly (without any error)
- folders are detected !
- no file are seen in the folder, but they really exist...

Can you send some files to the calculator?

Could you open Const.h
and edit the constant into this:
DEBUG_LINK_COM		EQU	1


Rebuild it, send it, and reports what you get for each command (perform a clear command before).
Like :
Recv: 0892 0000 Send: 8856 0000 Send: 8809 0000 ...

59

PpHd (./58) :
(*) Rebuild it, (**) send it (*)

(*) + reboot
(**) + patch pedrom sources + (*) + freeflash + (*)

Ok, I do that. First, I try to send a file.
=> It works !
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !

60

Could you built it for me ? My build is sent in 10 seconds (4.1 kB/s ?!?!?), two passes seem sufficient, its very strange !?! It boots... but something goes wrong ... confus
My patches just change some $FFFFFFF[F|E] to avoid the 64b bug.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !