Hardcore Retrogaming

Démarré par upsilandre, Novembre 09, 2013, 04:00:23 PM

« précédent - suivant »

upsilandre

Pour assouvir certaines pulsions de retrogaming et etant en meme temps un technophile extremiste je me suis mis dans l'idée de progammer moi meme sur les consoles historiques pour enfin comprendre comment fonctionnaient ces machines (les fiches de specs ne disent finallement pas grand chose meme quand elles sont tres detaillées) et ce que c'etait de programmer un jeu a cette epoque.

L'idée c'est deja de se pencher sur l'Atari 2600 pour au moins 4 raisons.
Dabord pour ce qu'elle represente historiquement, puis parce que c'est la premiere console que j'ai eu et sur laquel je me suis initié au jeu video, et puis parce que c'est un hardware extrement vieux et donc exotique ce qui rend l'experience interressante car progammer sur atari2600 ca ne ressemble a aucune autres consoles ulterieurs et sans mettre les mains dedans difficile de comprendre ces differences. Et en plus cerise sur le gateau c'est le meme CPU que la NES qui sera forcement la seconde etape et donc la transition sera a la fois tres interressante par comparaison et facilité.

J'ai pas vraiment d'experience poussé de la programmation (disont que ca remonte plutot a mon adolescence donc y a 20ans voir plus et juste de facon ponctuel) donc ca va etre asser laborieux d'autant que j'ai pas beaucoup de temps a y consacrer et que la faut vraiment aller dans le metal (language machine, penser binaire, maitriser tout le timing d'execution et suivre de pret les deplacements du canon a electron de l'ecran)  mais je vais y aller doucement et savourer car j'y prend vraiment un certain plaisir, autant que ca dure.

Mon premier excercice ca va etre deja de reproduire "Combat" qui est le jeu du launch de l'Atari 2600 (1977), le jeu pour lequel on achetait la console (et que j'avais moi meme). Tres bon jeu pour l'epoque meme si son defaut est d'etre uniquement un jeu versus.
C'est surtout un jeu qui utilise strictement toutes les fonctionnalités hardwares de la machine ni plus ni moins pour ce qu'elles ont été concus, un peu comme si la console avait ete concu pour produire ce jeu, c'est ce qui m'a sauté au yeux apres avoir bien epluché les documents techniques et qui en fait le parfait cas d'ecole contrairement a un "Space Invaders" par exemple qui sera mon second excercice et qui lui est sortie 3 ans plus tard et consistait a porter un enorme succes de l'arcade sur une console qui n'etait pas fait pour cela donc beaucoup de tricks et demande deja une grosse maitrise de la machine (c'est l'uncharted 2 de l'Atari2600)
2 jeux cultes de la machine (avec Pacman) qui seront donc mes 2 etapes pour comprendre au mieux cette machine.


L'emulateur Atari 2600 qu'il faut posseder (avec en bonus un excellent debugger super utile pour la programmation)
http://stella.sourceforge.net/downloads.php
Forcement pouvoir bosser sur emulateur (et donc avec debugger) c'est deja un enorme confort qu'avait pas les gens de l'epoque, c'est aussi pour ca que c'est tres tentant.


Et ce document ou l'on trouve toutes les informations hardwares a connaitre sur la machine et qui est mon support de travail
http://nocash.emubase.de/2k6specs.htm


Combat version original Atari 2600 (1977)




Space Invaders version original Atari 2600 (1980)




upsilandre

Le debugger de Stella est vraiment pratique, incontournable.

Tres drole par exemple de voir s'afficher l'integralité de la RAM de la console juste dans un petit tableau (entouré en rouge).Y a que sur Atari 2600 que tu peux voir ca  :roll:




Si jamais quelqu'un a des questions sur les caracteristiques hardware de cette machine c'est le moment ou jamais, je suis en plein dedans.


Hobes

On t'a déjà dit que tu étais un grand malade ?

Je salue l'initiative, ça doit être passionnant de se replonger là dedans. Surtout que c'est une machine assez ancienne donc il est plus aisée de maîtriser (sans que cela soit facile pour autant) tous les paramètres qui entrent en jeu. Cela dit je ne pense pas que tu puisses réellement te mettre à la place des développeurs de l'époque tant les choses ont changé, non ? Je vois que tu as un utilitaire de debbug très graphique, j'imagine qu'ils ne l'avaient pas autrefois. Idem pour la documentation qui doit être très détaillée. Sans compter que l'accès à celle ci était bien plus difficile vu qu'internet s'est démocratisé.

Par contre je ne vois pas, au premier abord en tout cas, quel effort il aurait fallu pour porter Space Invader sur Atari 2600. Faire un Space Invader c'est assez "simple" dans le fond.

pippoletsu

C'était pas grosso modo les mêmes proc aussi ?

upsilandre

Citation de: Hobes le Novembre 09, 2013, 04:41:02 PM
On t'a déjà dit que tu étais un grand malade ?

Je salue l'initiative, ça doit être passionnant de se replonger là dedans. Surtout que c'est une machine assez ancienne donc il est plus aisée de maîtriser (sans que cela soit facile pour autant) tous les paramètres qui entrent en jeu. Cela dit je ne pense pas que tu puisses réellement te mettre à la place des développeurs de l'époque tant les choses ont changé, non ? Je vois que tu as un utilitaire de debbug très graphique, j'imagine qu'ils ne l'avaient pas autrefois.
oui c'est ce que j'expliquais, le debugger ca change pas mal de chose en terme de confort par rapport a l'epoque, c'est super utile, et le fait de pas avoir a effacer et charger une EPROM chaque fois que tu veux faire un test grace a l'emulation.
Par contre j'ai aussi infiniment moins de temps a y consacrer que les gars de l'epoque donc heureusement qu'il y a ca sinon ca serait pas possible, ca serait un boulot a plein temps et j'ai deja un boulot a plein temps 6 jours sur 7.

CitationIdem pour la documentation qui doit être très détaillée. Sans compter que l'accès à celle ci était bien plus difficile vu qu'internet s'est démocratisé.
Bisarrement la documentation de reference du TIA (le GPU) ca reste un document de 1979 et pour le CPU 6502 c'est a peu pret pareille. Niveau doc y en a pas des tonnes (un seul suffit, celui que j'ai linké qui regroupe tout) d'autant qu'il y a pas enormement de chose a decrire non plus.
Internet t'aide au moins pour démarrer, trouver ces documents, l'emulateurs, le compilateur 6502 (Dasm) ensuite suffit d'utiliser le bloc-note de windows pour taper ton programme et c'est partie.
Ensuite les forums specialisés sont sans doute une source plus interressante mais pour l'instant j'utilise pas (pour galerer un peu tout seul et parce que ca sera forcement en anglais et que ca me fatigue tres vite vu mon niveau et je pense que c'est plus interressant d'y aller une fois que t'as deja une experience)


Citation
Par contre je ne vois pas, au premier abord en tout cas, quel effort il aurait fallu pour porter Space Invader sur Atari 2600. Faire un Space Invader c'est assez "simple" dans le fond.
c'est justement pour ca que je fais cette demarche c'est parce que tu comprend plein de truc qui ne peuvent pas aparaitre au premier abord mais entre Combat et Space invaders c'est vraiment tres different comme aproche.

Y a notement un gros defaut hardware qui ne pose pas de probleme pour un jeu comme Combat mais qui rend tres compliqué un jeu comme Space invaders.
Le TIA peut gerer 2 "sprites" (evidement c'est un peu plus compliqué que ca car c'est pas un GPU NES. le GPU est tres limité, son autonomie n'est pas a la frame mais a la ligne car y a pas de VRAM juste quelques registres donc a chaque ligne il faut alimenter ces registres avec le CPU en synchronisation avec le balayage de l'ecran. CPU qui est donc constament occupé par l'affichage a part pendant les blanking).
Et ces 2 "sprites" qui dans "combat" sont donc les 2 chars ont une position sur l'ecran a definir or on a pas acces au registre qui dit au TIA a quelle moment du balayage horisontal il doit commencer a tracer les 8 pixels du sprite (donc le registre qui donne la position horisontal du sprite), on peut juste incrementer ou décrementer ce registre (et difficilement, seulement pendant un Hblank donc une fois par ligne) mais pas le lire ni l'ecrire et c'est le principale defaut hardware de la machine je trouve (pourtant y a une soixantaine de registres du TIA auquels on a acces), si on avait eu acces ce registre ca aurait simplifier plein de truc.

pour un jeu comme Combat pas de probleme car y a seulement 2 sprites qui sont bien définie et ne change pas, t'as pas vraiment besoin d'avoir acces a ce registre.
Pour Space invaders ca devient beaucoup plus complexe car il va falloir jongler avec ces 2 sprites pour en afficher bien plus (tous les aliens, l'ovni, les 3 boucliers, les 2 joueurs) et donc a chaque fois il va falloir switcher et utiliser des trick indirect pour redéfinir la position horisontal de l'affichage du sprite avec des notions de timing tres pointu (faut bien connaitre le temps d'execution des instructions CPU) et tout ca alors que t'as tres peu de temps car a chaque instruction CPU le balayage ecran a deja avancé d'environ 10 pixels et que tout faire le temps d'un balayage de ligne (ou pire le temps du blanking horisontal juste avant l'affichage d'une ligne car c'est a ce moment la qu'il faut faire les operations sensible comme changer les registres du TIA) c'est tres coton.

En tres gros l'Atari 2600 a un hardware concu pour afficher un "playfield" (le decor) en 40x26 monochrome + 2 sprites monochromes 8x8 (sur la base d'une resolution 160x104) pour chaque joueur + 2 "missiles" qui sont juste des carrés de meme couleur que le sprite "player" correspondant et dont la position horisontal peut etre réinitialisé sur celle du sprite player + une "balle" qui elle est aussi un carré mais qui a la couleur du "playfield"
A l'exception de la balle qui n'est pas utilisé c'est strictement la description de Combat.





upsilandre

#5
Citation de: pippoletsu le Novembre 09, 2013, 04:45:29 PM
C'était pas grosso modo les mêmes proc aussi ?

tu veux dire par rapport au Space invaders Arcade?
non c'est pas du  tout le meme hardware. En arcade c'etait deja du x86 d'Intel et sans doute aussi avec une vrai VRAM et une vrai gestion "bitmap" de l'affichage. et y avait des lignes de 11 aliens (impossible a reproduire)

pippoletsu

Ah oui exact c'était une Intel 8080. Par contre il me semble que du coup c'est pas du x86, qui démarre logiquement avec la 8086.

upsilandre

ca se tiens  :D
ouai c'est encore du vieux 8bits

upsilandre

#8
Ouch je me suis pas mal arraché 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 certainement pas dans des CPU plus moderne (j'ai deja fais un peu d'assembleur x86 y a 20ans) 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.

AdamsVibe

Citation de: Hobes le Novembre 09, 2013, 04:41:02 PM
On t'a déjà dit que tu étais un grand malade ?

Je salue l'initiative, ça doit être passionnant de se replonger là dedans. Surtout que c'est une machine assez ancienne donc il est plus aisée de maîtriser (sans que cela soit facile pour autant) tous les paramètres qui entrent en jeu. Cela dit je ne pense pas que tu puisses réellement te mettre à la place des développeurs de l'époque tant les choses ont changé, non ? Je vois que tu as un utilitaire de debbug très graphique, j'imagine qu'ils ne l'avaient pas autrefois. Idem pour la documentation qui doit être très détaillée. Sans compter que l'accès à celle ci était bien plus difficile vu qu'internet s'est démocratisé.

Par contre je ne vois pas, au premier abord en tout cas, quel effort il aurait fallu pour porter Space Invader sur Atari 2600. Faire un Space Invader c'est assez "simple" dans le fond.

Pas aussi simple quand tu dois gérer un langage de bas niveau comme le langage machine. ( et même pas simple du tout pour beaucoup dans les langage de plus haut niveau )
Mais tu apprend superbement à programme les jeux , ça c'est cool.
Néanmoins la documentation semble assez cool pour l'atari. Si j'ai le temps , je vais me pencher la dessus.

upsilandre

#10
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).


upsilandre

#11
Ca prend forme.
J'ai deja 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é. 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.  :p



upsilandre

Citation de: AdamsVibe le Novembre 10, 2013, 03:25:57 PM
Néanmoins la documentation semble assez cool pour l'atari. Si j'ai le temps , je vais me pencher la dessus.

Plus on est de fous plus on rie  :)

Gmooron

Un truc que j'aimerais faire si j'avais le temps  :clciel:

upsilandre

Bon ca y est je peux piloter mes chars sur la map dans les 16 directions et avec la vitesse d'origine.
Je vais m'arreter la pour ce soir, demain je m'occupe des colisions avec l'arene (faut que je profite de ce jour férié, apres c'est boulot boulot...).