WebAssembly : programmer en assembleur dans une page Web

SoC,
Qui programme en assembleur de nos jours ? Plus qu'il n'y paraît en fait, si l'on veut bien considérer qu'avec WebAssembly - Wasm pour les intimes -, il est devenu possible d'écrire des programmes dans un langage qui s'en approche, et de les exécuter dans le contexte d'une page Web.
Wasm, un assembleur pour le Web
L'intérêt ? Des performances annoncées de très loin supérieures à celle de tout code JavaScript, aussi optimisé qu'il soit, sans perdre le bénéfice d'une intégration parfaite dans l'environnement d'exécution d'une page Web, c'est-à-dire en pouvant facilement accéder à des données et à des sous-programmes Wasm depuis du code JavaScript, mais aussi faire l'inverse.
Comment écrire en Wasm ? Comment exécuter du Wasm dans une page Web ? Et comment dialoguer entre Wasm et JavaScript ? Tout cela et plus encore dans ce qui suit...
Mise à jour du 21/12/2018 : Rajout d'un encadré pour remercier Dan Gohman, l'auteur du WebAssembly Reference Manual.
Mise à jour du 18/12/2018 : Mention à une représentation intelligible de la syntaxe d'un module, finalement trouvée (en creusant profond) ici.
Mise à jour du 17/12/2018 : Correction de petits bogues dans importExportMemory.zip.
Mise à jour du 16/12/2018 : Ajout d'une section liminaire "WebAssembly, c'est quoi ?", et d'une conclusion "WebAssembly en vaut-il la peine ?".
Continuer la lecture de "WebAssembly : programmer en assembleur dans une page Web" →
WebAssembly : programmer en assembleur dans une page Web

Développer pour Android sous Windows sans IDE (notamment sans Android Studio !)

SoC
Le moins qu'on puisse en dire, c'est qu'Android Studio n'est pas du genre léger. Sans doute, cet IDE est très complet, et il faut être reconnaissant à Google de le mettre gratuitement à disposition des développeurs, mais il requiert beaucoup de ressources pour fonctionner, et peut en conséquence se révèler très lent à l'usage.
Un canon pour tuer les mouches ? Ce serait bien dans l'air du temps. Comme l'explique avec beaucoup d('im)pertinence Bryan Lundunke dans programmers_are_evil(), "Everyone writing code is writing code that is getting exponentially larger and slower".
Partant, on peut se demander si Android Studio, c'est le bon choix pour commencer à développer des apps pour Android.
La question se pose d'autant plus que l'IDE masque nombre d'opérations dont la connaissance paraît essentielle pour que le développeur puisse comprendre ce qu'il est en train de faire. De manière un peu réductrice, mais qui n'est donc pas si éloignée de la réalité, l'IDE n'est qu'une IHM qui appelle des outils en ligne de commande pour faire tout ce qui dépasse l'édition de code. Se donner la peine de regarder sous le capot, c'est non seulement se ménager l'opportunité de pouvoir se débrouiller en cas de panne, mais aussi celle de gagner beaucoup de temps pour réaliser certains opérations.
Reste à savoir comment procéder, car pour la jouer roots, force est de constater que Google ne simplifie pas la tâche... Explications pour qui souhaiterait se lancer aujourd'hui même dans le développement d'apps pour Android.
Continuer la lecture de "Développer pour Android sous Windows sans IDE (notamment sans Android Studio !)" →
Développer pour Android sous Windows sans IDE (notamment sans Android Studio !)

Scoopex « TWO » : Le coding-of d’une cracktro sur Amiga 500

SoC, , ,
Et voilà ! On promet que c'est le dernier pour la route, et on s'en remet un malgré tout. Difficile de décrocher de la programmation en assembleur du hardware vidéo de l'Amiga 500, tant que la connaissance de ce dernier semble à parfaire, qu'il se trouve des FX à créer ou, plus modestement, à reproduire.
Un quart de siècle après la "dernière", trinquons donc encore ensemble avec Scoopex "TWO", cracktro codée en 2018 en guise d'appetizer pour le portage du jeu Starquake par Galahad du glorieux groupe Scoopex.
Scoopex "TWO" : Une cracktro pour A500 en 2018
Au menu : BOBs qui bougent, printer qui affiche, et rotozoom qui tourne. Et comme toujours, quelques leçons de portée plus générale que le sujet initial ne semblerait offrir l'opportunité d'en dispenser.
Mise à jour du 22/11/2018 : Optimisation du code JavaScript du rotozoom pour le mettre à disposition de l'auteur du portage de la cractro en HTML5 sur Flashtro.
Mise à jour du 19/11/2018 : Ajout d'un encadré (un peu long, mais me semble-t-il intéressant) sur l'enjeu pour l'authenticité que soulève l'émulation d'un jeu.
Mise à jour du 18/11/2018 : Cliquez ici pour télécharger copperScreen.s, un programme qui permet de générer un écran au Copper de n'importe quelle hauteur à n'importe quelle position verticale.
Mise à jour du 17/11/2018 : En complément, une vidéo de la cracktro est disponible sur YouTube. Par ailleurs Galahad raconte l'intéressant making-of du portage du jeu dans un fil de l'English Amiga Bord.
Continuer la lecture de "Scoopex « TWO » : Le coding-of d’une cracktro sur Amiga 500" →
Scoopex « TWO » : Le coding-of d’une cracktro sur Amiga 500

Un traceroute roots en Python avec Scapy

SoC, ,
Scapy est un package de Python bien connu dans le monde du hacking. Il permet d'interagir à bas niveau avec une interface réseau, c'est-à-dire de déterminer les octets qu'elle émet et de récupérer ceux qu'elle reçoit.
Scapy peut donc notamment être utilisé pour forger des trames et/ou paquets sur un réseau. Cela peut permettre de se livrer à des activités que la morale réprouve, comme l'ARP cache poisoning et autres joyeusetés. A l'inverse, comme nous le recommanderons, cela peut permettre de s'adonner à des activités tout à fait respectables, comme le diagnostic.
Scapy, pour sniffer, spoofer et autres
Dans tous les cas, se mettre à Scapy permet de se former au fonctionnement de réseaux en commençant par là où il faut commencer chaque fois qu'on prétend réellement apprendre quelque chose dans quel que domaine, c'est-à-dire à la base. C'est cette finalité pédagogique que poursuit cet article, à l'attention de tous ceux qui n'ont jamais mis le nez dans le réseau. Il présente comment réaliser une version simplifiée d'un outil qui figure inévitablement dans la boite à outils de tout hacker, à savoir traceroute.
Continuer la lecture de "Un traceroute roots en Python avec Scapy" →
Un traceroute roots en Python avec Scapy

Zoom hardware avec BPLxMOD et BPLCON1 sur Amiga

SoC, , ,
Le choc de l'arrivée de la Super Nintendo fin 1991 pour les amateurs de micros 16 bits, ce fut le Mode 7. La console était capable d'appliquer une rotation et un redimensionnement à un bitmap de grande taille dans la trame, et il était possible de trafiquer pour produire un effet de perspective.
L'Amiga 500 était doublement handicapé pour parvenir à produire de tels effets : pas de circuit spécialisé pour cela, et une organisation des données affichées sous forme de bitplanes exigeant, pour y parvenir, de nombreuses opérations au CPU et/ou au Blitter. Toutefois, cela n'empêcha pas certains de produire des effets du genre, par exemple le zoom au démarrage de la démo World of Commodore 92 de Sanity :
Zoom dans la démo World of Commodore 92 de Sanity
Parmi tous ces effets de zoom avec ou sans perspective, la plupart se sont appuyés sur le zoom vertical hardware, découvert dès les débuts de l'Amiga, et certains sur le zoom horizontal hardware, qui l'a été bien plus tard.
Comment procéder à l'un et l'autre de ces zooms avec le hardware ? En particulier, quel est ce fameux "$102 trick" régulièrement évoqué dans les forums de demomakers, souvent succinctement, et parfois abusivement ? Et dans quelle mesure est-il possible de zoomer ainsi ? Tout cela et plus encore dans ce qui suit.
Mise à jour du 11/09/2018 (matin) : Correction de la figure représentant le scénario du zoom horizontal hardware (une étape de trop!) et de la "magic table" (bogue dans le programme HTML5 générateur!).
Mise à jour du 11/09/2018 (soir) : Ajout d'un paragraphe et d'une figure pour expliquer pourquoi le zoom horizontal hardware limite à 4 le nombre de bitplanes.
Mise à jour du 12/09/2018 (matin) : Modification de la fin de la section sur le passage de la dissimulation à la suppression, pour expliquer pourquoi et comment il faut optimiser.
Mise à jour du 01/10/2018 : Tous les sources ont été modifiés pour intégrer une section "StingRay's stuff" qui permet d'assurer le bon fonctionnement sur tous les modèles d'Amiga, notamment dotés d'une carte graphique.
Continuer la lecture de "Zoom hardware avec BPLxMOD et BPLCON1 sur Amiga" →
Zoom hardware avec BPLxMOD et BPLCON1 sur Amiga

Quelques routines en assembleur pour demomaker sur Amiga

SoC,
Celui qui débute dans la programmation du hardware de l'Amiga en assembleur MC68000 se gratte souvent la tête pour exécuter des fonctions basiques : charger et afficher une image, lire les touches du clavier, etc.
Le fameux "KingTut.iff" de Deluxe Paint
"King Tut", le fichier IFF ILBM par excellence, dessiné par Avril Harrison en 1986 pour Deluxe Paint. © Electronic Arts.
Pour lui simplifier la tâche, cette page met à disposition le source de routines couvrant de telles tâches, qu'on a voulu abordables en se limitant au strict minimum.
Pour l'heure, on trouvera les sources des routines suivantes... :
Pour assembler ce code avec ASM-One, il est nécessaire de disposer de ce fichier qui contient la liste des offsets des registres du hardware.
L'article sera enrichi au fil des réalisations. Ces mises à jour seront signalées.
Mise à jour du 19/08/2018 : Correction d'un bogue dans l'interprétation de la valeur retournée par Read () dans IFF.s.
Mise à jour du 02/10/2018 : Tous les sources ont été modifiés pour intégrer une section "StingRay's stuff" qui permet d'assurer le bon fonctionnement sur tous les modèles d'Amiga, notamment dotés d'une carte graphique.
Mise à jour du 13/10/2018 : Correction d'un bogue dans le code attendant qu'il s'écoule deux lignes rasters pour acquitter l'interruption du CIA.
Continuer la lecture de "Quelques routines en assembleur pour demomaker sur Amiga" →
Quelques routines en assembleur pour demomaker sur Amiga

Afficher des sprites et des BOBs sur Amiga OCS et AGA (2/2)

SoC, , ,
Cet article est le second – et donc dernier – d'une série de deux consacrée à l'affichage de bitmaps sur Amiga. Dans le premier article, nous avons exploré dans le détail les sprites du hardware. A cette occasion, il est apparu que les sprites sont comme les hobbits : pratiques et colorés, mais petits et peu nombreux. Et même si le hardware permet d'en démultiplier apparemment le nombre en les découpant ou en les répétant, recourir à ces astuces reste assez contraignant.
C'est pourquoi une autre solution a souvent été préférée pour afficher des bitmaps : les BOBs. Le BOB est un bitmap affiché à l'aide du Blitter, le coprocesseur dont la fonctionnalité la plus notoire est la copie des données d'une ou plusieurs zones de mémoire vers une autre.
Des vector balls (avec quelques droites pour mieux constater la 3D)
Comment afficher un BOB ? Et ne faut-il pas alors assurer soi-même toutes ces tâches qui étaient prises en charge automatiquement par le hardware s'agissant de sprites : transparence, recover, clipping, détection de collisions, etc ? Tout cela et plus encore dans ce qui suit.
Mise à jour du 05/08/2018 : Précision apportée sur la nécessité d'utiliser b (l'inverse du masque) et non B (le masque) comme source dans la combinaison logique utilisée par le Blitter.
Mise à jour du 11/08/2018 : Ajout de perfectBob.s dans l'archive, une version améliorée de bobRAWB.s où la partie rectangulaire du décor que le BOB recouvre est précisément ou globalement restaurée au Blitter.
Mise à jour du 14/08/2018 : Mise à jour de bobRAW.s et bobRAWB.s dans l'archive, car les versions proposées ne mettaient pas en oeuvre le masquage présenté !
Mise à jour du 01/10/2018 : Tous les sources ont été modifiés pour intégrer une section "StingRay's stuff" qui permet d'assurer le bon fonctionnement sur tous les modèles d'Amiga, notamment dotés d'une carte graphique.
Continuer la lecture de "Afficher des sprites et des BOBs sur Amiga OCS et AGA (2/2)" →
Afficher des sprites et des BOBs sur Amiga OCS et AGA (2/2)

Afficher des sprites et des BOBs sur Amiga OCS et AGA (1/2)

SoC, , ,
Quoi de plus confortable qu'un sprite ? Le coprocesseur graphique l'affiche en laissant voir le décor derrière ses pixels transparents, et il préserve le décor derrière ses autres pixels pour le restaurer quand le sprite est déplacé. Par ailleurs, il découpe le sprite s'il sort de l'écran.
Malheureusement, les capacités de l'Amiga 500 sont en la matière très limitées. Huit sprites de 16 pixels de large, même de hauteur infinie, en 4 couleurs dont une transparente, seulement ? C'est la dèche...
Les sprites n'en conservent pas moins une certaine utilité, à condition d'en utiliser pleinement le potentiel. Ainsi, il est possible de les attacher pour former jusqu'à un bitmap de 64 pixels de large, de hauteur infinie, en 16 couleurs dont une transparente, notamment. Ou alors, il est possible d'en réutiliser pour créer un playfield supplémentaire, dont le contenu devra toutefois être un motif répétitif qui, dans le meilleur des cas, occupera 48 pixels de large sur une hauteur infinie, en peu de couleurs. Par ailleurs, l'Advanced Graphics Architecture, dont l'Amiga 1200 est doté, dispose de fonctionnalités un peu étendues en matière de sprites. En particulier, leur largeur unitaire passe de 16 à 64 pixels.
Des sprites un peu plus mieux en AGA
Comment afficher des sprites ? Et utiliser les sprites pour afficher un gros et beau bitmap, ou un playfield supplémentaire ? Et enfin utiliser les sprites sur AGA, sachant que Commodore n'a jamais documenté ce hardware ? Tout cela et plus en encore dans ce premier article consacré à l'affichage de bitmaps sur Amiga OCS et AGA.
Mise à jour du 08/07/2018 : Correction d'un bogue dans triplePlayfield.s.
Mise à jour du 01/10/2018 : Tous les sources ont été modifiés pour intégrer une section "StingRay's stuff" qui permet d'assurer le bon fonctionnement sur tous les modèles d'Amiga, notamment dotés d'une carte graphique.
Continuer la lecture de "Afficher des sprites et des BOBs sur Amiga OCS et AGA (1/2)" →
Afficher des sprites et des BOBs sur Amiga OCS et AGA (1/2)

Les opérateurs étoile (* et **) en Python

SoC
En Python, chacun sait que l'opérateur * permet d'effectuer une multiplication sur des opérandes numériques, ou à répéter un opérande quelconque, tandis que l'opérateur ** permet d'effectuer une élévation à une puissance quelconque d'un opérande numérique : 
print (2*3)
print (2*'Hello, world!')
print (2**3)

6
Hello, world!Hello, world!
8
Ce qui est moins connu, car elle est assez mal documentée, c'est la possibilité d'utiliser ces opérateurs pour du déballage (unpacking) d'itérables divers en vue de constituer un autre itérable. Par exemple : 
x = ['A', 'B']
y = ('C', 'D')
z = [*x, *y]
print (z)

['A', 'B', 'C', 'D']
Comment est-il possible d'utiliser ces opérateurs de cette manière ? Et pour quoi faire ? L'exploration de la documentation de Python permet de constater qu'ils peuvent servir dans deux circonstances : pour créer des itérables, et pour fournir des arguments à une fonction. Explications...
Mise à jour du 19/05/2018 : Mention de notations supplémentaires pour créer un itérable à partir d'un autre.
Continuer la lecture de "Les opérateurs étoile (* et **) en Python" →
Les opérateurs étoile (* et **) en Python

Fessebouc, l’Internet des neuneus ?

SoC
L'affaire Cambridge Analytica se définit avant tout par l'empressement avec lequel les médias mainstream ont communiqué sur la question de la propriété des données personnelles, contribuant à la constituer en problème auquel les pouvoirs publics sont invités à apporter sur le champ une solution.
Facebook, the leaking ship
L'histoire dira si cette affaire est le scandale qu'on prétend.
Dans sa version de base, des universitaires pervertis par l'appât du gain auraient siphoné les comptes de millions d'utilisateurs de Fessebouc au moyen d'un subterfuge, puis utilisé ces données pour déterminer le message à tenir selon le subconscient d'électeurs, lequel moyen aurait permis de piloter la campagne d'un démagogue, ce qui aurait déterminé l'élection de ce dernier au poste de leader du monde libre. Naufrage de l'Humanité.
Comme on le voit en la présentant ainsi, l'histoire tient du récit mythologique. C'est les hommes précipités dans le malheur par ceux d'entre eux qui ont accédé au moyen de les agir comme des dieux.
Mise à jour du 06/04/2018 : Découvrant ici (via l'excellent Hacker News) que l'université de Berkeley propose gratuitement un cours de Data Science (Data 8X) aux profanes, je le recommande à ceux qui voudraient faire l'effort de s'instruire.
Mise à jour du 17/04/2018 : Découvrant ici que Fessebouc-émissaire est désormais chargé de tous les maux d'Internet car il est solvable, je rajoute un petite section sur les précautions à prendre par l'internaute lambda pour protéger un peu sa vie privée quand il navigue sur le Web.
Mise à jour du 15/08/2018 : Ajout de Decentraleyes au rang des extensions à installer.
Mise à jour du 14/03/2020 : A partir de la version 74, ceux qui utilisent Firefox seront invités à installer l'extension Facebook Container. A défaut de prendre les précautions prodiguées ici, c'est toujours ça de pris.
Mise à jour du 16/01/23 : Après des tests, il s'avère que l'extension Forget Me Not nettoie bien mieux les donnnées que Cookie AutoDelete et doit donc être recommandé en lieu et place.
Continuer la lecture de "Fessebouc, l’Internet des neuneus ?" →
Fessebouc, l’Internet des neuneus ?