J'ai eu une petite idée qui nécessiterait une rupture à la ligne avec des lignes indépendantes et uniques mais je bloque sur un truc.En fait, on voit dans certaines démos (DTC par ex.) des ruptures à la ligne sur quasiment toute la surface de l'écran, le tout en overscan.

Mais, en étudiant un peu mon truc, je me suis rendu compte qu'en fait on ne peut faire adresser au CRTC via R12/13 que 2K (bit 0 à 9) par bloc pour 4 blocs (bits 12&13) (et admettant qu'on utilise pas les interruptions ou en mode vectorisé alors) soit 8K, ce qui me semble un peu léger pour couvrir un écran, de plus en overscan.

D'où ma question, y'a t'il une astuce pour dépasser ça ou alors mon raisonnement est foireux, ou encore il faut faire avec ? et surtout comment font certaines démos

_________________
"NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)

Réponse rapide d'un habitué mais novice (pas codeur en fait).

Si la technique que tu choisis est une ligne à ligne "classique", tu es effectivement limité à 8k de gfx adressable. C'est ce que fait la DTC et une multitude de demos CPC.

Il existe d'autres techniques bien plus compliquées et que je ne serais pas capable de t'expliquer dont tu pourras trouver des exemples dans la S&KOH ou la cheatpart de la Synergy2 (lui-même un hommage à la S&KOH).

Après, tu peux tenter une sorte de ligne à ligne en posant r9 à 1 au lieu de 0, ce qui t'affiche les lignes par 2, et te permettra des trames. La surface affichable passe alors de 8k à 16k.

_________________
Les Sucres en Morceaux

Merci de ta réponse, ça confirme ce qui me semblait.Par contre , c'est vrai j'avais pas cité S&KOH qui est une de mes préférées avec sa grosse image (32K?) et la cheat-part de Synergy2 qui est techniquement terrible.

Sinon, c'est vraiment pas con cette histoire de jouer avec R9, aussi pour l'histoire des trames, malheuresement les lignes doivent être indépendantes les unes des autres et je voudrai en plus que ça scrolle.Au pire, je vais réduire la largeur de l'écran à 32 caractères histoire de faire rentrer 256 lignes

_________________
"NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)

Ce que tu recherches s'appelle la rupture verticale, qui se décline selon plusieurs "noms" en fonction de la manière dont c'est réalisé...

Imagine que tu fasses une rupture ligne à ligne standard (r4=0) et que tu décides de modifier la taille d'une ligne via r0 en t'arrangeant pour qu'une ligne complète fasse 64 nop et que tu génères un signal hsync au bon endroit et de la bonne taille pour que le moniteur trouve ce signal de synchro. (en fait même chose que pour une rupture horizontale)

Le cas le plus "simple" est de fixer r0=7 et r9=7
Ainsi tu crées 8 petits écrans de 8 nop.
A chaque fois que 8 nops sont écoulés, le compteur de ligne s'incrémente, et donc tu affiches sur une ligne 8 blocs. Il faut réduire la longueur hbl à 0 pendant l'opération.
Cette méthode permet de contrôler l'adresse de chaque ligne mais pose le problème d'avoir une mémoire assez morcelée puisque tu changes de bloc tous les 16 octets. Elle présente aussi le problème d'afficher sur crtc 0 un octet de border entre chaque bloc, ce qui se traduit visuellement par des lignes verticales.

Tu peux aussi envisager de faire un écran de 48 nop et 8 écrans de 2 nop.
r0=47, puis r0=1 pendant 16 nop. Ce qui signifie que pendant la partie non visible ou tu auras judicieusement placé tes 8 écrans de 2 nops, il y aura des changements de blocs dont tu peux contrôler le bloc d'arrivée grâce à la modification judicieuse de r9.
(et là tu as le principe de S&KOH)

Toute la difficulté réside à changer les registres du crtc assez vite, et il faut donc assez bien maitriser le z80a et les systèmes d'i/o du cpc.

Merci Longshot !

C'est donc ça la fameuse rupture verticale, même si ce n'est pas encore bien net sur les points techniques, j'ai bien compris le principe.Ton explication est très claire, me restera à potasser encore un peu plus la doc existante pour relier les points entre eux.J'imagine qu'il y aussi derrière tout ça un sacré travail sur le code.

Et pis du coup, ça m'a sacrément éclairé sur certaines démos ou encore sur une des previews d'overflow où je me demandais comment il faisait (celle qui fait comme dans l'intro de S&KOH mais sans GFX avec des plus petites boites).

Du coup ça m'amène à poser deux questions : est ce que cette technique à été documentée ? et quel est l'esprit tordu qui a eu l'idée le premier de torturer le pauvre CRTC à ce point (ou est ce une idée qui "flottait dans l'air" ou encore un accident de laboratoire)

_________________
"NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)

Il y a eu des essais de documentation un peu empiriques réalisés par les pionniers du split vertical. Overflow et Gozeur par exemple. Après je pense que tu peux trouver des excellentes explications dans deux fanzines (Amslive (Madram) et Quasar (Offset))

Les premières ruptures "standards" connues n'étaient pas le fruit du hasard je pense.
Elles ont été réalisés par des auteurs de jeux comme Genocide ou Skateball, qui sont sans doute les premiers à ma connaissance.

Après, ce principe a été amélioré. (plus d'une rupture, ligne à ligne, vertical sous plusieurs "déclinaisons", évolutif, ...)

Après c'est sans doute une question de curiosité lorsqu'on bidouille le crtc.
La découverte des "overscans bits" pour avoir 32k de vidéo est le résultat inattendu d'expérimentations empiriques par exemple.

ou une bonne lecture des datasheets des composants qui donne les infos !!!
car tout n'est pas empirique dans la programmation !!!

C'est toujours intéressant de savoir comment voire pourquoi on en est arrivé à develloper des techniques aussi ingénieuses.

Tiens ça me rappelle une devise shadok à ce propos : plus ça rate, plus on a de chance que ça marche !

_________________
"NOP" tel est le programme parfait ! court, rapide, lisible et sans bugs (connus)

Disons qu'à l'époque les datasheet n'étaient pas forcément accessibles facilement...
Cela à tendance à s'adresser aussi aux électroniciens.
Et enfin, le datasheet, que ce soit pour un AY, un FDC ou un CRTC, par exemple, présente des cas simples prévus pour un cahier des charges standard.

Aller au delà de ce cahier des charges (par exemple les ruptures) fait rapidement apparaitre les petites "incompatibilités" qui ont fait le plaisir des petits et des grands

Longshot : en matiere de bidouillage CRTC, penses-tu qu'on a tout decouvert ? Ou qu'il reste encore des techniques possible a trouver ?

J'imagine que le positionnement actuel c'est genre "oui on a tout decouvert pour le coté hardware" mais "en termes d'effets basés sur des techniques hardware, il y a encore des choses inexploitées".

Je pense notemment à la Backtro de l'ami OVF.

@norecess :
Bin disons qu'avec 4 modeles de CRTC, y'a encore de la marge pour bien tout connaitre à fond.

Et il reste aussi l'Asic des Plus qui me semble plutôt inexploré, lol...

pour mettre tout le monde d'accord , ca saurai possible de faire une petite liste des different type ruptures avec l'image d'un effet pour l'illustré ??


DREAM DEMO 5 par CHANY/NPS (RUPTURE ???)


SHOW-OFF par EPSILON (RUPTURE LIGNE A LIGNE)

...

Je crois qu'on maitrise davantage les algorithmes internes des composants "complexes".
Il y a quand même eu beaucoup d'expérimentations sur les old.

Je ne suis pas certain qu'on sache tout sans avoir le code exact défini dans le circuit.
Du moins on s'en approche.
Ca tient maintenant surtout à des notions de "poteaux, d'intervalles et de timing".

Maintenant, pour l'utilisation de ces techniques à des fins de truande visuelle, sonore, ..., ce serait présomptueux de dire qu'on a pensé à tout faire.
Sinon à quoi servirait l'imagination...

Puis toi Longshot, on sait que tu es dans le coin en guise de "support"..

Sans entrer dans les details, connais-tu des utilisations, des méthodes.. que tu as en tête que personne n'aurait un jour exposé ? Genre un truc "ah, j'ai trouvé qq chose, ca marcherait bien..". Je reste tres evasif, mais juste savoir si tu te sens, avec le temps, "bloqué dans ton inspiration" ou si au contraire, tu penses qu'il y a encore des portes ouvertes a de nouveaux effets hardware..

Tu parlais du son, je suis convaincu que tu pencherais peut-etre pas forcement vers le CRTC.. peut-etre FDC & consorts..

Je dirais simplement (sans entrer dans les détails ) que la technique n'est pas une fin mais un moyen.

Ca a été longtemps le problème de la démo sur cpc.
Par exemple, beaucoup ont fait de la rupture pour faire de la rupture
Plutôt qu'utiliser la rupture par rapport à un besoin.

Et oui, je pense qu'il y a plein de choses qui n'ont pas encore été vues sur cpc.
On est quand même assez pauvres en démos si on se compare à d'autres machines.