Merci Bertrand c'est très intéressant. Comme on disait autrefois en atelier quand un technicien ne lisait pas suffisamment le manuel, "RTFM"!
2 года назад
Il y a déficiences dans le contenu de cette vidéo! Merci aux bidouilleurs d'avoir signalé les bourdes. 1- Ce n'était pas génial de court-circuiter deux lignes de données pour générer un échec de RAM car il n'y a aucun tampon ou bascule isolant la RAM sur le bus de donnée. Faire cela cause aussi un échec de lecture du programme sur le EPROM! Ceci dit, on a vu qu'il était possible de faire échouer le test de RAM par moment...et de façon plutôt aléatoire et incontrôlée, j'en conviens. 2- L'utilisation de l'instruction CALL utilise la mémoire RAM pour sauvegarder l'adresse de retour de l'instruction RET. Comme je ne peux pas utiliser la RAM pour tester la RAM (!), j'aurais dû simplement implémenter la fonction IMPULS_ERR comme instructions séparées directement dans le flux, et ne pas utiliser d'instruction CALL. Le programme fonctionne tout de même car le pointeur de pile est initialisé à l'adresse 0000h au démarrage (la ROM!). Le retour se fait donc à quelque part dans le code programme, et l'exécution semble se poursuivre correctement...par pure chance. J'ai inclus un nouveau fichier de code source corrigé dans le fichier zip disponible sur le site web bidouilleur.ca.
2 года назад
Merci pour ce grattage de tête! J'aurais juré que l'instruction Call utilisait la pile stockée en RAM. Mais vu que tout fonctionne en court-circuitant des pattes, ça ne doit pas être le cas! (ou alors des interruptions illegal instruction sont déclenchées!)
2 года назад
Vous avez totalement raison! l'instruction CALL utilise la pile, qui doit être définie dans la mémoire RAM. Mais comment ai-je pu manquer cela... Le code source fonctionne quand même, probablement parce que le pointeur de pile est initialisé à zéro lors du reset du CPU. De sorte que le RETurn ramème l'exécution dans les premiers bytes du programme. Bravo à vous! Je corrige...
Merci pour ce partage et vous pourrez noter que le raspberry pi pico a repris l appellation PIO pour de petites machines d état indépendantes du processeur principal /cela pourrait constituer un sujet interessant pour une de vos prochaines vidéos :)
Un grand merci pour ta vidéo, cela me fais rappeler mes bonnes années à l'école , ou on travaillait sur THOMSON MO5 et TO7 avec des automates TELEMECANIQUE TLX30 et 50.
Mes compétences sont bien maigre en code. Mais c'est très intéressant. Je suis donc absolument pas compétent pour dire si ton code est la façon la plus simple. De mon siège, je trouve ton approche très bonne et intuitive... En tout cas je suis toujours content de regarder une de tes vidéos. C'est mieux que ces émissions stupide qu'on nous sert sur la télévision française🤣🤣🤣 merci et change rien surtout.
La Ram et la ROM partageant le même bus de données, un court circuit sur ce bus fait que les instructions ne seront pas lues correctement et donc on ne sait pas ce que fait le programme exactement.
2 года назад
Tout à fait. Ce n'était pas génial de court-circuiter deux lignes de données car il n'y a aucun tampon ou bascule isolant la RAM sur le bus. Ceci dit, on a bien vu qu'il était possible de faire échouer le test par moment...et de façon plutôt aléatoire et incontrôlée, j'en conviens. Merci!
Bonjour. Super programme de test mémoire. Par contre, concernant le "CALL", il est dit sur le manuel des instructions : "Cette instruction effectue un saut absolu dans l'espace d'adressage 16 bits. L'adresse de l'instruction suivante est enregistrée dans la pile. Ainsi le programme appelant peut revenir où il en était avec un RET." Comme il n'y a pas eu de programmation du pointeur de pile au début du programme , je me demande comment il s'y retrouve... Mais s'y retrouve-t-il vraiment ?
2 года назад
Bien vu, mais vous n'êtes pas le premier! L'instruction CALL utilise en effet la pile, qui doit être définie dans la mémoire RAM. Le code source fonctionne quand même, probablement parce que le pointeur de pile est initialisé à zéro lors du reset du CPU. De sorte que le RETurn ramème l'exécution dans les premiers bytes du programme. Bravo à vous!
Effectivement, il semble qu'il y ait un lézard... La pile du Z80 utilise la RAM et doit être initialisée par un LD SP, xxxxH (xxxx étant généralement la plus haute adresse de RAM disponible). Mais comme la RAM semble toute bonne, il n'y a heureusement jamais eu d'appel à la routine de traitement...sinon crash garanti, ou alors le Stack Pointer est par défaut à 0000 et le programme se relance tout seul.
Concernant le bus S100, il y avait des micro-ordinateur complets basés sur ce bus. Il y a d'ailleurs une page wikipédia dessus. Étudiant, j'ai fait un petit job de programmation pour un boîte qui utilisait cela pour leur comptabilité. Il me semble que cela tournait sous OS9, un os très répandu à l'époque, déjà multitâches et multi-utilisateurs. Il y avait 7 postes de saisie (des terminaux) et une imprimante, tous ça avec un Z80 #
Bonjour Bertrand et encore félicitations pour cette autre série d’un grand intérêt pédagogique. Ayant moi-même reçu il y a peu un système similaire ( Dauphin ) - c’est l’école de mon fils qui s’en débarrassait car il ne fonctionnait plus - je n’ai pas pu résister à l’envie de le refaire fonctionner. Vite fatigué par la méthode d’entrée du code par un clavier archaïque, je me suis souvenu de mes cours ( j’ai 49 ans…) et qu’une broche BUSRQ ! permettait de prendre possession du bus et par là même de mettre le CPU en haute impédance le temps de lire ou écrire librement dans la ROM ou la RAM. J’ai réalisé cette bidouille par le biais d’un Arduino Mega branché sur le bus du Z80. Celui-ci reçoit le code assembleur compilé à partir de mon PC et le pousse dans la RAM en une fraction de seconde par une prise de contrôle du bus. C’est un petit script en python qui lit le fichier binaire sur le disque dur et l’injecte sur le port RS232 du Mega par le câble USB. Le script tourne indéfiniment dans une session powershell et vérifie si le fichier binaire est mis à jour et l’injecte dans le Mega à chaque fois. Si cela t’intéresse tu peux prendre contact et je t’envoie librement tous les fichiers source pour te permettre de l’adapter à ton projet si tu le désires. Cela te permettrait de montrer qu’un système peut partager son bus avec un autre système. C’est d’ailleurs le principe du (D)irect (M)emory (A)ccess. La mise au point du code en est grandement facilitée et plus besoin de programmeur à chaque modification. Comme quoi une vieille techno peut cohabiter avec une plus récente. Cordialement de Belgique
Intéressant! Les bons vieux CPU 8-bit avaient un certain 'cachet'. Leur simplicité (relative) à programmer en assembleur par rapport à la complexité effarante des nouveaux processeurs.
Je reste perplexe face à cette affirmation. À l'époque il n'y avait que des CISC avec un assembleur pas aussi trivial que les archi RISC de microcontroleurs plus modernes.
@@PainterVierax Effectivement quand on regarde du coté de certains uControlleurs. Le Z80 a son lot d'instructions complexes. En regardant la vidéo, mon cerveau à dériver vers le 6502 et le 1802 que j'ai programmé pas mal à l'époque, peu d'instructions, mémorisables en peu de temps. Pratiquement des RISC en comparaison.
Le premier synthétiseur musical piloté par microprocesseur au monde était justement piloté par un Z80. Pour ma part, j’ai fait la connaissance de l’assembleur avec le code machine du Z80. Mais pas pratiqué du tout avec le Z80. Plutôt avec le 68000 (Atari 1024 ST, qui est tjs dans ma cave, et tjs fonctionnel il y a quelques années).
Merci bcp pour cette vidéo Bertrand ! Je suis très curieux de connaître l'évolution de l'électronique vers + de simplicité que vous expliquez brièvement dans la vidéo. Ainsi, un comparatif d'une même fonctionnalité avec 50 ans d'écart serait peut être un bon thème de vidéo ?
Vidéo très intéressante, merci ! A la fin tu indiques que tu partages la doc de la carte Z80 PRO-83 sur ton site avec les sources ASM de tes tests, mais l'archive ne contient que les fichiers ASM. Est-ce que j'ai raté la documentation ?
2 года назад
Oups! Un oubli de ma part. J'ai mis le fichier ZIP à jour. Merci!
A l'époque le zx81 (micro ordinateur a base de z80 )était vendu en kit aussi (500 francs environ je crois) mais il y avait tellement de retour pour cause de non fonctionnement qu'ils ont ensuite arrêté, je me rappelle avoir vu des photos de kit non fonctionnel , c'était parfois de la boucherie, on aurait dit de la soudure à l'arc .😂 Merci pour ces vidéos c'est un réel plaisir de retourner 40 ans en arrière.
Merci Bertrand pour ces vidéos très passionnantes sur un microprocesseur que j'aime beaucoup. Bien vu pour l'instruction CALL cela ne m'a même pas choqué au moment où j'ai regardé la vidéo 😃 Continuez comme ça, c'est que du plaisir👍
Il me semble que la pile est prédéfinie dans la ligne de commande du compilateur (haut de la pile - 1) qui doit coder comme première instruction du main() l'opcode LD SP,#adressehaute pour avoir une pile valide dès le RESET.
