180

Sorry, when we displayed the menu, we have lost the information that it was a folder. It is not an easy fix. I prefer not doing it for the 0.82 release.

181

Can't you test if the result is a folder after?
avatar

182

I can find some workaround but not at this point of the release.

183

Browsing the calc with AMS : tromb Fichier joint : 7tob (ticonnect.png)
Browsing the calc with PedroM : tromb Fichier joint : ec9s (explorer2.png)

184

Ok I lost.
Does someone have a little idea why it doesn't work?
Otherwise I'll have to release as if.

185

I get a strange behavior with more.

When I invoke "asti68k config", I get that : tromb Fichier joint : IJ3t (as000.png)

When I invoke "asti68k config | more", I get that : tromb Fichier joint : nH6e (as001.png)

The two upper lines are inverted !!! Perhaps I become mad fou (tested on TiEmu and real-calc)

ps -> perhaps PedroM and more are not faultly at all : Before getting that, this routine worked fine when executing it. When tracing it, I got an adress error... couic

I didn't change my code before and now, getting this problem with more... bang

186

Folco (./185) :

The two upper lines are inverted !!! Perhaps I become mad fou.gif (tested on TiEmu and real-calc)


Maybe one was stderr, the other one stdout?

187

Yes ! So its... normal ? Would it be a feature ? grin
I don't understand how my code is executed to echo the strings in a reversed order, I've looked for a bug a long time. cry

188

189

Folco (./187) :
Yes ! So its... normal ? Would it be a feature ? biggrin.gif
I don't understand how my code is executed to echo the strings in a reversed order, I've looked for a bug a long time. ouin.gif


Well stdout is buffered because it is displayed through the command more (due tot the pipe).
stderr is not.
squalyl (./188) :
asynchronous buffer management ? tripo.gif

pencil

190

I also have it in the Netbeans console. sometimes it becomes annoying too.

191

PedroM 0.82 RC11 has been released with the followinf changes:
Fix tmpnam
Make unlink delete all files, including archived files.
Some minor fixes for the link.
Add optional signing of the OS images using rabbitsign.
The OS images are signed.

You can't receive files using ticonnect, but you can send them. I don't know why you can't. I plan to release 0.82 with this limitation on the 1st of october, execpt if there are new problems found.

192

193

Good smile
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

194

Transfert successful, using TiLP and the "install tib" command !

Just a minor problem, PedroM boots before than TiLP seems having transfered the whole OS (the main progress bar is at ~90% ). So TiLP timeouts, but PedroM seems to run fine.

195

Successfully transferred PedroM 0.82 RC11 to a 89T running AMS 3.10 smile
Link cable: DirectLink.
Link software: TILP/libti* SVN, direct send by drag and drop in TILP. In other words, signature validation passed.

I will later attempt to transfer AMS 3.10 to PedroM 0.82 RC11.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

196

197

Lionel Debroux (./195) :
Successfully transferred PedroM 0.82 RC11 to a 89T running AMS 3.10 smile
Link cable: DirectLink.
Link software: TILP/libti* SVN, direct send by drag and drop in TILP. In other words, signature validation passed.

I will later attempt to transfer AMS 3.10 to PedroM 0.82 RC11.


Before sending back AMS 3.10, could you perform the software-hardware integration tests described in ./1 for the Ti-89 Titanium (It was only tested on 92+ HW1 and 89 HW2).

198

I'm not sure I'll have enough time to do that today, but I can try. smile
I had already transferred back AMS 3.10 (by using the boot code), and on one of my computers, I cannot make AMS 3.10 accept either AMS 3.10 or PedroM 0.82 RC11, no matter I'm using SVN HEAD or SVN HEAD patched with topics/123598-tilp2-crash-dans-la-reception-des-fichiers/3#85 . I have switched between the two multiple times to check.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

199

I'll edit this post each time I'm done with one of the steps of the process described in ./1.

[ul][li]Successful second transfer of PedroM 0.82 RC11 to AMS 3.10 using DirectLink, boot OK. My 89T is a HW4, BTW.[/li]
[li]Keyboard drivers OK. I noticed that the auto-repetition behaviour is slightly different from that of AMS 2.05 on 89 HW2 (auto-repeat works on PedroM 0.82 RC11 89T with alpha-lock on, it doesn't on AMS 2.05 89), but that would probably be a feature IMO.[/li]
[li]Turning the calculator off and back on works, and auto power down works.[/li]
[li]Variable tests OK (creation, archival, reset, erase, recovery), tests deeper than those of ./1.[/li]
[li]Battery indicator not tested, I don't have used AAA batteries for now. But ttbatt runs properly.[/li]
[li]Link tests: mostly OK. Archived files and unarchived files are correctly detected. TILP SVN refuses to delete a file because it didn't detect an AMS 2.09. We talked about that a bit at topics/123598-tilp2-crash-dans-la-reception-des-fichiers/5 , so either PedroM doesn't advertise itself as AMS 2.09, or TILP/libti* doesn't understand PedroM.[/li]
[li]Further link tests such as sending a group file taken from another calculator: failure with "Link: VAR" for files that were archived on the calculator they were received from. Editing the group file to remove those attributes makes it possible to transfer those files.[/li]
[li]running various uncompressed or compressed AMS native programs (some of them without startup code): OK. I could see that my 89 HW2 contains outdated binaries (e.g. an eBook Reader that doesn't support PedroM, several programs that don't support grayscale on 89T)[/li]
[li]computing 1000! in zs: OK[/li][/ul]
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

200

PedroM has no problem with being sent an unarchived ASM program (vartype = 0x21), but it doesn't like the exact same archived ASM program (vartype = 0x27).
The change in vartype value is due to send_var() in calc_89.c of libticalcs:
switch (entry->attr) 
{
	//case ATTRB_NONE:     vartype = TI89_BKUP; break;
	case ATTRB_LOCKED:   vartype = 0x26; break;
	case ATTRB_PROTECTED:
	case ATTRB_ARCHIVED: vartype = 0x27; break;
}

TRYF(ti89_send_RTS(entry->size, vartype, varname));



Looking at Link.asm in PedroM, PedroM doesn't like vartypes 0x26 and 0x27 simply because they aren't in the list of supported file types:
SupportedFileType_LIST:
	dc.w	4,6,$a,$b,$c,$d,$e,$10,$12,$13,$14,$1C,$21,0

(on a side note, these vartypes aren't documented in the LIO_CTX page)
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

201

Lionel Debroux (./200) :
PedroM has no problem with being sent an unarchived ASM program (vartype = 0x21), but it doesn't like the exact same archived ASM program (vartype = 0x27).
The change in vartype value is due to send_var() in calc_89.c of libticalcs:
switch (entry->attr) 
{
	//case ATTRB_NONE:     vartype = TI89_BKUP; break;
	case ATTRB_LOCKED:   vartype = 0x26; break;
	case ATTRB_PROTECTED:
	case ATTRB_ARCHIVED: vartype = 0x27; break;
}

TRYF(ti89_send_RTS(entry->size, vartype, varname));



Looking at Link.asm in PedroM, PedroM doesn't like vartypes 0x26 and 0x27 simply because they aren't in the list of supported file types:
SupportedFileType_LIST:
	dc.w	4,6,$a,$b,$c,$d,$e,$10,$12,$13,$14,$1C,$21,0

(on a side note, these vartypes aren't documented in the LIO_CTX page)


Ok sad
Where does this value come from? It isn't explained in gcc4ti manual, neithert in link protocol guide.
Lionel Debroux (./199) :
TILP SVN refuses to delete a file because it didn't detect an AMS 2.09. We talked about that a bit at topics/123598-tilp2-crash-dans-la-reception-des-fichiers/5 , so either PedroM doesn't advertise itself as AMS 2.09, or TILP/libti* doesn't understand PedroM.


I have gone back to this change since it didn't help for ti-connect. And I don't know if it is a good change (setting the clock isn't supported).

202

I don't know either where the 0x26 and 0x27 values come from. That is, besides Romain's analysis of what goes through the link port when TI-Connect does the same operation, of course grin

Git tells me that the original form of the code I reproduced in ./200 was introduced by Romain at r1116 ("TI89 & TI92 support imported. Small macro fixes in commands.") on Sat May 21 14:08:50 2005 +0000, and that the current form was committed by Romain at r1327 ("Clock support finished") on Tue Jul 5 15:42:00 2005 +0000.


0x26 and 0x27 take precedence over the real vartype of the variable (0x21 for an assembly program, etc.), which means that any proper PedroM support for those vartypes (even if you decide not to add variable locking and archiving code this late in the RC series) needs to perform tag -> vartype mapping (so as to be able to reject, e.g., archived GDB variables or geometry figures, which PedroM has no clue about).


The clock setting and getting code, in calc_89.c, is as follows:
static int		set_clock	(CalcHandle* handle, CalcClock* clock)
{
    uint8_t buffer[16] = { 0 };
    uint16_t status;

    buffer[6] = clock->year >> 8;
    buffer[7] = clock->year & 0x00ff;
    buffer[8] = clock->month;
    buffer[9] = clock->day;
    buffer[10] = clock->hours;
    buffer[11] = clock->minutes;
    buffer[12] = clock->seconds;
    buffer[13] = clock->date_format;
    buffer[14] = clock->time_format;
    buffer[15] = 0xff;

    g_snprintf(update_->text, sizeof(update_->text), _("Setting clock..."));
    update_label();

    TRYF(ti89_send_RTS(0x10, TI89_CLK, "Clock"));
    TRYF(ti89_recv_ACK(NULL));

    TRYF(ti89_recv_CTS());
    TRYF(ti89_send_ACK());

    TRYF(ti89_send_XDP(0x10, buffer));
    TRYF(ti89_recv_ACK(NULL));

    TRYF(ti89_send_EOT());
    TRYF(ti89_recv_ACK(&status));

	return 0;
}

static int		get_clock	(CalcHandle* handle, CalcClock* clock)
{
	uint32_t varsize;
    uint8_t vartype;
   char varname[9];
    uint8_t buffer[32];

    g_snprintf(update_->text, sizeof(update_->text), _("Getting clock..."));
    update_label();

    TRYF(ti89_send_REQ(0x0000, TI89_CLK, "Clock"));
    TRYF(ti89_recv_ACK(NULL));

    TRYF(ti89_recv_VAR(&varsize, &vartype, varname));
    TRYF(ti89_send_ACK());

    TRYF(ti89_send_CTS());
    TRYF(ti89_recv_ACK(NULL));

    TRYF(ti89_recv_XDP(&varsize, buffer));
    TRYF(ti89_send_ACK());

    TRYF(ti89_recv_EOT());
    TRYF(ti89_send_ACK());

    clock->year = (buffer[6] << 8) | buffer[7];
    clock->month = buffer[8];
    clock->day = buffer[9];
    clock->hours = buffer[10];
    clock->minutes = buffer[11];
    clock->seconds = buffer[12];
    clock->date_format = buffer[13];
    clock->time_format = buffer[14];

	return 0;
}


Have a good night wink
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

203

I have added the values 0x26 and 0x27.

PedroM 0.82 has been released. Thanks a lot for all your work!!!!

204

Great smile
Thanks for your work wink

I've posted the news on #tcpa, therefore chronomex (Duncan Smith) or tev (Travis Evans) will probably pick it up for ticalc.org. But if you haven't already done it, you should send them a notice smile
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

205

Well I have sent a mail to ticalc. But I failed to upload the new archive: I get an error "Failed to parse file"...

206

PpHd (./203) :
PedroM 0.82 has been released.

Congratulations ! \o/

207

Several days ago, I have transferred PedroM 0.82 to my 89T HW4, and I'm playing with it a bit.
In MAY (the zs interpreter, I mean), I've tried to execute "1000!" and then "2000!". Computing 1000! works properly, but 2000! crashes the calculator (Protected Memory Violation).
I've talked about the problem with Folco, and he confirms the bug, on his real 89 HW2.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

208

After the crash, I get that :
:>mem
RAM Free: 001204
Flash ROM Free: 1441792

:>zs
$1000!
FATAL -- Base:03f892 Top:03fcde Used:1100 MaxUsed:1100 Max:1184
Exception 2 caught: Memory

:> clean
Free 1 handle(s)

:> mem
RAM Free: 226492
Flash ROM Free: 1441792

Then, it works again.

209

Lionel Debroux (./207) :
In MAY (the zs interpreter, I mean), I've tried to execute "1000!" and then "2000!". Computing 1000! works properly, but 2000! crashes the calculator (Protected Memory Violation).


For 1000!, there is no reached memory limit.
For 2000!, the first reached limit is the stack overflow (And zs doesn't handle such exception).
Note that huge stack overflow can not be detected...
Folco (./208) :
Then, it works again.

As usual after a crash.
In this case, the first reached limit is the available heap memory.
After the clean command, everything go back to normal.
I have discussed with you an option to auto execute clean command after a crash.

210

PpHd (./209) :
Note that huge stack overflow can not be detected...

It can be detected if the code is done properly. Either use NeedStack or allocate stack in smaller pieces with writes at each step or check before writing that you aren't out in nowhere's land. But of course this assumes actually coding for the target platform, not just recompiling libraries designed for a computer with megabytes of stack.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité