pseudo bitmap pour 9345 (VG5000/Alice32-90)

Cette catégorie traite de développements récents pour nos vieilles machines, applications, jeux ou démos... Amis programmeurs, c'est ici que vous pourrez enfin devenir célèbres!

Modérateurs : Carl, Papy.G, fneck

Avatar du membre
Patrice
Messages : 1198
Enregistré le : 14 janv. 2008 10:42
Localisation : Charente maritime
Contact :

Re: pseudo bitmap pour 9345 (VG5000/Alice32-90)

Message par Patrice » 27 avr. 2014 10:15

6502man a écrit :Oui il existe bien un mode bitmap 80 colonnes, mais uniquement en monochrome.

Voir ma démo : ALICE BITMAP
En mode bichrome serait plus juste(p 103 à 107 du même ouvrage)! :wink:
Alice la passion ;-)

Avatar du membre
Carl
Modérateur
Messages : 10435
Enregistré le : 08 avr. 2007 13:21
Localisation : http://www.doledujura.fr
Contact :

Re: pseudo bitmap pour 9345 (VG5000/Alice32-90)

Message par Carl » 27 avr. 2014 13:33

ah oui, j'ai déjà oublié... :?
le câblage du 9345 est-il le même sur VG5000 / Alice32 ?

Carl

Daniel
Messages : 11351
Enregistré le : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: pseudo bitmap pour 9345 (VG5000/Alice32-90)

Message par Daniel » 27 avr. 2014 13:43

Pas tout à fait : une des broches de l'EF9345 (j'ai oublié laquelle) est utilisée par Matra pour obtenir des couleurs supplémentaires. Ca ne change rien au mode bichrome, qui doit pouvoir être utilisé de la même façon sur VG5000 et sur Alice.
Daniel
L'obstacle augmente mon ardeur.

Avatar du membre
Patrice
Messages : 1198
Enregistré le : 14 janv. 2008 10:42
Localisation : Charente maritime
Contact :

Re: pseudo bitmap pour 9345 (VG5000/Alice32-90)

Message par Patrice » 27 avr. 2014 14:25

Il s'agit de la broche n° 10 (signal d'incrustation servant à fabriquer les demies teintes pour Alice 32/90). Le mode bitmap est identique entre Alice 32/90 et VG5000 :!: :wink:
Alice la passion ;-)

joaopa
Messages : 407
Enregistré le : 14 sept. 2013 12:17

Re: pseudo bitmap pour 9345 (VG5000/Alice32-90)

Message par joaopa » 07 mai 2014 02:38

Donc les 8 couleurs supplémentaires ne sont pas disponibles pour le VG5000?

Daniel
Messages : 11351
Enregistré le : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: pseudo bitmap pour 9345 (VG5000/Alice32-90)

Message par Daniel » 07 mai 2014 09:41

Non.
Daniel
L'obstacle augmente mon ardeur.

Avatar du membre
Papy.G
Modérateur
Messages : 1839
Enregistré le : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: pseudo bitmap pour 9345 (VG5000/Alice32-90)

Message par Papy.G » 03 sept. 2014 06:53

Le fait de disposer d'assez de mémoire pour mémoriser deux pages-écran permet-il de faire du double-buffering? (clignottement de deux images alternées pour "mélanger" les couleurs) Je n'arrive pas à cerner ce point dans la datasheet du EF9345.
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.

Markerror
Messages : 1389
Enregistré le : 31 oct. 2011 19:21
Localisation : Orléans
Contact :

Re: pseudo bitmap pour 9345 (VG5000/Alice32-90)

Message par Markerror » 03 sept. 2014 08:03

Bonjour,

Il me semble que c'est ce que fait la demo "27 couleurs" de Daniel. Le double buffering peut aussi servir dans un jeu pour faire de belles animations (pas vérifié, mais je ne serai pas surpris que le défilement des montagnes sur les bords dans US Rallye utilise cette technique).

Daniel
Messages : 11351
Enregistré le : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: pseudo bitmap pour 9345 (VG5000/Alice32-90)

Message par Daniel » 03 sept. 2014 08:30

Oui, le double (ou multi) buffering est possible avec l'EF9345, si on a assez de mémoire vidéo pour stocker plusieurs écrans. Il suffit de modifier le registre ROR (page pointer) pour changer instantanément l'écran affiché.

Les bandes de couleurs dans la marge sont provoqués par un autre effet : la modification du registre MAT provoque le changement de couleur de la marge. En changeant de couleur plusieurs fois pendant le balayage de l'écran on obtient cet effet de bandes horizontales de couleurs différentes. Si le changement est synchronisé sur la VBL les bandes horizontales sont fixes, s'il y a une petite désynchronisation elles défilent vers le haut ou vers le bas selon le sens de la désynchronisation, et s'il n'y a aucune synchronisation on ne voit plus de bandes mais des flashes de couleurs différentes.
Daniel
L'obstacle augmente mon ardeur.

Avatar du membre
Papy.G
Modérateur
Messages : 1839
Enregistré le : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: pseudo bitmap pour 9345 (VG5000/Alice32-90)

Message par Papy.G » 18 sept. 2014 11:29

Je retourne la doc du 9345, et je ne trouve toujours pas:
Y'a-t'il une "FAT" pour dire ce qui se trouve dans les différents blocks (de 1ko), et peut-on utiliser cinq sets de caractères quadrichromes avec seulement 8ko de ram?
Je ne comprend pas où est déclaré la localisation de tel ou tel set de caractères. :?
Quand on utilise le mode variable en 40 colonnes (24bits/8bits), la page écran occupera quand-même 3ko? (le gain de compression ne serait que sur la transmission processeur->9345)

Aussi, pour recadrer un hors sujet:
PcKid a écrit :Pourquoi vous parlez de basse déf sur le alice, on peut en assembleur charger en 80 colonnes ?
Je faisait référence au mode quadrichrome (en 40 colonnes), on dispose de 100 caractères par jeu en tuiles de 4x10, la résolution baissant à 160 pixels rendus en horizontal, pour obtenir des pixels plus "carrés", on peut utiliser un mode où la hauteur est doublée aussi, ce qui fait des tuiles de 4x5 pixels rendus, mais alors 200 caractères par jeu.
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.

Avatar du membre
6502man
Messages : 9348
Enregistré le : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: pseudo bitmap pour 9345 (VG5000/Alice32-90)

Message par 6502man » 18 sept. 2014 17:10

Papy.G a écrit :Y'a-t'il une "FAT" pour dire ce qui se trouve dans les différents blocks (de 1ko), et peut-on utiliser cinq sets de caractères quadrichromes avec seulement 8ko de ram?
Pour l'organisation voir ci dessous.
Pour les générateurs de caractères, je viens de vérifier dans la doc et ce n'est pas très clair :?
Mais j'ai compris ceci (et ca corrobore bien avec ce que j'avais en mémoire)
Normalement il faut 1 bloc pour le jeu G0 et 2 bloc pour le jeu G10/G11 (toujours défini ensemble G10 et G11) c'est le maximum (sauf erreur de ma part).
Donc ont à 100 caractères par jeux de caractères soit au total 300 Caractères maximum.
Compte tenu que l'écran fait 40x25 caractères = 1000 caractères donc ont ne peut remplir un écran complet :wink:
Je parle évidement de caractères différents pour chaque emplacements de l'écran et c'est bien le cas pour un scrolling.

SAUF INCOMPREHENSION DE MA PART DE LA DOC EF-9345 .

Papy.G a écrit :Je ne comprend pas où est déclaré la localisation de tel ou tel set de caractères. :?
Quand on utilise le mode variable en 40 colonnes (24bits/8bits), la page écran occupera quand-même 3ko? (le gain de compression ne serait que sur la transmission processeur->9345)
Alors pour être clair il faut bien comprendre (et c'est le plus dur avec l'EF9345) le système de blocs mémoire géré par ce VDP.
Avec l'Alice tu as 8K de VRAM découpé en 8 blocs d'1K de 25 tampons de 40 octets + 24 octets "fantome" soit :

Code : Tout sélectionner

|          EF9345                     VRAM  8ko                                      |
|----------------------------------------|   ~~ |----------------------------------------|
|         bloc 1   1024octets            |   ~~ |          bloc 8 1024octets             |
|----------------------------------------|   ~~ |----------------------------------------|
|TAMPON1|TAMPON2| .....|TAMPON25|24octets|   ~~ |TAMPON1|TAMPON2| .....|TAMPON25|24octets|
|$0000  |$0028  | .....|$03C0   |$03E8   |$0400~~...............................$2000|
Et oui une page écran occuperas 3 blocs MAIS ATTENTION il ne peut s'agir que de blocs contigus avec le premier numéro pair impérativement.

Ensuite attention car la numérotation des tampons est bizaroid :lol: :lol:
Les numéros de tampons sont adressé par Y (du Ef9345) :

Code : Tout sélectionner

| TAMPON1  | TAMPON2  | TAMPON3  | TAMPON4  | ~~ | TAMPON25  |
| Y=0      | Y=1      | Y=8      | Y=9      | ~~ | Y=31      |
En résumé Z=BLOC Y=TAMPON X=OCTET dans le TAMPON :roll:

Par exemple si tu veux accéder à l'octet 10 stocké dans le 3eme tampon du 2eme bloc :
Attend je calcul Z=1 Y=8 X=09 :wink:

Pour organiser tout ca tu doit utiliser les registres DOR, MAT ....
Ca doit être indiqué sur la fiche "vulgarisation du EF9345" que j'avais posté précédemment ;)



J’espère que l'explication est compréhensive :roll:
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.

Avatar du membre
Papy.G
Modérateur
Messages : 1839
Enregistré le : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: pseudo bitmap pour 9345 (VG5000/Alice32-90)

Message par Papy.G » 19 sept. 2014 11:35

En fait, alors, le 9345 mémorise juste la location du jeu de caractère et son type comme on le déclare lors de la mise en mémoire? Ce serait implicite, et pas précisé dans le manuel. :?

Ou alors, il faut 16ko de ram pour stocker et utiliser les jeux de caractères Q0 à Q7?

On a 100 caractères dans les quadrichromes, doublés en "basse résolution", ce qui fait 200 caractères par bloc de 1ko, donc, si l'on utilise cinq sets en basse résolution, on utilise 5ko pour le stockage des caractères, soit 1000 caractères uniques, de quoi remplir un écran, et 3ko maximum pour une page écran, on doit caser dans les 8ko?
Pour le scrolling, il faut ruser avec des caractères réutilisés et le mode variable 8/24 bits, afin de libérer de l'espace pour mémoriser deux pages.
Autrement, en caractères bichromes, et sans changements locaux (tout l'écran sur les mêmes teintes), comme dans oricium, la variété ne casse pas des briques (l'Oric n'a que 96 caractères personnalisables, et le changement de couleur bouffe des caractères à l'affichage) on peut compenser la lenteur d'accès par le double-buffering avec des jeux de caractères décalés d'un demi-pas, comme on dispose de plus de jeux, ce qui fait un pas de 4 pixels réels (tuile oric 6x8, tuile EF9345 en 40cols 8x10).
Pour le survol de sprites, il faut réserver des caractères redéfinis dynamiquement, les sprites "bruts" n'existant pas réellement dans le jeux de caractère utilisé. Cela nécessite presque une mémoire des tuiles dans la mémoire du processeur, pour savoir plus rapidement la localisation des objets et de l'arrière plan, un plan du niveau complet.

D'une manière générale, et sauf pour le mode bichrome 12bits, ou compatibilité/nécessité de 80cols, je pense qu'il vaut mieux éviter le mode 80colonnes avec le 9345, car les options de ce mode sont trop restreintes (accès aux jeux de caractères...)

Donc, Y0 (et Y1 dans les tampons d'adresse paire) ne sert qu'au stockage de la ligne d'état, puis 8 à 31 sont les lignes, qui tournent en rouleau, on fait pointer Y en 9 pour scroller l'écran vers le haut, la dernière ligne affichée sera donc Y8 (d'ailleurs, le tampon Y31 est le 26è), pour faire un scrolling vertical de un caractère, on n'a que la ligne sortie de l'écran à mettre à jour pour ne pas tourner en rond.

Pour un rendu bitmap plein écran, en oubliant les caractères personnalisables, on a:
Mode mosaïque 2x3 dans un écran 40 colonnes, deux couleurs parmi 8 à chaque caractère, 80x75 pixels rendus, jusqu'à 3ko à transférer (la page, moins selon les proximité de palette en mode variable 8/24 bits)
Mode quadrichrome basse résolution 4x5 dans un écran de 40 colonnes, quatre couleurs parmi 8 à chaque caractère, 160x125 pixels rendus, jusqu'à 8ko à transférer, 5ko caractères moins possible si réutilisation de caractères, 3Ko la page, toujours moins possible si mode variable 8/24 bits
Mode mosaïque 2x5 dans un écran de 80 colonnes, deux couleurs parmi 8 pour tout l'écran, 160x125 pixels rendus, 3ko à transférer (la page)

Tous ces nombres de pixels rendus sont sous réserve de pouvoir utiliser ce mode spécifique pour la ligne d'état aussi, je ne me suis pas penché sur ce problème, au pire, ça fait 80x72 ou 160x120.

Dans le mode 40 colonnes, on peut mélanger de la mosaïque 2x3 dans les zones moins détaillées, et même mettre plus de détail avec des caractères perso (si l'on a économisé un bloc de 1ko de caractères quadrichromes), comme c'est le cas des compressions JPEG. Ou même aussi, mettre des quadrichromes en pleine résolution 4x10 pixels par tuile, le plus dur avec l'EF9345, c'est de choisir. :mrgreen:
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.

Avatar du membre
6502man
Messages : 9348
Enregistré le : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: pseudo bitmap pour 9345 (VG5000/Alice32-90)

Message par 6502man » 19 sept. 2014 12:11

Papy.G a écrit :...il faut 16ko de ram pour stocker et utiliser les jeux de caractères Q0 à Q7?
Oui
Papy.G a écrit :On a 100 caractères dans les quadrichromes, doublés en "basse résolution", ce qui fait 200 caractères par bloc de 1ko, donc, si l'on utilise cinq sets en basse résolution, on utilise 5ko pour le stockage des caractères, soit 1000 caractères uniques, de quoi remplir un écran, et 3ko maximum pour une page écran, on doit caser dans les 8ko?
NON tu ne peux pas définir 5 set d'un même jeux de caractères en même temps :shock: avec l'EF-9345.

Si tu arrives à trouver dans la doc du EF9345 comment définir plus de 300 caractères (en mode 40 colonnes et 8Ko de VRAM) en même temps, je m'engage à faire un programme de test pour expérimenter ca :wink:
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.

Avatar du membre
Papy.G
Modérateur
Messages : 1839
Enregistré le : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: pseudo bitmap pour 9345 (VG5000/Alice32-90)

Message par Papy.G » 20 sept. 2014 22:10

Un monde s'écroule! :cry:
C'est pas clairement dit dans la notice, je suppose que si tu l'affirmes, tu as déjà essayé? :?
Oui, je suis un peu têtu. :mrgreen:
Car il y a bien jusqu'à 8 jeux Q adressables, évidemment, pas tous à la fois avec 8ko, ça ne laisse plus de place pour la page, mais cinq suffiraient alors.

Donc, si l'on suit la logique d'adressage, on comprend mieux pourquoi l'on n'a pas de caractère personnalisable de 4 à 31, ceci dit, en y réfléchissant bien, et en poussant la logique plus loin, on doit pouvoir disposer des caractères 4 à 7 quand le set est stocké dans un bloc pair, et le 7 dans un bloc impair, à vérifier toutefois.

On ne peut redéfinir un set, mais si l'adressage du set est implicite suite au chargement d'un jeu, peut-être alors peut-on précharger un bloc dans un jeu, je m'explique:
On charge G0' dans le bloc 4 (pour laisser 3 blocs pour la page), puis on charge un set complet G0' dans le bloc 5, les caractères du bloc 4 sont alors "oubliés", pour les rappeler ensuite, on charge à nouveau le premier caractère du set G0' dans le bloc 4, et il va ensuite piocher tous les caractères à nouveau dans le bloc 4.
Si ça marche, on a un gain considérable sur le switch de jeu de caractères, c'est peut-être aussi la solution pour le jeu d'échecs sur VGS5000.
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.

Avatar du membre
6502man
Messages : 9348
Enregistré le : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: pseudo bitmap pour 9345 (VG5000/Alice32-90)

Message par 6502man » 20 sept. 2014 23:28

Alors si le but recherché est d'avoir plusieurs G0 stocké en VRAM mais 1 seul utilisable à la fois OUI

Dans la VRAM tu met ce que tu veux, mais après il faut bien renseigner les registres et en tenir compte pour ne pas avoir de mauvaise surprise.

Donc dans ton idée :

BLOC 1 à 3 = écran
BLOC 4 = G0 A (premier)
BLOC 5 = G0 B (deuxième)
BLOC 6 = G0 C (troisième)
BLOC 7 = G0 D (quatrième)
BLOC 8 = G0 E (cinquième)

Donc tu aurait 5 fois G0 stocké mais 1 seul utilisable à la fois :)

Dans ton programme après avoir rempli la VRAM avec toutes les données tu n'auras ensuite plus qu'a renseigner le registre concerné pour affecté le G0 voulu A à E :wink:

J'ai jamais essayé mais ca devrait être possible, sauf à vérifier si on peut attribué G0 pair et impaire ....
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.

Répondre