Salut, je voudrais savoir si il est possible d'afficher plusieur mode sur la meme ligne.
C'est possible.
jeangonbay a écrit :
une petite idée du comment ?
Le mode écran est géré par le Gate Array et on y accède via les bits 0-1 de son registre RMR. Cependant, le changement de mode n'est pas immédiat. Le Gate Array n'applique le changement que lorsqu'une HSync (un signal produit par le CRTC) est active, et, plus précisément, durant la 2ème micro-seconde de la HSync.
Pour changer de mode plusieurs fois par "ligne", il faut donc changer le mode plusieurs fois via le registre RMR du Gate Array mais aussi faire en sorte que le CRTC déclenche une HSync au bon moment sur la "ligne" afin que le Gate Array applique le changement de mode. On fait ça en modifiant le registre 2 du CRTC, qui détermine la position, sur la "ligne", à laquelle une HSync doit être déclenchée.
Sauf que, le role d'une HSync est d'indiquer au moniteur quand une nouvelle "ligne" commence. En PAL 50 Hz, une HSync se produit toutes les 64µs. Si on se met à déclencher des HSync n'importe quand, le moniteur ne pourra plus synchroniser son affichage et va sombrer dans la démence.
Pour palier à cette contrainte, il faut faire en sorte que l'écran ne voit pas ces HSync supplémentaires. Ce qui est tout à fait possible, car le registre 3 du CRTC permet de définir la durée du signal HSync. Durée qu'il faut mettre à 2 (µs), qui est le minimum requis pour que le Gate Array ait le temps d'appliquer le changement de mode, mais qui est trop courte pour voir la HSync apparaitre dans le signal de synchro composite envoyé au moniteur.
jeangonbay a écrit :
Ah ! C'est comme si il y avait plusieur ecrans, non ?
Non.
jeangonbay a écrit :
ok, donc on part sur de la rupture verticale.
Non.
jeangonbay a écrit :
mais combien de fois on peut changer de mode sur une ligne ?
Ce qui détermine le nombre de changement de mode possible est la rapidité à laquelle ton programme peut modifier le RMR du Gate Array et les regsitres 2 et 3 du CRTC, le tout en respectant un timing précis.
Disons qu'au delà de 3 changements de mode par ligne, on commence à rentrer dans le domaine de l'orfèvrerie. Et c'est la que peut intervenir la rupture pour générer "automatiquement" des HSync à différentes positions de la "ligne" sans avoir à modifier le registre 2 du CRTC. Mais c'est une autre histoire.
jeangonbay a écrit :
en faite je voudrais avoir le bords gauche et droite en mode 2 qui fait 24 caracteres chacun, et le milieux en mode 1
Code :
ORG &80 RUN $
;; Quick & Dirty init ld hl,&c9fb ld (&38),hl ; setup a dummy ISR im 1 ; switch to IM1 ei ; enable interrupts ld sp,$+3 ; setup stack pointer here
; rough CRTC init (will nuke monitor's sync!) ld hl,_data_crtc_context ld bc,&BDBE _init_crtc bit 7,(hl) ex af,af' outi ld b,c outi ex af,af' jr z,_init_crtc ; wait until the monitor comes back to life _halt halt djnz _halt
;; 50 Hz main loop sustaining the multimode main ; wait for VSync ld b,&F5 in a,(c) rra jr nc,main+2 ; skip over the VBI djnz $ ; wait for INT0 halt ; entering timing critical part ; no interrupt allowed di ; synchronize precisely the CPU with the CRTC ld b,9 djnz $ nop ; initialize loop variables ld hl,&0600+200 ld de,&8d8e ; pre-select CRTC.R3 ld bc,&bc03 out (c),c inc b
;;Loop timing structure (no to scale): ;;HCC: 54 64/0 12 36 50 ;;Ops: [R3=2, R2=12, MODE 1] [MODE 2, R2=36] [R2=50, R3=6] [loop] ;; ;;with R# referring to CRTC registers ;; ;;Notes: ;; An HSync of at least 2us is required to give the Gate Array enough time to switch screen mode ;; An HSync lasting less than 3us won't pass through the GA hence to the monitor
;enter the loop at @HCC=54 _loop_multimode dec c out (c),c ; CRTC.R3 = 2 dec b out (c),c ; select CRTC.R2 inc b ld a,12 out (c),a ; CRTC.R2 = 12 (to trigger an HSync at HCC=12)
ld b,&7F out (c),d ; select mid-res (MODE 1) ;@HCC = 12 out (c),e ; select hi-res (MODE 2)
ld b,&bd ld a,12+24 out (c),a ; CRTC.R2 = 36 (to trigger an HSync at HCC=36)
; wasting CPU cycles to keep in sync with the CRTC DS 36-12 - 14 -2,0
ld a,50 ;@HCC = 36 out (c),a ; CRTC.R2 = 50 (to trigger an HSync at HCC=50) dec b inc c out (c),c ; select CRTC.R3 inc b out (c),h ; CRTC.R3 = 6 ;@HCC <= 50 ; loop dec l jr nz,_loop_multimode
ei jp main
_data_crtc_context DB 0,63 DB 1,48 DB 2,50 DB 3,&8e DB 4,38 DB 5,0 DB 6,30 DB 7,35 DB 8,0 DB 9,7 DB 12,&2c DB 13+128,&00
_________________ Ubi solitudinem faciunt, pacem appellant
Cependant, le changement de mode n'est pas immédiat. Le Gate Array n'applique le changement que lorsqu'une HSync (un signal produit par le CRTC) est active, et, plus précisément, durant la 2ème micro-seconde de la HSync.
Je pense que l'information n'est pas transmise au même moment avec tous les CRTCs : durant la seconde micro-seconde de la hsync sur CRTC 1, et durant la quatrième sur CRTC 0 (je n'ai pas pratiqué le CRTC 2... si quelqu'un à l'info ?). Je me souviens qu'Offset m'avait déjà expliqué ça à la Revision l'an dernier (?), mais j'en ai oublié la moitié donc je repose la question à Triple-Grimmy (allez, on t'a reconnu :) : quelles tâches le CRTC effectue-t-il pendant les micro-secondes précédant cette lecture du mode lors de la hsync ? Il semble que certaines tâches effectuées après le changement de mode sur CRTC 1 soient effectuées avant sur CRTC 0, qui demande une hsync plus longue.
Inscription : 12 Juin 2008, 20:29 Message(s) : 1709
Hicks a écrit :
Triple-Patte a écrit :
Cependant, le changement de mode n'est pas immédiat. Le Gate Array n'applique le changement que lorsqu'une HSync (un signal produit par le CRTC) est active, et, plus précisément, durant la 2ème micro-seconde de la HSync.
Je pense que l'information n'est pas transmise au même moment avec tous les CRTCs : durant la seconde micro-seconde de la hsync sur CRTC 1, et durant la quatrième sur CRTC 0 (je n'ai pas pratiqué le CRTC 2... si quelqu'un à l'info ?). Je me souviens qu'Offset m'avait déjà expliqué ça à la Revision l'an dernier (?), mais j'en ai oublié la moitié donc je repose la question à Triple-Grimmy (allez, on t'a reconnu : quelles tâches le CRTC effectue-t-il pendant les micro-secondes précédant cette lecture du mode lors de la hsync ? Il semble que certaines tâches effectuées après le changement de mode sur CRTC 1 soient effectuées avant sur CRTC 0, qui demande une hsync plus longue.
Hicks : là, ce que je comprends c'est que tu parles de la capacité des différents CRTCs a généré les HSYNCs ! si on a le même GATE-ARRAY ça change quoi exactement pour celui-ci ?!
La lecture de ces souvenirs laisse à croire que le CRTC aurait connaissance qu'un changement de mode va s'opérer, ou est en train de l'être. Et c'est accorder à ce simple galérien une certaine forme d'omniscience tout à fait étonnante.
Le CRTC, quel que soit son modèle, ne fait rien sortant de l'ordinaire lors d'un changement de mode. Plus généralement, le CRTC ne se pré-occupe absolument pas de ce qu'il se passe dans le CPC, à l'exception de la communication I/O avec le Z80 (pour lire ou écrire ses registres), des éventuels signaux extérieurs liés au lightpen et enfin, à son horloge.
Le seul composant quasi-omniscient du CPC est le Gate Array, qui lui coordonne vraiment tout le navire.
La plupart des légendes étant souvent inspirées de faits réels, on peut se permettre d'envisager théoriquement que le signal de HSync ne soit pas généré par le CRTC strictement au même moment selon le type (par exemple, sur un front montant de l'horloge plutôt que descendant), ce qui pourrait influer sur les timings du Gate Array. Néanmoins, cet océan de tergiversations théoriques ne m’intéresse qu'assez peu dans ce domaine. Je te propose, à toi ou n'importe quel esprit scientifique passant par la, de lancer le programme de test (normalement attaché à ce message) sur diverses configurations de CPC et de partager ses observations.
Vous n’êtes pas autorisé(e) à consulter les fichiers insérés à ce message.
_________________ Ubi solitudinem faciunt, pacem appellant
Sur ce sujet, je viens une fois de plus manifester mon étonnement devant la "tuyauterie" du Commodore 64, qui lui permet, apparemment, de mélanger presque indifféremment plusieurs modes graphiques sur de multiples zones sur le même écran, mais surtout avec une précision au caractère prêt ! Et tout ça sur des screens de jeux d'arcade, s'il vous plait...
Je viens de retrouver celui-là, pour l'exemple... c'est l'adaptation du coin-op Alien Storm (le jeu est mal noté sur lemon64 mais la raison n'est pas une lenteur anormale du jeu) REGARDEZ la g.... du "HUD" (panneau de scores) ! http://www.lemon64.com/games/details.php?ID=85
A moins que ce ne soit là une utilisation extrême des sprites hard du C64 rien que pour le "HUD" ? Ca me parait un poil du gâchis mais pourquoi pas ?
J'en en ai vu plein d'autres, mais c'est en général plus de la segmentation de l'écran (horizontalement ou verticalement). Celui-ci fait partie des trucs qui m’empêchent de dormir la nuit, quand je repense à mon 464 préféré...
A moins que ce ne soit là une utilisation extrême des sprites hard du C64 rien que pour le "HUD" ? Ca me parait un poil du gâchis mais pourquoi pas ?
Réflexion faite, et après vérification au pixel prêt, ce doit réellement être une utilisation des sprites hard dans ce cas (un peu comme Rick Dangerous+ chez nous), car (si on regarde bien) il y a superposition de 3 couleurs sur des zones en 40x25, alors que le mode 40x25 du C64 est en 1 bit de profondeur... donc ce serait impossible tel quel !
Ouf.... je vais pouvoir dormir, maintenant...
Reste que j'ai également déjà vu sur plusieurs autres jeux du C64 une segmentation horizontale de l'écran en multi-mode... à vérifier s'il s'agit systématiquement de sprites hard.
Le C64 peut mélanger ses modes graphiques au caractère, en gros on peut définir le mode et la palette pour chaque caractère, comme sur rick dangerous, ce qui est bien pratique.
sur un CPC cela serait super bien mais bon le CPC n'est vraiment pas basé sur des caractères, n'a pas de sprites et pas d'attributs, et sinon est 2x plus lourd en matière de bits par pixels, donc en chierait si il avait en plus des attribut.
mais on se prend à rêver aussi... des attributs avec les modes du CPC ça serait aussi bourrin que bien des consoles.
Pour info, mon intérêt dans cette évocation du C64 est de découvrir à partir de quand les programmeurs ont détourné le fonctionnement prévu du contrôleur video pour obtenir des résultats comparables au multi mode horizontal du CPC. Or...
MacDeath26 a écrit :
Le C64 peut mélanger ses modes graphiques au caractère, en gros on peut définir le mode et la palette pour chaque caractère, comme sur rick dangerous, ce qui est bien pratique.
Ok pour la définition de la palette pour chaque caractère, car cela correspond nativemet à la structure de la VRAM... par contre (c'est une question) est-ce vraiment le cas pour le "mode" graphique (résolution et profondeur de codage des couleurs).... y-aurait il vraiment un attribut "mode" pour chaque caractère de l'écran ? Ce qui serait étonnant pour une fonction (le "multimode" au caractère) finalement si peu "utile" en dehors des jeux.
Ce qui m'amène donc à mon sujet : si cet attribut magique n'existe pas nativement, les programmeurs du Rick Dangerous C64 ont-ils eux aussi intercepté les interruptions vidéo, mais tous les 8 pixels horizontaux afin de modifier systématiquement les registres de résolution du VIC entre chaque caractère ? (en plus du changement de la palette qui est, lui, natif). Si oui, comment arrivent-ils à une telle rapidité d'animation dans un jeu comme Rick Dangerous avec un tel traitement de fond en software ? Rappelons que le CPC ne peut réaliser cette prouesse que 3 fois par ligne environ... (d'après les experts ici présent).
Bref : cet attribut "résolution" existe t-il vraiment nativement en VRAM du C64 et si oui, ou se trouve t-il documenté ?
Dernière édition par qbert le 10 Mars 2015, 00:29, édité 1 fois.
Bon ben finalement, j'ai trouvé tout seul la confirmation de ma supposition... à savoir que le multi mode (horizontal ou vertical) n'est absolument pas géré en natif sur le C64 non plus (pas d'attribut dédié), et que seule l'interception systématique des interruptions du contrôleur video permet d'obtenir un mélange des résolutions. Mais la capacité du VIC-II à générer lui-même ces interruptions doit expliquer l'énorme différence de performance avec le CRTC du CPC qui doit "émuler" péniblement 3 fois par ligne ces fausses HBLANK (et encore... avec tout le puissant savoir faire de la crème des coders), pendant que le C64 peut faire l'équivalent pas moins de 40 fois par ligne dans un jeu... http://www.lemon64.com/games/popup_screen.php?s=rick_dangerous;03;5
Pour info, mon intérêt dans cette évocation du C64 est de découvrir à partir de quand les programmeurs ont détourné le fonctionnement prévu du contrôleur video pour obtenir des résultats comparables au multi mode horizontal du CPC. Or... [...] Bref : cet attribut "résolution" existe t-il vraiment nativement en VRAM du C64 et si oui, ou se trouve t-il documenté ?
[Je te propose, à toi ou n'importe quel esprit scientifique passant par la, de lancer le programme de test (normalement attaché à ce message) sur diverses configurations de CPC et de partager ses observations.
Excellent ton prog de test! Je vais essayer sur mon 6128 CRTC0 dès que je pourrais
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 18 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