L'overscan sur CPC ...
un « problème » matériel.
Personal Web Site.
Hard & Tweaks.
Le monstre sans tête : L'émulateur universel n'existe pas ...
Un micro, 5 CRTC : l'« Overscan » sur Amstrad CPC.
EDITO sur le CRTC « Il n'exite pas d'émulateur miracle ! »
Étude de M.MAIGROT « La Grande Verrière »
"SOS PROGRAMMEURS N.7" UTIL-SOFT 1990
1 - COURS DE GRAPHISME . LE CRTC
2 - OVERSCAN CHAPITRE 1 -
3 - OVERSCAN CHAPITRE 2 -
Mess le monstre sans tête ...
Mess est victime de son succès !
Émuler plus de 200 machines, incluant au passage des spécificités matériels inhérent à chaque version, ne ce révèle pas chose facile.
Tous les systèmes ne sont pas complètement fonctionnels, non pas pour des problème d'émulation, mais pour des problèmes d'interprétation de données!
Les émulateurs présent, émulent une partie visible de l'iceberg, ils permettent une utilisation simple des différents système qui lui est imposé par le constructeur.
Prenons l'exemple de l'émulateur Cpc (le plus connus en Europe), ce système posséde des fonctions « cachées » qui ont été découvertes par les programmeur de « Titus ».
L' « OverScan », cette méthode non documentée a permis des créations graphiques poussant aux limites la machine.
Un article du très célèbre NetExit en parle fort bien et Fabinou en parle mieux que moi :
Source Net Exit n°11 (Fabinou@netexit.com)
(...)
« Longshot, le Logon System, les Malibus Crackers et les autres : les DemoMakers du CPC.
Ah ah, ça vous en bouche un coin, mes p'tits gars, pas vrai ? Et oui, le CPC avait aussi des Demomakers dont le but principal, outre celui de faire des petites demos pour présenter les jeux qu'ils avaient crackés, était de repousser sans cesse les limites de la machine. Ce sont les demomakers qui ont permis l'affichage d'une image sur l'écran complet (oui, parce que j'ai oublié de vous le dire, mais autour de l'écran se trouvait une bordure dont on ne pouvait rien faire, si ce n'est en changer la couleur). Certes, cette méthode, appelée "OverScan", avait était développée par Titus (encore eux), mais ce sont les Demomakers qui l'avait popularisé. Ce sont encore les Demomakers qui avaient trouvé la possibilité d'afficher 27 couleurs simultanément en mode 2 (le mode qui donnait les graphes les plus fins). Et peu avant la mort du CPC, ces mêmes Demomakers commençaient à toucher à la 3D et au zoom... »
(...)
Dans ces conditions il semble normal que certains programmes assembleur ne fonctionne pas!
L'émulateur a été créé avec un taux de rafraîchissement fixe (celui du moniteur!) et certaines fonctions CRTC ont été bridées...
L'émulateur, dans ce cas ne peut fonctionner normalement.
En régle générale, les différents émulateurs supportent mal les codes optimisés et étendues.
La décompilation des codes machines s'effectues correctement mais générent des affichages incohérent et cabalistiques.
Pour le cas qui nous intéresse, l'adaptation des fonctions Direct x, pour l'affichage est en cours...
mais provoquent parfois des « plantages ».
Le traitement de désassemblage est le même quelle que soit le processeur, les Codes machines sont connus, mais le problème réside dans son traitement (adresse de contrôle CRTC, appel de fonction interne) bridé par un affichage Direct x qui ne se pliera pas aux exigences de la machine émulée.
Donc un émulateur ne ce contente pas d'émuler un bios, mais doit prendre en compte les spécificités de chaque machine pour des opérations complexes en sortant des limites imposées par le système de programmation.
Dans l'état d'avancement du projet Mess, l'équipe de programmeurs peut s'enorgueillir d'avoir créer une base stable d'émulateurs, fonctionnelle jusqu'aux différents points critiques précédemment cité.
Le projet ne se vente pas de créer une série d'émulateurs «professionnelles », mais constitue une base solide pour l'utilisation ponctuelle de machines émulées.
Il est donc déconseillé de jeter l'opprobre sur Mess, pour une utilisation poussée des émulateurs.
Les joueurs et autres utilisateurs de programmes complexes (faisant appel à des fonctions avancées) ne peuvent que subir ces limites, non pas celles de la machine mais celles de l'émulateur !
Il est possible de raisonner à la « mame » et de créer un driver par jeu ...
Mais le résultat ressemble plus à du bricolage qu'a la recherche et au développement d'un programme pour l'émulation d'une machine (et non pas d'un jeux). Pour information, Mame reconnait actuellement 4953 roms dont parmi eux 2147 clones, soit au total 2806 jeux (544 jeux refuse de fonctionner!), donc a leurs actif 1800 jeux fonctionnels (La programmation d'émulateurs de consoles pose le même problème).
A entendre ses concepteurs, aucun des systèmes n'est fonctionnel à 100%.
Aucun des émulateurs ne peut être la tête de proue du projet !
Aucun des émulateurs n'est donc finalisé (plus de 200 projets) !
Alors pourquoi utiliser Mess comme émulateur, alors qu'il est conseillé d'utiliser un émulateur concurrent en cas de problème !
Les travaux des différentes personnes ayant contribuer en dilettante ou avec acharnement, méritent mieux.
La conversion (incontournable) vers un traitement de l'émulateur sous Windows et sous direct x, a désorganisé les projets en gestation, créer des dysfonctionnements et a généré une période durant laquelle certains projets ont subi des régressions (desboguage destructif).
Mess est (et sera) une référence en matière d'émulateurs, mais la maîtrise des différants projets est intimement liée à l'évolution même de Mess. Il y aura toujours des interactions néfastes lors de l'utilisation de procédures partagées (un bogue fixé pour une machine vas peut-être généré un autre bogue sur une machine utilisant le même driver !)
Mess est donc victime de son gigantisme, et n'a pas la réputation d'être fiable (trop de mises à jour).
Pour finir, je vais vous faire part d'un problème directement lié au problèmes de « mauvaises réputations de Mess» aux points de vue qualitatif et promotionnel.
Un numéro spécial Hors-série « PC team » pour ne pas le citer.
Fourni un numéro spécial sans « l'émulateur des émulateurs » et se vente de distribuer près de 30 systèmes différents.
Mame est présent, mais Mess manque a l'appel.
Le magasine « PC team », premier magasine a avoir soutenu Mess en distribuant ses sources, semble avoir eu recours à une solution de facilité: distribuer exclusivement des projets indépendants (mieux maîtrisés et plus fonctionnels).
Ne jetons pas la pierre aux ex-supporter de Mess, il n'y a que les imbéciles qui ne changent pas d'avis.
Rassurer vous ce magasine a évolué depuis sa création et leur orientation commerciale en a fait une revue de médiocre qualité. D'un magasine pluridisciplinaire, il est passé a un magasine favorisant les maladie spongio-cérébrales. L'exemple n'est donc pas une référence viable, juste une anecdote.
Voilà tout.
Edito :
Il n'existe pas d'émulateur miracle !
Emuler un ordinateur permet de simuler une « machine » bien définie, en prenant les éléments séparément et d'obtenir un assemble homogène et fonctionnel.
Prenons un ordinateur, le principe de fonctionnement est défini et correspond à un cahier des charges préétabli par le constructeur du système natif. Cet charte de compatibilité permet à ce système de faire fonctionner une lignée de logiciels qui seront distribués par la suite. Immuable et statiques pour certaines machines due à la technologie employée (ROM bios inclus au système), l'émulation semble être pour certain, un jeu de construction d'algorithmes mathématiques stable et prédéfini !
En théorie, l'aspect limitatif de compatibilité permet d'asseoir ce genre de certitudes.
C'est sans compté sur les facteurs technologiques en matière de composants !
Divers facteurs, comme le prix de fabrication lié au prix des composants, comme l'architecture du circuit utilisée par le constructeur ou tout simplement par manque de composants utilisés dans leur fabrication par cause d'obsolescence ou de dysfonctionnement.
La norme reste, mais le micro évolue fatalement!
Pour exemple, le Zx81, connu pour son succès et sa longévité de fabrication, s'est vu affublé d'un micro-contrôleur sans Rom extérieur et sans processeur, le fameux Z80 connu sous le nom de « Zilog » Z80pio!
Dans ce cas, faut-il émuler un cpu Z80 ou un micro-contrôleur !, pire !, faut-il émuler un Zilog ou un Nec (D780C) ...
En fait, Zilog, intel ou autres composant ont les même instructions communes, mais certains d'entre eux ont des fonctions spécifiques.
La prise en charge de ces fonctions ne sont pas utilisées mais reste latentes dans le système ... le bios utilise les instructions les plus courante et laisse les fonctions matériels avancées de côté.
Le changement du bios ne peut être effectué sans risque, et pour une raison simple, le changement du bios rend la programmation hasardeuse! Déboguer un bios, bogue la programmation par des appels de routines bios avancées. Les « plantages » généré par les appels d'adresse décalées seraient trop nombreux ! Le constructeur ne peut que se résigné a utiliser le même bios ... où bien, créer une machine incompatible avec les anciennes.
Dans le cas qui nous intéresse, le CRTC de la lignée des Amstrads, le problème est « matériel ». Tout a commencé par une utilisation incomplète du BUS d'adressage du CRTC. Conçu pour fonctionner avec 2 bits dans sa version de base, le constructeur a pu utiliser un 3 ème bit de contrôle sur certain « shipset » CRTC. A l'origine non câblé, ce bit d'adressage fût par la suite utilisé, ajoutant aussi une nouvelle fonction ! Les fonctions exploitables sont donc liées aux références et a la maturité technologique du système de contrôle vidéo. Et ce n'est pas un hasard si les méthode l'overscan n'arrivent que tardivement sur les CPC.
Il existe de nombreux constructeurs ayant « cloné » ce fameux CRTC, mais nous retiendrons le CRTC de chez ASIC(Alan Sugar Integrated Circuits), MC6845 de Motorola, le UM6845 et UM6845r et le HD6845sp.
Le CTRC le plus abouti reste le UM 6845r pour les fonctions de contrôles avancés qu'il posséde.
Il faut tout de même garder à l'esprit que quelques fonctions standards communes à l'ASIC et au MC6845 sont utilisées couramment en programmation pour des causes de compatibilité entre anciens et CPC plus récent. Mais certaines Démos ne sont utilisable que par les CRTC UM6845r... sur les CPC d'ancienne génération, la programme ne fonctionne pas correctement !
Un émulateur de CPC avec un CRTC MC6845 ... ne fonctionnera pas non plus !
L' « overscan » est donc l'exploitation de fonctions ajoutées et ne peuvent donc pas être émulées sans une mise à jour du driver du CRTC.
L'émulateur fonctionne donc bien, mais pour une version spécifique du matériel. Pour les possesseurs de CPC, la tâche s'avère beaucoup plus difficile, il leur faut changer le composant et effectuer des straps sur la carte mère elle même !
Donc un émulateur universel (pour une machine standard) doit prendre en compte le plus grand nombre de spécificités matérielles!
Son bon fonctionnement, dans ce cas, est directement lié à l'audit matériel de chaque série de micro-ordinateurs, et non plus la description de la machine de référence (pour une marque identique ... ou non!).
Xavier Martin.
COURS DE GRAPHISME . LE CRTC
Par M.MAIGROT
« La Gde Verrière »
"SOS PROGRAMMEURS N.7" UTIL-SOFT 1990
Sans entrer dans tous les détails de l'électronique , je précise quand même que le CRTC 6845 est le circuit intégré qui gère tous les signaux vidéo nécessaire à l'écran . La manipulation des ports E/S de ce circuit permet d'obtenir des effets spéciaux assez spectaculaires dont l'overscan !
Pour modifier l'état de ce circuit il faut envoyer 2 commandes :
1 : OUT &BC00 , registre
2 : OUT &BD00 , valeur
Il y-à 18 registres (de 0 à 17) possibles.
Chacun d'entre a un rôle déterminé . La valeur a envoyer ensuite en &BD00 déterminera l'importance de la modification . On peut parfaitement effectuer la plupart des essais sous basic comme en témoigne le programme CRTC.BAS sur l'autre face .
Exemple :
10 OUT &BC00,13:OUT &BD00,4
20 CALL &BB06
30 OUT &BC00,13:OUT &BD00,0
Voici d'abord un résumé du rôle des principaux registre. Quelques uns d'entre sont réservés au crayon optique, ce genre d'accessoire n'ayant jamais donné de résultat probant sur le CPC, je n'en parlerai pas .
R0: Durée de balayage horizontal y compris le retour de rayon .
R1: Nombre de caractères affichables sur une ligne .
R2: Synchronisation de l'affichage horizontal .
R3: Durée du signal de synchronisation .
R4: Durée du balayage vertical y compris le retour de rayon .
R5: Fréquence de renouvellement de l'image .
R6: Nombre de lignes caractères affichables .
R7: Synchronisation de l'affichage vertical .
R8: Mode de fonctionnement du CRTC .
R9: Scanning .
R10: Aspect du curseur (Sans grand intérêt) .
R11: Numéro de ligne ou finit le curseur (Sans intérêt).
R12: Octet fort de l'adresse départ de la RAM écran .
R13: Octet faible de l'adresse départ de la RAM écran .
R14 & R15 : Position du curseur sans intérêt .
R16 & R17 : Crayon optique débilum babus .
Avant de détailler tous ces registres , je dois vous signaler une particularité essentielle du CRTC ! Contrairement à ce que l'on pourrait croire , il ne travaille pas en lignes écran et en cases écran mais en lignes caractères (8 lignes écran) et les modifications sur les colonnes portent toujours sur 2 cases mémoire à la fois soit la taille d'un caractère en mode1 . A l'initialisation du CPC , vu du point de vue du CRTC l'écran mesure 25 lignes sur 40 colonnes !
Note : Certaines modifications de registres ont des effets biens connus (Overscan , scrolling hard , tremblement de l'écran , etc ...) .
D'autres peuvent avoir des effets imprévus voire planter le CPC ! Des essais divers effectués au pifomètre peuvent parfois produire des effets spectaculaires .
R0: Ce registre conditionne le temps attribué au rayon pour balayer l'écran dans le sens de la largeur . Il faudra parfois jouer sur celui-ci si l'on augmente trop la largeur de l'écran avec R1 pour que le rayon aie le temps de balayer le nombre de colonnes prévues par R1 . Modifier R0 de manière excessive aura des effets parfois surprenants .
R1: Nombre de colonnes (40 normalement) d'affichage écran . Vous pouvez pousser jusqu'à 255 colonnes soit 500 cases écran par ligne ce qui fait beaucoup ... Si un changement de ce registre provoque des effets désagréables modifiez R0 dans le même sens (Au pif jusqu'à ce que l'image se stabilise) .
R2: La taille de la bordure dépend de la longueur de ce signal de synchronisation horizontale . Si on le réduit , l'affichage RAM écran se produit plus tôt, et tout l'écran se décale vers la gauche . Inversement , si on l'augmente on pousse l'écran à droite . Une unité correspond à un décalage de 2 cases écran . On peut donc pousser l'écran vers la gauche de 3 unités équivalent à 6 cases mémoire et augmenter R1 de 6 unités soit 12 cases mémoire . On aura ainsi un écran de 92 cases mémoire (46 caractères CRTC) de large entièrement visible . Toute modification exagérée de R2 entraîne des effets pernicieux qu'il faudra corriger avec R0.
R3: La modification de ce signal de synchronisation ne semble pas produire d'effets très utilisables , essayez quand même pour voir ...
Voilà pour les effets spéciaux dans le sens de la largeur maintenant, debout !
R4: Ce registre conditionne le temps attribué au rayon pour balayer l'écran sur toute la hauteur . Il faudra parfois jouer sur celui-ci si l'on augmente trop la hauteur de l'écran avec R7 pour que le rayon aie le temps de balayer le nombre de lignes prévues par R7 . Modifier R4 de manière excessive aura des effets parfois surprenants .
R5: Modifier la fréquence de renouvellement de l'image peut provoquer des tressautements et scrollings verticaux .
R6: Nombre de lignes (25 normalement) d'affichage écran . Vous pouvez pousser jusqu'à 255 lignes ...Si un changement de ce registre provoque des effets désagréables modifiez R4 dans le même sens (Au pif jusqu'à ce que l'image se stabilise) .
R7: La taille de la bordure dépend de la longueur de ce signal de synchronisation vertical . Si on le réduit , l'affichage RAM écran se produit plus tôt et tout l'écran se décale vers le haut . Inversement , si on l'augmente on pousse l'écran en bas. Une unité correspond à un décalage d'une ligne caractère . On peut donc pousser l'écran vers le haut de 4 lignes et augmenter R6 de 8 unités .On aura ainsi un écran de 33 lignes (264 lignes écran)de haut entièrement visible . Toute modification exagérée de R2
entraîne des effets pernicieux qu'il faudra corriger avec R4 .
Deux autres registres peu utilisables sauf pour faire trembler l'écran .
R8: Mode de travail du CRTC . C'est lié à la manière donc les connections
sont établies dans votre ordinateur et reste en principe à 0 . Toujours en
principe , seuls les bits 0 & 1 sont utilisés ... Pourtant si on lui envoie
240 l'écran est totalement occupé par la bordure , comprenne qui pourra ...
R9: Contient le nombre de lignes écran occupées par 1 caractère-1 donc 7.
Le modifier fragmente l'écran ou le promène dans le sens vertical .
Vous avez vu que l'on peut tranquillement modifier la taille de l'écran
et sa position de départ . Ce qui est dommage c'est que cet écran ne peut
toujours pas dépasser 16K soit 25 lignes de 40 colonnes CRTC (900 positions
CRTC) .
Si vous activez un écran de 46 colonnes par 33 lignes (1518 positions
CTRC) que va t-il se passer ?
Des possibilités du CTRC vont déborder : 1518-900 = 618 Positions .
Comme en temps normal la dernière ligne écran n'est pas utilisée (16K
font en réalité 26 lignes de 80 cases mémoire (26*8*80=16640) nous pourrons
accéder à cette 26ème ligne de 40 colonnes CRTC que ne gère pas le basic
(sauf en cas de scrolling) et il restera :
618-40=578 Positions inutilisables dans lesquelles le haut de la RAM
écran va se répéter à partir de &C000 ! Vous disposez donc d'une surface
équivalent à un overscan mais sans pouvoir gérer la totalité de l'écran ! Ne
pleurez pas , quand je vous aurai expliqué à quoi servent R12 & R13 .
R12: Ce seul registre permet non seulement de mettre la RAM écran dans
n'importe lequel des 4 blocs de 16K mais en plus il permet d'adresser 32K
pour l'écran au lieu des 16 prévus initialement . Ce sont les bits mis ou pas
qui permettent le choix du bloc RAM et de la longueur d'adressage .
Les bits 7 & 6 ne sont pas utilisés .
Les bits 5 & 4 déterminent l'adresse de départ de la RAM écran comme ceci
7 6 5 4 3 2 1 0
0 0 0 0 0 0 0 0 = 0 : RAM écran 16K de #0000 à #3FFF
0 0 0 1 0 0 0 0 = 16 : RAM écran 16K de #4000 à #7FFF
0 0 1 0 0 0 0 0 = 32 : RAM écran 16K de #8000 à #BFFF
0 0 1 1 0 0 0 0 = 48 : RAM écran 16K de #C000 à #FFFF
Les bits 3 & 2 mis simultanément adressent 32K de RAM écran .
7 6 5 4 3 2 1 0
0 0 0 0 1 1 0 0 = 12 : RAM écran 32K de #0000 à #7FFF
0 0 0 1 1 1 0 0 = 28 : RAM écran 32K de #4000 à #BFFF
0 0 1 0 1 1 0 0 = 44 : RAM écran 32K de #8000 à #FFFF
0 0 1 1 1 1 0 0 = 60 : RAM écran 32K de #C000 à #3FFF
NOTE : Ces 2 bits doivent être mis simultanément ! Un seul d'entre eux (3
ou 2) automatique de 25 sprites -mis n'a aucun effet .
Les bits 1 & 0 : Que la peste et la vérole s'abattent sur tous les
auteurs ayant traité du CRTC et ayant passé sous silence l'usage de ces 2
bits pourtant fort utiles ! Ils permettent en effet d'avancer le début de la
RAM écran de 512 à 1536 octets !
C'est a dire que pour un écran prévu en &C000 les bits 0 & 1 décaleront
la 1ère adresse en :
Bits : 1 0
0 1 : Départ en &C0 + &200 (32ème octet de la 6ème ligne caractère)
1 0 : Départ en &C0 + &400 (66ème octet de la 13éme ligne caractère)
1 1 : Départ en &C0 + &600 (16ème octet de la 20éme ligne caractère)
Ces 3 décalages (#200,#400,#600) seront les mêmes quelque soit l'adresse
de départ envisagée (#0000,#4000,#8000,#C000) et le mode d'adressage 16K ou 32K .
R13: Ce registre permet d'affiner le point de départ de la RAM écran . Il décalera l'adresse d'origine des données de 2 cases mémoire (1 colonne CRTC) pour une unité ajoutée . On peut encore repousser le départ d'écran de 255*2=500 octets avec R13 . Par exemple , avec une RAM en #C000 , mettre 4 dans le registre R13 mettra le début d'écran en #C000+2*4 = #C008 .
- OVERSCAN CHAPITRE 1 -
Enfin nous y-sommes ! Il fallait bien que je vous explique comment fonctionne le CRTC avant d'y parvenir car tout passe par lui ! Alors pour ouvrir l'écran à l'overscan c'est tout simple . Bien qu'on puisse affecter une RAM écran de 32K , le cadre en plastique qui entoure votre moniteur est un peu trop petit pour y loger tout ça ! Le maximum autorisé sera de 92 octets (46 colonnes CRTC) et 33 lignes caractère (264 lignes écran) . Ces dimensions laissent un petit bout de bordure visible mais si on pousse d'encore une colonne ou une ligne , une partie de l'affichage se fera derrière le plastique !
Pour donner à l'écran cette nouvelle dimension , vous mettrez :
46 (Colonnes) dans R1
49 dans R2 (Ce qui avance la synchro horizontale de 3 colonnes)
33 (lignes) dans R6
34 Dans R7 (Ce qui avance la synchro verticale de 4 colonnes)
Faites l'essai avec le programme CRTC (Autre face SOS7) et vous verrez l'écran s'éclater joyeusement . Reste à faire disparaître la répétition de l'écran vers le bas ! Il suffit de mettre 60 dans le registre R12 et vous aurez un écran de 32K commençant en #C000 !
Et c'est là que ça devient caca ! Avec un écran de 32K en #C000 , la seconde zone de 16K s'étendra de 0 à #3FFF . Comme la zone de 0 à #170 est utilisée par le système bonjour les dégâts ...
Alors entre #8000 & #C000 ? Dites adieu aux vecteurs et aux paramètres du drive ! Ce secteur est réservé aux spécialistes qui savent réécrire le système d'exploitation dans une zone préservée .
Entre #4000 et #8000 c'est pareil , on bouffe le système et entre 0 et
#7FFF on redétruit la zone 0-#170 . Alors on se le met où l'overscan ?? Ne répondez pas svp. Je vais vous le dire .
Comme on n'utilisera jamais les 32K , on le met un peu au-dessus de 0 en décalant le départ de la RAM écran . On peu choisir 3 possibilités :
#40C: Donner 14 dans R12 pour adresse 0 , 32K de RAM et décalage de #400 et 6 dans R13 pour décaler encore de 12 octets .
#240: Donner 13 dans R12 pour adresse 0 , 32K de RAM et décalage de 200 et 32 dans R13 pour décaler encore de 64 octets .
#D0 : Donner 12 dans R12 pour adresse 0 , 32K de RAM et 104 dans R13 pour décaler encore de 208 octets .
Je vous entends déjà demander pourquoi toujours décaler la RAM dans R13 alors que vous devriez deviner ... Il y-a une jointure à effectuer entre les 2 zones de 16K (#3FFF/#4000) et si l'adresse #4000 ne correspond pas exactement au début d'une ligne écran , amusez vous donc à calculer les adresses pour afficher un écran ou animer un sprite sur ce chevauchement ! Le décalage de R13 amène l'adresse #4000 sur la colonne la plus à gauche de la ligne où elle se trouve .
A part ça pourquoi pas #600 et des poussières ? Parceque dans ce cas , la seconde zone écran excède un peu 16K et il faudrait réduire la hauteur d'une ligne .
Laquelle des 3 choisir ? #240 et #40C permettent de préserver un petit bout de basic . #D0 détruit tout ce qui est basic mais préserve le système .
Les 3 sont donc valables , d'autant plus que la zone écran #C000/#FFFF n'est plus utilisée comme écran et peu contenir une zone programme de même que la zone RAM de #8000 à &A6FF donc, overscan ou pas , on dispose encore d'à peu près 28K pour la programmation ou pour sauvegarder une partie de la RAM basse pendant l'overscan .
Pour les 3 programmes overscan qui figurent dans le chapitre suivant j'ai choisi l'adresse #D0 . Ce choix s'explique par le fait que le programme d'affichage doit charger un fichier écran de 24K EN DEHORS DE LA ZONE OVERSCAN car il faut répartir ces 24K dans 32K écran et toute location trop basse entrainerait un recouvrement des données et un affichage incorrect . On peut bien sur charger plus bas mais dans ce cas , il faut jongler avec des zones de transit pour pour que tout se passe bien . Autre solution, séparer le fichier overscan en 2 fichiers de 12K , c'est plus simple mais plus long à charger .
Dernière précision vitale ! Comment calculer ADINF et ADSUP avec des écrans à coucher dehors ? C'est relativement aisé . Voici comment modifier les routines classiques :
Ca c'est la version Pour 92 colonnes
80 colonnes en #C000 en #C000 on fera
; ;
ADINF LD A,H ADINF LD A,H
ADD A,8 ADD A,8
LD H,A LD H,A
RET NC RET NC
PUSH DE PUSH DE
LD DE,#C050 LD DE,#C050+12 ;Puisqu'il y-a 12 colonnes
ADD HL,DE ADD HL,DE ;de plus . Pour un ecran en
POP DE POP DE ;88 colonnes devinez donc ?
RET RET
; ;
ADSUP LD A,H ADSUP LD A,H
SUB 8 SUB 8
LD H,A LD H,A
AND %01000000 AND %01000000
RET NZ RET NZ
PUSH DE PUSH DE
LD DE,#3FB0 LD DE,#3FB0+12
ADD HL,DE ADD HL,DE
POP DE POP DE
RET RET
;
Mais en overscan il faut gérer des adresses différentes de 0 à # 7FFF , il y-à de nombreuses solutions et la plus évidente est celle-ci . Les vecteurs #BC26 & #BC29 font ces calculs et le font sur toute adresse de 0 à #FFFF ! Alors pourquoi se casser la tête surtout quand comme moi on a définitivement voué une haine féroce à toute forme de calcul ? On recopie les bouts de ROM intéressants ce qui nous donnera les 2 nouvelles routines :
;
ADINFUNI LD A,H
ADD A,8
LD H,A
AND #38
RET NZ
;
LD A,H
SUB #40
LD H,A
LD A,L
ADD A,#50 ;A modifier selon la différence entre le nombre de colonnes
LD L,A ;en plus ou en moins de 80 .
RET NC
;
INC H
LD A,H
AND 7
RET NZ
;
LD A,H
SUB 8
LD H,A
RET
- L'OVERSCAN CHAPITRE 2 -
Je décris ici les 3 programmes qui permettent de créer et afficher un écran en overscan . Le plus difficile sera de réaliser votre dessin . Il n'existe aucun D.A.O fonctionnant en mode overscan ! Il faut donc ruser et couper l'overscan en 4 .
Ce 1er programme va sauvegarder un à un 4 écrans normaux sur lesquels il définira préalablement une zone de 46 colonnes par 132 lignes ce qui est le quart d'un écran de 92 colonnes par 264 lignes . Un texte repère sera sauvé avec l'écran . Cela nous donnera :
ECRAN HAUT GAUCHE - ECRAN HAUT DROIT
ECRAN
BAS GAUCHE - ECRAN BAS DROIT
Ou les pointillés figurent les 4 zones de l'écran overscan . Il vous faudra créer votre image en 4 fois à l'intérieur de ces zones et resauvegarder séparément chaque écran . Les 4 fichiers de 17K sont toujours sauvegardés sous les noms OVERSCR1.SCR --OVERSCR2.SCR - OVERSCR3.SCR - OVERSCR4.SCR -
Libre à vous de changer les noms lors de la création du dessin .
Le code source du programme est peu commenté , tout ce qui le concerne se trouve dans les cours de graphisme et les routines disquette .
ORG 41000
;
;- Création de 4 écrans pour OVERSCAN -
;
XOR A ;Remise a zéro éventuelle erreur fichier
LD (FLGERR),A
;
LD HL,#E280+34 ;Adresse départ 1er écran
LD B,46 ;de 46 colonnes par 132 lignes
LD C,132
;
PUSH BC
LD DE,TSC1 ;Afficher texte écran 1 et sauver .
CALL SAVE
POP BC
;
LD HL,#E280 ;Encore 3 a faire de la même manière
PUSH BC
LD DE,TSC2
CALL SAVE
POP BC
;
LD HL,#C000+34
PUSH BC
LD DE,TSC3
CALL SAVE
POP BC
;
LD HL,#C000
PUSH BC
LD DE,TSC4
CALL SAVE
POP BC
RET ;C'est fini
;
;- Marquer la zone overscan et sauver un écran -
;
SAVE PUSH BC ;Préserver registres
PUSH HL
PUSH DE
LD A,(MODE) ;L'octet de remplissage n'est pas le même
LD HL,BCLFLIN+1 ;selon le mode écran choisi cela évite d'avoir
LD (HL),48 ;un écran a rayures .
OR A
JR Z,SETMODE
LD (HL),255
SETMODE CALL #BC0E
POP DE
POP HL
POP BC
;
BCLFLIN1 PUSH BC ;Remplissage de la zone écran qui sera
PUSH HL ;utilisée par l'overscan
BCLFLIN LD (HL),48
INC HL
DJNZ BCLFLIN
POP HL
PUSH DE
CALL #BC26 ;Routine système qui fait la même chose que
POP DE ;ADINF mais en plus lent . Ici on n'est pas presse
POP BC
DEC C
JR NZ,BCLFLIN1
CALL PRT
;
LD HL,NOMSCR ;Sauver l'écran , voyez donc notre cours sur les
LD B,12 ;vecteurs disque dans ce numéro pour comprendre .
LD DE,34000
CALL #BC8C
JR NC,ERRFICH
LD HL,#C000
LD DE,#4000
LD A,2
CALL #BC98
JR NC,ERRFICH
CALL #BC8F
JR NC,ERRFICH
LD HL,NOMSCR+7 ;On augmente de 1 le 8eme caractère du nom de fichier
INC (HL) ;pour avoir OVERSCR1.SCR , OVERSCR2.SCR , Etc ..
RET
;
ERRFICH LD (FLGERR),A ;Sort ici si erreur de fichier .
CALL #BC92
LD DE,TERFICH
JP PRT
;
PRT LD A,(DE) ;Routine PRINT .
OR A
RET Z
CALL #BB5A
INC DE
JR PRT
;
TSC1 DB 31,1,2,"ECRAN HAUT GAUCHE",0
TSC2 DB 31,1,2,"ECRAN HAUT DROITE",0
TSC3 DB 31,1,24,"ECRAN BAS GAUCHE",0
TSC4 DB 31,1,24,"ECRAN BAS DROITE",0
TERFICH DB 31,1,1,"ERREUR FICHIER",0
LIST
NOMSCR DB "OVERSCR1.SCR"
FLGERR DB 0
MODE DB 0
NOLIST
Une fois le dessin créé à l'intérieur des 4 écrans séparés , il faut regrouper le tout en un seul fichier utilisable en overscan . Pour cela il faut extraire de chaque écran les portions utiles et les sauvegarder en une seule zone RAM . Voici ce qu'il faut obtenir :
Adresse 10046 : 46 Oct. - 46 Oct.
Adresse 10000 ----->
Adresse 22144 ----->
(10000+92 Col.*134 Lin.)
<----- Adresse 10092
Hauteur 134 lignes
Voici le listing source qui permet d'obtenir ce résultat .
;
;- Extraire et regrouper en un écran de 24K les 4 zones définies par OVERSCR -
;
NOLIST
ORG 41500
;
CP 5 ;5 Noms de fichiers a transmettre . 4 a charger
RET NZ ;et un a sauver en sortie .
;
LD B,65 ;RAZ de la zone noms de fichier
LD HL,NOM1
BCLRAZ LD (HL),0
INC HL
DJNZ BCLRAZ
;
XOR A
LD (FLGERR),A
;
LD L,(IX+0) ;Passer le nom de sauvegarde . (Voyez les routines
LD H,(IX+1) ;du drive dans ce numéro pour l'explication sur
LD C,(HL) ;le passage des paramètres)
INC HL
LD E,(HL)
INC HL
LD D,(HL)
;
LD HL,NOMSAV
LD (HL),C ;Stocker la longueur du nom de sauvegarde
INC HL
EX DE,HL ;et le nom du fichier a la suite .
LD B,0
LDIR
;
LD HL,NOM1
LD B,4
;
TRANS4N PUSH HL
LD L,(IX+8) ;Passer les noms des 4 fichiers
LD H,(IX+9) ;En pensant que pour conserver l'ordre
LD C,(HL) ;CALL àfic(1)$,àfic(2)$,àfic(3)$,àfic(4)$,àficsav$
INC HL ;Il faut commencer par le pointeur le plus haut
LD E,(HL) ;et décrémenter !
INC HL
LD D,(HL)
;
POP HL ;Adresse du nom en cours
PUSH BC
PUSH HL
;
LD (HL),C ;Ranger longueur dans le 1er octet nom
INC HL
EX DE,HL ;Copier le nom a la suite
LD B,0
LDIR
;
POP HL ;Adresse du nom en cours
LD BC,13
ADD HL,BC ;Pointer le nom suivant
POP BC
;
DEC IX
DEC IX
DJNZ TRANS4N ;4 fois .
;
;- Charger et transférer les fichiers -
;
LD HL,NOM1
CALL LOAD
LD HL,#E280+34 ;Adresse de la portion écran haut gauche
LD DE,10000 ;Debut de la zone overscan
CALL COPYSCR
;
LD HL,NOM2
CALL LOAD
LD HL,#E280 ;Adresse de la portion écran haut droite
LD DE,10046 ;Debut de la zone overscan + décalage de 46 octets
CALL COPYSCR
;
LD HL,NOM3
CALL LOAD
LD HL,#C000+34 ;Adresse de la portion écran bas gauche
LD DE,22144 ;Milieu de la zone overscan
CALL COPYSCR
;
LD HL,NOM4
CALL LOAD
LD HL,#C000 ;Adresse de la portion écran bas droite
LD DE,22190 ;Milieu de la zone overscan + décalage de 46 octets
CALL COPYSCR
;- Sauvegarde de la zone overscan -
;
LD HL,TPUTDIS ;Attendre disquette
CALL PRT
CALL #BB06
;
LD HL,NOMSAV ;Sauvegarde de la zone overscan
LD B,(HL) ;Longueur du nom
INC HL ;Adresse du nom
LD DE,5000 ;Buffer drive
CALL #BC8C
JR NC,ERRDRIV
LD HL,10000 ;Adresse début sauvegarde
LD DE,24298 ;Longueur a sauver
LD BC,0
LD A,2 ;Type binaire
CALL #BC98
JR NC,ERRDRIV
CALL #BC8F
JR NC,ERRDRIV
RET
;
;- Routine de transfert -
;
COPYSCR LD B,132 ;132 lignes (264/2)
COPY PUSH BC
PUSH HL ;Adresse source dans l'écran
LD BC,46 ;46 colonnes a transférer
LDIR
LD HL,46 ;Et on saute 46 colonnes pour laisser la place
ADD HL,DE ;a la moitie opposée
EX DE,HL ;Remet adresse suivante de la zone overscan dans DE
POP HL ;Recuperer adresse source écran
CALL #BC26 ;Et pointer la ligne en dessous
POP BC
DJNZ COPY ;On recommence pour 132 colonnes
RET
;
;- Routine de chargement des écrans -
;
LOAD LD B,(HL) ;Charger un des 4 fichiers . Longueur du nom dans B
INC HL ;Puis pointer sur le nom
LD DE,#C000 ;Buffer drive
CALL #BC77 ;Ouvrir fichier
JR NC,ERRDRIV
LD HL,#C000 ;Adresse chargement
CALL #BC83
JR NC,ERRDRIV
CALL #BC7A
JR NC,ERRDRIV
RET
;
ERRDRIV LD (FLGERR),A ;Sort ici si erreur drive
CALL #BC7D
CALL #BC92
LD HL,TERRDRIV
JP PRT
;
PRT LD A,(HL)
OR A
RET Z
CALL #BB5A
INC HL
JR PRT
;
TERRDRIV DB 31,1,1," ERREUR DISQUE !",7,0
TPUTDIS DB 31,1,1," PLACER DISQUETTE",10,13
DB " SAUVEGARDE IMAGE",10,13
DB " OVERSCAN ",10,13
DB " ET PRESSER UNE",10,13
DB " TOUCHE",7,0
LIST
NOM1 DS 13
NOLIST
NOM2 DS 13
NOM3 DS 13
NOM4 DS 13
NOMSAV DS 13
LIST
FLGERR DB 0
NOLIST
;
Et pour finir , il ne reste plus qu'à afficher l'overscan . Nous allons avoir quelques problèmes d'emplacement mémoire ... Comme expliqué dans le chapitre 1 , l'adresse la plus utilisable est #D0 alors utilisons la comme départ de la nouvelle RAM écran . Le 1er bloc de 16K commencera en #D0 , le second en #4000 . La RAM écran d'origine en #C000 ne sera pas utilisée par le CRTC . Nous y recopierons donc le contenu d'origine à partir de #D0 et sur 16K avant d'activer le CRTC . Avant de quitter le programme , cette zone sera ramenée de #C000 vers #D0 avant de provoquer le reset du CRTC . Nous pourrons ainsi retrouver intact un éventuel programme basic ou tout autre code situé en RAM basse pour peu qu'il n'excède pas 16K .
L'écran overscan ne remplissant pas exactement les 32K , il faudra le transférer ligne par ligne en #D0 puis en #4000 par LDIR . Pour éviter des chevauchements désagréables lors de LDIR , il sera chargé en 17000 puis transféré . Cela nous donne :
#D0 -----> 16999 : Ecran overscan .
17000 ---> 41298 : Chargement overscan .
41500 ---> 42500 : Programmes overscan .
Donc toute la RAM est occupée et si un code binaire doit être ensuite utilisé , il faut d'abord effectuer le transfert et l'affichage overscan et seulement après , charger le code en #8000 . Si l'on ne souhaite pas préserver la RAM basse au cours de cette opération , on pourra utiliser les 16K en #C000 comme zone de programmation .
;
;- Charger et afficher un écran en overscan -
;
;
ORG 42000
NOLIST
CP 1 ;1 Parametre pour le nom de fichier .
RET NZ
;
CALL LOADSCR ;Charger l'écran AVANT TOUT .
RET NC
;
CALL SAVERAM ;Sauver la RAM basse en #C000 (L'ancien écran)
LD HL,TOVERCRT ;Puis passer l'écran en 92 colonnes 264 lignes
CALL OUTCRTC ;avec #D0 comme départ .
;
CALL AFFSCR ;L'afficher .
;
CALL #BB06 ;Attendre une touche
LD HL,TRESTORE ;Remettre le CRTC aux normes CPC
CALL OUTCRTC
JP RESTORAM ;Récupérer la RAM basse et c'est fini
;
LOADSCR LD L,(IX+0) ;Passer nom de fichier
LD H,(IX+1)
LD B,(HL) ;Longueur dans B
INC HL
LD E,(HL)
INC HL
LD D,(HL)
;
EX DE,HL ;Adresse du nom
LD DE,#1000 ;Buffer
CALL #BC77
RET NC
;
LD HL,17000 ;Charger en 17000
CALL #BC83
CALL #BC7A
RET
;
AFFSCR LD B,255 ;264 lignes ça ne tient pas dans un registre 8 bits !
LD C,92 ;On procédera en 2 fois .
LD DE,#D0 ;Adresse de l'écran
LD HL,17000 ;Adresse de la zone overscan
CALL BCLT1 ;Transferer 255 lignes
LD B,9 ;Puis les 9 qui manquent pour faire 264
;
BCLT1 PUSH DE ;Préserver adresse écran
PUSH BC
LD B,0
LDIR ;Transferer 1 ligne
POP BC
POP DE
;
PUSH HL ;ADINFUNI est une routine qui a le même effet que
EX DE,HL ;ADINF mais calcule le décalage écran pour toute
CALL ADINFUNI ;adresse de 0 a #FFFF . Autre avantage , lorsque
LD A,H ;le 1er groupe est dépasse (de 0 à #3FFF) H revient
OR A ;a 0 ce qui permet de tester rapidement si on doit
JR NZ,OKAFF ;passer au second groupe en #4000
LD H,#40
OKAFF EX DE,HL
POP HL
DJNZ BCLT1
RET
;
OUTCRTC LD BC,#BC00 ;Activation du CRTC
BCLOUTC LD A,(HL)
CP #FF
RET Z
OUT (C),C ;Selection des port #BC00 a #BC12
INC B
OUT (C),A ;Port BDxx envoyer l'octet voulu .
DEC B ;Port #BCnn
INC C ;incrémente
INC HL ;Pointer octet CRTC suivant .
JR BCLOUTC
;
ADINFUNI LD A,H ;Routine ADINF spéciale
ADD A,8
LD H,A
AND #38
RET NZ
;
LD A,H
SUB #40
LD H,A
LD A,L
ADD A,#5C
LD L,A
RET NC
;
INC H
LD A,H
AND 7
RET NZ
;
LD A,H
SUB 8
LD H,A
RET
;
RESTORAM LD DE,#D0 ;Récupérer la RAM depuis #C000
LD HL,#C000
JR TRANS
;
SAVERAM LD HL,#D0 ;Sauver la RAM en #C000
LD DE,#C000
TRANS LD BC,#4000
LDIR
RET
;
;ci-dessous : La 1ere ligne indique les registres du CRTC concernes .
;La seconde les valeurs a envoyer aux registres correspondants pour
;activer l'overscan en #D0 .
;La troisième les valeurs pour restaurer le CTRC aux normes CPC
;
; 0 1 2 3 4 5 6 7 8 9 10 11 12 13
TOVERCRT DB 62,46,48,14,38,00,32,34,00,07,00,00,12,104,#FF
TRESTORE DB 63,40,46,14,38,00,25,30,00,07,00,00,48,00,#FF
;
list
db 0
ins de 80 .
RET NC
;
LD A,H
DEC H
AND 7
RET NZ
;
LD A,H
ADD A,8
LD H,A
RET
;
Fichier texte extrait du fichier « SOS Programmeurs Issue 7 (F) (1990) (PD) (Disk 2 of 2).zip », sources compilée et démos sur la disquette format CPC.
Exemples sur la face 2 de la disquette : « SOS Programmeurs Issue 7 (F) (1990) (PD) (Disk 1 of 2).zip ». - Merci à l'auteur.
Nota : Ce genre d'overscan est fonctionnel avec la plupart des CRTC.
... Ce qui n'est pas forcement le cas avec les Démos qui poussent les CRTC au maximum de leurs capacités (à réserver au CRTC6845R).
Pour en savoir plus sur l'overscan sur CPC (et pour faire fumer le CRTC de votre bon vieux CPC):
http://cpcrulez.free.fr/coding_logon_menu.htm
http://cpcrulez.free.fr/coding.htm
XavSnap. /// Xavier Martin ///
Email :
fetrmartin@free.fr
( Français
&ndash English )
.
.
Last up-Date 11/09/2004 (jj:mm:yyyy)