routine 3D ultra-performante pour 6502

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 : Papy.G, fneck, Carl

Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: routine 3D ultra-performante pour 6502

Message par Neotenien »

Fool-DupleX a écrit : 28 avr. 2021 17:58 (...)
Mais il n' y a eu qu'un seul développeur, sur son coin de table de cuisine. Tu auras peut-être envie de lui demander comment il a fait ?

C'est par ici --> https://www.linkedin.com/in/dguillonnet

Ce qui devrait te faire plaisir, c'est qu'il a beaucoup utilisé l'instruction MUL.
Une seule personne ? Wow. Par contre je n'arrive pas à accéder à Linkedin, il y a un test incessant pour vérifier que je ne suis pas un robot,...

Je pense que sur TO8/MO6, on peut avoir un système qui efface l'écran complètement (avec les PSHS PULS) puis retraçage, dans une des 2 RAM bank 2 et 3. Mais il faut réécrire les routines moniteur de tracer de ligne puisque celle ci ne s'applique QUE pour la bank RAM 0 (affichage écran par défaut), puisqu'elle écrivent en RAM logique "écran".

Oui pour l'instruction MUL, parce que ça n'utilise que 11 cycles...
Fool-DupleX a écrit : 28 avr. 2021 17:58 Ce qui va moins te faire plaisir, c'est qu'il a aussi beaucoup utilisé ceci :
(...)
Qu'est ce qui te fait croire que ça me plait moins ? Figure toi que j'ai commencé une routine pour un scrolling d'écran pour Bubble Bobble utilisant ceci (il m'a fallu comprendre dans quels sens étaient stockée les registre en empilement et dépilement). Dans l'Hitashi 6309;, il y a une instruction qui permet de faire de la copie de block d'octets (même de plusieurs centaine d'octet) en une seule instruction (et utilisant le régistre W comme "décompteur"), c'est quelque chose d'assez unique, n'existant pas sur le 68k par exemple.

Pour moi, ceci devrait être (enfin je crois) utilisé pour les piles (comme la prog récursive) mais ça a un inconvénient, c'est qu'il faut contrôler les limites de l'espace RAM dans lequel on utilise les piles dans ce cas là. C'est sans doute pourquoi Sam a trouvé énormément d'éléments de contrôle pour un programme "Pascal Base" compilé. C'est aussi un outil idéal pour un OS multitâche.
Fool-DupleX
Messages : 2284
Inscription : 06 avr. 2009 12:07

Re: routine 3D ultra-performante pour 6502

Message par Fool-DupleX »

Neotinien a écrit :Qu'est ce qui te fait croire que ça me plait moins ? Figure toi que j'ai commencé une routine pour un scrolling d'écran pour Bubble Bobble utilisant ceci ...
Neotinien, sur logicielsmoto.com, a écrit :Quand c'est optimisé avec les PULU/PSHU, ça peut aller jusquà' 3 fois plus vite qu'avec les LDD, mais franchement je ne suis pas fan de cette technique, pour moi c'est pas de la programmation propre.
Non, rien :D
il y a un test incessant pour vérifier que je ne suis pas un robot,...
Ah ben c'est que tu dois être un robot, alors. Ok, ok, je sors ... :arrow:
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: routine 3D ultra-performante pour 6502

Message par __sam__ »

Neotenien a écrit : 29 avr. 2021 13:19 MDR faire du Raytracing sous MO5 c'est comme essayer de faire un grand prix de F1 avec une bicyclette LOL :D
Tu va kiffer grave....

Charger la diskette ci-jointe dans un MO6/TO8/TO9+ (ca marche aussi sur TO9, mais il faut décommenter un bout vers la fin du code). S'assurer qu'on peut bien écrire dessus. Booter sur "B"... l'écran passe en noir sur blanc et demande un nom de fichier. Saisir RAYTR en majuscule. S'affiche alors un code source qui ressemble à une sorte de basic sans numéros de lignes, avec une instruction par ligne, des IF/ENDIF bien structurés, des labels symboliques etc. C'est une syntaxe largement inspiré du GFA-Basic que j'avais écrit en 1988 et qui m'a permis d'écrire plus facilement qu'en basic conventionnel des softs relativement évolués sur mon TO9 tel que le fichier RAYTR qui figure sur la diskette ci-jointe.

Pour le lancer faire CTRL-R (comme run) et attendre......... longtemps........ non non encore plus longtemps (même avec l'émul en x10) A l'époque je faisais comme Daniel avec mon TO9 que je laissais tourner des jours et des nuits (et ca c'est rien par rapport à ma période fractale ou encore 3D" fait aussi avec ce pseudo GFA-Basic thomson.)

[EDIT] Oops non zut.. je vois que je, nous en fait, te parasitons ton fil JiBé. Excuse moi/nous. Nous autres sur thomson on est incorrigibles.
Pièces jointes
sam_gfa.zip
(19.75 Kio) Téléchargé 120 fois
Dernière modification par __sam__ le 29 avr. 2021 23:57, modifié 1 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: routine 3D ultra-performante pour 6502

Message par Neotenien »

Fool-DupleX a écrit : 29 avr. 2021 15:13
Neotinien a écrit :Qu'est ce qui te fait croire que ça me plait moins ? Figure toi que j'ai commencé une routine pour un scrolling d'écran pour Bubble Bobble utilisant ceci ...
Neotinien, sur logicielsmoto.com, a écrit :Quand c'est optimisé avec les PULU/PSHU, ça peut aller jusquà' 3 fois plus vite qu'avec les LDD, mais franchement je ne suis pas fan de cette technique, pour moi c'est pas de la programmation propre.
Oui ce n'est pas de la programmation propre, pas du "standard". Au CNAM on m'a appris à faire du standard. Cette technique est un peu "hors norme". A priori, les piles sur le 6809 n'ont pas été écrit au départ pour faire du transfert de RAM mais bien pour des choses du genre programmation récursive (et donc, aussi, pour le multitâche). Mais bon effectivement c'est efficace pour les scrolling. Même si ça demande un certain cheminement intellectuel pour comprendre le concept.
il y a un test incessant pour vérifier que je ne suis pas un robot,...
Fool-DupleX a écrit : 29 avr. 2021 15:13 Ah ben c'est que tu dois être un robot, alors. Ok, ok, je sors ... :arrow:
Ben je ne sais pas comment on peut entrer dedans, j'ai fait une série de 4 fois le tests, il me mettent que je ne suis pas un robot à chaque gfois ... et rebelotte... Je suis sous Chromium (LMinux) et je ne suis pas inscrit sur ce site, il y a eu toujours d'énormes problèmes techniques (à une époque, c'était dans les champs texte qui étaient quasi gelé, maintenant ça). Je suis sur INdeed depuis un bout de temps et je 'nai jamais eu ce genre de probl_ème.
Avatar de l’utilisateur
Papy.G
Modérateur
Messages : 3047
Inscription : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: routine 3D ultra-performante pour 6502

Message par Papy.G »

Le Re-Captcha Google, c'est vraiment n'importe quoi (cf Leboncoin). :roll:

C'est impressionnant, il y a peut-être des précédents de pseudo-3d basés sur des points pré-calculés qui donnaient des résultats plus rapides, mais saccadés, et pas avec des textures, ou ça ne s'est jamais fait?
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.
Avatar de l’utilisateur
6502man
Messages : 12286
Inscription : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: routine 3D ultra-performante pour 6502

Message par 6502man »

Neotenien a écrit : 29 avr. 2021 20:32 Quand c'est optimisé avec les PULU/PSHU, ça peut aller jusquà' 3 fois plus vite qu'avec les LDD, mais franchement je ne suis pas fan de cette technique, pour moi c'est pas de la programmation propre.
Neotenien a écrit :Oui ce n'est pas de la programmation propre, pas du "standard". Au CNAM on m'a appris à faire du standard. Cette technique est un peu "hors norme".
Quand je lis que ce n'est pas de la programmation "standard" ca me fait tiquer, car je comprend pas qu'est ce qu'un standard en programmation assembleur :roll:
A partir du moment ou tu assemble ton code et qu'il ne retourne pas d'erreur et que le programme fonctionne comme attendu, qu'il est était écrit d'une manière ou d'une autre peu importe.
A la rigueur on peut parler d'optimisation ou de rapidité :wink:
J'ai pas la prétention d'être un expert en programmation assembleur mais la seule règle c'est d'arriver au résultat escompté :wink:
et si le résultat est d'être suffisamment rapide pour ne pas désynchroniser l'affichage alors vaut mieux optimiser avec les instructions
les plus rapides quitte à trouver des astuces de programmation "hors norme".
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.
Avatar de l’utilisateur
rendomizer
Messages : 413
Inscription : 17 juin 2016 21:00
Contact :

Re: routine 3D ultra-performante pour 6502

Message par rendomizer »

La question maintenant serait-ce comment faire une sinusoïde en assembleur z80 VG5000 ? :lol:
Je ne suis qu'un utilisateur pas un pro
Markerror
Messages : 2121
Inscription : 31 oct. 2011 19:21
Localisation : Orléans
Contact :

Re: routine 3D ultra-performante pour 6502

Message par Markerror »

J'y connais rien en programmation 6809, je suppose que les instructions PSHU/PULU, ça sert à empiler/déplier un registre 16 bits (apparemment, ça en prend plusieurs, mince, je suis jaloux :-) ).

Ce n'est pour moi pas une technique de programmation "crado", car cela suppose de savoir ce qu'on fait et de gérer correctement la pile et les interruptions (sinon, joli plantage -) ). C'est souvent utilisé sur CPC pour faire des scrolling softs ou des déplacements de sprites sur l'écran, car une routine bien conçue est un peu plus rapide que des séries de copies d'octets avec la commande LDI.
Dernière modification par Markerror le 13 sept. 2021 22:01, modifié 1 fois.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: routine 3D ultra-performante pour 6502

Message par hlide »

Sur le MZ-700, j'utilise une séquence de POP pour lire une série d'octets qui sera écrite dans la VRAM via une séquence de PUSH en ordre inverse. Je me contre-fiche que cela semble "crado" parce qu'il n'y a pas d'alternative pour remplir un écran entier en-dessous de la période d'une frame. Au niveau interruption, je peux m'en passer car d'origine elle sert sert juste à basculer un flag AM/PM pour l'heure. Donc les considérations de "standard" de la programmation moderne me font un peu rire car elle ne prend pas en compte les spécificités et limitations de ces machines 8-bit. Essayez donc d'avoir un programme C compilé en Z80 qui soit supérieur à tout programme écrit à la main. Le Z80 n'est pas une architecture adaptée au C ou même au PASCAL (la gestion de la pile est incomplète sur le Z80). On n'a pas le choix que d'écrire de la façon qui semblerait "crado" sur une architecture moderne.

Et si vous n'êtes pas convaincus, regardez cette spécificité du "Z80" de la GameBoy :

Code : Tout sélectionner

    ADD SP,offset   -> LDA SP,offset(SP)
    LDHL SP,offset  -> LDA HL,offset(SP)
Notez que c'est précisément des instructions qu'un C ou PASCAL aurait bien besoin qui ne sont pas dans le vrai Z80. Une coincidence ?
Zebulon
Messages : 2787
Inscription : 02 nov. 2020 14:03

Re: routine 3D ultra-performante pour 6502

Message par Zebulon »

En effet je pense qu'il y a deux contextes diamétralement opposés et que "crado" ne signifie pas la même chose dans les deux cas :
- d'un côté le développement en équipes (souvent distribuées) sur des architectures foisonnantes modernes dans des langages de haut-niveau et pour lequel on a besoin de surveiller des critères de maintenabilité, de sécurité, etc qui peuvent être assimilés à des "normes",
- de l'autre le "one-man project" sur des architectures ultra-limitées et pour lequel la nécessité de performance, compacité du binaire, etc passe par le langage machine et toutes les optimisations possibles en fonction de chaque but à atteindre sont de fait acceptables.

Par contre documenter la source de ce code optimisé pour justement expliquer le pourquoi du comment permet de le rendre plus accessible à d'autres.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: routine 3D ultra-performante pour 6502

Message par hlide »

Tout à fait.

Et pour revenir aux deux piles S et U du 6809, je me demande s'il n'y avait pas une volonté de permettre à ce processeur d'être un atout pour le Forth (ce processeur a l'air vraiment d'exceller en Forth) car il me semble avoir lu que le Forth pourrait bénéficier d'avoir deux piles. Ce n'est que de l'hypothèse parmi d'autre.
Avatar de l’utilisateur
fxrobin
Messages : 102
Inscription : 07 mars 2019 13:51
Localisation : RENNES
Contact :

Re: routine 3D ultra-performante pour 6502

Message par fxrobin »

__sam__ a écrit : 29 avr. 2021 20:04 C'est une syntaxe largement inspiré du GFA-Basic que j'avais écrit en 1988 et qui m'a permis d'écrire plus facilement qu'en basic conventionnel des softs relativement évolués sur mon TO9 tel que le fichier RAYTR qui figure sur la diskette ci-jointe.
T'es un dingue ! :shock:
(c'est un compliment)
Fan d'ATARI 2600, de THOMSON MO5-TO8 et d'ATARI ST
Mes articles : https://www.fxjavadevblog.fr/retro-programming/
Membre du groupe wide-dot.
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: routine 3D ultra-performante pour 6502

Message par Neotenien »

6502man a écrit : 30 avr. 2021 16:39
Neotenien a écrit : 29 avr. 2021 20:32 Quand c'est optimisé avec les PULU/PSHU, ça peut aller jusquà' 3 fois plus vite qu'avec les LDD, mais franchement je ne suis pas fan de cette technique, pour moi c'est pas de la programmation propre.
Neotenien a écrit :Oui ce n'est pas de la programmation propre, pas du "standard". Au CNAM on m'a appris à faire du standard. Cette technique est un peu "hors norme".
Quand je lis que ce n'est pas de la programmation "standard" ca me fait tiquer, car je comprend pas qu'est ce qu'un standard en programmation assembleur :roll:
A partir du moment ou tu assemble ton code et qu'il ne retourne pas d'erreur et que le programme fonctionne comme attendu, qu'il est était écrit d'une manière ou d'une autre peu importe.
A la rigueur on peut parler d'optimisation ou de rapidité :wink:
J'ai pas la prétention d'être un expert en programmation assembleur mais la seule règle c'est d'arriver au résultat escompté :wink:
et si le résultat est d'être suffisamment rapide pour ne pas désynchroniser l'affichage alors vaut mieux optimiser avec les instructions
les plus rapides quitte à trouver des astuces de programmation "hors norme".

Ce qui est dangereux avec les PULU et PSHS, c'est qu'on utilise des zones mémoires qu'on doit absolument réserver pour cela... Ok sur Thomson TO, on peut dire que la zone 0-$3999 et les banques RAM peuvent servir à ça, mais tout de même... Et avec le 6302 on a une super instruction qui permet de faire des copies de block mémoire en une seule instruction (ça c'est vraiment top pour les scrolling!) et ça le fait de manière optimisée (en terme de nombre de cycles d'horloges)

Dans la pratique, les piles servent, devraient servir, pour la programmation récursive (ce que Pascal Base et Pascal UCSD font d'ialleurs, et tous les langages Pascal)
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: routine 3D ultra-performante pour 6502

Message par __sam__ »

Neotenien a écrit : 13 sept. 2021 12:26 Ce qui est dangereux avec les PULU et PSHS, c'est qu'on utilise des zones mémoires qu'on doit absolument réserver pour cela...
...comme pour toute les zones de données. Ca n'est pas plus dangereux qu'un STD ,--X ou LDD ,X++ quand le pointeur déborde. L'essentiel est de savoir ce qu'on code et ne rien laisser au hasard. Comme disait la pub: "sans maitrise, la puissance n'est rien".
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: routine 3D ultra-performante pour 6502

Message par Neotenien »

__sam__ a écrit : 13 sept. 2021 13:57
Neotenien a écrit : 13 sept. 2021 12:26 Ce qui est dangereux avec les PULU et PSHS, c'est qu'on utilise des zones mémoires qu'on doit absolument réserver pour cela...
...comme pour toute les zones de données. Ca n'est pas plus dangereux qu'un STD ,--X ou LDD ,X++ quand le pointeur déborde. L'essentiel est de savoir ce qu'on code et ne rien laisser au hasard. Comme disait la pub: "sans maitrise, la puissance n'est rien".
"C'est pas faux" Enfin bon l'inconvénient de cette techno est que les registre sont tous sollicité et qu'il faut penser à faire une sauvegarde avant. C'est ce que le système est sensé faire quand on fait un JSR.

Et dire que le 6309 a une instruction capable de faire de la "copie" de bloc RAM!! Vraiment intéressant dans le cadre de scrolling... Et je viens de voir qu'il est aussi capable d'avoir des instruction d'opération arithmétiques et logique INTRA registres! Ca c'est vraiment top!! Ca gagne énormément de cycles d'horloges

Daniel a eu une super idée d'inclure l'émulation 6309 dans DC MOTO, si seulement il y avait un assembleur spécial 6309... En mode émulation, le 6309 est déjà 33% plus rapide que le 6809 (ça fait du 0.55 MIPS/MHz au lieu de 0.43) et en mode natif, c'est 15% en plus.

Je songe vraiment à créer une doc sur les instructions assembleur 6809 et 6309. La doc PDF sur le 6309 fait plus de 200 pages!
Répondre