MSX Village forum

Salut à tous,

J'aurais besoin d'une petite routine en Assembleur qui agirait comme l’instruction COPY du Basic mais en plus rapide...
Déjà .. je ne sais pas si c'est faisable de faire une routine qui soit plus rapide que le COPY .. ?
Je vous explique ce dont j'ai besoin...

J'ai des fichiers images sur mon support qui sont des parties d'images qui ont été sauvegardées comme ceci : COPY (100,100)-(200,200) to "a:PART1.S8"

Dans mon programme Basic, lorsque j'en ai besoin, je fait donc l'opération inverse, à savoir
COPY "a:PART1.S8" to (100,100),0

Mais ce Copy est relativement long, surtout que j'en ai 5 à la suite...

Est-il possible de faire en ASM une routine qui soit plus rapide et que je puisse utiliser depuis le Basic ?
Si, oui... Qui pourrait me la faire ?

Oui je lis depuis une carte SD effectivement...

Mon Copy prends 24 cycles (pour image qui fait 45x62 pixels).

Ca prends 22 Cycles depuis H: (Le Ram disk MSXDOS2)


Edit : J'ai fait une routine en NEstorBasic (Kun Basic / Turbo Basic) qui stock les données du Copy en RAM, puis qui recopie ces données de la RAM vers la VRAM.
Mais cette dernière opération (RAM > VRAM) me prends aussi 24 Cycles en Turbo Basic (Contre 107 Cycles en Basic normal). Du coup je ne gagne toujours rien...

Peut être est-ce plus facile et plus efficace de faire une routine en ASM pour faire ce COPY de la RAM vers la VRAM ? Edité par ericb59 Le 07/01/2016 à 19h19

C'est en quel Screen? P'tet qu'en utilisant une page libre de la vram (screen5 set page 3 par exemple) afin de copier de la vram vers la vram serait plus rapide, en plus une page Screen5 peu contenir plusieurs bribes .
La Vram est gerer par le VDP en direct il me semble (désolé si je dis de co...! )

Le plus rapide c'est d'attendre la VBL puis tu coupe les sprites et l'affichage, et tu transfert octet par octet transfert RAM vers vram sans la fonction COPY.
Sinon au lieu de transféré de RAM à vram tu utilisé une fonction COPY bloc RAM vers (x,y)
En suite tu te allumé l'affichage et les sprites.
Couper l'affichage et les sprites est le seul moyen d'accélérer les transferts/COPY du VDP.

Si bload"image.scx",S permettait la transparence, je t'aurais dit fait un bload, mais j'ai jamais pu appliquer la transparence juste en chargeant une image et/ou bribe en appliquant la transparence instantanément

Autrement, tu préparais préalablement ton image en colorant juste les pixels qui t'intéressent, les pixels d'avant et d'après sur les mêmes lignes horizontales "coloriées" en color 0 et comme ça tu obtiens un carré d'image chargé directement avec un bload au lieu d'un copy.

J'ai essayé mais jamais réussi et d'ailleurs je comprends pas trop pourquoi

Est comme si que pour tirer partie de la transparence, t'es obligé de passer par copy et donc longitude plus latitude etc etc Edité par igal Le 07/01/2016 à 21h04

Je sais, ton image fais 45×62.

Cela veut dire qqu'avec un copy il faut charger 45×62 pixels soit 2790 pixels au total.

Avec bload, tu dois charger 45×256 pixels soit 11620 pixels.

Bload fais charger une bribe virtuellement 4 fois plus grande que ton copy.

Cependant, mon idée était que si l'on pouvait appliquer la couleur ZÉRO à la bribe que l'on bload, il suffirait de charger cette bribe qui contiendrait une plage de 11620 pixels mais dont seulement 2790 pixels serait colorés.

Dans la pratique, je suis CERTAIN que la transparence est beaucoup plus rapide à afficher qu'une couleur, la perte de temps à charger la partie transparente du bload serait minime.

A cela, sachant que bload ne nécessite pas de coordonnées longitudes+latitudes requise par copy, le gain peut être valable.

Je sais pas si ça correspond à ce que tu veux faire mais dans tous les cas, je ne suis pas arrivé à exploiter correctement cette idée Edité par igal Le 07/01/2016 à 22h12

Je crois me souvenir qu'en Basic, que ce soit COPY ou BLOAD, plus le programme Basic grossit, plus une image met de temps à charger parce que la mémoire libre (entre le programme Basic et les variables) est utilisée comme cache.

Pour obtenir quelque chose de rapide, il faut réserver un emplacement pour y mettre le maximum de l'image à charger.

En machine, les routines BLTDV et BLTDV de la Sub-ROM sont sans doute les plus simples pour essayer ce que tu veux faire. Edité par GDX Le 08/01/2016 à 08h30

En marge du copy que je cherche à rendre plus rapide, je cherche aussi à accélérer l'accès à toutes mes données graphiques.
Je viens de faire une jolie découverte qui pourra intéresser l'ami Igal avec son "moteur à brides"

Une image de 54Ko met 47 cycles à se charger et s'afficher à l'écran avec un BLOAD ,S.

Nestor Basic possède des fonctions qui permettent de lire/Ecrire directement sur les secteurs d'un disque.
En ayant préalablement sauvegardé mon image de 54Ko directement dans les secteurs de la carte SD,
J'arrive maintenant à lire et afficher l'image en 18 Cycles seulement !
Soit un gain de 29 cycles (Près d'une demi seconde tout de même) Edité par ericb59 Le 08/01/2016 à 10h12