Documentation

Si vous faites n'importe laquelle des choses que je vous ait dit de ne pas faire, le matériel réagira de manière complètement imprévisible et on ne pourra pas espérer le faire revenir dans un état normal sans passer par une réinitialisation complète du système. Donc, ne les faites pas.

¤ Accès au registre SCB de Suzy. Tous les registres dans le SCB de Suzy sont réputés instables quand le moteur de sprite est en fonctionnement. Cette limitation est valable en lecture ET en écriture. Avant d'accéder à n'importe lequel de ces registres (ils sont identifiés dans l'annexe des adresses mémoire comme 'unsafe') vous devez d'abord vérifier si le moteur de sprites est actif ou non(qu'il s'agisse de sprites ou d'arithmétique). Ces bits de statut sont dans SPRSYS
¤ Accès séquentiels à la mémoire. Les actions du microprocesseur qui déclenchent un accès sur Suzy immédiatement suivis d'un autre accès à Suzy peuvent planter Suzy. Merci de ne pas en faire.
¤ Bidouilles du compilateur. Certains compilateurs font des choses stupides quand ils convertissent certaines déclarations. Par exemple, "A=B=C=0" peut être converti en : écrire 0 dans C, lire C et écrire le résultat dans B, lire B et écrire le résultat dans A. Ca va planter si vous l'essayez sur l'un de mes matériels donc à moins d'être sûr que votre compilateur ne fera jamais ça, n'écrivez jamais votre code comme ça.
¤ Ecritures sur la cartouche de jeu. Les écritures sur Suzy sont aveugles mais se termineront avant qu'une autre fonction CPU puisse les troubler SAUF dans le cas de l'écriture sur la cartouche de jeu. Pendant les 12 ticks qui suivent l'écriture sur la cartouche de jeu, le CPU NE DOIT PAS accéder à Suzy (ni en lecture, ni en écriture). S'il le fait, l'écriture sur la cartouche sera ratée.
¤ Palettes et saut de pages. Celui ci est l'un de bugs de mon fait. Le signal matériel qui indique la fin du process de chargement pour n'importe quel SCB intervient 2 octets avant la fin réelle de l'élément. Si un saut de page intervient en même temps que le signal de fin de chargement alors le signal de fin de chargement doit être mis en attente pour un cycle. Sinon, le chargement va s'arrêter et ne pas reprendre à la fin du saut de page. Donc, j'ai foiré la logique pour le chargeur de stylos depuis la palette. Par conséquent, si un tableau de stylos démarre à une adresse xxFA alors un saut de page interviendra en même temps que le signal de fin et le chargeur de palette ignorera ce saut de page. Les deux derniers octets de cette palette de cette palette de 8 octets ne seront pas lus en RAM et les valeurs chargées par le précédent SCB seront toujours dans le système. Les stylos d'indexes C, D, E et F resteront inchangés par erreur. Parfois je suis un imbécile.