Catégorie : Non classé

(c) Pexels – Anete Lusina

Polytech – 3eme partie

⚠ AVERTISSEMENT : Toutes les informations fournies dans cette publication le sont à des fins éducatives uniquement. Le site n'est en aucun cas responsable de toute utilisation abusive de ces informations. Vous êtes seul responsable de vos actes devant la loi.

3ème partie des aventures Polytechnicienne.

Je continue avec ma fameuse disquette de boot.

J’ai quelques manquements dans mes souvenirs à propos de cette anecdote. J’espère que je ne dirai pas trop de bétises.

Pendant mes explorations des interruptions du PC, j’étais tombé sur la fonction 25h de la bien connue interruption 21h. Cette fonction permet d’intercepter n’importe quel autre interruption. Pour mon résident (GREY.COM), j’allais dévier les fonctions 05h, 1Ch, 28h de l’int 21h. Si vous vous rappelez de ces interruptions (et je vous en félicite), vous devriez avoir compris qu’il y a un problème dans les fonctions que je dévie. Sinon, je continue:

La 05h est appelée lors d’une sortie caractère vers l’imprimante,
La 1Ch est appelée lors d’une demande d’information de l’unité de disque,
La 28h est appelée lors d’une écriture vers un fichier

Dans la fonction redirigée 05h, je lis le clavier, rempli un buffer et rend la main à la fonction 05h originale.
Dans les fonctions 1Ch et 28h, si mon buffer n’est pas vide, j’écris dans un fichier log les appuis claver et rend la main. Ainsi, l’utilisateur ne se rend pas compte qu’il y a un accès disque supplémentaire (nous étions sur disquette, cela se voyait assez vite). Ca, c’est en théorie, j’expliquerai plus tard que ce n’était pas le cas.

Mon problème est donc ma fonction 05h. Pourquoi donc est-ce que je lisais le clavier à cet endroit ? Est-ce que chaque appui d’une touche provoquait une int21h fct05h ? J’ai testé mes applications dans une DOSBox et tout fonctionne toujours.

Le programme résident ne sauvegardant que les scancodes, il fallait un convertisseur scancode -> ascii. Et là, deuxième inconnue: il ne lit pas un fichier mais directement l’emplacement mémoire du résident (de plus, la fonction d’écriture vers un fichier dans le résident est inactive). C’était la tâche du deuxième programme: LIT.EXE.

Pour ce qui est du convertisseur, un troisiéme programme (CARSET.EXE) transformait le scancode en symbole compréhensible à l’écran.

Pour accèder à la mémoire LIT.EXE devait être lancé sur l’ordinateur de la victime en esperant qu’il n’éteigne pas son PC en quittant le local.

Cela semble logique vu qu’ils me rendaient ma disquette boot dès qu’ils étaient connectés mais ce n’était vraiment pas pratique. Ca expliquerait aussi que je m’en suis peu servi. Mon seul souvenir à son propos est d’avoir eu le mot de passe d’un étudiant de 2ème (angusmac) qui était tous les jours dans la salle informatique avec nous.

Je me demande ce qu’il reste de ces interruptions sur un PC moderne. Connaissant Microsoft, ils n’ont certainement pas tout jeté. J’ai essayé de lancer GREY.COM en ligne de commande sous un Window 10 mais il m’indique ‘Applications 16 bits non prise en charge‘.

Mes deux années de Polytech ne m’ont pas apporté un diplôme mais elles m’auront au moins servi à manipuler l’assembleur x86, qui me servira beaucoup quelques années plus tard dans ma période demomaker……

Une souris sur iPad

Une souris sur iPad ? Depuis iPadOS 13.4, c’est assez facile. Mais comment faire sur un iPad qui ne supporte pas cet OS ou simplement sur iPhone ? Impossible me direz-vous. Steve Jobs (et Apple) n’en voulait pas !

Faux, vous répondrai-je ! (Heureusement, sinon ce post aurait été fort court)

Ce miracle a pu se produire sans que Apple ne puisse l’interdire grâce à mon grand ami BLE4.

Pour ceux qui ne connaissent pas, BLE4 (Bluetooth à basse consommation version 4 – en anglais : Bluetooth Low Energy) permet d’établir un lien bidirectionnel entre deux périphériques de manière sécurisée et très facilement niveau programmation. Cela pourrait faire l’objet d’un prochain post (ou même de plusieurs vu tout ce que j’ai à dire sur cette technologie).

Deux modèles de souris existent:

  • la Citrix Plus X1,
  • la SwiftPoint GT.

La première ressemble à la une souris standard et est supporté dans quelques application dont la plus connue est celle de son constructeur: Citrix Receiver.

La deuxième, mon choix, est plus petite. Cela constituait déjà un gros avantage pour moi. Mais ce qui m’a fait définitivement pencher vers elle est que son API est disponible et que donc un tas d’application peuvent l’utiliser (entre autre Jump – un client VNC et RDP ou Horizon, le client VDI de VMware).

En plus, elle est aussi reconnu par un PC ou un MAC à l’aide de son dongle.

Utilisation du Digispark en AZERTY

⚠ AVERTISSEMENT : Toutes les informations fournies dans cette publication le sont à des fins éducatives uniquement. Le site n'est en aucun cas responsable de toute utilisation abusive de ces informations. Vous êtes seul responsable de vos actes devant la loi.

Si vous avez lu le précédent article sur le Digispark, vous savez maintenant envoyer des chaines de caractères automatiquement.

Mais vous vous êtes sans doute rendu compte (je l’avais bien précisé en plus), que le mapping des caractères est incorrect. Le Digispark pense que vous êtes en QWERTY alors que ce n’est peut-être pas le cas.

Heureusement pour nous, Ernesto a pensé a cela. Sa version DigisparkKeyboard est multilangue

La modification se fait facilement en remplaçant le contenu du répertoire $PWD/Library/Arduino15/packages/digistump/hardware/avr/1.6.7/libraries/DigisparkKeyboard par le contenu de https://github.com/ernesto-xload/DigisparkKeyboard.

cd ~/Downloads
git clone https://github.com/ernesto-xload/DigisparkKeyboard.git
cd DigisparkKeyboard/src
cp * $PWD/Library/Arduino15/packages/digistump/hardware/avr/1.6.7/libraries/DigisparkKeyboard

Vérifiez aussi que le tableau ascii_to_scan_code_table commencent bien par BS Backspace dans les fichiers digi_be_be.h et digi_fr_fr. Si ce n’est pas le cas, effacez les 8 valeurs en trop. J’ai fais un pull request pour les effacer mais elles n’ont pas encore été prises en compte.

Quand vous avez fait cela, il suffit de mettre un de ces #define au début de votre sketch (avant le #include « DigiKeyboard.h »)

#define kbd_fr_fr           // Pour l'utilisation sur un système dont le clavier est AZERTY FR
#define kbd_be_be           // Pour l'utilisation sur un système dont le clavier est AZERTY BE

Amstrad

Depuis un peu plus de 2 ans, je crée des jeux sur cette machine dans le groupe Crazy Piri. Sur le site de notre groupe, j’avais commencé quelques cours pour expliquer comment développer en C sur le CPC. Je n’ai pas continué suite à l’indifférence des visiteurs. Je ne sais pas si c’est dû à la faible visibilité du site ou alors parce que tout le monde s’en moque.

Ces derniers jours, j’ai déplacé ces cours ici pour leur donner un deuxième chance. Si cela vous intéresse, je pourrais reprendre ces cours. À vous de me le dire

Dans le dernier post, je citais RVM, WinAPE et CrocoDS en tant qu’émulateur Amstrad.

Si on s’intéresse à Linux, nous remarquons que, malgré ce que l’on pourrait penser, nous sommes assez gâtés.

  • CPCEmu de Marco Vieth (dont la première version date de… 1996 et tournait sur un 386SX. Un des premiers émulateurs Amstrad CPC). Il n’est pas open source, mais fonctionne assez bien sur tous les OS. Actuellement, il est le seul à simuler l’interface wifi M4. Il ne lui manque que le support du CPC+.
  • CPCEC de CNGsoft (ou son fork GTK de NoRecess)
  • Retro Virtual Machine de Juan Carlos González Amestoy (assez lourd, mais doté d’une belle interface, compatible Dandanator et avec un outil de debug assez agréable. Mon préféré sous macOS)
  • Sugarbox de Thomas Guillemin

Et si vous ne voulez pas installer d’émulateur, à l’heure actuelle, les browsers et javascript sont largement assez puissants que pour faire fonctionner un émulateur Amstrad en ligne. Parmi ceux-ci, CrocoDS, le mien, est disponible en ligne et fonctionne aussi bien sur smartphone que sur les navigateurs récents et est compilé en WebAssembly grâce à Emscripten.

CrocoDS n’est pas encore assez complet que pour l’utiliser pour du développement. Cela va changer bientôt, mais ceci est une autre histoire, qui sera contée une autre fois.

Développement de BriXen: épisode 7 – Docker Hub

Il n’y a pas eu beaucoup de posts ces dernières semaines à propos du développement de BriXen.

Cela ne veut pas dire que nous avons chômé…

Nous sommes beaucoup pris sur plusieurs projets (RetroANA, FaRK entre autres) mais surtout par le portage de BriXen sur d’autres plateformes. (Amiga, Super Nintendo, SEGA MasterSystem et SDL2 pour l’instant).

Pour simplifier le développement sur ces plateformes et ne voulant pas installer de lourds outils pour le développement cross-plateform sur mes ordinateurs, je suis en train de faire des images Docker sur Docker Hub permettant de compiler facilement mes outils.

Par exemple, sur Sega Master System, il suffit de taper cette commande à la racine du projet

docker run --rm -v $PWD:/src/ -it redbug26/devitsms-docker make

Facile, non ?

Pour l’instant, les Repositories existants sont:

Les autres plateformes suivront ;p

Développement de BriXen: épisode 6 – L’émulateur

Mon ordinateur prinicpal est un mac et sur macOS, le choix de l’émulateur est assez facile: Arnold ou Retro Virtual Machine (RVM).

Malgré que Arnold soit un très bon émulateur, niveau developpement RVM reste plus pratique avec toutes ses options de debugging et sa possibilité d’être appelé via la ligne de commande.

Retro Virtual Machine

Comme vu dans l’épisode 3, j’utilise une tâche pour lancer rapidement mon binaire dans Visual Studio avec la commande suivante

/Applications/Retro Virtual Machine 2.app/Contents/MacOS/Retro Virtual Machine 2 -w -b=cpc6128 -i brixen.dsk -c=run"main

J’utilise principalement les 3 vues suivantes:

la première affiche une vue d’ensemble du processeur Z80
la seconde qui affiche la mémoire
et enfin, la 3ème qui affiche une vue du code désassemblé.

SDCC étant assez verbeux et créant des fichiers .map et .lst du code qu’il a compilé, il est assez facile de faire la correspondance entre le code désassemblé de RVM et votre code C.

CrocoDS

En plus de RVM, ayant quand même notre propre émulateur (CrocoDS, vous connaissez ?), j’ai aussi ajouté quelques fonctions dans celui-ci qui m’aide régulièrement:

Redirection de l’imprimante.

CrocoDS redirige le port imprimante vers un fichier log. J’ai donc deux fonctions qui me permettent d’envoyer du texte à partir du CPC vers la console

void cpc_out(u8 b)
{
    (void)b;
 __asm
    ld hl, #2 + 0
    add hl, sp
    ld c, (hl)
    ld b, #0xEF
    out(c), c
    ld a, #0x80
    xor c
    ld c, a
    out(c), c
    __endasm;
}

void cpc_Debug(const char *str)
{
    char *a = (char *)str;
    while (*a != 0) {
         cpc_out(*a);
         a++;
     }
 }

Capture d’écran

Un opcode spécial (ED FD) me permet de demander une capture d’écran à partir de l’Amstrad. Je l’utilise pour sortir la liste des 32 niveaux de BriXen en fichier pdf. Plus facile à consulter pour l’équipe.

__asm
.db #0xED
.db #0xFD
__endasm;

Comptage de FRAME

Autre opcode (ED FE) qui me logge le compteur de frame et le compteur de cycle:

F4 - T123/80000
F4 - T3153/80000

Cela me permet facilement de voir le temps que prend une routine et de l’optimiser si nécessaire.

Conclusion

Comme d’habitude, ces outils correspondent à mes besoins. Beaucoup ne jure que par WinAPE pour développer sous Windows (Certains jeux ont même été entièrement réalisé à partir de son assembleur intégré).

Et puis, n’oubliez pas: testez aussi sur vos vraies machines ! (et restez couvert)

A suivre pour un prochain épisode

Développement de BriXen: épisode 5 – Mode démo

Quand j’étais petit, j’adorais le mode démo dans les jeux. Cela permettait d’avoir une musique et une animation qui tourne en fond. 

Pour BriXen, il en fallait donc un.

Niveau développement, c’est assez simple. En gros, on joue à un niveau, chaque modification de touche est sauvée avec un compteur de frame et dans le mode démo, le programme utilise la séquence pour simuler le joueur qui joue.

J’ai donc deux fonctions à faire:

  • une qui enregistre (que je pourrais supprimer dans la version finale)
  • une qui joue.

Pour cela, j’ai crée une scène SC_DEMO qui est appelé après 30 secondes (soit 1500 frames).

Un chaine de replay se ressemble à ça (pour le level 1)

const u8 seq_level0[] = {22, 2, 18, 0, 14, 2, 10, 0, 17, 2, 9, 0, 14, 2, 9, 0, 10, 2, 11, 0, 14, 2, 17, 0, 21, 2, 8, 0, 78, 2, 11, 0, 36, 2, 8, 0, 51, 1, 84, 0, 15, 1, 5, 0, 16, 2, 16, 0, 21, 2, 19, 0, 23, 1, 7, 0, 11, 2, 24, 0, 10, 2, 17, 0, 19, 2, 21, 0, 37, 2};

Cela se traduit par:

  • 1er octet: nombre de frame avant d’executer la commande
  • 2éme octet: commande à executer (1: gauche, 2: droite, 0: on relache)

Arrivé à la fin de la chaine, j’aurai pu crée une commande 3… Mais vu que je ne fais que de la lecture et que cela n’influence qu’une simulation d’appui de touche, je laisse aller le pointeur au-delà de la chaine. De toute façon, il ne lira que quelques octets avant de compléter le niveau…

Développement de BriXen: épisode 4 – La compression

Un des choses qui nous fait le plus vite défaut sur l’Amstrad, c’est le peu de mémoire dont nous disposons.

Actuellement, je préfère n’utiliser que les 64k de disponible afin de rendre nos jeux compatibles avec le plus de machine possible (c’est même une des conditions de la CPC Retrodev)

De nombreuses méthodes de compression existent pour notre Z80. La plus connues des demomakers est Shrinkler de par son haut taux de compression. Malheureusement, son temps de décompression est plus de 25 fois la vitesse de la commande assembleur LDIR (copie d’octets).

Pour un jeu, ce n’est pas acceptable. Il m’a donc fallu trouver un compromis vitesse/taux de compression.

Mon choix s’est porté sur LZSA de Emmanuel Marty.

Il nous donne un taux de compression de 2 pour une vitesse de LDIR x2. C’est plus qu’acceptable. Le meilleur, c’est que la fonction de décompression ne prend que 220 octets ! Il n’y a donc presque pas de raisons de ne pas l’utiliser.

La fonction est disponible dans le template Crazy Piri.

A suivre pour un prochain épisode…

(c) Pexels – Anna Shvets

Retour en Polytech

Suite des aventures Polytechnicienne en 1995.

Je vous avais déjà dit précédemment que je possédais une disquette de boot pour se connecter aux PCs de la salle informatique (qui ne possédaient pas de disque dur).

Étant présent plus que je ne le devrais dans cette salle, beaucoup me demandaient ma disquette pour pouvoir travailler sur leurs rapports (rapports qu’ils enregistraient sur un disque partagé).

Malheureusement pour eux, la salle ne contenait pas que des PCs récents et les jeux Doom, Descent ou le tout premier Warcraft venaient d’arriver. Parmi la trentaine de PCs présent dans la salle, moins d’une dizaine seulement possédait un écran couleur (et un processeur digne de ce nom).

Lorsqu’ils étaient tous occupés, cela posait un problème pour le joueur qui venait d’arriver dans la salle.

J’avais donc réalisé sur mon disque de boot un petit programme résident (c’est comme ça que cela s’appelait les daemons en DOS), qui attendait un paquet IPX magique. Je pouvais envoyer ce paquet de n’importe quel autre PC pour redémarrer le PC à distance. Après 2 ou 3 fois, l’utilisateur changeait de PC de lui-même, quitte à en prendre un plus lent, mais plus stable. Sale gosse, vous dites ?

Certains ont sans doute du retaper une partie de leur rapport, mais ils auront appris, grâce à moi, à sauvegarder plus souvent. Et en fin de compte, beaucoup d’entre eux ont réussi leur année…. à la différence de votre hôte.

Si j’ai encore la disquette de boot, je n’ai malheureusement plus les sources de ce résident ipx. Par contre, j’en ai un autre qui fut tout aussi amusant à développer… mais ceci est une autre histoire, qui sera contée une autre fois.

Un Rubber Ducky à 3€

⚠ AVERTISSEMENT : Toutes les informations fournies dans cette publication le sont à des fins éducatives uniquement. Le site n'est en aucun cas responsable de toute utilisation abusive de ces informations. Vous êtes seul responsable de vos actes devant la loi.

Je vous ai déja parler du Rubber Ducky, un clef usb qui permet d’injecter du code via la prise usb en se faisant passer pour un clavier.

Un de ses défauts, en plus de son manque de connectivité Bluetooth et Wifi, est son prix de 50€. Que diriez-vous d’avoir presque l’équivalent pour seulement 3€ ?

L’objet qui répond à nos besoins se nomme le Digispark. Il s’agit d’une carte basée sur un Arduino ATtiny85 avec un port usb tout petit et pas cher donc. L’avantage d’une clef pas cher, c’est que vous n’aurez pas peur de la perdre.

Niveau specs, malgré son prix, le Digispark n’a pas à rougir par rapport à d’autres cartes Arduino:

  • Support de l’environnement de developpement Arduino,
  • Alimentation via USB ou une source éléctrique de 5v ou 7-35v,
  • Un régulateur 500ma 5V,
  • Un USB intégré,
  • 6 pins I/O (2 pour l’USB qui peut être désactivé),
  • 8k de mémoire flash (6k disponible après le boot),
  • I2C & SPI,
  • PWM sur 3 pins,
  • ADC sur 4 pins,
  • Une LED d’alimenation, et une être de statut.

Par contre, contrairement au Rubber Ducky, il n’y a pas de slot micro SD sur le Digispark: il faut donc developper vos séquences claviers en C et injecter l’application via l’environnement de developpement Arduino.

Néanmoins, si vous voulez bénéficier des payloads du Ruber Ducky (, ou encore ), Marcus Mengs nous a developpé un convertisseur DuckyScript vers Digispark. Tout cela est disponible sur GitHub.

Avec un tel prix, le Digispark pourra encore nous servir dans de futurs projets, mais ceci est une autre histoire, qui sera contée une autre fois.