COLECOVISION : discussions programmation C&Assembleur

Page 1 sur 7 1, 2, 3, 4, 5, 6, 7  Suivant

Aller en bas

COLECOVISION : discussions programmation C&Assembleur

Message par youki le Lun 26 Jan 2015 - 16:08

@TotOOntHeMooN a écrit:
Quoi qu'il en soit, sur une console, la RAM c'est juste utile pour stocker ce qui change. (stack, variables, buffers)
Tout le reste peut-être en ROM... Et comme il est possible de se servir de la VRAM, c'est au moins 4K de dispo pour stocker des données temporaires.

Les Acces VRAM sur la coleco sont terriblement lent.

La RAM est tres utile pour preparer tes images avant de les envoyer dans la VRAM.

Tu prepare tout en RAM  , ca va tres vite,  ensuite quand c'est fini tu balances tout dans la VRAM d'un coup avec les instruction optimizé pour le transfert en séquence.

Si tu essage de faire rien qu' en VRAM , c'est meme pas la peine...
avatar
youki
Infirmier

Masculin Nombre de messages : 4710
Age : 46
Date d'inscription : 01/08/2009

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par Touko le Lun 26 Jan 2015 - 16:39

Les Acces VRAM sur la coleco sont terriblement lent.
Tu entends quoi par lent ???

Parce que faire le traitement en ram, et transférer après, j'appelle ça faire 2x le boulot, tu écris en ram, et tu écris en vram .
Le seul avantage à travailler en RAM est de réserver tout le vblank pour le transfert,mais c'est pas plus rapide .
C'est valable quand tu as un DMA, par contre si tu dois tout faire au CPU, je suis pas sur que tu sois gagnant .
avatar
Touko
Docteur *
Docteur *

Masculin Nombre de messages : 13555
Age : 45
Localisation : LE MANS/MARSEILLE
Date d'inscription : 08/07/2010

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par bfg le Lun 26 Jan 2015 - 16:53

@TOUKO a écrit:
Les Acces VRAM sur la coleco sont terriblement lent.
Tu entends quoi par lent ???

Parce que faire le traitement en ram, et transférer après, j'appelle ça faire 2x le boulot, tu écris en ram, et tu écris en vram .
Le seul avantage à travailler en RAM est de réserver tout le vblank pour le transfert,mais c'est pas plus rapide .
C'est valable quand tu as un DMA, par contre si tu dois tout faire au CPU, je suis pas sur que tu sois gagnant .

Alors moi je suis pas spécialiste ... Mais de ce que je comprends si pour remplir ton écran il te faut 20 tiles, ecrire 20 * la rom en VRAM c'est plus lent que de tout écrire d'un coup ...

Alors qu'en RAM tu as déjâ tout ton écran, tu décales tes caractères et tu complètes par les x tiles qui te manque. Après je dis certainement une grosse connerie, mais au moins les spécialistes corrigeront, et seront forcé de m'expliquer comment ça marche !!! Mr. Green Mr. Green Mr. Green Mr. Green Mr. Green Mr. Green Mr. Green Mr. Green Mr. Green Mr. Green

Pour info, un écran de Coleco en RAM fait 768 octets (1 code caractère par octet). Avec le kit de Daniel, il ne reste déja plus que 700 octets, donc c'est déja la merde. A mon avis, en full assembleur c'est jouable par contre ... Ou en dégageant du code de Daniel Bienvenu ce qui sert à rien. Mais bon, il reste plus grand chose pour les variables des ennemis and co ... Donc je pense qu'il doit y avoir une autre technique plus efficace puisque plein de jeu Coleco on un scrolling qui fonctionne bien ...

bfg
Patient contaminé

Nombre de messages : 797
Date d'inscription : 11/09/2005

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par Touko le Lun 26 Jan 2015 - 16:57

Alors moi je suis pas spécialiste ... Mais de ce que je comprends si pour remplir ton écran il te faut 20 tiles, ecrire 20 * la rom en VRAM c'est plus lent que de tout écrire d'un coup ... 
C'est vrai, mais tu oublies l'écriture en RAM d'abord dans ton calcul  Razz
Donc traitement + ecriture en VRAM est plus rapide que traitement+ecriture en RAM+ecriture en VRAM  Mr. Green
Donc si par exemple tu utilises des données non compressées en ROM, tu fais ROM->RAM->VRAM ??  Shocked

Alors qu'en RAM tu as déjâ tout ton écran, tu décales tes caractères et tu complètes par les x tiles qui te manque. Après je dis certainement une grosse connerie, mais au moins les spécialistes corrigeront, et seront forcé de m'expliquer comment ça marche !!!           
Rien ne t'empêche de faire la même chose pendant le vblank et d'écrire directement en VRAM tu économises l'écriture en RAM .
J'ai pas dis que c'était plus efficace, juste plus rapide .

Pour info, un écran de Coleco en RAM fait 768 octets (1 code caractère par octet). Avec le kit de Daniel, il ne reste déja plus que 700 octets, donc c'est déja la merde. A mon avis, en full assembleur c'est jouable par contre ... Ou en dégageant du code de Daniel Bienvenu ce qui sert à rien. Mais bon, il reste plus grand chose pour les variables des ennemis and co ... Donc je pense qu'il doit y avoir une autre technique plus efficace puisque plein de jeu Coleco on un scrolling qui fonctionne bien ...
Bien sur en C c'est pas la peine de chercher à optimiser, le gain ne serra jamais aussi important qu'en ASM  Wink
avatar
Touko
Docteur *
Docteur *

Masculin Nombre de messages : 13555
Age : 45
Localisation : LE MANS/MARSEILLE
Date d'inscription : 08/07/2010

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par bfg le Lun 26 Jan 2015 - 17:46

@TOUKO a écrit:
Alors moi je suis pas spécialiste ... Mais de ce que je comprends si pour remplir ton écran il te faut 20 tiles, ecrire 20 * la rom en VRAM c'est plus lent que de tout écrire d'un coup ... 
C'est vrai, mais tu oublies l'écriture en RAM d'abord dans ton calcul  Razz
Donc traitement + ecriture en VRAM est plus rapide que traitement+ecriture en RAM+ecriture en VRAM  Mr. Green
Donc si par exemple tu utilises des données non compressées en ROM, tu fais ROM->RAM->VRAM ??  Shocked

Alors qu'en RAM tu as déjâ tout ton écran, tu décales tes caractères et tu complètes par les x tiles qui te manque. Après je dis certainement une grosse connerie, mais au moins les spécialistes corrigeront, et seront forcé de m'expliquer comment ça marche !!!           
Rien ne t'empêche de faire la même chose pendant le vblank et d'écrire directement en VRAM tu économises l'écriture en RAM .
J'ai pas dis que c'était plus efficace, juste plus rapide .

Pour info, un écran de Coleco en RAM fait 768 octets (1 code caractère par octet). Avec le kit de Daniel, il ne reste déja plus que 700 octets, donc c'est déja la merde. A mon avis, en full assembleur c'est jouable par contre ... Ou en dégageant du code de Daniel Bienvenu ce qui sert à rien. Mais bon, il reste plus grand chose pour les variables des ennemis and co ... Donc je pense qu'il doit y avoir une autre technique plus efficace puisque plein de jeu Coleco on un scrolling qui fonctionne bien ...
Bien sur en C c'est pas la peine de chercher à optimiser, le gain ne serra jamais aussi important qu'en ASM  Wink

Non, je fais ROM-->VRAM n fois
ou ROM --> n fois RAM --> 1 fois VRAM

J'ai cru comprendre que la seconde solution était plus rapide ... Mais j'en sais foutrement rien en fait.

Et comment tu fais pour décaler un écran d'un caractère vers la gauche sans passer au moins chaque ligne par la RAM ? On peut pas faire de copie directe de VRAM en VRAM sur Coleco ...

Grosso merdo tu comprendras que ... j'y comprends rien  Mr. Green

bfg
Patient contaminé

Nombre de messages : 797
Date d'inscription : 11/09/2005

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par youki le Lun 26 Jan 2015 - 18:00

Je pense que Touko n'a pas touché le VDP de la coleco :)

Les acces a la VRAM sont font exclusivement par un port. 

Ici quelque info, qui eclairssiront (j'espere) ta laterne :)

The TMS9918A's method of accessing the video RAM is slower than direct access, as used in unified-memory computers, because accessing video memory involved first outputting the low- then the hi-byte of the (14-bit) video memory address to I/O port $99, then one or more bytes of 8-bit data to port $98. After each write, the memory pointer advances to the next address, so consecutive addresses can be written to with repeated OUT instructions to $98.[1] This also meant that the fast Z80 blockmove and blockfill instructions could not be used on the video memory.


Sans compter qu'entre 2 write ou read sur le VDP , tu dois attendre un certain temps, sinon la VRAM se corrupt!!

Bref, par exemple moi pour Battle of Hoth. J'ai un buffer en RAM ..  dans lequel je shift les octets a la volée . une fois que ton mon buffer est shiffté , je le balance en VRAM.
avatar
youki
Infirmier

Masculin Nombre de messages : 4710
Age : 46
Date d'inscription : 01/08/2009

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par drfloyd le Lun 26 Jan 2015 - 18:00

en tout cas sans tout maitriser tu arrives quand meme à nous faire des jeux dignes des meilleurs jeux de l'époque Michel !

_______________________________________________________

Mes objets en vente :
http://www.gamopat-forum.com/t98267-la-caverne-du-doc-poilu#2765310
Mon profil Gamopat Advisor :
http://www.gamopat-forum.com/t94659-dr-floyd-advisor





avatar
drfloyd
DOYEN ET PROFESSEUR FOU DE L'HOPITAL

Masculin Nombre de messages : 140112
Age : 49
Localisation : Dpt 62
Date d'inscription : 05/12/2004

http://www.gamopat.com

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par youki le Lun 26 Jan 2015 - 18:04

@drfloyd a écrit:en tout cas sans tout maitriser tu arrives quand meme à nous faire des jeux dignes des meilleurs jeux de l'époque Michel !

Mais c'est pas lui qui les fait,  vu son rythme de production, c'est evident qu'il a une orde de petits chinois qui travaille pour lui dans sa cave! Mr. Green  (moi je dirai qu'il y en a au moins 50!)

Ceci dit, ne pas savoir faire de scrolling, n'empeche pas de faire un bon jeu!
avatar
youki
Infirmier

Masculin Nombre de messages : 4710
Age : 46
Date d'inscription : 01/08/2009

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par Touko le Lun 26 Jan 2015 - 19:11

Les acces a la VRAM sont font exclusivement par un port.  
Comme sur toutes les machines avec VRAM dédiée  Wink

The TMS9918A's method of accessing the video RAM is slower than direct access, as used in unified-memory computers, because accessing video memory involved first outputting the low- then the hi-byte of the (14-bit) video memory address to I/O port $99, then one or more bytes of 8-bit data to port $98. After each write, the memory pointer advances to the next address, so consecutive addresses can be written to with repeated OUT instructions to $98.[1] This also meant that the fast Z80 blockmove and blockfill instructions could not be used on the video memory.
Ok, c'est normal, mais ça dit en rien du comment c'est plus lent !!
1 cycles de plus ??, 10 ?? 20 ??? ..
Sur pce écrire en VRAM via le port prend 1 cycles de plus que la RAM , c'est plus lent aussi, mais rien de dramatique non plus . 
D'où ma question, tu entends quoi par plus lent ??

Sans compter qu'entre 2 write ou read sur le VDP , tu dois attendre un certain temps, sinon la VRAM se corrupt!! 
Là d'accord, je comprends mieux, mais tu as le même soucis quand tu fais tes transferts RAM->vram alors ..
Pire même je comprends pas comment un transfert séquentiel peut être rapide dans ce cas là,vu qu'il aura aussi des wait state en écriture,y'a aucun gain à bufferiser en RAM ..
avatar
Touko
Docteur *
Docteur *

Masculin Nombre de messages : 13555
Age : 45
Localisation : LE MANS/MARSEILLE
Date d'inscription : 08/07/2010

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par youki le Lun 26 Jan 2015 - 19:20

@Touko a écrit:Là d'accord, je comprends mieux, mais tu as le même soucis quand tu fais tes transferts RAM->vram alors ..
Pire même je comprends pas comment un transfert séquentiel peut être rapide dans ce cas là,vu qu'il aura aussi des wait state en écriture,y'a aucun gain à bufferiser en RAM ..
quand tu ecris en sequence, tu n'a pas besoin de recharger l'adresse de destination , elle est automatiquement incrementé par le VDP.  Ducoup , ca va plus vite .
Pour le timing regarde la doc du TMS  , tu auras toute les réponses! Wink
avatar
youki
Infirmier

Masculin Nombre de messages : 4710
Age : 46
Date d'inscription : 01/08/2009

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par Touko le Lun 26 Jan 2015 - 19:32

Et comment tu fais pour décaler un écran d'un caractère vers la gauche sans passer au moins chaque ligne par la RAM ? On peut pas faire de copie directe de VRAM en VRAM sur Coleco ...
Ah c'est vrai que cette merde n'a pas de scrolling, putain, ouai en fait ça marche pas alors ..

quand tu ecris en sequence, tu n'a pas besoin de recharger l'adresse de destination , elle est automatiquement incrementé par le VDP.  Ducoup , ca va plus vite . 
Pour le timing regarde la doc du TMS  , tu auras toute les réponses! 
Ok, je me doutais qu'il y aurait de l'auto increm., mais si tu as des wait state pour un simple write, tu l'auras aussi pour une copie séquentielle ..
Et l'auto incrémentation fonctionne à chaque lecture/écriture dans le port du VDP, que ce soit séquentiel ou pas  Wink
Donc si tu dis que tu dois attendre un certain temps, j'ai du mal à comprendre pk le séquentiel (je suppose que ce sont les instruction de transfert de blocs du Z80 qui sont utilisées) est plus rapide justement .

Youki, t'as un lien vers la doc ??

Non, je fais ROM-->VRAM n fois
ou ROM --> n fois RAM --> 1 fois VRAM
Ok, par contre je pense comprendre, comme vous ne pouvez écrire que pendant le vblank, vous maximisez les transfert pendant cette période, donc oui les transfert sont plus rapides, mais pas en cycles CPU pendant la frame, puisque vous rajouter l'écriture en RAM (qui elle à lieu dans la boucle principal avec la décompression) .


Dernière édition par TOUKO le Lun 26 Jan 2015 - 19:45, édité 1 fois
avatar
Touko
Docteur *
Docteur *

Masculin Nombre de messages : 13555
Age : 45
Localisation : LE MANS/MARSEILLE
Date d'inscription : 08/07/2010

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par youki le Lun 26 Jan 2015 - 19:45

@Touko a écrit:Et l'auto incrémentation fonctionne à chaque écriture dans le port du VDP, que ce soit séquentiel ou pas 
Donc si tu dis que tu dois attendre un certain temps, j'ai du mal à comprendre pk le séquentiel (je suppose que ce sont les instruction de transfert de blocs du Z80 qui sont utilisées) est plus rapide justement .
Heu...
Bon alors je vais de faire un dessin  , pas des seins (pour ca regarde le dernier OIB de Michel :) ).

Options 1 sans utilisé auto incrementation :
Toi  ecrire Adresse destination sur port.
Toi  ecrire Valeur sur port
Toi  ecrire Adresse destination sur port
Toi  ecrire  Valeur sur port
Toi  ecrire Adresse destination sur port.
Toi  ecrire Valeur sur port
Toi  ecrire Adresse destination sur port
Toi  ecrire  Valeur sur port

options 2 en profitant de l'autoincrementation naturelle :

Toi  ecrire Adresse destination sur port.
Toi  ecrire Valeur sur port
Toi  ecrire  Valeur sur port
Toi  ecrire Valeur sur port
Toi  ecrire  Valeur sur port

Lequel va plus vite? 😄 ...  tu vois là ? cyclops
avatar
youki
Infirmier

Masculin Nombre de messages : 4710
Age : 46
Date d'inscription : 01/08/2009

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par Touko le Lun 26 Jan 2015 - 19:50

Options 1 sans utilisé auto incrementation :
Toi  ecrire Adresse destination sur port.
Toi  ecrire Valeur sur port
Toi  ecrire Adresse destination sur port
Toi  ecrire  Valeur sur port
Toi  ecrire Adresse destination sur port.
Toi  ecrire Valeur sur port
Toi  ecrire Adresse destination sur port
Toi  ecrire  Valeur sur port
Aucune logique dans ce que tu dis ..
L'auto incrémentation doit marcher comme toutes les puces vidéo CAD à chaque accès au port, qu'il soit séquentiel ou pas .. 

Si tu écris à chaque fois l'adresse de destination pour une copie manuelle, je pense que tu dois mal avoir lu la doc mon bon youki ..  Wink , ou alors le VDP de la coleco est bien pourrave  Mr. Green

EDIT: En lisant la doc, c'est bien ce que j'ai dis, tu sais pas lire youki  Mr. Green
Tant que tu changes pas le pointeur du VDP t'as pas besoin de remettre ton adresse de destination .
Donc tu peux faire
init de l'adresse dest en VRAM
lecture des données en rom
decompression
ecriture en vram
lecture des données en rom
decompression
ecriture en vram
lecture des données en rom
decompression
ecriture en vram
etc ...

Et pas forcement ce que vous faites vous :
lecture des données en rom
decompression
ecriture en RAM
lecture des données en rom
decompression
ecriture en RAM
lecture des données en rom
decompression
ecriture en RAM
etc ...
Puis
init de l'adresse dest en VRAM
lecture en ram
ecriture en VRAM
lecture en ram
ecriture en VRAM
lecture en ram
ecriture en VRAM
etc ..

Lequel est le plus rapide  Razz

tu peux même écrire hors vblank, mais c'est moins facile(les timings varient selon les modes) .


Dernière édition par TOUKO le Lun 26 Jan 2015 - 20:16, édité 5 fois (Raison : ire)
avatar
Touko
Docteur *
Docteur *

Masculin Nombre de messages : 13555
Age : 45
Localisation : LE MANS/MARSEILLE
Date d'inscription : 08/07/2010

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par bfg le Lun 26 Jan 2015 - 20:13

Je pense avoir compris, mais je pense que ça n'est possible qu'en pure assembleur ... Sad Sad A moins qu'en C avec de l'assembleur inline c'est jouable ...

bfg
Patient contaminé

Nombre de messages : 797
Date d'inscription : 11/09/2005

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par vingazole le Lun 26 Jan 2015 - 20:15

Et l'auto incrémentation fonctionne à chaque lecture/écriture dans le port du VDP, que ce soit séquentiel ou pas
D'accord, mais si tes données ne sont pas séquentielles, tu es bien obligé d'indiquer écrire les prochaines données Wink

La Sega Master System a un fonctionnement très proche de la Coleco, il me semble.

Sur SMS écrire en dehors de l'affichage actif permet d'éviter de rajouter des délais entre les écritures en VRAM sans qu'il y ait de corruption des données : le transfert de données est accéléré.
avatar
vingazole
Infirmier

Masculin Nombre de messages : 4092
Age : 44
Localisation : Nilbog
Date d'inscription : 05/01/2012

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par Touko le Lun 26 Jan 2015 - 20:20

Je pense avoir compris, mais je pense que ça n'est possible qu'en pure assembleur ...   A moins qu'en C avec de l'assembleur inline c'est jouable ...
On est d'accord, je pense pas qu'en C tu puisse le faire ..

D'accord, mais si tes données ne sont pas séquentielles, tu es bien obligé d'indiquer  écrire les prochaines données 
On s'est mal compris en fait sur le terme séquentiel, je pensais qu'il parlait des instructions de transfert de blocs ..
Mais tant que tu touches pas au pointeur du VDP(pas d'ecriture/lecture, ou changement d'adresses), il reste où il est .

donc que tu fasses
init adresse vram
lire rom
decompression
ecrire vram
lire rom
decompression
ecrire vram

c'est pareil, mais plus rapide que:
lire rom
decompresse
ecrire ram
lire rom
decompresse
ecrire ram
init adresse vram
lire ram
ecrire vram
lire ram
ecrire vram

La Sega Master System a un fonctionnement très proche de la Coleco, il me semble.
Les VDP de la sms et de la Md sont pas issus de celui de la coleco ???


Dernière édition par TOUKO le Lun 26 Jan 2015 - 20:27, édité 1 fois
avatar
Touko
Docteur *
Docteur *

Masculin Nombre de messages : 13555
Age : 45
Localisation : LE MANS/MARSEILLE
Date d'inscription : 08/07/2010

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par bfg le Lun 26 Jan 2015 - 20:25

Sinon je suis en train de jouer avec l'émulateur d'AlekMaul et je suis en train de regarder certains scrolls.

Celui de Circus Charlie est un mélange de préshifting et de sprite. Pas trop compliqué à comprendre ça boucle.

Mais alors celui de princess quest ...
Il n'à qu'un seul jeu de caractères pour 1 niveau soit 3*255 caractères. Tout est préshifté, mais je ne comprends pas comment il arrive à créé un niveau comme ça ... Faudrait que je fasse un dessins pour comprendre.

Me manque 20 ou 30 points de QI là ...

Avec son ému, je vais découvrir les secrets de Battle of Hoth  Mr. Green Mr. Green Mr. Green Mr. Green

bfg
Patient contaminé

Nombre de messages : 797
Date d'inscription : 11/09/2005

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par vingazole le Lun 26 Jan 2015 - 20:26

On s'est mal compris en fait sur le terme séquentiel, je pensais qu'il parlait des instructions de transfert de blocs ..
Oui, mais les instructions de transfert de blocs sont par essence séquentielles.

Mais tant que tu touches pas au pointeur du VDP(pas d'ecriture/lecture, ou changement d'adresses), il reste où il est .
J'espère bien^^
Les VDP de la sms et de la Md sont pas issus de celui de la coleco ???
Le VDP de la SMS est une évolution du Texas Instruments qui équipe la Coleco ou la Sega SG-1000 (les modes graph de la SG-1000 sont utilisables sur SMS); le VDP de la Megadrive assure la compatibilité avec le VDP de la SMS.


Dernière édition par vingazole le Lun 26 Jan 2015 - 20:31, édité 1 fois
avatar
vingazole
Infirmier

Masculin Nombre de messages : 4092
Age : 44
Localisation : Nilbog
Date d'inscription : 05/01/2012

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par Fabf le Lun 26 Jan 2015 - 20:27

@TOUKO a écrit:
Tant que tu changes pas le pointeur du VDP t'as pas besoin de remettre ton adresse de destination .
Donc tu peux faire
init de l'adresse dest en VRAM
lecture des données en rom
decompression
ecriture en vram
lecture des données en rom
decompression
ecriture en vram
lecture des données en rom
decompression
ecriture en vram
etc ...
Et dans la pratique, tu décompresse ou ?
avatar
Fabf
Patient incurable

Masculin Nombre de messages : 1502
Age : 45
Localisation : Vienne (38)
Date d'inscription : 11/09/2012

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par Touko le Lun 26 Jan 2015 - 20:31

Et dans la pratique, tu décompresse ou ?
Dans tes registres, mais au lieu de sauvegarder en ram, tu balances directement en VRAM ..
youki et bfg font la décompression, ecriture en ram dans la boucle principale, puis copie des données en ram vers la vram pendant le vblank .

Oui, mais les instructions de transfert de blocs sont par essence séquentielles.
Tout à fait, sur ça on est d'accord .
mais une lecture, puis ecriture, une lecture, puis ecriture, c'est séquentiel aussi  Wink , plus lent aussi, mais tu te dispenses de l'écriture en RAM, donc au final tu es gagnant,c'est là ou je veux en venir ..
Si la coleco avait un DMA pour faire la copie RAM -> VRAM, là ok ..

Le VDP de la SMS est une évolution du Texas Instruments qui équipe la Coleco ou la Sega SG-1000 (les modes graph de la SG-1000 sont utilisables sur SMS); le VDP de la Megadrive assure la compatibilité avec le VDP de la SMS.
C'est ce qui me semblait d'où les similitudes ..

@bfg: Normal que tu comprennes pas le scroll de toledo, c'est un scroll soft plus évolué qu'un simple scroll basique, c'est difficile à comprendre comme ça juste avec un émulateur ..  Wink
Et je suis pas sur qu'il fasse son scroll en C non plus ..


Dernière édition par TOUKO le Lun 26 Jan 2015 - 20:44, édité 3 fois
avatar
Touko
Docteur *
Docteur *

Masculin Nombre de messages : 13555
Age : 45
Localisation : LE MANS/MARSEILLE
Date d'inscription : 08/07/2010

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par vingazole le Lun 26 Jan 2015 - 20:36

mais une lecture, puis ecriture, une lecture, puis ecriture, c'est séquentiel aussi   , plus lent aussi, mais tu te dispenses de l'écriture en RAM, donc au final tu es gagnant,c'est là ou je veux en venir ..

Oui, mais la lecture comme l'écriture auto-incrémente l'adresse du prochain accès en VRAM.

Si tu positionnes le pointeur de VRAM à 0 et que tu fais ce que tu as écrit, tu as :
-lecture adresse 0
-écriture adresse 1
-lecture adresse 2
-écriture adresse 3
etc...
avatar
vingazole
Infirmier

Masculin Nombre de messages : 4092
Age : 44
Localisation : Nilbog
Date d'inscription : 05/01/2012

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par Touko le Lun 26 Jan 2015 - 20:39

Oui, mais la lecture comme l'écriture auto-incrémente l'adresse du prochain accès en VRAM.
Ah mais là tu parles dans le cas d'une copie VRAM->VRAM ..
moi je parle de données compressées en rom puis décompressées directement en VRAM sans passer par la RAM .

Dans le premier cas, dommage que le VDP n'ai pas 2 pointeurs (1 en lecture, l'autre en écriture) .
avatar
Touko
Docteur *
Docteur *

Masculin Nombre de messages : 13555
Age : 45
Localisation : LE MANS/MARSEILLE
Date d'inscription : 08/07/2010

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par vingazole le Lun 26 Jan 2015 - 20:43

Ah mais là tu parles dans le cas d'une copie VRAM->VRAM ..
Je croyais que c'est ce que tu voulais dire.

moi je parle de données compressées en rom puis décompressées directement en VRAM sans passer par la RAM .
Même réponse que Fabf : il faut bien décompresser quelque part saispas
avatar
vingazole
Infirmier

Masculin Nombre de messages : 4092
Age : 44
Localisation : Nilbog
Date d'inscription : 05/01/2012

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par bfg le Lun 26 Jan 2015 - 20:43

@TOUKO a écrit:

@bfg: Normal que tu comprennes pas le scroll de toledo, c'est un scroll soft plus évolué qu'un simple scroll basique, c'est difficile à comprendre comme ça juste avec un émulateur ..  Wink

Mais un putain d'ému quand même  Mr. Green


bfg
Patient contaminé

Nombre de messages : 797
Date d'inscription : 11/09/2005

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par Touko le Lun 26 Jan 2015 - 20:47

Même réponse que Fabf : il faut bien décompresser quelque part 
Bah tes registres
tu lis un octets / mot en rom
tu decompresses dans un registre
tu écris en VRAM

Non ???

Mais un putain d'ému quand même   
Mr. Green 
Ca c'est bien vrai ..  Wink
avatar
Touko
Docteur *
Docteur *

Masculin Nombre de messages : 13555
Age : 45
Localisation : LE MANS/MARSEILLE
Date d'inscription : 08/07/2010

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par vingazole le Lun 26 Jan 2015 - 20:52

Bah tes registres
tu lis un octets / mot en rom
tu decompresses dans un registre
tu écris en VRAM

Non ???
Je ne comprends pas trop ce que tu as écrit : là j'ai l'impression que tu copies directement la ROM en VRAM (dans ce cas là bien sûr inutile de passer par la RAM).

Je ne suis pas spécialiste de la compression graphique mais je crois bien qu'il te faut un vrai buffer en RAM pour le genre d'algorithmes utilisés (c'est pas vraiment du RLE).
avatar
vingazole
Infirmier

Masculin Nombre de messages : 4092
Age : 44
Localisation : Nilbog
Date d'inscription : 05/01/2012

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par TotOOntHeMooN le Lun 26 Jan 2015 - 21:01

@vingazole a écrit:Le VDP de la SMS est une évolution du Texas Instruments qui équipe la Coleco ou la Sega SG-1000 (les modes graph de la SG-1000 sont utilisables sur SMS); le VDP de la Megadrive assure la compatibilité avec le VDP de la SMS.
Le VDP de la Megadrive exclus le support des modes utilisés dans la SG-1000 ; Donc des modes d'origine de TI.
avatar
TotOOntHeMooN
Docteur *
Docteur *

Masculin Nombre de messages : 7832
Age : 48
Localisation : France
Date d'inscription : 18/04/2013

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par Touko le Lun 26 Jan 2015 - 21:11

Je ne comprends pas trop ce que tu as écrit : là j'ai l'impression que tu copies directement la ROM en VRAM (dans ce cas là bien sûr inutile de passer par la RAM).
Non je parle bien de décompression rom /ecriture en VRAM .
Après c'est sur que tout dépend de l'algo de compression que tu utilises ..
Mais si j'ai bien compris le kit coleco, ils utilisent un buffer en ram pour décompresser dans la boucle principale en ram, puis transférer en vram pendant le vblank .

Ce qui est bizarre, c'est qu'en plus dans la doc du vdp, ils disent que tu peux aussi écrire en vram hors vblank, mais là tu as des wait states ..


Dernière édition par TOUKO le Lun 26 Jan 2015 - 21:14, édité 1 fois
avatar
Touko
Docteur *
Docteur *

Masculin Nombre de messages : 13555
Age : 45
Localisation : LE MANS/MARSEILLE
Date d'inscription : 08/07/2010

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par vingazole le Lun 26 Jan 2015 - 21:11

Le VDP de la Megadrive exclus le support des modes utilisés dans la SG-1000 ; Donc des modes d'origine de TI.
Oui, c'est mieux de le préciser Wink




Non je parle bien de décompression rom /ecriture en VRAM .
Après c'est sur que tout dépend de l'algo de compression que tu utilises ..
Mais si j'ai bien compris le kit coleco, ils utilisent un buffer en ram pour décompresser dans la boucle principale en ram, puis transférer en vram pendant le vblank .
C'est bien ce que je te dis, il faut un buffer plus conséquent que les quelques octets disponibles avec les registres du z80.
avatar
vingazole
Infirmier

Masculin Nombre de messages : 4092
Age : 44
Localisation : Nilbog
Date d'inscription : 05/01/2012

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par Touko le Lun 26 Jan 2015 - 21:42

Tu as aplib qui te permet de faire ca il me semble.
avatar
Touko
Docteur *
Docteur *

Masculin Nombre de messages : 13555
Age : 45
Localisation : LE MANS/MARSEILLE
Date d'inscription : 08/07/2010

Revenir en haut Aller en bas

Re: COLECOVISION : discussions programmation C&Assembleur

Message par Contenu sponsorisé


Contenu sponsorisé


Revenir en haut Aller en bas

Page 1 sur 7 1, 2, 3, 4, 5, 6, 7  Suivant

Revenir en haut


 
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum