Re: Mr ToutLeMonde et la programmation NES...

par upsilandre Dim 3 Fév 2019 - 23:43

Les couleurs sont aussi une source de lumière donc c'est peu probable que la cellule photosensible fasse la différence :)

par tetsuro Lun 4 Fév 2019 - 0:08

Car moi je suis pas trop Facebook, j'avais vu que tu t'y été exclusivement penché. je préfères encore Twitter et YouTube.

par vincent2105 Lun 4 Fév 2019 - 8:00

upsilandre a écrit:Les couleurs sont aussi une source de lumière donc c'est peu probable que la cellule photosensible fasse la différence :)

D'après ce que j'ai lu un peu partout, sur une NES, seul le blanc ($30) permet de faire passer le bit en question de 1 à 0, c'est pour ça que je trouvais étrange que l'émulateur renvoit 0 pour tout ce qui n'est pas noir. :)

par upsilandre Lun 4 Fév 2019 - 11:26

Dans les pistolets a priori c'est juste une cellule photo sensible. Un jaune peut etre largement plus lumineux qu'un blanc selon la TV et comment elle est reglé donc a mon avis ca serait impossible pour le pistolet de faire la distinction entre un blanc et une autre couleur. Mais par convention si tu veux etre certain d'activer le pistolet faut logiquement utiliser le blanc qui est par définition le plus lumineux. En situation réel y a sans doute des couleurs qui ne serait pas détecter par la cellule selon le contexte, la TV, les réglages, la distance, l'angle, la propreté et l'etat du pistolet... donc meme si les couleurs activent la cellule il faut sans doute éviter de les utiliser comme trigger. En situation réel le seuil du trigger est jamais le meme pour chaque utilisateur donc par convention faut utiliser le blanc.
Dans un émulateur c'est plus simple puisque tu t'affranchie du contexte et de l'aléatoire mais il faut donc choisir arbitrairement le seuil du trigger et j'imagine qu'ils choisissent le cas ou la cellule photosensible et le contexte serait idéal avec une sensibilité parfaite donc tout ce qui est au dessus de l'absence de lumière et donc au dessus du noir.

par upsilandre Lun 4 Fév 2019 - 11:31

tetsuro a écrit:Car moi je suis pas trop Facebook, j'avais vu que tu t'y été exclusivement penché. je préfères encore Twitter et YouTube.

Mais tu peux me trouver partout et nulle part a la fois car ca prend trop de temps Razz

par vincent2105 Lun 4 Fév 2019 - 20:49

upsilandre a écrit:Dans les pistolets a priori c'est juste une cellule photo sensible. Un jaune peut etre largement plus lumineux qu'un blanc selon la TV et comment elle est reglé donc a mon avis ca serait impossible pour le pistolet de faire la distinction entre un blanc et une autre couleur. Mais par convention si tu veux etre certain d'activer le pistolet faut logiquement utiliser le blanc qui est par définition le plus lumineux. En situation réel y a sans doute des couleurs qui ne serait pas détecter par la cellule selon le contexte, la TV, les réglages, la distance, l'angle, la propreté et l'etat du pistolet... donc meme si les couleurs activent la cellule il faut sans doute éviter de les utiliser comme trigger. En situation réel le seuil du trigger est jamais le meme pour chaque utilisateur donc par convention faut utiliser le blanc.
Dans un émulateur c'est plus simple puisque tu t'affranchie du contexte et de l'aléatoire mais il faut donc choisir arbitrairement le seuil du trigger et j'imagine qu'ils choisissent le cas ou la cellule photosensible et le contexte serait idéal avec une sensibilité parfaite donc tout ce qui est au dessus de l'absence de lumière et donc au dessus du noir.

Ok, c'est bon, j'ai percuté. Merci upsilandre thumleft

T'en va pas trop loin, je vais jouer avec la gachette maintenant... je risque d'enrayer mon zapper :p

par upsilandre Mar 5 Fév 2019 - 22:42

Moi ce que je voudrais faire c'est une demo NES de type Axelay dans la continuité de ma demo Coleco et de ma demo SMS. Un truc calibré pour la NES (qu'on pourrait donc pas faire sur SMS).
Mais ca va etre plus chiant que ce que j'imaginais (et plus compliqué que la demo Coleco et SMS) car meme si il est vrai qu'on peut toucher au Vscroll pendant l'affichage (contrairement a la SMS) en vrai c'est de la grosse bidouille, je sais meme pas si c'etait intentionnel. Suffit pas de modifier un registre "Y" faut aller taper dans les registres internes du PPU de facon indirect en passant par d'autres registres et d'autres port avec un timing particulier. C'est une danse assez cryptique. Vaut mieux en tout cas comprendre tout le fonctionnement interne du PPU. Heureusement grace au projet Virtual NES qui a permit de virtualiser les chip de la NES ils n'ont plus vraiment de secret et on connait quasiment tout de ce qu'il se passe a l'interieur du PPU cycle par cycle donc on a toute l'information qu'on peut désirer, de ce coté au moins y a pas de problème (et c'est aussi pour ca que j'aime programmer sur NES, y a pas vraiment de zone d'ombre).
A cela s'ajoute les problèmes de synchro dont j'ai parlé, pour ca la NES c'est vraiment merdique mais bon faut faire avec. Puis des complication aussi lié au format de tilemap de la NES, faut que je sois en mode 256x480 mais c'est pas vraiment du 256x480, sur NES c'est plutot 2 tilemaps 256x240 connecté du point de vue du scrolling mais qui n'ont pas de continuité en mémoire. C'est meme plutot 2 nametables entrelacé avec 2 colortable et avec des granularité différente. Donc c'est un peu chiant a manipuler. Puis en plus de la partie "ground" qui défile sous le vaisseau (et avec donc un décors qui évolue) faut que j'incruste aussi une partie ciel mais sans avoir une autre tilemap a dispo. Et puis je voudrais aucun glitch sur l'image comme on voit trop souvent.
Donc pour l'instant c'est plus de la reflexion que de l'action meme si j'ai deja fait quelques trucs mais je commence a entrevoir les solutions.

par Stef Mer 6 Fév 2019 - 11:09

Ah je ne savais pas que c'était si ardu... naïvement je pensais que c'était comme sur MD/SNES où tu te contentes de reprogrammer le scroll Y.
Il se passe quoi si tu touches au registre Y pendant l'affichage ?
Et du coup j'imagine qu'il y a peu de jeux qui font ce genre d'effet sur NES ?
(on voit souvent un HUB type mario 3 mais un vrai effet sur le V-Scroll j'en vois pas des masses).

Mais du coup si c'est si sioux sur NES, y'aurait pas moyen d'en faire autant sur SMS ? :p
Genre un switch de mode video à la volé (on passe en mode 0/1/2 et on revient en mode 3) pour forcer un refresh du registre ? D'ailleurs on doit pouvoir bricoler un HUD fixe en bas de l'écran avec un scroll multi directionnel en changeant le mode video je pense.

par upsilandre Mer 6 Fév 2019 - 13:15

Si si y a beaucoup de jeux NES qui jouent avec le Vscroll pendant l'affichage autre que pour le HUD, y en a des dizaines. Plein de jeu qui font des effets ascenseurs ou des effet écrasement et beaucoup de jeux qui l'utilisent pour des bosse. Mais en général c'est juste un changement par frame. Dans mon cas faut que je le fasse a chaque ligne et je peux pas précomputer une table a l'avance ou dans le Vblank.

Pour ce qui est du fonctionnement c'est un peu compliqué a expliquer. Par principe c'est un peu normal que le registre Y ne permette pas d'agir pendant l'affichage contrairement au registre X car si y a besoin d'acceder au registre X a chaque ligne pour mettre a jour l'adresse du pointeur VRAM, y a pas besoin du registre Y autrement qu'en debut de frame donc il y a pas d'obligation de le reloader a chaque ligne. Il n'est pas utile pour la mise a jour de l'adressage. Donc le comportement de la Master System est plutot logique et c'est pas tres différent au final sur NES. Le registre Y (meme si y a pas vraiment de registre Y a proprement parlé sur NES) n'est pas reloadé non plus a chaque scanline donc si on le modifie pendant l'affichage ca change rien.

Si sur NES on peut modifier le Vscroll pendant l'affichage c'est lié au fait que le PPU est un chip tres économique en transistors et qu'il y a des registres interne qui se partage plusieurs fonction. Par exemple le registre d'adressage interne au PPU qui sert pendant le balayage a pointer la VRAM vers la prochaine ID tuile a charger par le PPU c'est aussi le registre d'adresse qu'on utilise nous meme quand on veut lire ou ecrire la VRAM par le port $2006 (donc en 2 fois pour charger l'adresse) pendant le Vblank mais le port reste tout le temps ouvert.
Mais entre le port $2006 et ce pointeur interne y a un autre registre intermédiaire (qui permet notamment de bufferiser les 2 acces successif au port $2006 avant de transferer le tout dans le veritable pointeur VRAM interne) qui lui aussi a la particularité d'etre partagé entre le port $2006 et le port $2005.

Ce registre intermédiaire sert a stocker aussi les origine X,Y de l'ecran (sauf le "fine x" c'est a dire les 3bit de poid faible) et sert donc de registre X,Y et contient donc les bits qui vont etre reloadé dans le pointer VRAM en debut de chaque ligne (x) et en debut de frame (y). Le port $2005 sert donc a paramétrer le scroll X,Y par l’intermédiaire de ce registre intermédiaire, c'est sa fonction (y a pas un registre X et un registre Y sur NES, faut paramétrer les 2 en meme temps en passant par le port $2005 en 2 accès successif) .
La différence avec le port $2006 c'est la facon dont ce port $2005 est connecté a ce registre intermediaire ce qui permet d'y ranger les bit dans un ordre different (en gros le cablage différent de ce port exécute une sorte de conversion des valeur X,Y en adresse VRAM alors que le port $2006 c'est directement une adresse qu'on envoie mais les 2 vont dans le meme registre). Par contre en passant par le port $2006 y a une grosse différence c'est que le contenu de ce registre intermédiaire partagé avec le port $2005 est automatiquement transféré dans le pointeur VRAM interne du PPU lors du second acces (ce qui n'est pas le cas en passant par le port $2005) du coup en passant par $2006 on peut modifier le registre interne que le PPU est en train d'utiliser pendant le balayage et donc modifier la position Y (alors que par le port $2005 on ne modifie que le registre intermediaire qui servira seulement lors du reload en debut d'ecran).

Du coup plutot que de passer par le port $2005 qui sert normalement a configurer le scrolling, on peut faire la meme chose en plus direct par le port $2006 meme si il est pas prévu pour ca. Seulement y a un bit de ce registre intermediaire qui n'est accessible qu'en passant par le port $2005 (l'un des bit du "fine" Y, car la fonction du port $2006 c'est l'adressage VRAM et que le bus d'adresse est seulemlent 14bit) du coup faut quand meme aussi passé par le port $2005, on peut pas completement se contenter du port $2006.

Au final si on veut un controle total du Vscroll on a besoin de faire 4 acces de port dans cette ordre:
> ecrire $2006: surtout pour toucher au 2bit qui permet de choisir la nametable
> ecrire $2005: qui du coup sera considéré comme le second acces au port $2005 (car en plus les 2 port $2005 et $2006 partage aussi le meme toggle qui permet de définir si c'est un premier ou second acces au port) et va permettre surtout de configurer l'un des bit de fine Y qui n'est pas accessible par $2006 mais va aussi écraser certain bit de l’accès précédent
> ecrire $2005: une seconde fois mais sera alors considérer comme le premier acces car le toggle a encore switché et va principalement servir a permuter le toggle pour pouvoir executer le second acces au port $2006
> ecrire $2006: qui sera alors considéré comme le second acces de ce port. Il permet de finir de configurer tous les bit (en écrasant aussi certain deja ecrit dans les acces précédent a $2005) et surtout il faut terminer par lui car c'est lui qui va déclencher le transfère du registre intermediaire au pointer VRAM interne du PPU et qui permet le miracle de modifier le Vscroll pendant le balayage

Bien sure faut aussi des timing plus ou moins précis puisque pendant le balayage ces registres sont utilisé par le PPU et mis a jour.
Cette séquence c'est si on veut un controle de tous les bit (notamment sur Y) mais y a pas mal de cas ou c'est pas forcement nécessaire si t'as pas besoin d'un controle fin tu peux utiliser des séquences plus simple. Une fois que t'as compris le fonctionnement tu trouve tout seul la meilleur solution selon tes besoins et les bit que tu veux modifier. Et apres avoir bien ruminer le truc tu finis par l'assimiler et c'est pas si compliqué que ca en a l'aire.

Pour que ce soit plus claire le mieux c'est la page nesdev
http://wiki.nesdev.com/w/index.php/PPU_scrolling

Mais pour revenir a la SMS a priori non y a pas vraiment de solution de ce genre pour manipuler le Vscroll. Y a juste une bidouille pour fixer un HUD en passant par les mode vidéo SG-1000 qui n'ont pas de scrolling mais avec pas mal de contrainte.

par upsilandre Mer 6 Fév 2019 - 20:26

Ca y est j'ai un truc qui fonctionne avec un belle effet de scaling vertical a 60fps et sans aucun glitch Razz

(meme si c'est pas encore un effet axelay car j'ai pas préparé la table).
J'avais peur de pas avoir assez de cycle CPU mais en fait y a largement la place. Je me suis inquiété pour rien.

par vincent2105 Mer 6 Fév 2019 - 21:07

upsilandre toujours plus haut ! cheers

par Stef Jeu 7 Fév 2019 - 1:14

Ah oui effectivement c'est un peu sioux (mais la doc sur nesdev explique bien) et on voit que c'était pas forcément prévu mais c'est pratique au final d'avoir cette possibilité :)
Je suis que tu pourras nous le sortir le rouleau à la Axelay sur NES !

par upsilandre Jeu 7 Fév 2019 - 11:41

Oui maintenant c'est certain j'aurais ma demo Axelay, la routine fonctionne, la partie la plus sensible est passé. Suffirait que je change les data de ma table pour transformer mon scaling x2 en rouleau sans changer la routine. mais y a d'autre truc a faire avant.
Faut maintenant que je m'occupe de la partie "sky". Y a la partie "ground" avec un scrolling (sur une trentaine d'ecran) combiné a l'effet rouleau mais je garde aussi une bande de 32 pixels en haut pour afficher le ciel comme dans Axelay. Je pense que c'est important pour la perspective d'avoir l'impression d'avoir un horizon mais ca complique les choses, c'est un autre type d'affichage a gérer sur le meme ecran qu'il va donc falloir considérer et j'ai pas une second tilemap pour ce décors.
Du coup j'hésitais entre 3 solutions. Soit ne pas mettre de décors pour le sky et m'amuser a faire un autre type de raster effect sur la palette cette fois et faire un dégradé (c'est ce qui est utilisé dans Axelay).
Soit réserver un veritable espace dans la tilemap pour ce décors sky et déplacer tout ce décors dans la tilemap au fur et a mesure de la progression du scrolling (avec un double buffering) pour ne pas interférer avec la partie "ground".
Ou alors avoir une partie sky qui soit fixe dans la tilemap et profiter du fait que j'ai un controle total de l'affichage du ground ligne par ligne pour "sauter" la partie sky dans la tilemap lors de l'affichage du ground.
Maintenant que je vois que j'ai de la marge dans ma routine d'affichage du ground je pense choisir la dernière solution. Ca serait une facon amusante de profiter du controle total de chaque scanline, pouvoir cacher un second décors dans une meme tilemap malgré le scrolling qui passe dessus, y aura pas d'autre occasion de faire un truc comme ca donc autant le faire.

par Stef Jeu 7 Fév 2019 - 16:56

Je pense que la dernière solution est la meilleur aussi, comme tu dis de toute façon tu controles manuellement ton affichage donc tu peux réserver un emplacement fixe du tilemap pour le ciel :)
Je serai curieux de voir le résultat, et surtout de savoir combien de temps libre il te reste derrière :)

par upsilandre Jeu 7 Fév 2019 - 17:44

J'avais fais le calcule et pas possible de rendre la main au programme principale a chaque scanline. Dans ce cas précis d'un raster effect a chaque scanline la Master System avec le Z80 c'est mieux surtout grace au registre shadow c'est parfait pour ce cas la, sur la demo SMS je pouvais rendre la main et libérer du temps CPU a chaque scanline.
La c'est impossible entre le cout de l’interruption et la gestion complexe du Vscroll ou alors peut etre pour libérer 10 cycles a tout casser, c'est pas intéressant, du coup j'ai vraiment fait un Kernel comme sur Atari VCS, donc une routine qui dure exactement le nombre de cycle d'une scanline et qui prend le controle de tout l'affichage. C'est ce qui fait du coup que je suis large en cycle (puisque y a pas le cout de l'interruption, sauver/restaurer ect...) mais peu de chance de faire tourner un jeu derrière contrairement a la demo SMS.
Si je voulais faire tourner un jeu derrière je pense que je doublerais la taille du ciel (puisque de toute facon j'ai plus de ligne que sur SNES) pour passer a 64 lignes car c'est une portion ou le CPU est libre. Et je ferais l'update du moteur du jeu a 30hz (sauf le scrolling du jeu qui lui reste 60fps) du coup ca me ferait 128 lignes pour le moteur en plus du Vblank et je tenterais probablement quand meme de libérer quelques cycles CPU par scanline meme si c'est pas grand chose. Ca serait quand meme tres limité.

par upsilandre Jeu 7 Fév 2019 - 20:36

Bon finalement la solution avec le ciel fixe dans la tilemap me coute seulement 1 cycle de plus dans le kernel pour sauter par dessus! C'est bien la meilleur solution a priori, ca aurait été dommage de s'en priver.
Mais c'est pas avec ca que je vais remplir mon kernel :). J'ai encore plus de 50 cycles de libre.

Par contre va falloir que je refasse ma routine de maj du scrolling du Vblank pour sauter aussi ce bloc. Je vais en profiter pour en faire une propre et définitive. On verra ca un prochain jour.

par vincent2105 Jeu 7 Fév 2019 - 21:20

Ah, mince, moi qui pensait avoir une rom ou un gif... Razz

Plus anecdotique, de mon côté, j'ai une routine qui fonctionne sur émulateur pour le Zapper (1cible)... Je cherche un concept pour creuser davantage.

par upsilandre Jeu 7 Fév 2019 - 21:29

Si je faisais un jeu je montrerais la progression mais pour une simple demo je pense que c'est plus rigolo de montrer directement le resultat final Razz

Ce qui risque de prendre du temps car je vais diluer ca. La partie habillage risque d’être un peu longue.

J'ai jamais tester les jeux zapper en émulation mais tu me donne envie de fouiller un peu dans le catalogue.

par Stef Jeu 7 Fév 2019 - 21:33

ah ok je n'avais pas compris que tu faisais une routine avec du cycle count, comme l'interruption du 65x est rapide je pensais que ça restait jouable.. mais j'imagine que dans ta boucle tu as une synchro type v-counter ou un autre truc pour être certain d'être bien synchro avec le PPU ?
Enfin avec tout ce que tu racontes, ça reste une belle performance d'arriver à faire ça sur NES (le scrolling à la Axelay) et en plus à y mettre un peu de logique à côté pour faire un mini jeu ^^

par upsilandre Jeu 7 Fév 2019 - 22:02

Stef a écrit:ah ok je n'avais pas compris que tu faisais une routine avec du cycle count, comme l'interruption du 65x est rapide je pensais que ça restait jouable..

l'irq c'est seulement 7 cycles mais apres faut bien sauver le registre d'etat, 4 cycles, puis les registres A,X,Y (dans la RAM c'est plus rapide) ca fait 9 cycles, puis faut éteindre l'interruption du MMC3 et la reinit pour la prochaine ligne c'est encore 8 cycle puis a la fin restaurer les registre, 13 cycles, puis sortir de la routine irq, 6 cycles (qui par contre réactive automatiquement l'irq CPU contrairement au Z80, c'est toujours 2 cycles de gagné).
Si j'ajoute tout ca pour transformer mon kernel en veritable routine irq il reste plus de place au final dans la scanline, ca va libérer au mieux une dizaine de cycle CPU et sans parlé que en faisant comme ca je perd le controle de la synchro (j'ai au mieux 2 choix de timing d'interruption avec le MMC3, peu de chance que ca tombe pile comme j'ai besoin) tandis qu'avec mon kernel qui prend le controle de l'affichage non seulement je me retrouve avec beaucoup de cycle dispo (tout ce que j'ai cité n'existe plus, y a juste un jump a la place pour faire la boucle soit 3 cycles) mais en plus je controle parfaitement la synchro en choisissant le moment ou je boucle ma routine (modulo 4 pixels de marge d'erreur du a l'aléatoire de l'interruption initial qui lance mon kernel. en verité c'est 10 pixels de marge d'erreur mais j'ai utilisé 2 interruptions pour lancer mon kernel. Une première qui sert a mieux synchroniser la seconde en la faisant interrompre au beau milieu d'une série de nop)
Pour ca les registres shadow sur le Z80 c'etait vraiment super cool sur ma demo SMS, c'est vraiment le truc que j'ai adoré sur le Z80, mais c'est pas comparable non plus car j'avais pas non plus les meme contrainte sur le Hscroll de cette demo, pas de contrainte de complexité ni de timing, juste un registre a mettre a jour. mais j'aime bien cette demo SMS car elle laisse vraiment pas mal de ressource CPU disponible.

par Stef Ven 8 Fév 2019 - 0:03

Ah ouais non ça fait effectivement beaucoup trop de cycles perdus.. on dit souvent que le 65x est rapide pour les interruptions (ce qui est vrai si on compare au 68000 par ex) mais il ne fait pas de miracle non plus quand on a 15000 interruptions par seconde (logique aussi), là où le Z80 a vraiment un bonus avec son second set de registre. Je l'utilise aussi dans mon driver son pour entrelacer mon code de playback avec le reste du code du driver, sans ce second set de registres ça serait la misère (ou plutot j'aurai du baisser sensiblement le nombre de channel ou le sample rate).
Mais bon, c'est bien le seul truc que j'aime sur le Z80, franchement sur tout le reste je le trouve assez pénible Razz

(et je ne parle pas du 6502 que je considère comme un demi CPU MDR

).

par upsilandre Ven 8 Fév 2019 - 6:22

Par contre j'ai dis une connerie. Le registre d'etat est sauver automatiquement par l'irq et restauré c'est ça qui fait que c'est quand même efficace (en plus de réactiver l'irq cpu en restaurant le flag correspondant ) ça fait 8 cycles de moins que ce que j'ai dis mais reste toujours le problème du timing de ma routine que ce soit sur nes ou sms

par Invité Ven 8 Fév 2019 - 9:15

Pour ca les registres shadow sur le Z80 c'etait vraiment super cool sur ma demo SMS, c'est vraiment le truc que j'ai adoré sur le Z80, mais c'est pas comparable non plus car j'avais pas non plus les meme contrainte sur le Hscroll de cette demo, pas de contrainte de complexité ni de timing, juste un registre a mettre a jour. mais j'aime bien cette demo SMS car elle laisse vraiment pas mal de ressource CPU disponible.

Normal, d'après la doc NES, la moitié des registres de scroll sont buffered, l'autre avec prise en compte immédiate (une belle connerie soit dit en passant), du coup forcement t'as pas le choix de synchroniser ta routine pile poil pendant le hblank pour éviter d'y toucher pendant l'affichage et avoir des soucis de synchro,alors que si tout les registres étaient buffered, tu aurais toute la ligne précédente pour modifier le scroll .
En plus si j'ai bien compris, tu n'as qu'un seul registre pour X et Y,donc forcement ça allonge la consommation de cycles .

par Stef Ven 8 Fév 2019 - 10:54

Mais du coup tu te synchronises qu'une seule fois par frame ?
Tu n'as pas un flag hblank ou un hvcounter sur lequel tu pourrais te synchroniser pour être sûr de ne pas diverger au fur et à mesure de la frame ?

par Invité Ven 8 Fév 2019 - 12:12

J'ai l'impression qu'il fait une double interruption pour avoir une interruption stable dans la seconde (technique du C64) et éviter la désynchro.
Peut être que il utilise le timer + hsync .

par upsilandre Ven 8 Fév 2019 - 14:37

Oui je fais une seule synchro par frame. Ensuite la routine a exactement le meme nombre de cycle qu'une scanline donc t'as plus besoin de t'occuper de la synchro c'est ce qu'on appel le kernel sur VCS sauf que sur VCS c'est un passage obligatoire qui en fait une routine central de ton jeu d'ou son nom. Ton kernel sur VCS il fait soit 76 cycles CPU soit 152 cycles selon la résolution que tu vises.
La sur NES c'est un peu plus compliqué que sur VCS ou SMS encore une fois a cause du fait que la scanline ne dure pas un nombre entier de cycle CPU du coup mon kernel fait 114 cycles mais une lignes sur 3 il fait 113 cycles. Si je fais pas ca la oui y aura vite une dérive de la synchro.
Ce qui manque aussi c'est une instruction Halt sur le 6502, ca simplifierait la synchro initiale.

par upsilandre Ven 8 Fév 2019 - 14:48

Touko a écrit:Normal, d'après la doc NES, la moitié des registres de scroll sont buffered, l'autre avec prise en compte immédiate (une belle connerie soit dit en passant), du coup forcement t'as pas le choix de synchroniser ta routine pile poil pendant le hblank pour éviter d'y toucher pendant l'affichage et avoir des soucis de synchro,alors que si tout les registres étaient buffered, tu aurais toute la ligne précédente pour modifier le scroll .
En plus si j'ai bien compris, tu n'as qu'un seul registre pour X et Y,donc forcement ça allonge la consommation de cycles .

Oui c'est ca, t'as un seule registre pour X et Y (et dans lequel tu retrouve aussi les 2bit qui servent a selectionner l'écran et qui sont en gros les 9eme bit de X et Y puisque l'ecran virtuel sur NES est en 512x480 mais ces 2bit la du les configure en passant par un autre port)
Par contre ce registre est bien un buffer, c'est pour ca justement que si tu modifies Y dans ce registre ca changera rien a l'affichage comme sur SMS car la partie Y du registre n'est loader qu'une fois par frame au debut donc le changer apres n'a aucun effet et c'est pour ca qu'il faut aller taper directement dans le registre interne du PPU par une autre procédure et du coup faut le bon timing.
Pour X la oui effectivement c'est pas comme sur SMS car quand tu charges X seul les bits de poid fort sont stocker dans ce registre buffer mais les 3 bit de poid faible vont eux directement dans un autre petit registre interne au PPU (ces 3 bit la servent pas au calcule de l'adresse, juste a se positionner dans la tuile) du coup effectivement quand tu vas vouloir modifier X tu vas aussi modifier ce petit registre qui lui par contre n'est pas un buffer mais un registre a usage immédiat par le PPU donc ca va glitcher et impose donc aussi un timing pour modifier X (contrairement a la SMS)

par Stef Ven 8 Fév 2019 - 16:45

upsilandre a écrit:Oui je fais une seule synchro par frame. Ensuite la routine a exactement le meme nombre de cycle qu'une scanline donc t'as plus besoin de t'occuper de la synchro c'est ce qu'on appel le kernel sur VCS sauf que sur VCS c'est un passage obligatoire qui en fait une routine central de ton jeu d'ou son nom. Ton kernel sur VCS il fait soit 76 cycles CPU soit 152 cycles selon la résolution que tu vises.
La sur NES c'est un peu plus compliqué que sur VCS ou SMS encore une fois a cause du fait que la scanline ne dure pas un nombre entier de cycle CPU du coup mon kernel fait 114 cycles mais une lignes sur 3 il fait 113 cycles. Si je fais pas ca la oui y aura vite une dérive de la synchro.
Ce qui manque aussi c'est une instruction Halt sur le 6502, ca simplifierait la synchro initiale.

Oui justement je pensais au fait de ne pas avoir un nombre de cycle entier qui pose problème, ça veut dire que tu dois en plus compter les lignes, ou plutot tu as du faire ton kernel pour qu'il tourne sur 3 lignes (plus simple et plus rapide aussi).
Tu ne peux pas avoir de dérives à cause d'un cycle 'refresh' ou un truc dans ce genre ? en tout cas sur MD tu as de la dérive, à cause du Z80 qui peut voler quelques cycles en accèdant au bus par exemple... du coup tu as intérêt à avoir une synchro (il y a heureusement x manières de l'avoir).

par upsilandre Ven 8 Fév 2019 - 17:47

Ah merde c'est vrai que sur MD ca pose probleme (ca + les interruptions lourde du 68000. Heureusement c'est compensé par la table de scroll). Sur NES y a pas de dérive possible avec la SRAM et a priori sur SMS (ou PCE) j'imagine que c'est pareil car c'est de la SRAM aussi mais c'est vrai qu'un Z80 connecté a de la DRAM ca doit poser problème du coup. Y a peut etre pas tant de machine que ca qui sont idéal pour la synchro avec l'affichage.
La Master System ca me parait une bonne machine pour la synchro, t'as a la fois l'instruction Halt, de la SRAM, une irq intégré au VDP et un nombre entier de cycle CPU par scanline.

par Stef Sam 9 Fév 2019 - 12:48

Sur SMS ça semble assez facile pour autant je ne pense pas que beaucoup de jeux poussent assez loin ce genre d'astuce sur cette machine.
Je ne connais pas bien la ludothèque de la SMS mais de mémoire je n'ai jamais vu de truc super impressionnant. Je pense à Aladdin qui fait du scrolling en semi profondeur avec des murs "en 3D" et Road Rash qui est assez impressionnant avec son rendu tout en soft pour la gestion des "collines" puisqu'on n'a pas de controle sur le VScroll pendant l'affichage. C'est vraiment à partir des 16 bits qu'on a commencé à voir des effets plus complexes et assez poussés... en même temps le hard permettaient d'en faire beaucoup plus.

par upsilandre Dim 10 Fév 2019 - 23:21

J'ai tenté de modifier toutes mes routines pour rendre invisible la bande 256x32 du ciel dans la tilemap mais je viens de réalisé que ca n'est pas suffisant a cause de cette foutu colortable rambo

Sur NES la tilemap est un peu merdique puisque composé a la fois d'une nametable et d'une colortable qui n'ont pas la meme granularité. La nametable a une granularité de 8x8 par octet et couvre un ecran 256x240 mais la colortable a une granularité de 32x32 par octet et elle couvre un ecran 256x256 dont les 16 dernières lignes sont en excedant, y a un petit surplus de data inutilisé dans la colortable.
Du coup le fait de passer d'une configuration de 2 ecrans 256x240 pour mon ground a une configuration d'un ecran 224x240 + un ecran 256x240 ca rend invalide mon fichier colortable d'une trentaine d'ecran. Va falloir que je fasse a nouveau un petit script Lua pour convertir ma colortable en réorganisant chaque octet bit par bit (plutot nibble par nibble). On verra ca peut etre demain.