Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Bonjour à tous !
Et tout d'abord merci a Hermol pour ce site ,et aussi à ceux qui l'alimentent, qui est une mine d'or ( j'espère que tu as une copie offline)
Ca fait un peu de temps que je vous lis mais je n'ai jamais posté, faut dire que vu les pointures qui trainent ici, on est intimidé (/fanboy_mode on au fait il sont où Overflow et Longshot ? /Fanboy_mode off)
Malgré tous ces docs, il y a encore deux ou trois choses qui ne sont pas claires pour moi et qui sont très importantes pour prendre certaines décisions pour mon projet.
En fait ça tient surtout au format de l'écran et au timing de la machine.Tout d'abord si j'ai bien compris, l'overscan sur cpc porte sa résolution réelle à 384*272 (48*34 caractères CRTC avec R9 à 7) mais dans certains articles (notamment celui de Longshot sur la rupture), il est indiqué que le CRTC travaille sur 312 lignes. Donc quand on se cale sur le signal de début de trame, on est hors de l'écran réel ? au bout de combien de lignes, on est dans le domaine du visible ?
Hors interruptions, le temps disponible par ligne est de 64nops donc on 312*64*4 = 79872 cycles par VBL, c'est bien ça ?
J'ai lu dans un autre article que les timings en cycles sur les instructions Z80 n'étaient pas les bons, est il vrai que le Z80 travaille par cycles de 4 ?
Le SSCR de l'Asic sert juste à décaler le contenu de l'écran jusqu'à 7 pixels (mode2) mais j'ai du mal à comprendre comment alimenter le scrolling, il faut l'associer avec un scroll hard avec les registre 12 & 13 du CRTC ?
Enfin, ça n'a rien à voir avec le reste mais j'ecris un petit loader compatible avec le format DATA mais j'ai un affreux doute sur le calcul des pistes/secteurs à partir des blocs.Le calcul du premier secteur du bloc se ferait alors avec le calcul suivant : piste = bloc\9 secteur = secteur de base(ici #C1) + (bloc modulo 9) est ce correct ?
J'espère que vous prendrez le temps de m'aider un peu à comprendre certaines choses parce que j'ai la tête comme un compteur à gaz à tenter d'assimiler tout ça (la dernière chose à laquelle je m'était arrété ado étaient les rasters loool)
fano (qui a hâte de retrouver un CPC pour faire tourner son code et voir DTC en vrai )
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
En fait ça tient surtout au format de l'écran et au timing de la machine.Tout d'abord si j'ai bien compris, l'overscan sur cpc porte sa résolution réelle à 384*272 (48*34 caractères CRTC avec R9 à 7) mais dans certains articles (notamment celui de Longshot sur la rupture), il est indiqué que le CRTC travaille sur 312 lignes. Donc quand on se cale sur le signal de début de trame, on est hors de l'écran réel ? au bout de combien de lignes, on est dans le domaine du visible ?
La frequence de balayage est de 15625 Hz pour 50 images secondes (frequence normale de l'écran), tu as donc: 15625/50=312,5 lignes par ecran.
Il faut voir "ecran CRTC" et "moniteur" ce n'est pas du tout la même chose. L'écran CRTC est fonction des Regs tandis que le moniteur ce contente de ce caller sur la VBL et HBL et de balancer la sauce.
Citer :
Le SSCR de l'Asic sert juste à décaler le contenu de l'écran jusqu'à 7 pixels (mode2) mais j'ai du mal à comprendre comment alimenter le scrolling, il faut l'associer avec un scroll hard avec les registre 12 & 13 du CRTC ?
Oui, sauf s'il s'agit de rupture+ dans quel cas tu utilises les regs equivalents R12 et R13.
Inscription : 15 Oct 2007, 02:49 Message(s) : 402 Localisation : Les Sucres en Morceaux
J'ai un clavier CPC 6128 pour toi, gratos si tu veux. A retirer en Bretagne ou à un meeting (je poste plus). Pas de lecteur, mais ça se rajoute facilement en 3'5.
Pour préciser ce que dit BDCIron, le CPC ne travaille donc qu'en 312 lignes là où le signal TV est 312 lignes, puis 313, puis 312... donc des lignes entrelacées une VBL sur 2. Sur CPC, on n'entrelace pas, on reste à 312 lignes, ce qui augmente d'un pouillème la fréquence de balayage (50,008Hz)
Concernant la taille affichable à l'écran, on s'accorde effectivement à dire qu'on peut voir 272 lignes à l'écran. Par contre, les réglages étant erratiques, tu ne sais pas toujours à partir de quelle ligne ça commence (ça dépend du réglage de l'écran). BDCIron préfère ne pas faire dans la dentelle est afficher 285 lignes de haut Ca permet d'avoir plus de chances que l'image soit partout (sans certitude), mais ça permet pas pour autant de cadrer l'image (ce qui est impossible de façon automatique).
Je n'ai pas fait de tests, mais je pense que l'écran monochrome permet de voir moins de lignes que ça.
Inscription : 28 Août 2008, 23:41 Message(s) : 258
Citer :
J'ai lu dans un autre article que les timings en cycles sur les instructions Z80 n'étaient pas les bons, est il vrai que le Z80 travaille par cycles de 4 ?
Je crois que c'est lié au rafraichissement de la mémoire. C'est pourquoi l'instruction élémentaire en temps d'exécution sur cpc est le NOP puisque cette instruction prend 4 cycles. Etant donné que certaines instructions Z80A ne sont pas forcément multiples de 4, le nombre de "nop" est arrondi. INC A : 4 cycles donne 1 µsec INC BC : 6 cycles donne 2 µsec INC (IX+n) : 23 cycles donne 6 µsec Parfois il y a des trucs bizarres. BIT 0,(IX+n) : 20 cycles donne 6 µsec (au lieu de 5) Le temps de lecture de l'instruction en mémoire par le Z80A doit jouer.
C'est encore à vérifier, mais l'interruption avant ou après une instruction doit peut-être dépendre de ces cycles.
Citer :
Donc quand on se cale sur le signal de début de trame, on est hors de l'écran réel ? au bout de combien de lignes, on est dans le domaine du visible ?
Ca dépend de la manière dont tu as programmé le crtc ET du moniteur. Ce que t'expliquent BDC et Sylvère à propos du nombre de lignes visibles. Déborder des 2 côtés par exemple...
Citer :
piste = bloc\9 secteur = secteur de base(ici #C1) + (bloc modulo 9) est ce correct ?
Non ce n'est pas correct. 1 bloc sur cpc (amsdos standard) fait 1 ko soient 2 secteurs Et les blocs sont numérotés à partir de 0 Bloc 0 = secteur 1.2 piste 0 Bloc 1 = secteur 3.4 piste 0 Bloc 2 = secteur 5.6 piste 0 Les blocs 0 et 1 sont réservés au catalogue en format DATA (2 ko) Donc un bloc peut être à cheval sur 2 pistes (bloc 4 par exemple) Donc le bon calcul, c'est No Piste = (Bloc x 2) / 9 No secteur = (Bloc x 2) mod 9 + C1 (data)
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Merci pour ces réponses
BDCIron a écrit :
Oui, sauf s'il s'agit de rupture+ dans quel cas tu utilises les regs equivalents R12 et R13.
Ah j'ai cru échapper ça, bon ben ça sera des routines d'affichage biscornues Du coup me viennent des réflexions douteuses à propos de l'ASIC que la décence m'obligera à taire...
Supersly a écrit :
J'ai un clavier CPC 6128 pour toi, gratos si tu veux. A retirer en Bretagne ou à un meeting (je poste plus).
Je serai preneur si je n'étais pas si loin mais je suis dans l'est, à Troyes dans l'Aube pour être précis (où ça ?).Mais pas de problème je finirai bien par m'en dégotter un (et dire que ma chère et tendre m'en a jeté 2 avec les jeux et les bouquins en 99, me reste plus qu'un vieux livre d'assembleur Z80, la cartouche de BATMAN et un paddle + ).
Longshot a écrit :
Non ce n'est pas correct. 1 bloc sur cpc (amsdos standard) fait 1 ko soient 2 secteurs... ...Donc le bon calcul, c'est No Piste = (Bloc x 2) / 9 No secteur = (Bloc x 2) mod 9 + C1 (data)
Attends, je crois que j'ai un switch qui était resté coincé... /mode_boulet off Ah ça va mieux, là je suis honteux, c'était tellement gros et devant mes yeux que j'ai raté ça Ceci dit, l'avantage avec l'émulation c'est qu'on n'a pas de bruits bizarres qui sortent du lecteur de disc quand on fait des conneries
Citer :
Guru méditation...
Mdr ! effectivement
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Ah j'ai cru échapper ça, bon ben ça sera des routines d'affichage biscornues Du coup me viennent des réflexions douteuses à propos de l'ASIC que la décence m'obligera à taire...
Qu'est ce a dire ??? Affichage biscornu ??? C'est quoi tes reflexions douteuses ?
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Et non, n'est pas le sexe faible celui auquel on pense en premier
Plus sérieusement, c'est juste qu'avec le scroll hard la structure de l'écran est décalée, donc ça complique le code et ça le rend plus lent, plus moyen d'utiliser des tables directement pour récupérer l'adresse de la ligne suivante et en plus il faut vérifier à chaque fois qu'on modifie le pointeur d'adresses.
Quand j'ai vu le décalage entre la présentation qui était faite de l'ASIC à l'époque et les contraintes avec lesquelles on se retrouve en réalité (notamment les sprites qui sont une horreur) , ça me fait penser à la super nana avec laquelle tu sors mais qui n'est pas très portée sur la bagatelle : C'est très joli (surtout les 4k couleurs) mais faut encore se taper une bonne partie du boulot à la main (j'avais dit que ça allait pas être très fin)
C'est pour ça que je m'intéresse aux timings, histoire de voir combien de sprites Hard/Soft il est possible de gérer avant que le faisceau arrive à la partie affichée de l'écran.C'est d'ailleurs un problème bien chiant cette histoire de cycles inexacts.
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Inscription : 28 Août 2008, 23:41 Message(s) : 258
Citer :
Plus sérieusement, c'est juste qu'avec le scroll hard la structure de l'écran est décalée
Cela est vrai sur tous les cpc. Le vrai intérêt, c'est le décalage horizontal pour ralentir un scroll.
Citer :
plus moyen d'utiliser des tables directement pour récupérer l'adresse de la ligne suivante
N'exagérons rien. Je suis pas sûr du tout que tu ailles plus vite avec une table. (car il faut un ptr sur la table, ajouter yx2, lire l'adresse et additionner ensuite x en octet. ca va plus vite de calculer directement le ptr) Et en plus, c'est inexploitable avec un scroll hard.
Citer :
les sprites qui sont une horreur
Les sprites en eux mêmes ne sont pas une horreur. Les vrais défauts sont qu'ils ne sont pas vectorisables et pas en ram , ce qui ne permet pas de les prioriser ou de changer leur contenu rapidement.
Citer :
histoire de voir combien de sprites Hard/Soft il est possible de gérer avant que le faisceau arrive à la partie affichée de l'écran
Tu poses un faux problème. Le positionnement d'un sprite hard est très rapide si il est fait au début du balayage. L'affectation des coordonnées en cours de balayage des sprites hard permet leur multiplexage (affichage plusieurs fois du même sprite hard) (iron pourrait t'en causer). Pour les sprites soft tu peux aussi afficher les sprites pendant le balayage vidéo si la zone ou bouge le sprite ne correspond pas à la zone ou se trouve le code qui l'affiche. Ou utiliser tout ton écran en travaillant sur 2 pages.(afficher tes sprites sur la page 1 pendant que tu affiches la page 2, et faire l'inverse au balayage suivant)
Citer :
C'est d'ailleurs un problème bien chiant cette histoire de cycles inexacts.
Pourquoi ? Tu peux trouver très facilement le nombre de nop de chaque instruction du z80a sur cpc. Je pense que tu dois pouvoir trouver ça sur le site de kevin thacker (http://www.kjthacker.f2s.com/) ou sur le site de grim (http://www.grimware.org/doku.php)
Hormis le fait que les sprites hard ne soient pas en RAM et vectorisés comme l'a dit Longshot, pour le reste il n'y a aucun problème avec eux... 16 Sprites hard remplissent largement l'ecran (voir preview de delirium tremens sur un vrai CPC+). Tout dépend de ce que tu veux en faire.
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Merci pour le lien vers le site de grim, j'ai trouvé mon bonheur BDCIron, je peux avoir le lien vers ton site ? Je regarderai la preview de délirium tremens pour voir. Et fait, le projet est de faire dans un premier temps un prototype de schmup (c'est original, hein ?) avec un scroll moelleux (donc malheureusement ça exclut d'emblée le CPC old ).
Quand je dis horreur pour les sprites, je pense au fait qu'ils ne soient pas vectorisés, effectivement , mais j'ai aussi du mal à comprendre pourquoi les pixels sont encodés sur 8 bits doublant ainsi la taille des données à transférer à quand on les update (après il y peut être une raison technique comme pour l'entrelacement des bits des pixels mais je n'ai aucune connaissance en électronique).Mais bon, après c'est sûr que c'est mieux avec que sans et , surtout avec les 16 couleurs en plus.
Pour les tables, je suis effectivement à coté de la plaque. En fait, j'avais idée d'utiliser une file d'attente pour mettre à jour le contenu des sprites hard animés en fonction du nombre que je peux mettre à jour, le décalage de l'anim d'une ou deux étapes ne serait pas bien grave si la vitesse est suffisante. Quand au double buffer, je voudrais juste l'éviter pour sauver 16K (j'avais essayé 2*8K dans le tps mais ça faisait petit, d'autant plus que je ne savais pas faire une rupture (en fait j'avais lu ton article à l'époque mais j'avais pas compris tout comme j'ai raté les 2 bits qui permettent de passer le CRTC en 32K dans un autre article, l'impatience de la jeunesse surement Mdr !)) surtout que ce sont de tout petits sprites (genre 2 octets, ou des figures à base de points).
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Merci pour le lien vers le site de grim, j'ai trouvé mon bonheur BDCIron, je peux avoir le lien vers ton site ? Je regarderai la preview de délirium tremens pour voir.
Pour delirium tremens: Cliques ici, mais a regarder sur un vrai CPC+ sinon tu loupes la moitié des choses.
Citer :
Et fait, le projet est de faire dans un premier temps un prototype de schmup (c'est original, hein ?) avec un scroll moelleux (donc malheureusement ça exclut d'emblée le CPC old ).
Un shoot sur + c'est facile. Certains avaient commencé mais jamais fini, par exemple avec burger parti (Cliques ici), jeu n'ayant béneficié d'aucuns gfx et d'un game play plus que naze.
Citer :
Quand je dis horreur pour les sprites, je pense au fait qu'ils ne soient pas vectorisés, effectivement , mais j'ai aussi du mal à comprendre pourquoi les pixels sont encodés sur 8 bits doublant ainsi la taille des données à transférer à quand on les update (après il y peut être une raison technique comme pour l'entrelacement des bits des pixels mais je n'ai aucune connaissance en électronique).Mais bon, après c'est sûr que c'est mieux avec que sans et , surtout avec les 16 couleurs en plus.
15 couleurs en fait... Sinon oui, c'est un peu naze de n'avoir utilisé que 4 bits par octet pour les sprites... Mais c'est comme ca.
Citer :
Quand au double buffer, je voudrais juste l'éviter pour sauver 16K (j'avais essayé 2*8K dans le tps mais ça faisait petit, d'autant plus que je ne savais pas faire une rupture (en fait j'avais lu ton article à l'époque mais j'avais pas compris tout comme j'ai raté les 2 bits qui permettent de passer le CRTC en 32K dans un autre article, l'impatience de la jeunesse surement Mdr !)) surtout que ce sont de tout petits sprites (genre 2 octets, ou des figures à base de points).
Si tu veux économiser de la place avec tes scrolls, fait de la rupture toutes les 8 lignes et affiche en double, tu n'utiliseras alors que 2 fois la place du gfx en ram.
Inscription : 28 Août 2008, 23:41 Message(s) : 258
Citer :
de schmup (c'est original, hein ?) avec un scroll moelleux (donc malheureusement ça exclut d'emblée le CPC old ).
Sans savoir ce qu'est un schmup à scroll moelleux, difficile d'affirmer que ce n'est faisable que sur le plus...
Citer :
le décalage de l'anim d'une ou deux étapes ne serait pas bien grave si la vitesse est suffisante.
La modification du contenu d'un sprite pour une animation ne se fait jamais au frame, loin de là. Le meilleur moyen de dépenser moins de cpu pour la mise à jour, c'est de répartir ce temps en utilisant une technique de flipping entre les sprites. Ca permet une mise à jour partielle des sprites à animer. La contrepartie, c'est que pour un sprite à animer on en utilise 2.
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
BDCIron a écrit :
Un shoot sur + c'est facile
Bah pour moi peu être pas Mdr ! Plus sérieusement, il y en a pas beaucoup sur + et ils sont pas top.Sinon, il y XEO3 mais c'est wip.
J'ai eu du mal à comprendre l'histoire de rupture toutes les 8 lignes juqu'à voir burger parti.Après je suis loin d'être un bon graphiste donc je vais déjà essayer de faire un prototype qui pourrait donner envie à quelqu'un de faire des graphs pour
Longshot a écrit :
Sans savoir ce qu'est un schmup à scroll moelleux, difficile d'affirmer que ce n'est faisable que sur le plus...
A me comprendre, j'en oublie que ça n'est pas clair pour les autres
Un schmup à scroll moelleux en language fanotien est un schmup avec un scroll horizontal lent (au pixel/frame voir moins) avec des niveaux qui demandent parfois de se faufiler, R-type (et encore plus le 2) en est un bon exemple.Je sais qu'il y une technique qui consisterait à utiliser 4 écrans en décalé mais déjà que j'aurai du mal avec 2 et puis le format c'est plus letterbox , c'est timbre poste
C'est vrai que un flipping de sprites ça peut être super utile dans le cas où on utilise peu de sprites parce déjà 16 ça fait pas bien lourd
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Inscription : 15 Août 2008, 13:00 Message(s) : 968 Localisation : Troyes, France
Bon ben ça avance tout doucement mais je bloque sur un truc : le cyclage des adresses avec le scroll hard. Avec certaines lignes, quand l'offset passe une certaine limite, mes points sont décalés, ça surement à voir le fait que ma configuration CRTC ne prend pas entièrement les 16K (48*21 donc 256 octets en rab) mais je ne trouve pas de solution à ce problème. Ca fait trois jours que je me creuse la tête et que je frotte les cheveux qu'il me reste mais je trouve pas, à l'aide !
_________________ "NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 78 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum