Au secours! - Page 1

Je me suis deja fait la meme reflexion en lisant le readme
Mais j'ai pas d'explications ^^'

(le 09/18 ça n'existe pas de toute façon, donc c'est forcément une erreur indépendamment de l'autre fichier ^^)

Si, le 09/18 existe, c'est le 18 septembre.
Le problème là, c'est que PedroM ne compile pas sans un A68k patché.
Tu devrais avoir plus de succès avec pedrom-ld-tigcc (cf. sources de TiEmu), mais il y a des problèmes de casse des fichiers dans le makefile. (J'avais testé ça sur un système de fichiers insensitif à la casse à l'époque.)

Martial Demolins (./1) :
PpHd avait anticipé la sortie de PreOS par rapport à ma lecture de ce texte ?!?

Ben oui. Comme je développe les deux, j'ai pu anticipé l'un pour l'autre.

Kevin Kofler (./6) :
Tu devrais avoir plus de succès avec pedrom-ld-tigcc (cf. sources de TiEmu), mais il y a des problèmes de casse des fichiers dans le makefile.

Je pense pas. Je buld sur un système sensible à la casse.
Seulement dans les premières versions (0.80).

Martial Demolins (./7) :
Sinon, ça serait bien de mettre PedroM en svn, non?

Il est déjà sous CVS (non disponible au public).

Martial Demolins (./4) :
Sauf là, je sèche :

Comme dit il faut que tu recompiles a68k (car KK a refusé mon patch) en modifiant un fichier:

--- A68kdef.h~  2006-07-27 19:26:36.000000000 +0200
+++ A68kdef.h   2007-12-17 07:27:00.000000000 +0100
@@ -107,7 +107,7 @@
 #if 1 /* Same settings for all platforms -- Kevin Kofler, v.2.71.F3s */
 /*defined(WIN32)||defined(__linux__)*/ /* (TIGCC) no need to save memory under Win32 */
 /* no need to save memory under GNU/Linux either (Kevin Kofler, v.2.71.F3c) */
-#define MAXLINE   256  /* Longest source line
+#define MAXLINE   65536        /* Longest source line
                            Increased by Paul Froissart */
 #define MAXFN     259  /* Maximum length of file name
                            Increased by Kevin Kofler */

Sally (./5) :
(le 09/18 ça n'existe pas de toute façon, donc c'est forcément une erreur indépendamment de l'autre fichier ^^)

C'est le 18/09 en francais

PpHd (./8) :
Je pense pas. Je buld sur un système sensible à la casse.

Je sais, c'est mon patch ld-tigcc qui est foireux, pas ton makefile original.

car KK a refusé mon patch

Parce que ta méthode ne marche de toute façon pas avec le target FlashOS de ld-tigcc, que TIGCC ne permet pas les programmes hors FlashOS de 65536 octets, que pour tout ce qui n'est pas FlashOS, il est impossible de garantir un alignement de plus de 2 octets et que le hack o2tib n'est pas supporté.

Kevin Kofler (./10) :
Parce que ta méthode ne marche de toute façon pas avec le target FlashOS de ld-tigcc, que TIGCC ne permet pas les programmes hors FlashOS de 65536 octets, que pour tout ce qui n'est pas FlashOS, il est impossible de garantir un alignement de plus de 2 octets et que le hack o2tib n'est pas supporté.

De toute façon, maintenant, je n'en ai cure, et j'attends autre chose

D'ailleurs, vous êtes 2 à l'attendre, l'auteur de Punix m'a demandé la même fonctionnalité.
Il faut dire que je suis très occupé actuellement avec KDE 4 dans Rawhide.

'tain, faudrait que je prenne quelques heures pour finir et contribuer ce patch de génération d'un timestamp valide pour les OS non officiels (au lieu de 01 02 03 04 05 06)...

ah oui ça serait cool ça

Mais pour quoi faire? Ce timestamp n'est affiché nulle part.

Ce timestamp n'est effectivement affiché nulle part.
J'imagine que c'est pour avoir des OS non officiels qui ressemblent un peu plus à des OS officiels. Pour avoir un timestamp qui soit en accord avec ReleaseDate, si l'OS l'implémente, aussi...

(Tu étais contre ce patch, à l'époque ?)

Je ne suis pas contre, mais je ne vois pas trop l'intérêt.

au moins en interne pour se rappeler quand on a pondu une version particulière

Bonne chance pour déchiffrer le format de timestamps de TI...

faudra un lecteur

> Bonne chance pour déchiffrer le format de timestamps de TI...
Le nombre de secondes depuis le 1er janvier 1997, 0h00m0s n'est ni difficile à générer ni à déchiffrer
Les derniers AMS 2.xx (2.03+ ou 2.04+, je ne sais plus) ont un ROM_CALL pour ça. Ma calculette contient depuis longtemps un programme de 389 octets qui utilise ce ROM_CALL pour interpréter comme nombre de secondes depuis le 1er janvier 1997, 0h00m00s, l'entier qu'on lui passe en argument

Quant à le trouver dans un dump d'AMS: il est dans les infos à ROM_base + 0x12000. C'est le field 0x320, sous-field 0900. Pour ça aussi, il y a un ROM_CALL.
Pour AMS 2.05, ce bloc d'octets est 03 26 09 04 06 99 B9 E2. Son décodage donne "07/05/2000, 16h31m30s" (date au format inversé par rapport au format français, parce qu'il me semble que j'ai utilisé les ROM_CALLs qui impriment une date sous forme localisée).

Bah, pour le générer, il faudra bien distinguer entre les OS qui gèrent gettimeofday et l'OS (devine lequel ) qui utilise une API propriétaire à la place.

Pas de problème, je demanderai éventuellement à mon binôme de M2 de me faire la version Windows

A priori, il suffit d'utiliser ça:
http://svn.tilp.info/cgi-bin/viewcvs.cgi/tiemu/trunk/src/misc/gettimeofday.h?rev=2559&root=tiemu&view=markup
http://svn.tilp.info/cgi-bin/viewcvs.cgi/tiemu/trunk/src/misc/gettimeofday_win32_impl.h?rev=2557&root=tiemu&view=markup (C'est un .h dans TiEmu parce que c'est compilé à des endroits différents dans la version GDB et no-GDB.)

(ah oui c'est pas super dur en fait... )

./25: OK, merci

Rien à voir mais ca serait bien de mettre www.yaronet.com/t3 au lieu de http://www.timetoteam.fr.st désormais.