Panne du côté de la Compact Flash, très difficile à lire (et écrire), puis d’accès impossible. La CF est lisible depuis une autre machine (macOS avec lecteur en USB). Ce qui rend la FireBee presque inutilisable. L’accès SD card fonctionne toujours, mais la lenteur empêche de « travailler » normalement avec la machine.

Continuer la lecture de So long, and thanks for all the fun →

Petits tracas ces derniers temps, la langue du clavier est perdue, le boot n’est plus en noir et blanc, donc lent. La batterie lithium bleue n’est plus en mesure de conserver les paramétrages dans la NVRAM.
Bien qu’il soit possible de « remplacer NVM » dans le CPX qui va bien, ça ne me satisfait pas.
La boutique AG Electronic ne propose plus le modèle 18650 2200mAh, mais me conseille une compatible à 2600 mAh, ainsi qu’un berceau pour cette pile. La vendeuse déconseille la soudure sur ce type de batterie, tout à fait d’accord.

Continuer la lecture de Recharge →

Le moniteur HP2211x était plus ou moins la cause de problèmes suivants :
– impossibilité d’avoir la résolution native, maximum de 1920*1080px (polarité non gérée, probablement un bogue dans le FPGA de la FireBee).
– impossibilité d’upgrader MiNT et XaAES (combinaison malheureuse entre FireTOS + MiNT (sans XaAES) et du moniteur). On n’obtenait rien d’autre que le 640*640px, problème de détection par le moniteur ? Alors que sur le Sony 19″, l’affichage était OK.

Du coup, profitant de l’expérience d’autres utilisateurs, et de l’examen minutieux du catalogue de www.ldlc.com (coucou BouB !), le remplacement a été fait. Et on a grandement gagné au change avec ce Philips 22″ LED – 220S4LCB.

La résolution native de 1680*1050px est acceptée et affichée, sans bogue de polarité. MiNT et XaAES ont pu enfin être upgradés. Voir la capture d’écran ci-dessous. J’avoue qu’avoir autant de place pour étaler son code GFA assez jouïssif. Et pas de ralentissement par rapport à l’ancien 1366*768px en TC32 bits (on est pas sur Falcon où la vidéo bouffe la bande passante au détriment du processeur).

Bref, que du bonheur. Je ne saurais que conseiller ce modèle de moniteur à tout nouveau possesseur de la Bee.

De mémoire, car l’article originel a été perdu lors du dernier plantage du serveur mysql de mon fournisseur d’accès à internet. Suite aux problèmes à répétitions chez SFR (le php qui rame et balance des erreurs 500, et personne en été pour récupérer correctement mysql…), j’ai finalement déménagé chez un vrai fournisseur d’hébergement.

Avant de reprendre le torchage du Troll avec entre autres le support de l’IMAP4, quelques mots sur ma pitite abeille…
– Toujours capot retiré, carte mère à l’air libre. Voir les LEDs clignoter ou pas s’avère assez pratique. Elles ont toutes une signification. En plein travail et canicule, un doigt sur le ColdFire ou sur le FPGA : les puces sont brûlantes. Mais le système tient bon. Pas de plantage. En fait, c’est très stable, et il faut que je code comme un cochon pour que MiNT crashe ou que la LED orange ne batte plus la cadence.
– Le FireTOS a été mis à jour, avec une correction pour mes jeux ; les fonctions vro/vrt_cpyfm() utilisaient le DMA sans attendre un signal de fin avant d’être réappelée. Du coup les rasters apposés en rafale ne se dessinaient pas correctement. Là, corrigé, et il n’y a plus à désactiver le DMA dans le FireTOS.cpx pour que l’affichage soit correct. Autre plus notable, le mode monochrome. Et l’on peut booter avec. Cela améliore la vitesse de démarrage de façon assez spectaculaire et tant pis pour l’icône couleur du début. Adopté !
– Aniplayer est sorti officiellement pour les utilisateurs de la FireBee. Avec un patch récent sorti ce 16 Août ; le bogue alerte en boucle si le mp3 ne peut pas être chargé a disparu. Quel plaisir d’écouter les mp3 d’AmigaRemixes. Le programme a l’air plus efficace et optimisé pour lire les mp3 que mxPlay, mais moins tolérant sur certains fichiers. J’ai par ailleurs retesté mes anciennes vidéos de pr0n que j’avais réencodées pour le Falcon+Eclipse ATI RageIIc… De quoi donner l’envie de procréer à un panda.
– Un test de Inshape (Demo) est concluant. Les objets 3D en mode filaire s’affichent très rapidement en TC32. Quelques problèmes de clipping sur les traits côté gauche, mais je suppose que ça vient de la vétusté de la version de démo.
– Finalement, je suis passé en TC32 pour le mode vidéo. C’est tout aussi agréable niveau vitesse d’affichage et les dégradés du fond d’écran ne sont plus massacrés. J’aimerais bien qu’une nouvelle version du FPGA sorte pour corriger le problème de détection du moniteur, et obtenir finalement le 1920*1080, mais on est déjà assez à l’aise avec le 1366*768 (voir les captures d’écran sur un autre billet).

Bon, c’est pas tout, mais il y a du code à pondre…

Petite pause ce week-end…

C’est toujours plus facile en mode (grosse) passive.
Appeler MiNTnet est relativement simple en tant que client pur tcp/ip, qui correspond au mode de transfert ftp passif. C’est assez compliqué en tant que serveur tcp/ip, utilisé pour le mode de transfert ftp actif. Nouvelle séance nocturne pour faire choux blanc. On y arrive le lendemain, après une bonne nuit de sommeil. Et cela dépote toujours aussi rapide.
Donc ce soir, possible lâché public du Litchi, si je n’attends pas les corrections du RSC et HYP de mon traducteur de la version allemande.

Sinon, quelques réflexions et recommandations cette semaine…

Juice

Le petit transfo qui était utilisé, provenant d’un disque dur externe, a été remplacé par un transfo dédié et flambant neuf. Acheté dans une boutique d’électronique et sans trop regarder le prix. La nouvelle fait 24V-3A, et après deux semaines, la FireBee est plus à l’aise avec. L’ancienne faisait du 12V-3A avec un diamètre lègèrement en dessous de 5mm. Maintenant, la clef USB a sa petite LED qui clignote lors des écritures, et il n’y a plus à reconnecter parfois la souris USB pour la faire reconnaître complètement par le système. Bref, préférez donc directement 24V-3A, cela vaut mieux pour les périphériques USB. D’autant que le clavier MegaST et la souris Atari sont aussi alimentés par la FireBee.
Je pense aussi que la batterie devait souffrir un peu avec l’ancien transfo. Je n’ai pas eu de recharge/cycle complet, donc pas possible pour l’instant de savoir si les grésillements et chauffe seront de mise la prochaine fois.

Caliente

Puisque l’on parle chaleur, je trouve plus pratique de laisser l’ordinateur sans capot. D’une part pour voir certaines LEDs indiquer le bon fonctionnement (surtout celle orange entre le ColdFire et le FPGA, pratique pour savoir si le reset se passe bien), et d’autre part pour évacuer les calories. Les composants produisant du chaud sont tous d’un côté ou de l’autre : batterie et condensateur, ColdFire et FPGA et nombreux autres. L’on pose le doigt sur ces derniers, en plein fonctionnement, et l’on sent cette chaleur. Chaud mais pas brûlant, on peut laisser son doigt des heures durant dessus. Lorsqu’on ferme le boitier, l’on sent au bout de quelques minutes que le capot côté composants devient tiède : la chaleur est mal évacuée. Les fentes au dessus du lecteur de SD-card ne suffisent apparemment pas. Et l’on se demande si cela peut gêner le bon fonctionnement.
Lorsqu’on voit que le 060 a besoin d’un radiateur et d’un ventilateur pour éviter que cela bogue, l’on voudrait par précaution rajouter au moins un radiateur sur le ColdFire et FPGA. Or, ce n’est pas la même génération ni même conception de composants. Changement de paradigme again. Lorsqu’on a vécu avec des processeurs et des architectures Atari qui n’ont pas changé depuis des décennies, c’est encore un peu dur au cerveau d’accepter ce big leap.

Purée de neurones

Prochaine étape : updater KK Commander, et refaire le DEFLATE.LDG avec des versions vraiment compilées pour 68K, 020-060, et pur CFv4e. Du vrai C avec une vraie cible ColdFire, quoi, et non pas du GFA 68K juste patché pour CF. En essayant de compiler directement sur le FireBee avec les objets zlib.a de Vincent Rivière, et non plus en cross-compilation avec Xcode/Mac et les sources zlib.

On va faire rapide cette semaine…

Pas le temps d’épancher mes réflexions sur le web cette fois-ci. Ce qui me reste de neurones à la quarantaine est focalisé durant le temps dit « libre » à l’upgrade de mon client ftp nommé Litchi. Client utilisant la couche tcp/ip STinG qui est adaptée aux faibles configurations, au TOS et à MagiC.

C’est un miracle qu’il fonctionne d’emblée et sans recompilation sur FireBee, sous MiNT, MiNTnet et Gluestick (qui assure la traduction des appels STinG en MiNTnet). Mais j’ai noté des erreurs de transferts. En examinant les sources de Gluestick vient la compréhension d’un blocage à la connexion et la suspicion de bogues si le débit et les tailles de morceaux à transférer augmentent.

C’est qu’avec la petite abeille, on a changé de paradigme. Du coup, je me fais une nuit presque blanche ce samedi (dodo à 6h du matin, juste dire à Môman, « oui j’ai dormi ») pour implémenter des appels direct à la couche tcp/ip MiNTnet. Lonny Pursell (encore lui, et encore merci) a fait un exemple et les gars de la MiNT Mailing-List ont été assez informatifs.

Surprise de la vie, je pensais ne jamais, ô grand jamais, avoir à pondre ça.

Ce soir, donc, utilisation directe de MiNTnet sous MiNT. Je vous rassure, STinG est utilisé si TOS ou MagiC. On a encore besoin de Gluestick, mais il ne sert plus qu’à détecter le cookie et sa fonction resolver (traduire les noms de domaine en adresse IP).

J’ai encore à peaufiner et tester. Cela dépend de la taille des fichiers, mais on peut atteindre avec Litchi 1.2 sur FireBee :
– en upload : 1200 KB/s
– en download : 500 KB/s
Bref, ça dépote bien. Utiliser MiNTnet permet un très gros gain en vitesse (et sécurisation). Cela change des 6-7 KB/s sur mon MegaST4 et son EtherNEC.

Reste des fichiers qui bloquent en download, cause originelle de mon étude. J’en viens à me demander si mon AirPort Express de 2004 est pas un peu vieille pour le wifi. Je teste en effet sur les serveurs ftp de mes Mac. Il faudra que j’essaye en ethernet pur avec FileZille FTP Server d’un PC.

Où les tracasseries de la semaine dernière sont oubliées, et où l’on s’installe dans la routine industrieuse…

GFA mon amour

Quand on dit love, il faut penser aussi hate. Si le GFA était adapté au ST, sa simplicité et sa rapidité est à double tranchant. Les bidouilles internes au GFA ne sont plus tolérées au fur et à mesure de l’évolution des machines et des systèmes. On passe le cap en nettoyant le code, en remplaçant les instructions plantogènes par des appels légaux et propres au système d’exploitation. Et en utilisant les librairies patchées. Sont venues celles patchées pour MagiC, puis d’autres, et maintenant pour ColdFire V4e. Merci à Lonny Pursell.
Attention, le code généré ne marche qu’avec le ColdFire, et nécessite toujours l’émulation 68000. Ceci pour éviter un problème de pile (stack) sur certaines instructions. Séances de débogages donc, sur l’ensemble de ma logithèque. Vous aurez constaté que les jeux et jouets sont actualisés, avec quelques défauts mineurs (problème de masques localisé dans la VDI utilisée pour le Videl de la FireBee). Le travail est surtout ennuyeux au niveau de la création des archives déposées sur ce site : il y avait celles pour chaque langue, en plus des sources. Il faut maintenant multiplier par deux, avec la version classique 68K et celle ColdFire. Le travail de débogage et code est par contre des plus plaisants ; l’éditeur GBE a été adopté, la rapidité de la FireBee en plus de la convivialité du bureau permet de tester le résultat après quelques secondes de compilation.
Alors qu’avant, il fallait quelques minutes sur le MegaST, puis transférer par FTP sur le Falcon, puis tester.

Heureusement que la librarie est patchée, car je ne me vois pas recoder toute ma logithèque en C pour l’occasion. Donc so far, so good. Viennent maintenant les applications « sérieuses ». Et l’on pense aux évolutions à implémenter. Pas de spoilers, mais il y a du code à pondre. Beaucoup de code.

Divine surprise

Pas possible pour l’instant d’écouter des MP3 d’AmigaRemix avec Aniplayer. Certaines personnes ont pu tester, sans doute avec une version officieuse. En attendant, PaulaNG et son MOD.LDG rejoue sans plantage les anciens modules Amiga de l’ancien disque dur de mon Falcon : Cherry Coke, Blueberry, Sleepwalk… Séquence souvenirs.