kuk (./141) :
'il existe un Radio unit
de memoire 64 consoles peuvent se connecter...ça pourrait etre interessant de faire un jeu compatible avec ce machin

Sûr, tu te charges de fournir 64 radio units, 64 NGPC et la doc qui explique tout ça à Furrtek ?

furrtek (./140) :
Sachant que je veux utiliser de la 29W400DB qui n'a pas de protection par bloc, mais que je dois tout de même débloquer le /we via le mapper, est-ce une bonne idée ?

Y'a toujours un risque potentiel bien sûr, mais c'est à comparer à la complexité de rajouter une mémoire externe juste pour ça. Si ton mapper est un CPLD, ajouter une EEPROM série I²C (ou autre standard) ne me semble pas trop complexe à gérer, ça ne coûte pas grand chose, et ça ne prend pas beaucoup de place sur le PCB non plus. Si tu ne peux pas faire ça et que la seule solution est de rajouter une Flash parallèle, pour moi ça ne vaut pas le coup.

Le premier risque est que les données hors du secteur soit corrompues si la console est éteinte pendant l'écriture. Je pense que les mémoires garantissent que ça ne peut pas se produire, mais tu peux toujours faire des tests pour vérifier.

Le second risque est qu'un bug dans le code provoque une écriture ailleurs que dans le secteur qu'il faut. Vu qu'il faut envoyer des commandes particulières à la mémoire pour déclencher l'écriture, il y a très peu de chances que ça arrive par accident dans du code qui n'a rien à voir. Le risque principal c'est que le bout de code qui fait la sauvegarde soit exécuté par erreur de manière incorrecte, par exemple via un saut à la mauvaise adresse, ou une corruption de la pile dans une sous-fonction. Mais tu peux limiter les risques. Imaginons par exemple que c'est du 68k et que la mémoire nécessite d'écrire $55 et $AA avant l'octet de données :
; on suppose que l'octet à écrire est dans d0 move.l #$12345678, d3 move.b #$55, d1 move.b #$AA, d2 move.l #adresse, a0 ; Protection 1 cmp.l #$12345678, d3 erreur1: bne erreur1 ; Écriture des données move.b d1, (a0) move.b d2, (a0) move.b d0, (a0) ; Protection 2 cmp.l #$12345678, d3 erreur2: bne erreur2
- Cas 1 : l'exécution commence après le move.l #$12345678, d3, mais avant ; Protection 1 -> à moins d'avoir vraiment pas de bol, on n'aura pas d3 = $12345678, du coup ça va bloquer à erreur1

- Cas 2 : l'exécution commence à ; Écriture des données : à moins d'avoir vraiment pas de bol, on n'aura pas d1 = $55 ET d2 = $AA (et a0 qui point vers une zone "dangereuse"), donc les écritures ne provoqueront pas de corruption. De plus, comme d3 sera différent de $12345678, ça va bloquer à erreur2 pour limiter la casse.

- Cas 3 : l'exécution commence après ; Écriture des données : il manquera au moins une écriture pour déverrouiller la mémoire, donc pas de risque de corruption non plus.

Évidemment, il faut désactiver les interruptions pendant l'exécution de tout ce bazar