Re: Mes questions sur mon projet Coleco

par **TotOOntHeMooN** Sam 26 Aoû 2017 - 22:38

upsilandre a écrit:Mais ce systeme de palette par ligne du mode 2 c'est quand meme pas pratique, ca permet plein de couleur mais c'est lourd en data (a peu pret autant que du 2bpp) et ca vaut pas un vrai mode 2bpp (NES) en terme de liberté graphique (alors que potentiellement ca permet d'afficher 16 couleur par tuile contre 4 seulement pour du 2bpp).

Mais pour peut qu'on s'en donne la peine, ça fait vraiment la différence avec les autres jeux.

par upsilandre Dim 27 Aoû 2017 - 13:59

C'est claire mais c'est ca qui est terrible c'est que si t'as un minimum d'ambition graphique t'es obligés de passer par ce mode 2 et c'est ce que fond tout les gros jeux MSX, SG-1000, Colecovision. Et le probleme c'est pas seulement la création des pattern (ca peut etre une gymnastique amusante pour un graphiste, ou en tout cas etre satisfaisant une fois le défi relevé comme tout les truc tordu) mais aussi le fait que ce mode soit concu pour du bitmap et par vraiment pour du "jeu video" avec un gros gachie de VRAM. C'est tellement absurde vu qu'il manquait vraiment rien pour autoriser la possibilité de fixer un tileset et en faire un vrai mode "jeu video" que ca ressemble vraiment a un bug ou alors ca trahit (avec l'absence de scrolling) que ce TMS9918 etait vraiment destiné a la micro plus qu'aux consoles (malgres que ce soit sur le marché console qu'il aura le plus d'impact)

par **TotOOntHeMooN** Dim 27 Aoû 2017 - 14:30

Il y a de ça, effectivement.

par upsilandre Lun 28 Aoû 2017 - 23:13

est ce que toi Tu utilises les fonction du bios, au moins celle de base?
Y a des fonctions qui m'amusent beaucoup. Y a meme une gestion haut niveau des objets graphiques mobile qui permet de s'affranchir du simple sprite hardware et de proposer 2 autres type d'objet mobile en software. Ce qu'ils appellent les "semi-mobile" qui sont en fait des tuile de background utilisé comme des sprites (et avec reconstruction automatique du background dèrriere) mais qui se déplace donc de facon saccader (par tuile) et aussi des objets "mobile" qui sont carrement des sprites software facon Golden Axe ou Mortal Kombat sur Master System ou la routine du bios va produire en temps réel les pattern en mixant celle de l'objet (format 16x16 donc comme un sprite hardware) avec le background (et toujours en sauvegardant le background pour pouvoir le restaurer ensuite).
J'ose meme pas imaginer comment ca doit etre lent et inutilisable (et ca bouffe aussi pas mal de ressource dans le tileset puisque faut réserver 22 tuiles pour un seul sprite software), mais je trouve ca trop stylé comme fonction bios Very Happy

par **TotOOntHeMooN** Mar 29 Aoû 2017 - 13:45

Si tu parles de Risky Rick, le BIOS n'est pas du tout utilisé.

C'est vrai que les fonctions proposées sont très complètes et bien pensées. Il est vraiment dommage qu'un BASIC n'ait pas été proposé pour permettre à tout un chacun de les exploiter via l'ADAM.
(sinon, elles sont beaucoup trop lentes pour du commercial et on en voit le résultat)

Le top serait de toutes les réécrire pour avoir un BIOS alternatif plus puissant mais compatible. On pourrait ainsi proposer une nouvelle console ou carte mère de remplacement sans problème de droits.

As-tu une Coleco et de quoi charger des ROM d'ailleurs ?

par upsilandre Mar 29 Aoû 2017 - 15:45

nan j'ai jamais touché une coleco

par **TotOOntHeMooN** Mar 29 Aoû 2017 - 15:46

Personne en a en fait ! MDR

par upsilandre Jeu 31 Aoû 2017 - 14:42

En tout cas ca m'a donner envie de programmer un peu sur Coleco, un pretexte surtout pour me mettre au Z80 (c'est le bordel pour moi le jeu d'instruction du Z80).
J'ai pas l'intention de produire quoique ce soit, juste des truc du genre afficher une image, un sprite, pour tater le bousin. Je suis pas sure que ca vaille le coup d'ouvrir un autre topic.

par upsilandre Jeu 31 Aoû 2017 - 20:57

Est ce qu'il existe un bon debugger Colecovision? J'ai rien trouvé de mieux que Mekka et ca reste quand meme loin de ce qu'on trouve sur NES (ce qui est un peu logique mais sait on jamais)

par **TotOOntHeMooN** Jeu 31 Aoû 2017 - 22:53

Jettes un oeuil à BlueMSX au cas où.

par upsilandre Jeu 31 Aoû 2017 - 23:00

Oui j'avais deja testé, c'est possible que ce soit mieux en terme d'emulation (car j'avais deja repéré des bug d'emulation coleco sur Mekka) mais en debugging Mekka est quand meme mieux je toruve.
Bon je crois qu'en emulation Coleco il y a pas grand chose quand meme.

par Monos Ven 1 Sep 2017 - 5:14

Comment vous stalker mon topic !

par upsilandre Ven 1 Sep 2017 - 14:10

J'ai l'habitude de squater les topic

j'aime pas trop ouvrir des topic car j'ai rarement de quoi le justifier (pas de projet) et puis ca permet de rendre les autres topic plus actif mais si tu préfère que j'ouvre un autre topic n'hesite pas d'autant que je vais sans doute poluer avec des questions Razz

par Monos Ven 1 Sep 2017 - 17:59

Non Non c'est bon. Quand j'aurais le projet concret, j'ouvrirais un topic de mon projet, ça peut être cool un topic coleco.

par tetsuro Ven 1 Sep 2017 - 19:11

Oui ça serait cool de programmer sur Coleco !
- Tu code avec quel langage ?
- Quel IDE ?
- Des logiciels annexes genre pour les sprites, la musique etc ?

par Monos Ven 1 Sep 2017 - 20:01

Le langage c'est du C avec le Kit de M. Bienvenu.
Not pad ++ pour écrire le code.
Et dans le kit il y a des logiciels pour faire des graphismes.

par upsilandre Ven 1 Sep 2017 - 20:22

Moi ca sera assembleur mouliné avec tniASM
Du python si nécéssaire
Notepad ++
ICVGM pour les tuiles
Mekka et Bizhawk pour l'emulation

Mais bon c'est l'histoire de 2 ou 3 semaines. Je pense pas m'attarder sur la machine (apres on sait jamais si ca m'amuse).

par upsilandre Sam 2 Sep 2017 - 20:21

Je galère bien sur le jeu d'instruction Z80 qui est pas facile a appréhender mais ca commence a entrer, y a beaucoup de chose differente par rapport au 6502, c'est marrant de les découvrir, y a des choses qui surprennent.
J'ai bien galéré aussi sur l'interruption NMI, je comprenais pas pourquoi ca marchait pas alors que je l'avais activé mais suffit pas d'activer le NMI, il faut aussi reset un autre flag a chaque interruption sinon le NMI ne se relance pas la frame suivante et t'es comme un con (en gros le NMI du TMS9918 est conditionné par 2 flags, pas un seul, ca aussi c'est piegeux quand tu viens de la NES)
Ensuite j'ai galéré aussi pour ecrire en VRAM car cette foutu doc officiel de Texas Instrument de 1982 est ERRONÉE bordel!
Ce tableau est faux
Mes questions sur mon projet Coleco - Page 2 Fail_Doc_TI_TMS9918

Mes questions sur mon projet Coleco - Page 2 Fail_Doc_TI_TMS9918

J'ai galéré aussi pour trouver l'adresse des ports de la coleco car autant il est facile de trouver de la doc sur le Z80 ou le TMS9918 , autant ce qui concerne les particularités propre a la Coleco (comme le cablage qui définie donc le mapping memoire) c'est difficile avec des info contradictoire. En plus je m'etais moi meme emmêlé les pinceaux, j'avais trouvé la bonne info mais j'avais inversé les valeurs des 2 port du VDP et je me suis obstiné et forcement ca marchait pas. J'ai finit par aller chercher l'info dans le bios de la coleco. Au final maintenant quand je veux des infos sur la coleco je vais directement lire le code du bios qui a ete retranscrit et c'est pas mal comme source d'info.

D'ailleurs j'ai vu que pour ecrire en VRAM le bios utilise ce type de loop

Code:: loop: outi nop nop jp nz,loop

Donc j'ai une question pour TotOOntHeMooN si jamais t'as la reponse. Je sais que quand j'avais fait des recherche sur la Master System j'avais lu qu'il fallait pas enchainer les acces VRAM avec moins de 29 cycles pendant l'affichage mais normalement un seul nop devrait suffire puisque ca fait deja une boucle de 30 cycles. Pourquoi dans le bios ils utilisent une boucle de 34 cycles? Est ce que c'est juste du zèle par sécurité pour etre vraiment large (ce qui peut se comprendre surtout quand t'as pas beaucoup de recule sur le hardware) ou est ce que vraiment la boucle a 30 cycles pose probleme? En emulation ca passe tres bien mais sur du vrai hardware je sais pas.
Et enchainer les outi (donc tout les 16 cycles) ca passe vraiment pendant le Vblank? je crois que c'est la limite aussi.

voila mon premier compte-rendu. Pour moi c'est quand meme le meilleur moment quand tu découvrir une nouvelle machine, c'est la que t'apprend le plus de truc.

par fanoplusplus64K Dim 3 Sep 2017 - 13:18

upsilandre a écrit:
D'ailleurs j'ai vu que pour ecrire en VRAM le bios utilise ce type de loop
Code:
loop: outi nop nop jp nz,loop
Donc j'ai une question pour TotOOntHeMooN si jamais t'as la reponse. Je sais que quand j'avais fait des recherche sur la Master System j'avais lu qu'il fallait pas enchainer les acces VRAM avec moins de 29 cycles pendant l'affichage mais normalement un seul nop devrait suffire puisque ca fait deja une boucle de 30 cycles. Pourquoi dans le bios ils utilisent une boucle de 34 cycles? Est ce que c'est juste du zèle par sécurité pour etre vraiment large (ce qui peut se comprendre surtout quand t'as pas beaucoup de recule sur le hardware) ou est ce que vraiment la boucle a 30 cycles pose probleme? En emulation ca passe tres bien mais sur du vrai hardware je sais pas.
Et enchainer les outi (donc tout les 16 cycles) ca passe vraiment pendant le Vblank? je crois que c'est la limite aussi.

voila mon premier compte-rendu. Pour moi c'est quand meme le meilleur moment quand tu découvrir une nouvelle machine, c'est la que t'apprend le plus de truc.

Salut, le souci des timings vers le VDP c'est qu'ils sont théoriques, j'ai remarqué qu'en réalité ils sont plus importants sur certaines machines car après test sur certaines routines j'ai du ajouter du temps.
Après sur les timings vbl/hors vbl , je m'emmerde pas à savoir vu que je travaille tout le temps sur la vram donc je prends toujours le pire cas pour être sur d'être compatible à 100%.

par upsilandre Dim 3 Sep 2017 - 14:14

oui j'imagine que cette histoire de 29 cycles est pas fiable a 100% d'ou la boucle de 34 cycles dans le bios (qui lui aussi prend par defaut le pire cas). Donc au final t'as adopter la meme stratégie que le bios par la force des choses. c'est intéressant si t'as vraiment vu des test planter a 30 cycles, ca fait au moins un témoignage concret. merci.

Sinon j'ai un peu exagéré en disant que le tableau de TI est faux. En fait ils numerotent les bit a l'envers, pour eux les bits de poid fort on des petits numeros et les bits de poid faible les gros, c'est tres déroutante d'autant que meme a l'epoque on faisait pas ca, j'en ai lu pas mal des docs d'epoque.

par vingazole Dim 3 Sep 2017 - 14:28

upsilandre a écrit:j'avais fait des recherche sur la Master System j'avais lu qu'il fallait pas enchainer les acces VRAM avec moins de 29 cycles pendant l'affichage

En réalité c'est 26 cycles minimum sur Master System, pas 29 Wink

par upsilandre Dim 3 Sep 2017 - 14:34

Donc tu met aucun nop et ca passe tranquille? Si c'est comme ca, ca tombe plutot bien.

par vingazole Dim 3 Sep 2017 - 14:42

Oui, ça colle parfaitement avec la boucle "-: outi/jp nz,-" thumleft

C'est utilisé sur Space Harrier ou pour les donjons de Phantasy Star, par exemple.

Sinon j'ai testé des boucles à 25 cycles et ça glitche sur mes SMS (par contre ça passe sur MD).

Je ne sais pas ce qu'il en est pour la Coleco, mais sur SMS pendant les VBlanks on est seulement limité par la vitesse des instructions du z80.

par **TotOOntHeMooN** Dim 3 Sep 2017 - 14:50

upsilandre a écrit:oui j'imagine que cette histoire de 29 cycles est pas fiable a 100% d'ou la boucle de 34 cycles dans le bios (qui lui aussi prend par defaut le pire cas). Donc au final t'as adopter la meme stratégie que le bios par la force des choses. c'est intéressant si t'as vraiment vu des test planter a 30 cycles, ca fait au moins un témoignage concret. merci.

Tout à fait. Les versions avec des cycles trop courts montraient des glitchs à l'écran lors des tests sur une vrai machine.

par upsilandre Dim 3 Sep 2017 - 15:30

vingazole a écrit:Oui, ça colle parfaitement avec la boucle "-: outi/jp nz,-"

C'est utilisé sur Space Harrier ou pour les donjons de Phantasy Star, par exemple.

Sinon j'ai testé des boucles à 25 cycles et ça glitche sur mes SMS (par contre ça passe sur MD).

Ca tombe vraiment bien que ce soit 26 cycles, peut etre qu'ils ont fait quelque chose pour arrivé a ca.
Et si t'as deja décortique comment fonctionne l'affichage des donjons (uniquement précalculé ou un melange de composition temps réel et de précalculé?) ou que tu connais un papier dessus ca m'interresse car je voulais le faire.

Je ne sais pas ce qu'il en est pour la Coleco, mais sur SMS pendant les VBlanks on est seulement limité par la vitesse des instructions du z80.

Je crois que sur Coleco aussi tu peux enchainer les outi pendant le Vblank, en tout cas c'est ce que je fais pour l'instant

par upsilandre Dim 3 Sep 2017 - 15:33

TotOOntHeMooN a écrit:
upsilandre a écrit:oui j'imagine que cette histoire de 29 cycles est pas fiable a 100% d'ou la boucle de 34 cycles dans le bios (qui lui aussi prend par defaut le pire cas). Donc au final t'as adopter la meme stratégie que le bios par la force des choses. c'est intéressant si t'as vraiment vu des test planter a 30 cycles, ca fait au moins un témoignage concret. merci.
Tout à fait. Les versions avec des cycles trop courts montraient des glitchs à l'écran lors des tests sur une vrai machine.

Donc les timing du TMS et ceux du VDP de la SMS sont different.
Du coup faudrait savoir ce qu'il en est pendant le Vblank car si hors Vblank faut faire des boucles de 34 cycles alors que tu peux tourner a 16 pendant le Vblank ca commence a faire une sacré difference.

par **TotOOntHeMooN** Dim 3 Sep 2017 - 15:37

Ce n'est pas forcément le VDP, mais le délais de rafraichissement de la VRAM.

par upsilandre Dim 3 Sep 2017 - 15:39

C'est sure que ca doit pas etre la meme VRAM.

par fanoplusplus64K Dim 3 Sep 2017 - 19:52

upsilandre a écrit:Sinon j'ai un peu exagéré en disant que le tableau de TI est faux. En fait ils numerotent les bit a l'envers, pour eux les bits de poid fort on des petits numeros et les bits de poid faible les gros, c'est tres déroutante d'autant que meme a l'epoque on faisait pas ca, j'en ai lu pas mal des docs d'epoque.

Me rapelle effectivement que c'était le cas, heureusement j'avais quelques exemples de code sous la main qui m'ont fait comprendre ça rapidement.Il me semble aussi avoir eu ce genre de soucis avec la doc du SN.

upsilandre a écrit:oui j'imagine que cette histoire de 29 cycles est pas fiable a 100% d'ou la boucle de 34 cycles dans le bios (qui lui aussi prend par defaut le pire cas). Donc au final t'as adopter la meme stratégie que le bios par la force des choses. c'est intéressant si t'as vraiment vu des test planter a 30 cycles, ca fait au moins un témoignage concret. merci.

Ces fixes datent un peu mais il me semblait que c'était à certains moments que les timings s'allongeaient car les glitches apparaissent rarement sur les dernieres versions, je soupçonnais des rallongements de timings du à certains events (début/fin de vbl ,etc...) mais j'ai pas réussi à mettre ça en évidence.

par upsilandre Lun 4 Sep 2017 - 15:34

fanoplusplus64K a écrit:
upsilandre a écrit:Sinon j'ai un peu exagéré en disant que le tableau de TI est faux. En fait ils numerotent les bit a l'envers, pour eux les bits de poid fort on des petits numeros et les bits de poid faible les gros, c'est tres déroutante d'autant que meme a l'epoque on faisait pas ca, j'en ai lu pas mal des docs d'epoque.
Me rapelle effectivement que c'était le cas, heureusement j'avais quelques exemples de code sous la main qui m'ont fait comprendre ça rapidement.Il me semble aussi avoir eu ce genre de soucis avec la doc du SN.

Ca serait la marque de fabrique de Texas Instrument? Mr. Green

upsilandre a écrit:Ces fixes datent un peu mais il me semblait que c'était à certains moments que les timings s'allongeaient car les glitches apparaissent rarement sur les dernières versions, je soupçonnais des rallongements de timings du à certains events (début/fin de vbl ,etc...) mais j'ai pas réussi à mettre ça en évidence.

C'est sur que si le timing foire uniquement dans un contexte spécifique ca suffit a faire planter ton code et en meme temps c'est tres difficile ensuite d'identifier la cause. En tout cas le fait est que le bios a choisie 34 cycles CPU, c'est deja un indice.
Et pendant le Vblank y a eu des expérimentations pour mieux cerner aussi la limite? j'aurais tendance a penser que tout doit passer sans probleme pendant le Vblank.

par upsilandre Sam 9 Sep 2017 - 20:34

Je me suis bien amusé a coder sur coleco tout ces derniers jours. Je me suis fais un petit exercice sympa, je vous montrerais ca demain apres le boulot je pense.
Par contre ca a renforcer mon affection pour le 6502. J'aime pas vraiment programmer sur le Z80, j'ai ete un peu decu sur certain point par rapport a ce que j'imaginais. J'essayerais d'en parler plus longuement pour donner mes premières impression (y a pas deja un topic Z80?) ou peut etre en video, je sais pas encore.