[SHARP MZ-700] Sortie DVI via le RP2040-PiZero

[Bricox]

Ha bien, je n'avais pas regardé en détail, le SPI est donc en entrée, pas en sortie comme je l'avais imaginé.

Effectivement, c'est un bon point de départ pour analyser le processus de création.

[hlide]

Mais qu'est-ce que je maudis ce forum à la con qui me demande à nouveau le login après que je poste un long pavé !!!!

Purée je n'ai plus d'énergie à expliquer…

Ce que je souhaitais faire, c'est faire tout le traitement de capture et de remplissage du buffer vidéo par le PIO par le biais de la DMA.

Tout ça est sous réserve que cela soit possible avec la DMA, à savoir pointer la DMA sur les 320x200 pixels (octets) et la possibilité de la remplir en cycle (wrapping en anglais). Le buffer étant alloué, il est forcément aligné sur 4 octets et sa taille est multiple de 4 octets. A chaque fois qu'un octet est écrit, l'adresse est incrémenté de façon à pouvoir remplir le buffer. Et je prie pour que le DMA gère le retour en début d'adresse à la fin.

Je simplifie en omettant le color blending.

Donc le code SM va contenir les différentes étapes :
1) attendre la synchro verticale et ignorer les N lignes non visibles en comptant les synchros horizontaux.
2) compter les pixel clocks pour ignorer les pixels non visibles qui commence la ligne visible.
3) capturer les signaux B, R, G et I, les empiler dans la FIFO puis empiler 4 zeros pour faire un octet à DMA-iser dans le buffer vidéo.
4) compter les pixel clocks pour les 320 pixels visibles en rebouclant en 3)
5) compter les lignes pour les 200 lignes visibles en rebouclant en 4)
6) revenir en 1)

Alors le SM a des limitations :
- 32 instructions maximum,
- deux registres X et Y seulement,
- l'instruction SET accepte d'affecter une valeur 31 au plus en constante,
- l'instruction JMP X--/Y--, target est la seule façon de compter.

Malheureusement, c'est un peu chaud à faire en un seul SM.

Premier SM : gestion des blanks et signale au deuxième SM pour les lignes visibles
SM0 :

Etiquette de saut	N° Instruction (PC)	Instruction ASM PIO	Commentaire
wait_vsync:	00	WAIT 0 GPIO vsync	attendre le début d'une trame
	01	WAIT 1 GPIO vsync
	02	SET Y, V_BLANK_N	on présume qu'il y a moins de 32 lignes non visibles
v_blank_loop:	03	WAIT 0 GPIO hsync	attendre le début d'une ligne non visible
	04	WAIT 1 GPIO hsync	et que ce signal remonte pour pouvoir détecter le prochain en rebouclant
	05	JMP Y--, v_blank_loop	ignore les première lignes non visibles
	06	SET Y, 10	200 lignes -> 10 blocs ...
h_blank_loop_1:	07	SET X, 20	... de 20 lignes
h_blank_loop_2:	08	IRQ SET hsync_irq	déclenche le remplissage de la ligne visible
	09	WAIT 0 GPIO hsync	attendre le début de la ligne visible
	10	WAIT 1 GPIO hsync	et que ce signal soit remonté pour pouvoir détecter le prochain en rebouclant
	11	JMP X--, h_blank_loop_2
	12	JMP Y--, h_blank_loop_1	on itère sur les 200 lignes visibles
	13	JMP wait_vsync	on reboucle sur l'attente de la trame suivante

Deuxième SM : gestion de capture des pixels visible pour la ligne en cours
SM1 :

Etiquette de saut	N° Instruction (PC)	Instruction ASM PIO	Commentaire
capture_pixels:	00	IRQ WAIT hsync_irq	attente de la demande de remplissage de la ligne visible
	01	WAIT 0 GPIO hsync	attendre le début de la ligne visible
	02	IRQ CLEAR hsync_irq	l'IRQ est pris en compte
h_blank_loop:	03	SET X, H_BLANK_N/2	on présume qu'il y a moins de 32 paires des pixel non visibles
	04	WAIT 0 GPIO colr	attendre sur COLR
	05	WAIT 1 GPIO colr	et que ce signal remonte pour pouvoir détecter le prochain en rebouclant
	06	JMP X--, h_blank_loop	ignore les premiers pixels non visibles
	07	SET Y, 20	une ligne visible = 320 pixels, soit 20 blocs de 16 pixels
capture_320px_loop:	08	SET X, 8	8 paires de pixels = 16 pixels
capture_16px_loop:	09	WAIT 0 GPIO colr	attendre sur COLR
	10	IN PINS 4	récupère B, R, G et I et empile dans la FIFO pour la DMA
	11	IN NULL 4	empile 4 zéros pour compléter l'octet dans la FIFO pour la DMA
	12	WAIT 1 GPIO colr	attendre sur COLR
	13	IN PINS 4	récupère B, R, G et I et empile dans la FIFO pour la DMA
	14	IN NULL 4	empile 4 zéros pour compléter l'octet dans la FIFO pour la DMA
	15	JMP X--, capture_16px_loop
	16	JMP Y--, capture_320px_loop	itère sur les 320 pixels visibles
	17	JMP capture_pixels	on reboucle sur l'attente de la ligne suivante

Je suis dans l'hypothèse que les registres X et Y sont par SM et non juste par PIO. Et bien sûr, rien de codé réellement.

[Bricox]

Whaou ... belle analyse ...

Il faut toujours passer du temps pour l'analyse, c'est un bon investissement.

Quel est le mécanisme de synchro entre SM0 et SM1 ?

Avec cette présentation, cela met en évidence l'absence de l'instruction 07 :
(Si cela est juste un décalage, je te le fais. C'est facile pour moi avec Excel.)
tabat_asmpio
SM0 :

Etiquette	N° Instruction	Instruction ASM PIO	Commentaire
wait_vsync:	00	WAIT 0 GPIO vsync	attendre le début d'une trame
	01	WAIT 1 GPIO vsync
	02	SET Y, V_BLANK_N	on présume qu'il y a moins de 32 lignes non visibles
v_blank_loop:	03	WAIT 0 GPIO hsync	attendre le début d'une ligne non visible
	04	WAIT 1 GPIO hsync
	05	JMP Y--, v_blank_loop	ignore les première lignes non visibles
	06	SET Y, 10	200 lignes -> 10 blocs ...
h_blank_loop_1:	08	SET X, 20	... de 20 lignes
h_blank_loop_2:	09	IRQ SET hsync_irq	déclenche le remplissage de la ligne visible
	10	WAIT 0 GPIO hsync	attendre le début de la ligne visible
	11	WAIT 1 GPIO hsync
	12	JMP X--, h_blank_loop_2
	13	JMP Y--, h_blank_loop_1	on itère sur les 200 lignes visibles
	14	JMP wait_vsync	on reboucle sur l'attente de la trame suivante

SM1 :

Etiquette	N° Instruction	Instruction ASM PIO	Commentaire
capture_pixels:	00	IRQ WAIT hsync_irq	attente de la demande de remplissage de la ligne visible
	01	WAIT 0 GPIO hsync	attendre le début de la ligne visible
	02	IRQ CLEAR hsync_irq	l'IRQ est pris en compte
h_blank_loop:	03	SET X, H_BLANK_N/2	on présume qu'il y a moins de 32 paires des pixel non visibles
	04	WAIT 0 GPIO colr	attendre sur COLR
	05	WAIT 1 GPIO colr
	06	JMP X--, h_blank_loop	ignore les premiers pixels non visibles
	07	SET Y, 20	Un ligne visible = 320 pixels, soit 20 blocs de 16 pixels
capture_200px_loop:	08	SET X, 8	8 paires de pixels = 16 pixels
capture_16px_loop:	09	WAIT 0 GPIO colr	attendre sur COLR
	10	IN PINS 4	récupère B, R, G et I et empile dans la FIFO pour la DMA
	11	IN NULL 4	empile 4 zéros pour compléter l'octet dans la FIFO pour la DMA
	12	WAIT 1 GPIO colr	attendre sur COLR
	13	IN PINS 4	récupère B, R, G et I et empile dans la FIFO pour la DMA
	14	IN NULL 4	empile 4 zéros pour compléter l'octet dans la FIFO pour la DMA
	15	JMP X--, capture_16px_loop
	16	JMP Y--, capture_200px_loop	itère sur les 320 pixels visibles
	17	JMP capture_pixels	on reboucle sur l'attente de la ligne suivante

Autopush is enabled, threshold 8 : Transmission automatique quand 8 octets sont constituées

[hlide]

Les SM du même PIO peuvent utiliser jusqu'à 4 IRQ pour se signaler entre eux. Donc j'ai le SM0 qui signale au SM1 quand il doit traiter une ligne visible.

Grosso modo, SM0 lève un IRQ dès que l'on a passé la dernière ligne non visible avant d'entrer dans les lignes visible. Le SM1 attend que cet IRQ soit levé pour commencer à traiter la ligne. Il désactive ensuite le flag de l'IRQ et commence à traiter les pixels invisibles puis celle visibles. Les deux SM continuent de leur côté à traiter la ligne. Le SM0 va lever 200 fois l'IRQ puis passera à la trame suivante sous le feu des synchros /VSYNC et /HSYNC.

Je vais regarder comment t'a fait pour le tableau… et corrigé le mien.

Après, je n'ai pas fait attention au fait que les deux SM ne pourraient pas s'exécuter en même temps. Si c'est le cas, il faut signaler et attendre que l'IRQ soit traité par le SM1 (IRQ libéré à la fin dans ce cas) et le SM0 n'aura plus qu'à boucler 200 fois sans attendre sur le /HSYNC juste en signalant l'IRQ et en attendant qu'il est fini.

[Bricox]

Si tu réponds au post du tableau, tu peux récupérer le BBcode.

J'ai remplacé "Nom fonction" par "Etiquette".

Je suppose que WAIT 0 GPIO puis WAIT 1 GPIO attendent un front montant.

Je suppose également que GPIO vsync fait partie d'un bloc de déclarations préalable.

capture_200px_loop devrait s'appeler capture_320px_loop

Si cela fonctionne sans modif, tu pourrais mettre les 2 SMs dans une seule et là, plus de doute sur le fonctionnement // des SMs.

Je suppose qu'à l'autre bout du DMA PIO1/ARM1 , les quartets de 4 pixels sont traités, par le Core1.
Un DMA pur ARM1 peut ventiler les quartets vers des buffers, qui seront transmis par DMA ARM1/PIO0, au PIO0 de sortie HDMI.

[hlide]

Non, un "WAIT 0 <source>" attend juste que le signal passe à 0 si ce n'est pas déjà le cas.

Le "WAIT 0 hsync" puis le "WAIT 1 hsync" c'est pour m'assurer que quand je reboucle N fois, je passe bien N hsync, car le signal hsync peut durer bien plus longtemps que les cycles nécessaires au rebouclage.

[hlide]

Si cela fonctionne sans modif, tu pourrais mettre les 2 SMs dans une seule et là, plus de doute sur le fonctionnement // des SMs.

Je suppose qu'à l'autre bout du DMA PIO1/ARM1 , les quartets de 4 pixels sont traités, par le Core1.
Un DMA pur ARM1 peut ventiler les quartets vers des buffers, qui seront transmis par DMA ARM1/PIO0, au PIO0 de sortie HDMI.

1) Non, j'ai tenté avec un seul SM et ce n'est pas possible : je n'ai que deux registres X et Y et il m'en faudrait 4 pour pouvoir traiter les 200 lignes et les 320 pixels.

2) L'objectif c'est 0 CPU. Il faut deux DMA de ce que j'ai lu, la première pointe sur le buffer à remplir. La deuxième DMA va remettre l'adresse de début dans l'adresse d'écriture de la première DMA quand elle atteint la fin. Donc SM1 devrait remplir directement ce buffer qui sera lu en parallèle par le core 1 pour sortir en DVI (code que je ne touche pas !). Ca permettrait de libérer le core 0 pour d'autre tâche.

J'ajoute que si je veux faire le color blending, ça présume que j'utilise la DMA à la fois en lecture et en écriture (chacun leur adresse) : le SM1 devrait lire la partie MSB de l'octet depuis le DMA en lecture, le placer en LSB combiné au B, R, G et I capturés et placés en MSB puis écrire le résultat dans la DMA en écriture. Je ne sais pas si c'est faisable, si oui, on aura notre 27/81 couleurs sans opérations CPU.

Au cas où tu n'aurais pas deviné, voici comment en pseudo code, je calcule le color blending :

Code : Tout sélectionner

    // attend un changement de front de COLR.
    wait upon GPIO[15] == 0;
    // on effectue le blending par le jeu de la palette.
    vram[pos++] = (vram[pos] >> 4) | (GPIO[4-7]<<4);
    // attend un changement de l'autre front de COLR 
    wait upon GPIO[15] == 1;
    // on effectue le blending par le jeu de la palette.
    vram[pos++] = (vram[pos] >> 4) | (GPIO[4-7]<<4);

[Bricox]

N'ayant pas la structure des bits de vram, je ne comprends pas.

Il faudrait également que je me remémore les positions des couleurs utiles de la palette 16x16.

[hlide]

La palette de 256 couleur est découpée comme suit :
index = (couleur du pixel de la trame précédente) + 16*(couleur du pixel de la trame en cours)

J'ignore I pour la suite.

ainsi un noir c'est index = 0.
ainsi un bleu foncé c'est index = 1 ou 16.
ainsi un bleu normal c'est index = 1+16 = 17.
ainsi un rouge foncé c'est index = 2 ou 32.
ainsi un rouge normal c'est index = 2+32 = 34.
ainsi un vert foncé c'est index = 4 ou 64.
ainsi un vert normal c'est index = 4+64 = 68.

J'ai donc deux quartets pour l'index et à chaque capture du pixel je recalcule son index = (quartet du pixel de la trame précédente) | ((quartet du pixel de la trame en cours) << 4).

La vram est juste un tableau d'octet représentant des index de la palette, soit 256 couleurs. J'ai défini la palette de sorte à obtenir le mixage de couleur tenant compte dans un quartet sa valeur dans la trame précédente et un autre quartet sa valeur en cours. Et magiquement, j'obtiens la couleur mixée.

[Bricox]

Super ... le mystère s'éclaircit ...

Merci pour ta pédagogie.

[Bricox]

Exemple d'initialisation de l'encapsulation du programme PIO d'écoute SPI TFT, en C :
sm_config_set_wrap(&c, offset + fourwire_wrap_target, offset + fourwire_wrap);

Programme d'écoute SPI TFT, en ASM PIO RP2040 :tabat_asmpio

Directives	Etiquette de saut	Instruction ASM PIO	N°Inst.PC	Commentaire
.program fourwire	flush:	mov isr, null	00	Clear ISR and input shift counter
		jmp check_chip_select	01	Poll chip select again
.wrap_target	do_bit:	wait 0 pin 2	02	Detect rising edge and sample input data
		wait 1 pin 2	03	(autopush takes care of moving each
		in pins, 2	04	complete data word to the FIFO)
	check_chip_select:	jmp pin, flush	05	Bail out if we see chip select high
.wrap

[Bricox]

La palette de 256 couleur est découpée comme suit :
index = (couleur du pixel de la trame précédente) + 16*(couleur du pixel de la trame en cours)

J'ai donc deux quartets pour l'index et à chaque capture du pixel je recalcule son index = (quartet du pixel de la trame précédente) | ((quartet du pixel de la trame en cours) << 4).

couleur du pixel de la trame précédente et couleur du pixel de la trame précédente sont commutatifs.

Je pense que :

Code : Tout sélectionner

vram[pos++] = (vram[pos] >> 4) | (GPIO[4-7]<<4)

est équivalent à :

Code : Tout sélectionner

vram[pos++] = (vram[pos] & F0) | GPIO[4-7]

Cela devrait être plus rapide

[hlide]

C'est du pseudo code.

le vrai code, si c'était en C par le CPU : vram[pos] = (vram[pos] >> 4) | (gpio & 0xF0); ++pos;

Par le PIO, il faut jongler par décalage car il n'y a pas de AND.

[Bricox]

Table de référence, des 9 instructions ASM PIO :tabat_asmpioref

__________Instr. binaire

Bit:	15	14	13	12|11|10|9|8	7_|_ 6 _|_ 5	4 | 3 | 2 | 1 | 0
JMP	0	0	0	Delay/side-set	Condition (nc) !X scratch X zero X-- scratch X !zero, prior decrement !Y scratch Y zero Y-- scratch Y !zero, prior decrement X!=Y scratch X != Y PIN branch on input pin !OSRE output shift reg notEmpty	Address
WAIT	0	0	1	Delay/side-set	Polarité Source Source 1 GPIO Syst.GPIO input select by Index 0 PINS Input pin selected by Index IRQ PIO IRQ flag selected by Index	Index
IN	0	1	0	Delay/side-set	Source PINS X scratch register X Y scratch register Y NULL all zeroes ISR OSR	BitCount
OUT	0	1	1	Delay/side-set	Destination PINS X scratch register X Y scratch register Y NULL discard data PINDIRS PC ISR also sets ISR shift cuntr to BitCount EXEC Exec. OSR shift data as instruction	BitCount
PUSH	1	0	0	Delay/side-set	block Push ISR=>Rx FIFO, wait space available noblock Push ISR=>Rx FIFO, if noSpace free, no-op iffull block Push ISR=>Rx FIFO, if enough bits & space free iffull noblock Push ISR=>Rx FIFO, as on top + else no-op	0 | 0 | 0 | 0 | 0
PULL	1	0	0	Delay/side-set	block Pull Tx FIFO => 32bit => OSR noblock Pull Tx FIFO =>if notData, X => OSR iffull block Blocking pull, only if OSR is sufficiently empty iffull noblock Nonblocking pull, but only if OSR is empty	0 | 0 | 0 | 0 | 0
MOV	1	0	1	Delay/side-set	Destination PINS Uses same pin mapping as OUT X scratch register X Y scratch register Y PC ISR Input shift counter is reset OSR Output shift counter is reset EXEC Execute data as instruction	Operation Source None PINS Invert X Bit-reverse Y PC ISR OSR EXEC
IRQ	1	1	0	Delay/side-set	Int 0–3 to the ARM CPU Int 4–7 to appropriate PIO in the same bank. SET 2 set int 2, won't wait for interrupt to be handled CLEAR 2 clear interrupt 2 WAIT 2 set int 2 and wait for int handler to clear it SET 2 REL int nbr will be adjusted by adding PIO nbr	Index
SET	1	1	1	Delay/side-set	Destination PINS X scratch register X Y scratch register Y PINDIRS	Data

Remarque : PUSH et PULL ont le même code binaire d'instruction, c'est le bit 7 qui fait la distinction.

[hlide]

Ah enfin, j'ai retrouvé mon LA5032. Vu que j'ai démonté complétement mon MZ-700, ça ne va pas être pour tout de suite.

1) Mon MZ-700 étant malade, je compte l'examiner plus en détail et donc mettre en pause la sortie DVI le temps que je trouve ce qui ne va pas.

2) j'ai examiné d'autres exemples et je commence à deviner comment on peut affecter les valeurs de X et Y plus grandes que 31. En fait, quand on démarre le SM et que ce dernier ne joue pas avec le FIFO dans son noyau (code en boucle), on peut utiliser OSR dans le prologue pour mettre initialement des valeurs constantes.

Directives	Etiquette de saut	Instruction ASM PIO	N°Inst.PC	Commentaire
.program syncs		pull block	00	Dépile du FIFO la première constante dans OSR
		mov isr,osr	01	Et copie dans le registre ISR
		pull block	02	Dépile du FIFO la dernière constante dans OSR
.wrap_target	wait_vsync:	wait 1 gpio 9	03	Détecte un front descendant sur /VSYNC
		...	xx	Là le code avec des boucles utilisant OSR ou ISR affecté à X ou Y...
.wrap

Ce qui veut dire que OSR, ISR peuvent contenir nos constantes tandis que X et Y seront utilisés comme compteurs de boucle.

En revanche, pour le SM1 qui gère la DMA, ça ne sera pas vraiment possible.