Yomgui

Je me suis amusé avec Python et le module PIL (python et les ''thirdparty'' sont disponibles pour MorphOS ici) à faire un script pour tester une moulinette qui me sort le waveform d'une image... c'est très utile en vidéo

Voilà la sortie du script pour une image d'exemple:

PS: non c'est pas une échographie de ma femme!

Bon alors je me suis couché tard (4h...) donc la lumière elle vient pas de moi là... ... Mais de ma pile Firewire Helios.

J'ai codé le mode isochrone, qui au passage n'aura pris que 2 jours, et fait un petit code de test pour charger des vidéos depuis une caméra supportant le protocole iec61883 et sortant en format HDV (MPEG2-TS) ou DV.

Et ça fonctionne !!!

Bon faut que je mette au propre un peu tout cela et je fais une release...

PS: ouai c'est pas très étoffé comme news, mais ZZZZzzzzzz

Quand ça va plus rond... il faut tout mettre au carré! Logique...

Version pre-alpha pour bêta-bouffons-testeurs bientôt disponible... Sur aminet

EDIT: Je rajoute une petite capture de FWInspector, l'interface graphique sous MUI pour montrer et faire quelques manipulations sur les devices connectés en FireWire.

Cliquez sur l'image pour voir en plus grand.

Oula que j'ai bien travaillé!

Helios est enfin stable depuis samedi (et même encore plus le dimanche :-D)!

C'est donc une étape majeur dans le dév, où j'ai d'abord préférer stabiliser les requêtes asynchrones vers les nodes et donc la gestion des réponses aussi.

Donc update dans le status depuis le billet suivant:

• Gestion des resets du bus et des packet SelfID: 100% pas vu de bug depuis.
• Envois de requêtes asynchrone: 92%, manque juste locker les buffers DMA pouvant être utilisés par les applications en attendant qu'elles lisent les données inscrites.
• Gestion ROM locale: 85%, je recode tout, depuis la processus de lecture dans la couche device. Il faut faire la lecture de la structure complète, pour l'instant je ne lis que le Bus Info Block. Définition de la ROM locale pas faite non plus.
• Couche devices: 90% fonctionnelle mais elle me plaît pas encore sur la façon dont elle dialogue avec les applications.
• API publique (SDK): 20% mais quelques changement à faire.
• Interface MUI de configuration et de status: 0% pour la config, mais j'ai commencé FWInspect, un petit outil pour voir et utiliser le bus.

Yomgui

Depuis longtemps attendue pour être ensuite abandonnée, car tuée sur l'hôtel des profits financiers (surtout ceux d'Intel) par ses créateurs, voici de retour la venue de la pile FireWire/IEEE1394/Lynx/i.Link_<inserer ici votre marque> spécialement pour notre OS préféré, le bien nommé MorphOS!

Voui, voui, voui, vous avez bien lu!

Si vous n'avez pas bien vu encore, j'ai eu 30 ans en août!
Hein ? C'est quoi le rapport ?? Comme vous le voyez sur mon billet d'anniv, j'ai eu une caméra vidéo au format DV (HDV même) et donc avec son petit port 1394...
Ouai c'est cool mais c'est pas du tout cool sous Window... la moindre application faisant correctement de la vidéo est payante, et encore ce sont des usines à gaz!

Guerre de choix s'offre donc à vous que d'avoir un bon vieux Mac (pas le cas pour moi et cela résous pas le problème du prix, oh non!) ou bien de pirater emprunter un soft à un ami pour finalement vous dire que ouai c'est vraiment une merde un casse tête pour travailler avec.

Bon, bah y a pas trop le choix et comme je le dis régulièrement on est jamais mieux servis que par soit même.

Donc la caméra c'était en août, le bilan pas très joyeux de l'existant c'était début septembre, le voyage au Canada (histoire de dire que l'achat en valait le coup) c'était fin septembre, donc le début du projet c'était fin septembre - début octobre.

Comme tout bon développement qui se commence, j'ai commencé par voir si cela n'était pas déjà en cours (cf le premier lien du billet). J'ai donc contacté Sonic qui a en premier tenté un port de la pile Linux (cf toujours le premier lien, décidément!). Malheureusement au vu du Firewire en 2006, abandonné par ses pères, il décida qu'il ne valait plus la peine (dixit Sonic, que j'ai eu par e-mail) de continuer. Fin de l'histoire.

Dommage pour les utilisateurs, cool pour moi (ouai enfin je me donne du taf de nuit en même temps...) je saute sur l'occasion et commence à réunir la documentation après avoir vérifié le chipset en place dans mes Peg1 et 2, un VIA VT6306 (ieee1394a-1995, 3 ports). Ce qui nous donne:

• la norme IEEE1394a-1995, ainsi que son amendement de 2000 (utile pour certaines explications sur les paquets du type Self-ID et la ROM) ;
• la norme OHCI1394 qui elle est une couche d'abstraction pour les concepteurs de chipset comme VIA et qui nous facilite les choses pour nous les concepteurs de drivers ;
• le datasheet du VT6303, utile pour le format des paquets de la couche PHY.

En même temps que je me prend un gros mal de crâne à lire tout cela en même temps, je passe un peu de temps sur l'implémentation sous Linux histoire de voir si j'ai bien compris les docs tordues peu triviales du Firewire.
Et zou passage au code début octobre en commençant par utiliser les nouveaux includes du SDK de MorphOS 2.x dont certains fichiers pas encore publiques quand j'écris ces lignes par ailleurs (lib PCIX pour remplacer openpci par exemple).
D'ailleurs j'avais jamais attaqué le PCI sur MorphOS, c'est tout de même bien ce projet

Nous voilà donc aujourd'hui (début décembre) et qu'en est-il?
Et bien après plus de 2 semaines sur un bug des plus crétin subtile, inventé par votre crétin de subtile serviteur, je gère complètement la modification temps-réel de la topologie du bus (connections/déconnections des devices)et quasiment le mode asynchrone en envoi-réception. Il me reste à:

• débuger le code de réception des acquittements des requêtes en transmission ;
• gérer complètement et correctement les paquets de types 'lock' et 'phy' (toujours en asynchrone) ;
• envoyer des paquets de réponses aux paquets de requêtes reçus ;
• terminer le code de la couche 'device' qui sera vue par l'utilisateur et par où il pourra les contrôler ;
• coder toute la partie isochrone, le mode le plus intéressant bien-sûr ;
• faire un petit 1394raw.device pour déjà s'amuser avec.

Vous l'aurez compris (comment ça non ?!) cette pile ne s'occupe que du transport de données entre les nœuds sur le bus 1394, le contrôle sera donc laisser au soins de bibliothèques en xxxxxxx.device (genre dv1394.device ou bien sbp2.device et même avc1394.device).
Si tout cela marche bien j'espère pas moins que sont intégration officielle dans MorphOS 2.x (3.x?) à l'instar de son homologue USB: Poseidon.

Voilà, voilà pour les nouvelles

PS: Je me disais bien que j'avais oublié quelque chose d'important: cette pile n'est pas un port, mais bien un truc développé sur et pour MorphOS!