FR:
Pour revenir au problème que j'ai. J'ai écris un programme que je charge d'abord dans la page vidéo non-affichée du MZ-700. Ce programme me permet de calculer le checksum du dernier programme chargé (et je l'ai par la suite modifié pour qu'il m'affiche des checksums partiels tous les 256 octets lus). Je charge donc ce programme, puis ensuite le programme qui ne veut pas se lancer et j'ai bien une erreur de checksum. En appelant le programme checksum par JD400, il m'affiche les checksums : il y a bien une différence. Premier constat, les programme est bien chargé complètement, pas un bit en plus ou en moins. Deuxième constat, l'erreur est reproductible avec le même résultat en valeur des checksums. Troisième constat, quand le problème apparaît, c'est lié à un bit 0 transformé en 1, augmentant ainsi la valeur du checksum du côté du MZ-700. Quatrième constat, les valeurs max mesurées des périodes haut et bas pour les signaux long et court restent dans les clous : cela conduit à un paradoxe. J'ai mis les tables de comparaison des checksums à la fin du post.
Je parle de la version procédurale qui émet bien un 0 sur le signal READ à la fin de chaque impulsion émise. Le programe lit d'abord un octet du SD puis émet une impulsion longue suivi de 8 impulsions correspondantes à l'octet lu. Si j'arrête la lecture et que je lance programme direment avec Jxxxx, il tourne sans issue malgré les bits transformés (pas suffisamment pour faire crasher le programme en tout cas). J'aurais pensé que la transformation d'un bit 0 en 1 aurait été vue avec la capture de la période maximum pour un signal haut correspondant à un 0 excédant la période attendue. Ben non, c'est dans les clous et pourtant il y a bien des bits qui changent.
Face à cette enigme, j'ai décidé de remplir les octets du programme d'abord dans un tableau (environ 5 Koctet) avant de commencer l'émission du programme et de passer par ce tableau pour émettre les octets du programme. Surprise : plus de problème de checksum !
Donc lire un octet à partir du SD a des effets de bord sur le temps réellement passé à émettre un signal haut ou bas sans que cela soit capturable par micros() !? se peut-il qu'une interruption ait eu lieu entre le moment où on sort de la boucle d'attente pour le signal haut et avant de mettre le signal bas !? et le temps de cette interruption pourrait être assez longue pour faire transformer le bit attendu 0 en un bit 1 vu par le MZ-700 !? si c'est cela, alors je vais devoir considérer une solution plus radicale :
1) rajouter une SRAM I2C/SPI pour lire tout le programme dans cette SRAM puis lire dans cette SRAM pour émettre les octets.
2) ou utiliser un buffer, pas sûr que cela fonctionne.
3) ou utiliser un PWM pour émettre un signal haut sans pertubation.
EN:
To get back to the problem I have. I wrote a program that I first load into the MZ-700's non-displayed video page. This program allows me to calculate the checksum of the last loaded program (and I modified it later so that it displays me partial checksums every 256 bytes read). So I load this program, then the program that doesn't want to run and I do have a checksum error. When calling the checksum program by JD400, it shows me the checksums: there is a difference. First observation, the program is fully loaded, not a bit more or less. Second observation, the error is reproducible with the same result in checksum values. Third observation, when the problem appears, it is related to a bit 0 transformed into 1, thus increasing the checksum value on the MZ-700 side. Fourth observation, the maximum measured values of the high and low periods for the long and short signals remain in the expected ranges: this leads to a paradox. I put the checksum comparison tables at the end of the post.
I am talking about the procedural version which emits a 0 on the READ signal at the end of each pulse emitted. The program first reads one byte from the SD and then emits a long pulse followed by 8 pulses corresponding to the byte read. If I stop the reading and start the program with Jxxxx, it runs without an exit despite the transformed bits (not enough to crash the program anyway). I would have thought that transforming a 0 bit to 1 would have been seen with capturing the maximum period for a high signal corresponding to a 0 exceeding the expected period. Well no, it's in the range and yet there are some bits that change.
Faced with this enigma, I decided to fill the program bytes first in a table (about 5 Kbytes) before starting the program output and to go through this table to output the program bytes. Surprise: no more checksum problems!
So reading a byte from the SD has edge effects on the time actually spent emitting a high or low signal without it being capturable by micros() !? can an interruption have occurred between the time you exit the standby loop for the high signal and before putting the low signal !? and the time of this interruption could be long enough to turn the expected bit 0 into a bit 1 seen by the MZ-700 !? if that's the case, then I'll have to consider a more radical solution:
1) add an I2C/SPI SRAM to read the whole program in this SRAM then read in this SRAM to output the bytes.
2) or use a buffer, not sure if it works.
3) or use a PWM to transmit a high signal without disturbance.
---------------------
FR: Voici les checksums respectivement pour MAN-HUNT et SPACE DRIVE :
EN: Here are the checksums for MAN-HUNT and SPACE DRIVE respectively:
Code: Select all
MAN-HUNT
--------+-------
MZ-700 |Arduino
--------+-------
0040 |0040
03CB |03CB
076B |076A -> 1 bit à 0 transformé en 1
0B0E |0B0D
0DF6 |0DF5
117F |117E
14DB |14D9 -> 2 bits à 0 transformé en 1
1813 |1811 -> 3 bits à 0 transformé en 1
1ABE |1ABC
1DD0 |1DCE
1F13 |1F10
SPACE DRIVE
--------+-------
MZ-700 |Arduino
--------+-------
01F9 |01F9
054C |054C
090E |090E
0C6F |0C6E -> 1 bit à 0 transformé en 1
1007 |1006
1349 |1347 -> 2 bits à 0 transformé en 1
16D0 |16CE
1A1C |1A19 -> 3 bits à 0 transformé en 1
1D90 |1D8D
1D91 |1D8D -> 4 bits à 0 transformé en 1
1D91 |1D8D
1D92 |1D8D -> 5 bits à 0 transformé en 1
1FC3 |1FBE
22B1 |22AC
25BB |25B6
28AE |28A9
2B06 |2B01
2D72 |2D6D