Hardcore Retrogaming

Spacechem c'est chouette mais je me suis dit quite a se casser la tete pourquoi pas le faire sur de la programmation pure et encore mieux sur de la programmation retrogaming de vieille console?

ca m'est evidement souvent arrivé de feuilleter des specs detaillées de vieilles consoles mais au final ca suffit j'avais vraiment a cerner comment fonctionnait ces machines, meme pas de facon aproximative.
alors que tenter de vraiment programmer un truc sans forcement pousser tres loin la demarche ca permet de franchir vraiment un gouffre dans la comprehension des premieres machines qui ont fait l'histoire du jeu video, c'est le jour et la nuit et au moins ensuite ca permet de vraiment en parler.

j'ai envie d'aller vraiment a la source et de progammer sur Atari 2600 avec deja dans l'idée de passer plus tard a la NES ensuite. c'est exactement le meme CPU avec une frequence 50% superieur et 16x plus de RAM (la nextgen  ).

Cette similarité (aparente car ensuite dans l'aproche de la construction de l'image y a sans doute un gouffre interressant) est vraiment une opportunité car si y a bien 2 consoles qu'il faudrait manipuler pour comprendre le debut des jeux video c'est bien ces 2 la, ca tombe bien.
Et le faire dans cette ordre chronologique peut etre tres interressant pour ressentir ce qu'on ressentie les progammeurs quand il a fallu passer a des machines de jeu plus evolué comme la SNES et ce que ca a pu representer en terme d'evolution (apres pourquoi pas aussi tester vite fait la SNES qui reste aussi sur le meme type de CPU)

j'ai envie de profiter que maintenant on trouve tout sur internet (doc, emulateur...) et pourquoi pas pousser l'experience a tester ensuite sur une vrai Atari 2600 et une vieille TV avec une EEPROM de test

tiens nous au courant, c'est un truc qui m'interesse bien.
J'avais étudié rapidement les différents fonctionnements d'un emulateur, mais clairement, pas le temps (et c'est un taff de longue haleine, clairement, avec l'aspect hard, soft en asm, contraintes des becanes de l'epoque sur l'adressage memoire, super important, etc...).

c'est a la fois compliqué car faut etre au plus pret du hardware (faut parfois meme compter les cycles de chaque instruction et suivre de pret la cadence du canon a electron de l'ecran), et simple car le hardware est reduit a sa plus simple expression. tout est la:
http://nocash.emubase.de/2k6specs.htm
http://atarihq.com/danb/files/stella.pdf

ensuite pour programmer suffis juste du bloc-notes windows et de DASM pour compiler le code 6502 et c'est partie

pour l'emulateur faut le plus aboutie, la derniere version de Stella (et qui integre un bon debugger aparement)
http://stella.sourceforge.net/downloads.php

ca me fait marrer quand t'active le debugger et que tu vois l'integralité de la RAM s'afficher devant toi dans un petit tableau  

Projet que je trouve complètement génial.
Et surtout c'est une suite logique du topic sur les framerates.

Je me demande d'ailleurs s'il est possible de mettre la main sur les derniers kits des vielles machines (à partir du moment où ça a existé bien sûr).

j'ai deja pas mal epluché, j'ai maintenant une idée asser precise de comment fonctionne la machine.
Par exemple un jeu du launch comme "Combat" qui est un classic tres sympatique me parait asser accessible car il utilise precisement la machine pour ce qu'elle a ete concu mais dès que tu pars sur du Space Invader, du Pacman ou pire du Pitfall la c'est evident que c'est bouré de tricks. on se rend pas compte comment c'est compliqué de faire ces petits jeux sur cettte machines.

l'architecture est simple, t'a un CPU 6507 (un 6502 mais avec seulement 13 lignes d'adressage soit 4Ko de ROM + la ram et les registres) qui est donc le processeur qu'on va programmer, et a coté un processeur video/audio TIA (+ un chip I/O qui contient la RAM) qu'on pilote en accedant a ses registres (lire ou ecrire) avec le 6502 en visant la bonne plage d'adresse.

mon premier constat c'est que le processeur Video est plus evolué que ce que je pensais avant cela. j'avais plutot cette idée que le CPU faisait tout dans l'atari2600 mais en faite y a quand meme un vrai processeur video (qui tourne a une frequence 3x superieur au CPU comme dans la NES) avec une notion de playfield (le decors) et de sprites (5) et meme capable d'identifier les colisions entre sprites (et avec le playfield)

Maintenant la grosse particularité "archaique" (car c'est pas une NES non plus) c'est que le chip video est quand meme tres limité dans le sens ou son autonomie n'est pas a la frame mais a la ligne. le TIA n'a pas de VRAM, juste quelques registres et c'est au CPU de lui dire ce qu'il doit faire avant chaque ligne en lui remplissant ses registres (qui correspond a 20 pixels horisontal monochrome pour le playfield qui sont soit doublé soit mirroré pour en faire 40 de facon symetrique + 8 pixels monochrome pour chacun des 5 "sprites"). si tu laisse le TIA tout seul il va effectivement t'afficher l'image mais il va juste repeter  x fois la meme ligne avec les infos contenu dans ses registres.

a savoir que pendant le blank horisontal pour preparer la prochaine ligne t'as juste le temps de placer quelques instructions CPU (moins d'une dizaine) ensuite la plus part des trick tordu vont consister a modifier les registres du TIA meme pendant le balayage et donc faire des estimations de ou se trouve le canon selon le temps que prend chaque instruction CPU
c'est aussi a toi de gerer la Vsync, le Vblank, l'overscan... la TV est a tes ordres (a par la Hsync qui est geré automatiquement par le TIA)

bon j'ai reussis a faire tourner mon premier petit progamme d'affichage en partant de rien histoire de deja m'habituer aux outils, a la mise en place d'un programme dans DASM et maitriser les histoires de Vsync, Vblank...
j'ai constament un oeil sur la doc nocash http://nocash.emubase.de/2k6specs.htm donc c'est long mais y a vraiment tout dedans suffis de prendre son temps
c'etait la phase chiante mais au moins c'est fait, maintenant je peux vraiment commencer a bidouiller
et vraiment tres pratique le debugger integré a l'emulateur Stella, si t'es coincé tu finis toujours par trouver pourquoi si tu prend le temps

me faut maintenant une idée d'excercice, soit tenter de reproduire un jeu atari 2600 existant (tout du moins grossierement, les elements principaux sans les detailles chiants) soit un truc original. ou juste continuer a faire des test d'affichage pour comprendre les possibilités et les limites

Dans le cadre d'un exercice, un Space Invader serait correct non ?

Space Invader ca me tente bien pour ce qu'il represente dans l'histoire du jeux video (au japon il est un peu a l'origine de l'industrie du jeu video et meme l'element declencheur pour nintendo)
mais pour commencer c'est compliqué l'aire de rien, c'est deja plein de trick contrairement a combat (rien que les lignes de 6 sprites independant...), pour simplifier faudrait enlever deja les boucliers et le score et l'ovni pour garder que l'essentiel.
je verrais ca

Oui j'ai bien conscience que c'est compliqué (j'avais lu des trucs dessus, je ne sais plus quand).

Mais je pense qu'il y a l'essentiel dans le jeu. Et comme tu l'as dit la meilleure chose à faire c'est d'y aller étape par étape et de voir s'il y a de la ressource qui reste pour continuer (sinon faut revenir un peu en arrière).

Sinon Frogger ça peut être marrant aussi.

Je pense que tout bon débutant commencerai par un pong.

Le problème étant que connaissant Upsi, il risque de torcher un Pong dans la soirée même (au pire demain soir). Puis bon il a déjà programmé des trucs bien avant de ce qu'il a pu dire sur le forum donc Pong me paraît un peu limité par rapport à son objectif de départ (pousser la machine au max pour comprendre l'ensemble des contraintes).

Sinon l'idée pourrait aussi de partir sur un espèce de projet sandbox original et de coder par ordre chronologique d'apparition des différents types de technique/gameplay (c'était souvent lié à l'époque). C'est souvent ce que je fais/faisais quand je me retrouve avec un nouvel outil/moteur. Bon là les contraintes sont quand même hardcore.

Mais personnellement je dirais que les deux jeux qui reviennent souvent c'est :
Space Invader (N'importe quel shmup fait l'affaire):
déplacer un objet,
créer un objet,
collision,
détruire un objet,
incrémenter et afficher un score,
sauvegarde du highscore (mais bon là je crois que c'est mort non?)

Super Mario Bros :
scrolling,
inertie,
velocité,
changement d'état du player,
différent comportement selon les ennemis,

Là on a dû ratisser largement tout ce qui se fait jusqu'à aujourd'hui vu que c'est la base de tout.
Et bien sûr avec ça faut accompagner des choix graphiques/animations variés histoire d'avoir un retour visuel sinon ce n'est pas drôle. C'est d'ailleurs à ce moment là que ça peut devenir coton.
Bon après on peut amener sa touche perso suivant le feeling.

Après faut pas non plus oublier que niveau input on a un stick + un bouton. On ne peut pas se permettre des folies non plus si on ne peut jouer avec. Après on peut penser à des combinaisons. Par exemple un jeu de plaforme avec un bullet-time qu'on active avec stick vers le bas + bouton mais qui ne ralenti le temps qu'à une distance de pixel max du player (selon un radius).

On peut aussi prendre des intentions de devs d'aujourd'hui et essayer de voir comment certaines visions/approches auraient pu être matérialiser à l'époque (j'aurai été prof ça serait le genre de sujet à la con que j'aurai donné d'ailleurs). Et là ça serait carrément terrible parce qu'éventuellement il n'y a que deux choix:
- Soit on se retrousse les manches et on simplifie pour n'en garder ce que le strict essentiel réalisable. (mais bon on est plus dans un délire créatif là et ce n'est pas le but du jeu).
- Soit on attend la génération d'après, après avoir buté sur le sujet de manière sûre et certain.

L'inverse aussi est viable : prendre un vieux concept à la réalisation moisie et faire un truc mais mieux foutu sur exactement la même plateforme.

Nan franchement il y a moyen de se faire plaisir. Après c'est juste l'approche générale de l'expérimentation qui dépend de chacun.

un pong.... ou un 2D Tetris...  

Sinon moi je vous rejoins dans le délire quand on en sera à la PS1... ça me rappellera des bons souvenirs !

C'est pas que j'aime pas l'asm et l'archi old school (au contraire chui pas mauvais) mais j'ai pas le temps en ce moment et puis se mettre à plusieurs sur un jeux 2600 ou NES c'est un peu se prendre pour Rockstar sur GTA 5

oui je vais tenter le space invader je pense que c'est le plus interressant mais par contre je compte pas y passer mes journées (je vais pratiqué ca plutot comme un puzzle game)
je vais essayé de profiter que je travaille pas aujourd'hui pour demarrer apres on verra...

space invader est deja un jeu 4Ko donc j'aurais pas plus de place. ca fait pas beaucoup, pareille pour la RAM 128 octets mais ce qui m'inquiete le plus c'est la maitrise du nombre de cycle cpu dans chaque Hblank pour préparer l'image, t'as juste la place pour environ 6 a 8 instructions, ca demande de bien maitriser la programmation 6502 c'est ca le plus chiant, c'est censé venir avec l'experience et j'ai pas le temps

perso, cela me fait penser à l'ère Hebdogiciel avec les bugs dans le code

bon voila ou j'en suis



j'ai deja un decor et un sprite qu'on peut faire bouger au joystick de gauche a droite et dont le deplacement se bloque au bord du précipice

contrairement a la version original qui represente les limites de ta zone de deplacement simplement par 2 petits traits au sol (une limitation des deplacements qui t'oblige a etre toujours sous le feu des ennemies donc c'est pour des raisons de gamedesign) j'ai préferé contextualisé la chose et representer plutot 2 precipices, 2 trous dans le sol de par et d'autre du canon pour plus de realisme  
ca doit etre l'epoque qui fait ca  


la version original




a part ca moi je sais maintenant pourquoi y a plein de petit trait noir degeux sur le coté gauche



y a une fonction dans le TIA (le GPU donc) qui lorsque tu l'active va mettre a jour la position horisontal des 5 sprites (c'est a dire le delai entre la Hsync et le moment ou le TIA va commencer a tracer ton sprite) selon ce qui est contenu dans d'autre registre du TIA
au dela du fait que j'ai du apprendre a mes depend que cette fonction doit etre activé juste apres une Hsync sinon ca bug et le resultat est aleatoire, et bien meme quand tu l'actives juste apres une Vsync ca crée quand meme ce petit bug en debut de ligne (donc chaque fois qu'il y a un trait noir ca veut dire que le programme a utilisé cette fonction a cette ligne precisement, par exemple y en a un devant chaque ligne d'aliens)



en tout ca merci encore une fois le debugger de Stella, c'est vraiment super utile. c'est l'avantage d'arriver aussi tard les emulateurs sont encore plus aboutie. y en avait un dans un autre vieux emulateur mais pas aussi bien je pense

je vous met ma ROM si vous voulez deja tester (je vous conseille l'emulateur stella que j'ai mis au debut du topic)
http://dl.free.fr/getfile.pl?file=/hzHb0Eu3

ca m'a deja permis de toucher a pas mal de truc
la prochaine fois j'essayerais d'afficher une ligne de 6 aliens qui se deplace

je me rend compte en fait que les seuls veritable sprite y en a que 2 (player1 et player2) les autres n'ont pas de representation graphique (juste un point dont on peut faire varier la taille)
vu que le playfield est aussi tres limité en resolution (20 pixels x2 pour toute la largeur de l'ecran) le seul moyen de representer des elements graphics avec un minimum de precision horisontal c'est de passer par les sprite P1 et P2


par exemple sur cette image de pitfall



le feuillage vert foncé en haut c'est gerer par le playfield (on reconnait la symetrie central et la resolution horisontal limité a 20x2 pixels).
les troncs d'arbe aussi (symetrie central et une epaisseur de 1 pixels de playfield)
mais les petits bout de branche qu'on voit entre les tronc et le feuillage ca c'est du sprite P1 et P2. c'est le seul moyen d'obtenir ce niveau de detail.
pour la liane je miserais sur un empilement de sprite de type "ball" en version 1 pixel


et pour ecrire activision en bas a mon avis c'est compliqué car ca ne peut etre qu'un entrelacement de sprite P1,P2,P1,P2 sauf qu'il faut changer l'etat des registre entre les premiers P1,P2 et les seconds or tu dois avoir juste le temps d'executer une seul instruction (8 pixels d'un sprite c'est seulement 8/3= 2.66 cycle cpu et les instruction cpu prennent au minimum 2 cycles pour les plus simple) et encore a condition d'avoir prevu le coup et d'avoir charger les registres du CPU (et y en a que 3) avec les données en question a l'avance pour avoir juste a executer une instruction rapide a partir des registres cpu

voilà ce que je comprends :



 

le vortex de merdier pour simplement afficher et deplacer une ligne de 6 aliens
je commence seulement a entrevoir les solutions (et surtout a cerner celle qui ne peuvent pas fonctionner) et tout le merdier que ca va engendrer en cascade

notement le TIA utilise un registre interne pour determiner a quelle moment de la scanline il commence a afficher le contenu du registre du sprite P1 ou P2, c'est ce qu'on va appeler la position Horisontal du sprite en question
sauf qu'on a aucun acces a ce registre, on peut pas par exemple aller il inscrire la position horisontal qu'on souhaite. on peut seulement le reset ou l'incrementé et le decrementé (et seulement une fois par scanline et seulement apres une Hsync)

or pour afficher cette putain de ligne de 6 aliens j'ai pas d'autre choix que d'utiliser en meme temps les 2 sprites P1 et P2 mais le sprite P1 je l'utilise deja pour le canon mobile qu'on dirige.
et si je dois utiliser le sprite P1 a la fois pour les aliens et le canon ca veut dire obliger de reset le registre de position horisontal du sprite a chaque fois que j'affiche l'un ou l'autre.

du coup a chaque fois que je dois afficher le canon par exemple il faut que je remette dans le registre de position horisontal la bonne valeur tel qu'elle etait a la frame precedente mais comme on a pas acces a ce registre faut le faire de facon indirect avec la fonction reset qui va mettre dans le registre de position H du sprite la valeur qui correspond a la position du canon a electron au moment ou tu utilise cette fonction donc il faut compter le temps que prend chaque instruction pour savoir a peu pret ou se trouve le canon ce qui va te donner une position aproximative (a priori par interval de 15 pixels car la boucle la plus rapide prend 5 cycles cpu soit 15 pixels) qu'il faut ensuite ajusté avec plusieurs incrementation ou decrementation (une seul fois par ligne donc sur plusieurs lignes) qui sont les seuls fonction qui permettent d'agir sur ce registre de position H et de le positionner au pixel que l'on souhaite. un merdier pas possible

dailleurs sur le screenshot de la page precedente ou l'on voit les petits trait noir sur le coté y a un endroit ou l'on en voit une douzaine d'affilé. je pense que c'est le moment ou il reconditionne le registre de position horisontal du sprite P1 utilisé pour le sprite du canon qui va pas tarder a etre affiché

Difficile de s'y mettre les semaines de boulot. programmer c'est bien quand t'as 5 ou 6 heures devant toi et le cerveau pas trop fatigué. en une journé de congés tu fais au moins ce que tu ferais en une semaine de boulot. me faudrait des conges mais j'ai rien les prochain mois


en tout cas j'ai quand meme reflechie pour Space invader et tout les problemes de gestion des sprites et de timing que ca implique, je commencais a voir plus ou moins la solution mais je me suis vraiment rendu compte que c'etait pas la bonne facon de demarrer l'aprentissage de l'atari2600, c'est vraiment un jeu qui demande deja une grande maitrise de la machine du coup j'ai transité temporairement sur "Combat" qui est vraiment pour le coup le cas d'ecole ideal pour l'aprentissage. je ferais Space invader en second pour pouvoir me concentrer uniquement sur les difficultés (et puis j'ai pas envie d'aller chercher sur des forum specialisé ca n'aurait plus grand interet, la demarche c'est justement de galérer tout seul pour se mettre dans la situation de l'epoque et donc voir les difficultés)


"Combat" c'est le jeu du launch de l'atari 2600 et de loin le meilleur a ce moment la, celui pour lequel on achetait la console. je l'avais moi meme a l'epoque (donc il est aussi doublement historique pour moi, dailleurs je l'ai toujours), son gros defaut c'est que c'est un jeu uniquement versus mais tres bon dans ce genre (c'est meme resté le meilleur de la console je pense), asser riche comparé a un pong et avec pas mal de mode de jeu different
et avec ce que je sais maintenant j'ai vraiment l'impression que le GPU de l'atari2600 a ete concu avec ce jeu en tete car chaque element de ce jeu utilise chacune des particularités du GPU. c'est pour ca que c'est l'excercice ideal pour commencer

a l'inverse Space Invader est arrivé 3 ans apres, c'est le "Uncharted 2" de l'Atari2600 qui pousse la machine.
la console n'etait pas pensé pour faire tourner ce genre de jeu mais il se trouve que ce jeu a fait exploser l'industrie du jeu video de par son succes et que Atari cherchait un jeu pour relancer fortement la vente de sa console donc il a fallu faire entrer ce jeu dans l'Atari2600 a coup de pompe.
C'est plutot reussit mais y a 3 ans d'experience derriere (et 4Ko de cartouche vs 2Ko pour Combat)
C'est en tout cas pas la meme categorie et ca on le comprend vite quand on fait ma demarche


pour les inclutes combat c'est ca



je met une image du mode de jeu numeros 2 qui etait le plus interressant et qui est celui que je vais reproduire

Pour l'instant j'ai deja recuperé a la main les sprites (16 sprites pour la rotation complete du char) et le decor
je les redessines pixel par pixel (8*8 pour les sprites) sur paint. ca me sert de support ensuite avec le quadrillage paint pour convertir chaque ligne de tete en valeur hexadecimal. c'est un peu chiant mais bon y en a pas des tonnes non plus (j'aurais pu aussi les retrouver dans la cartouche grace au debugger mais pas sur que j'aurais mis moins de temps)
mes outils de devs: le Bloc-note et Paint

au final les 16 sprites ca donne ca (128 octets):

Citation :

   BYTE $63,$63,$7F,$7F,$7F,$6B,$08,$08
   BYTE $04,$0E,$4E,$FF,$FF,$79,$64,$24
   BYTE $18,$1C,$0E,$DF,$FF,$7C,$3A,$19
   BYTE $18,$3E,$1F,$1C,$7C,$FB,$78,$1C
   BYTE $FC,$FC,$38,$3F,$38,$FC,$FC,$00
   BYTE $1C,$78,$FB,$7C,$1C,$1F,$3E,$18
   BYTE $19,$3A,$7C,$FF,$DF,$0E,$1C,$18
   BYTE $24,$64,$79,$FF,$FF,$4E,$0E,$04
   BYTE $08,$08,$6B,$7F,$7F,$7F,$63,$63
   BYTE $24,$26,$9E,$FF,$FF,$72,$70,$20
   BYTE $98,$5C,$3E,$FF,$FB,$70,$38,$18
   BYTE $38,$1E,$DF,$3E,$38,$F8,$7C,$18
   BYTE $3F,$3F,$1C,$FC,$1C,$3F,$3F,$00
   BYTE $18,$7C,$F8,$38,$3E,$DF,$1E,$38
   BYTE $18,$38,$70,$FB,$FF,$3E,$5C,$98
   BYTE $20,$70,$72,$FF,$FF,$9E,$26,$24

et le decors du mode 2 (72 octets):

Citation :

ArenePF0
   BYTE $FF,$1F,$1F,$1F,$1F,$1F,$1F,$1F,$1F,$1F,$1F,$1F,$1F,$1F,$1F,$1F,$1F,$1F,$1F,$1F,$1F,$1F,$1F,$FF
ArenePF1
   BYTE $FF,$00,$00,$00,$00,$00,$00,$00,$00,$60,$20,$21,$21,$20,$60,$00,$00,$00,$00,$00,$00,$00,$00,$FF
ArenePF2
   BYTE $FF,$00,$00,$00,$80,$80,$80,$80,$00,$00,$00,$07,$07,$00,$00,$00,$80,$80,$80,$80,$00,$00,$00,$FF

pour les sprites j'aurais pu me contenter de 9 et d'utiliser une fonction de symetrie du GPU pour les 7 autres (juste un flag qui inverse les bit de l'octet du registre GRPO et GRP1 ou sont stocker l'unique ligne de sprite en court d'affichage)
mais y aura pas de probleme de place sur cette excercice, aucune interet a economiser quelque octet et puis le fait d'avoir 16 sprites de 8 pixels c'est des valeurs super pratique a manipuler et a indexer.
Le CPU est basique, il ne fait pas de multiplication, de division... les instruction que tu utilise c'est plutot des instructions de manipulation binaire, du decalage binaire, de la rotation binaire, du AND... bref faut penser binaire autant que possible pour avoir un code jolie et 16 c'est beaucoup mieux que 9 comme nombre.



donc j'ai deja pu mettre en place le decors (j'ai changé la couleur qui est dégeulasse et illisible sur l'original) et j'ai mon sprite animé du Char qui tourne dans un sens ou dans l'autre en utilisant le stick




prochaine etape gérer le deplacement

Ouch je me suis pas mal arracher les cheveux sur le CPU. dès que j'ai commencé a utiliser des operations arithmetiques (ca se limite a additionner et soustraire. Sur ce genre de CPU pas de multiplication,division...) j'ai eu des problemes.

Deja avec les "carry", un flag du CPU qui s'active ou pas selon les operations et qui a vite fait de mettre le boxon dans tes calcules car il peut tres bien parasiter un calcule 100 cycles plus tard si rien ne l'a modifier entre temps.
Et histoire de compliquer les choses son comportement n'est pas vraiment intuitif notement la soustraction du 6502 est asser particuliere, quand tu fais 10 - 4 par exemple ca te donne pas 6 mais 5 car le CPU fait A - B - 1 + C (carry) donc pour avoir une soustraction juste il faut dabord penser a activer le flags "carry". Donc deja j'ai pas mal galéré la dessus avant de comprendre (y avait la solution d'additionner un nombre negatif mais je voulais quand meme comprendre et puis l'addition nécéssite aussi de faire attention au carry mais dans l'autre sens ce qui est quand meme plus intuitif)

Mais en meme temps que ce probleme j'avais une seconde galere inextricable qui etait par dessus (ce qui n'a pas aidé).
Chaque fois que je testais mon programme ca fonctionnait ou ca bugait au lancement de facon aleatoire (a peu pret a 50%).
Vu le coté aleatoire et apres quelques tests divers (j'etais encore sur mes problemes de carry donc je pensais que c'etait encore lié) j'ai finis par me dire que ca pouvait venir de l'initialisation virtuel de la console (au démarage l'emulateur met des valeurs randoms dans la RAM pour simuler une vrai console et tous les bug que ca pourait générer) mais non ca pouvait pas etre ca car je fais tres peu usage de la RAM pour l'instant puis je me suis rendu compte que les flags d'etat du CPU etaient aussi activés de facon aleatoire au démarage donc tout de suite j'ai pensé au flags carry encore une fois.

Mais non ca pouvait pas etre lui car dès le debut du programme ce genre de flag etait alteré peu importe leur etat initial, pareil pour le flag "negatif", "overflow", "nulle"... puis la je decouvre un flag etrange qui n'existe pas dans des CPU plus moderne, le flag BCD (binaire codé decimal) qui sert a modifier le fonctionnement des instructions d'additions et de soustractions qui passe donc en mode BCD pour simplifier ensuite un possible affichage decimale sur l'ecran (par exemple un score a plusieurs decimal) et ce foutu flag une fois activé il reste tout le temps activé (aucune operation ne peut le modifier) tant que tu le met par sur off avec une instruction dédié.
Donc ce flag s'activait de facon aleatoire au démarrage  :fou:


Tout ca pour dire qu'on peut pas sauter les etapes, en meme temps qu'on apprend a maitriser les specificités hardware de l'Atari2600 il faut aussi en parallele decouvrir et maitriser le fonctionnement du CPU 6502, l'un ne vas pas sans l'autre.

Bon ca y est je commence a avoir un moteur d'affichage qui semble tenir la route apres plusieurs remaniement.

C'est vraiment la qu'est toute la difficulté et la particularité de l'Atari2600 par raport a toutes les autres consoles c'est qu'il faut gérer l'affichage soit meme avec le CPU et donc il te faut un moteur d'affichage suffisament optimisé pour faire une boucle complete en moins d'une scanline (c'est a dire en moins de temps que ne met le canon a electron a parcourir une seul ligne d'ecran)
... en faite pas tout a fait. Heureusement on a le droit a 2 scanlines car si on le fait en une seul scanline ca permet d'avoir effectivement un affichage 160x224 mais c'est une resolution anamorphique (resolution vertical 2x superieur a la resolution horisontal) donc en toute logique on double les lignes pour avoir un affichage 160x112 qui est la resolution correct d'utilisation (et de toute facon en une scanline tu peux pas gerer un affichage classic)

avec 2 scanlines ca commence a etre tenable. Ca veut dire faire tenir ton moteur d'affichage en une cinquantaine d'instructions CPU mais faut quand meme etre meticuleux car y a un certain nombre de branchement conditionnel a tenir pour decider a la prochaine ligne quelle partie du décor tu vas afficher? est ce qu'il faudra afficher le sprite du player1? et quelle sprite (pour la rotation)? et quelle ligne du sprite? ensuite pour le player2 puis pour les 2 missiles. Et aussi charger tous les datas correspondant dans les bons registres du TIA avec la contrainte suplementaire que cette etape ne peut etre faite uniquement pendant le tres court instant de Vblank juste apres la Vsync. Et ca c'est pour un jeu juste "classic" comme Combat.

Une cinquantaine d'instructions ca se comsomme tres vite surtout que la on parle d'instructions tres basique et avec tres peu de registres tampon (juste un registre d'accumulation et 2 registres d'indexations) mais heureusement la RAM a tres peu de penalité comparé a ce qu'on connait aujourd'hui. Ici un acces a la RAM plutot qu'a un registre te coute environ 50% de cycles suplementaire donc la RAM c'est presque comme 128 registres suplementaires (dailleurs meme en quantité j'ai pas l'impression que la RAM puisse etre vraiment un bottlneck).

Ca prend forme.
J'ai l'affichage du décor + l'affichage des sprites des 2 joueurs bien positionné et la possibilité pour chacun des joueurs de faire tourner son char sur place dans un sens ou dans l'autre (mais on peut pas encore avancer ca sera la prochaine etape avec la gestion des colisions avec le décor)





J'ai l'impression que le plus chiant est passé. Cette fois mon moteur d'affichage tourne bien, meme sur une ligne full décor + les 2 sprites des joueurs il me reste encore 30% de temps libre pour la gestion de l'affichage des missiles de chaque joueur. Ca devrait passer.  

Merci pour les updates,
Super intéressante ta démarche.