Logicielsmoto.com

Nous sommes le 28 Mar 2024, 11:42

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 168 messages ]  Aller à la page Précédente  1 ... 8, 9, 10, 11, 12  Suivante
Auteur Message
MessagePosté: 07 Jan 2021, 00:52 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Neotenien a écrit:
Citation:
Le problème est résolu.
Si tu le dis, mais pour moi tes explications ne sont pas claires dans la mesure où tu ne dis pas si tu as compris les points en rouges plus haut. Mais une chose est sure, en restant dans l'ASM c'est à dire dans un environnement que tu contrôles à 100%, si ca bug, c'est que ca vient de toi et pas de d'un codage ne permettant pas la cohabitation avec le système sous-jacent. Par contre il faudra tout faire à la main, les initialisations de l'extramon, du dos-disk, la gestion de la pile, etc. En particulier il faudra que tu fasses toi-même le chargement du binaire depuis le disk dans les bank mémoire. C'est pas mal de boulot, mais c'est passionnant, et c'est bien ca qui compte au final.


Ben justement pas tout à la main, je laisse la possibilité d'utiliser l'extramon en gardant l'espace cartouche tel qu'elle, notamment la gestion du disque, le RND etc... Ca peut se faire aussi en commutant l'espace cartouche, puisque les opérations ne se font pas en même temps.
Je pense qu'on peut charger toutes les datas en une fois en basic dans les différentes banques en basic (sachant que les 100 tableaux prennent 65kO rien qu'eux, ça bouffe déjà 2 banques! Et les motifs des niveaux (100x2x64 O), les sprites... Ok le TO8 a 16 voire 32 banque ça devrait suffire mais c'est la localisation de tout ça à un instant t... Mais si même l'Apple2 a pu le faire ya aucune raison que ça ne se fasse pas sur le TO8.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 07 Jan 2021, 01:11 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Neotenien a écrit:
... ce qui, fatalement, écrase le script BASIC se trouvant en espace physique 2... On ne peut donc pas revenir à ce BASIC qui a été écrasé COMPLETEMENT par le traitement data servant à l'affichage écran.

Tu n'es pas obligé d'écraser les données du basic. Tu peux les sauvegarder les banques physiques 2 & 3 utilisées par le basic dans les banques 14 et 15 par exemple et restaurer le tout quand tu as besoin du basic.

De même tu peux mapper ce que tu veux dans l'espace ROM vu que tu peux restaurer à volonté et à bas cout CPU le contenu. Si tu voyais comment la ROM s'amuse à changer en permanence de banque ROM $000->3FFF et même en rom moniteur sur TO9, tu n'aurais aucun complexe à faire pareil.

Citation:
On a déjà parlé de ça avant..
Oui ca fait plusieurs fois que je te dis qu'il n'y a pas de raisons de ne pas cohabiter avec le basic. Mais dans le fond je me demande si ca ne sera pas plus sain pour toi de travailler sans le basic. Les routines de générateur aléatoire ne sont pas très difficiles à coder soi-même, et seront même plus rapide que celle du basic (voir du coté de ce que a fait G. Marsaglia en son temps).

Citation:
Sans parler de tous les Sprites (j'ai pas compter mais ça doit bien dépasser les 100, à raison d'au moins 16 par personnages), les niveaux de tableaux (100 tableaux avec plus de 600 octets par tableau), les paramètres audio... Ca prend de la place tout ça.

Il te faudra dans tous les cas une gestion de mémoire rigoureuse avec un chargement et une organisation disk qui marche de concert.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 07 Jan 2021, 17:24 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Neotenien a écrit:
... ce qui, fatalement, écrase le script BASIC se trouvant en espace physique 2... On ne peut donc pas revenir à ce BASIC qui a été écrasé COMPLETEMENT par le traitement data servant à l'affichage écran.

Tu n'es pas obligé d'écraser les données du basic. Tu peux les sauvegarder les banques physiques 2 & 3 utilisées par le basic dans les banques 14 et 15 par exemple et restaurer le tout quand tu as besoin du basic.

C'est une idée que je garde sous le coude... Ca suppose de mettre un de ces espaces (banque 2 ou 14) en dessous de l'espace $A000... Donc en espace cartouche à priori. Pur le moment je ne voit pas trop l'intérêt d'utiliser le BASIC, vu que l'extramoniteur possède énormément de fonctions très intéressantes!! Les fonctions mathématiques, graphiques, et même le DOS Iconique. La fonction PLAY de l'extramoniteur en assembleur reprend EXACTEMENT la même démarche que celle du BASIC.

Je préfère quand même largement utiliser l'existant ET NE PAS LE REECRIRE. 2 raisons:
- Pour utiliser au mieux l'espace utilisateur entre $6100 et $9FFF (s'il y a des tas de routines.. Ok pour le moment, ma routine complète d'affichage de sprite prend moins de 256 Octets, mais il ne me reste que 61 (puisque l'espace $6000-$60FF sert pour le moniteur, que j'ai déjà 256 réservé pour la routine d'affichage de Tile/Sprites et 256 pour le masque des sprites) autres "pages" ram à utiliser. pour les routines assembleurs. Ca peut paraître beaucoup mais le jeu Bubble Boble me parait avoir énormément de fonction dedans!!
- Ca me fait perdre du temps pour écrire (ou recopier ?) ce code

Samuel Devulder a écrit:
De même tu peux mapper ce que tu veux dans l'espace ROM vu que tu peux restaurer à volonté et à bas cout CPU le contenu. Si tu voyais comment la ROM s'amuse à changer en permanence de banque ROM $000->3FFF et même en rom moniteur sur TO9, tu n'aurais aucun complexe à faire pareil.

Ca me rassure!! Parce que c'était un point sur lequel j'hésitais énormément (et j'étais même parti pour ne pas utiliser cette possibilité du tout, malgré ce que tu avais écrit auparavant sur la méthodologie d'allocation des espaces en RAM logique dans les jeux. Bon ben ça va me faire une routine de plus à écrire

Samuel Devulder a écrit:
Citation:
On a déjà parlé de ça avant..
Oui ca fait plusieurs fois que je te dis qu'il n'y a pas de raisons de ne pas cohabiter avec le basic. Mais dans le fond je me demande si ca ne sera pas plus sain pour toi de travailler sans le basic. Les routines de générateur aléatoire ne sont pas très difficiles à coder soi-même, et seront même plus rapide que celle du basic (voir du coté de ce que a fait G. Marsaglia en son temps).

Peut-être, au CNAM on en avait codé une telle routine en langage Pascal (que j'ai d'ailleurs gardé sous le coude pour Pascal Base)... Mais en fin de compte, je préfère utiliser l'existant pour les raisons que j'ai indiquées juste au dessus.

Samuel Devulder a écrit:
Citation:
Sans parler de tous les Sprites (j'ai pas compter mais ça doit bien dépasser les 100, à raison d'au moins 16 par personnages), les niveaux de tableaux (100 tableaux avec plus de 600 octets par tableau), les paramètres audio... Ca prend de la place tout ça.

Il te faudra dans tous les cas une gestion de mémoire rigoureuse avec un chargement et une organisation disk qui marche de concert.

A ce propos, j'espère qu'il y a une alerte dans le système indiquant quand un fichier est chargé ? Ca serait top. Je n'en sais pas encore à ce niveau. j'ai beaucoup d'autres trucs à faire avant.

De toutes façons, je pense que je vais tout charger du Basic (les 4 fichiers de 16kO pour les tableaux, 25 tableaux par fichier, dans différentes banques, les Motifs des tableaux (2 Tiles par tableau), les sprites, les programmes binaires, et l'audio...)

En tous cas, la routine assembleur actuelle permet de dire qu'elle peut effacer et afficher 200 Sprites (avec transparence) de 8x16 par seconde. C'est pas mal!! Sachant qu'il y aura grand max 20 Sprites (Personnages+bulles) à la fois, on peut tabler avec de la marge sur du 2 im/s au plus lent (en y intégrant la musique de fond).

Et le test d'animation de 12 Sprites en 4 MHz sous DC Moto (en mode 6809) donne une vitesse de déplacement PHENOMENALE! Je me demande comment l'Amstrad (Z80 à 4 MHz quand même) peut être aussi lent avec le jeu "Enduro Racer", je l'ai testé en mode 4 MHz sur DC Moto, ça va aussi vite qu'une borne d'arcade!! J'ose à peine imaginer ce que l'Hitachi 6309 avec les 4 registre d'ALU, les fonctions supplémentaire (dont déplacement de bloc je crois ? Et surtout division entière) donnerait mais ça ferait du Thomson l'ordinateur 8 bits le plus puissant existant. Même l'audio via CNA (au lieu d'avoir un VALTImer qu'on programme à 1/2000, on ferait du 1/8000 et n ne serait plus limité en rien!!) je crois qu'on aurait une machine équivalente à l'Atari ST même avec la moitié en MHZ (pour info, le 68000 à 8 MHz est donné à 1 MIPS seulement, alors que si le 6809E à 1 MHz est donné à 0.42 MIPS, le 6309 à 4 MHz... à priori, ça ferait au moins du 1.68 MIPS non ? Donc l'atari ST (et l'Amiga encore + puisque lui est à 7 MHZ) est éclaté LOL.


Dernière édition par Neotenien le 07 Jan 2021, 18:26, édité 1 fois.

Haut
 Profil  
Répondre en citant le message  
MessagePosté: 07 Jan 2021, 18:21 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Même boosté avec un hitachi 6309, un Thomson seconde génération "n'éclatera" jamais un ST ou un Amiga.
Un 8 bits reste un 8 bits! Et dans notre cas, comme Daniel l'a souligné, c'est 1 Mhz max :tourne:


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 07 Jan 2021, 18:39 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
lol stoppez le 8bits(amstrad/thomson etc..) versus ST/amiga

amiga/st ça défoncera toujours, ça se compare pas :D

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 08 Jan 2021, 14:05 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
jasz a écrit:
Même boosté avec un hitachi 6309, un Thomson seconde génération "n'éclatera" jamais un ST ou un Amiga.
Un 8 bits reste un 8 bits! Et dans notre cas, comme Daniel l'a souligné, c'est 1 Mhz max :tourne:


Eh non ça sera du 4 MHz comme je l'explique (et ça fera bien du 1.8 MIPS contre 1 MIPS contre le ST!!), et comme je l'ai évoqué plusieurs fois, le but serait de créer un boitier compatible Thomson TOMO, comme c'est le cas d'autres standards :
  • Le firebee sorti en 2014, qui est 100 fois plus rapide que l'Atari Falcon 030, est 99% fully compatibe avec toute la gamme Atari ST,
  • Le C64 mini qui est un clavier en tout intégré, avec exactement les mêmes composant que le C64 de l'époque mais avec prise HDMI
  • Ataribox, une nouvelle version de l'atari VCS 2600

On peut très bien envisager un Thomson Box, avec un Hitachi 6309 à 4 MHz avec 2 ROM, un reprenant celui des TO/MO (et adaptant éventuellement les routines utilisant le timer pour les multiplier par 4...) et une spécial 6309" et nouveau chipset graphique (permettant d'avoir su SVGA par exemple).

Et pour info, l'Hitachi n'est plus un 8 bits, c'est plutôt un 16/32 bits (au niveau des registes, W et Q), les registre A, B, C et D étant plutôt des parties des 2 régistres 16 bits, pour garder la compatibilité avec le 6809!


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 08 Jan 2021, 14:27 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
adnz a écrit:
lol stoppez le 8bits(amstrad/thomson etc..) versus ST/amiga

amiga/st ça défoncera toujours, ça se compare pas :D


Désolé mais pour avoir eu un atari Falcon (qui est à 3.84 MIPS, donc à priori 3 fois plus rapide que les ST) quand on parle de jeux en 3D, si ça n'utilisait pas le DSP, c'était mou de chez mou!! J'ai testé POV entre le Falcon et un PC 486 à 16 MHZ à l'époque, et le PC le battait carrément à plate couture!! Pourquoi ? Parce les accès RAM des Atari était très lents comparé à l'accès RAM des PC

Et si on veut comparer des machines de même génération, les Amiga et Atari ST était carrément laissé sur place par les Acorn Archimèdes (qui avait les mêmes fréquences d'horloge pour les premier modèles).. Il suffit de comparer le jeu "Zarch" entre Atari ST et un Archimedes à 8 MHz à l'époque...
phpBB [video]


Quand je met DC MOTO en mode 4 MHz et 6809, les jeux Thomson sont très (trop) rapide!! Comparé aux même jeux sur Amstrad (qui sont sous ZX80 à 4 MHz) ça n'a rien à voir.... Malheureusement, les 6809 ont été carrément boudé (à part les tandy, homson et autre Vectrex, les autres machines étaient avec ce "pauvre" 6502 (même si le C64, qui s'en sort parce qu'il a une belle architecture autour) ou ZX 80 (seul le SX Spectrum a des truc intéresssant côté vitesse, mais l'Amstrad n'est pas plus rapide que les Thomson qui ont un proc /4)


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 08 Jan 2021, 14:36 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Neotenien a écrit:
jasz a écrit:
Même boosté avec un hitachi 6309, un Thomson seconde génération "n'éclatera" jamais un ST ou un Amiga.
Un 8 bits reste un 8 bits! Et dans notre cas, comme Daniel l'a souligné, c'est 1 Mhz max :tourne:


Eh non ça sera du 4 MHz comme je l'explique (et ça fera bien du 1.8 MIPS contre 1 MIPS contre le ST!!), et comme je l'ai évoqué plusieurs fois, le but serait de créer un boitier compatible Thomson TOMO, comme c'est le cas d'autres standards :
  • Le firebee sorti en 2014, qui est 100 fois plus rapide que l'Atari Falcon 030, est 99% fully compatibe avec toute la gamme Atari ST,
  • Le C64 mini qui est un clavier en tout intégré, avec exactement les mêmes composant que le C64 de l'époque mais avec prise HDMI
  • Ataribox, une nouvelle version de l'atari VCS 2600

On peut très bien envisager un Thomson Box, avec un Hitachi 6309 à 4 MHz avec 2 ROM, un reprenant celui des TO/MO (et adaptant éventuellement les routines utilisant le timer pour les multiplier par 4...) et une spécial 6309" et nouveau chipset graphique (permettant d'avoir su SVGA par exemple).

Et pour info, l'Hitachi n'est plus un 8 bits, c'est plutôt un 16/32 bits (au niveau des registes, D, W et Q), les registre A, B, E et F étant plutôt des parties des 2 registres 16 bits, pour garder la compatibilité avec le 6809!


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 08 Jan 2021, 17:00 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Neotenien a écrit:
Et pour info, l'Hitachi n'est plus un 8 bits, c'est plutôt un 16/32 bits (au niveau des registes, W et Q), les registre A, B, C et D étant plutôt des parties des 2 régistres 16 bits, pour garder la compatibilité avec le 6809!

Ce qui définit le nb de bits du CPU c'est la taille du bus de données. Et le "pin-out" de l'hitachi étant identique au mc6809, il n'accède à la mémoire que par mots de 8bits. Autrement dit, charger 16bits requiert au moins 2 cycles d'accès mémoire alors qu'un cpu 16bits le fera en un seul.

Par ailleurs oublie les 4mhz de l'amstrad. Le mhz c'est pas la bonne unité de mesure pour comparer les machines parce que les processeurs sont différents: Le Z80 a besoin de 4 cycles minimum par instruction, le mc6809 deux seulement. Au plus rapide, le Z80 peut faire 2 opérations là où le mc6809 n'en a fait qu'une. Mais le cas optimal n'est pas non plus représentatif car le 6809 a des modes d'adressages plus complexe que le Z80 ce qui peut compenser. La bonne unité de mesure est celle qui moyenne sur des instructions utiles, comme dans le benchmark Dhrystone qui se compte en Mips. Ainsi le Z80 tourne donc à environ 0.58Mips @ 4Mhz et le 6809 et le 6502 des Orics environ 0.42Mips @ 1mhz (source) ce qui est vraiment bien par rapport aux 0.33Mips @ 5Mhz du 8086. Cependant le Z80 a quand même 38% de puissance en plus que ses concurrents immédiats. Ce n'est pas du tout un mauvais cpu comparé à la concurrence en fait. C'est pas surprenant qu'il fut utilisé un peu partout à l'époque des 8bits.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 08 Jan 2021, 21:12 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Neotenien a écrit:
Et pour info, l'Hitachi n'est plus un 8 bits, c'est plutôt un 16/32 bits (au niveau des registes, W et Q), les registre A, B, C et D étant plutôt des parties des 2 régistres 16 bits, pour garder la compatibilité avec le 6809!

Ce qui définit le nb de bits du CPU c'est la taille du bus de données. Et le "pin-out" de l'hitachi étant identique au mc6809, il n'accède à la mémoire que par mots de 8bits. Autrement dit, charger 16bits requiert au moins 2 cycles d'accès mémoire alors qu'un cpu 16bits le fera en un seul.


Maintenant que tu me rappelle ça, oui effectivement. Mais du coup, les cycles indiqués, par processeus cont bien les cycles réels de l'exécution des instructions ? Ca signifie que le 6809E avec ces nombreuses instruction (surtoit ALU) à 2 cycles, est quand même bien optimisé!

Samuel Devulder a écrit:
Neotenien a écrit:
Par ailleurs oublie les 4mhz de l'amstrad. Le mhz c'est pas la bonne unité de mesure pour comparer les machines parce que les processeurs sont différents: Le Z80 a besoin de 4 cycles minimum par instruction, le mc6809 deux seulement. Au plus rapide, le Z80 peut faire 2 opérations là où le mc6809 n'en a fait qu'une. Mais le cas optimal n'est pas non plus représentatif car le 6809 a des modes d'adressages plus complexe que le Z80 ce qui peut compenser. La bonne unité de mesure est celle qui moyenne sur des instructions utiles, comme dans le benchmark Dhrystone qui se compte en Mips. Ainsi le Z80 tourne donc à environ 0.58Mips @ 4Mhz et le 6809 et le 6502 des Orics environ 0.42Mips @ 1mhz (source) ce qui est vraiment bien par rapport aux 0.33Mips @ 5Mhz du 8086. Cependant le Z80 a quand même 38% de puissance en plus que ses concurrents immédiats. Ce n'est pas du tout un mauvais cpu comparé à la concurrence en fait. C'est pas surprenant qu'il fut utilisé un peu partout à l'époque des 8bits.



C'est pourquoi j'ai parlé plusieurs fois des MIPS en comparaison. Mais là encore, ça peut être trompeur si les MIPS sont une moyenne basé sur les instructions présentes au sein de la puce (une division par exemple, bouffe pas mal de cycles... Le 6309 a, à la fois la multiplication et la division, certes ce ne sont QUE 2 instructions dans la masse).
Le 6502 a équipé les consoles Atari, les Atari XL, les Apple II, Oric Atmos et C64 (si j'en n'oublie pas). Le 6809 était plus limité car plus cher (à l'époque). Ce qui détache le 6809 est qu'il a l'instruction MUL, la possibilité de code réentrant, 2 registres pour l'ALU (contre 1 seul pour le 6502), 2 registre d'adresse 16 bits (contre 2 de 8 bits pour le 6502) et de nombreuses possibilité d'indexage par instruction et ça c'est un grand + comparé au 6502, et aussi, plusieurs interruptions. Le 6502 avait en plus un bug. Le fait qu'il y ait des registre 16 bits aurait pu handicaper le 6809/6502 en terme de MIPS mais en fait non.

Concernant le Z80 https://fr.wikipedia.org/wiki/Zilog_Z80 aient une architecture de type PipeLine, c'est à dire que si on a 2 instructions de 4, ou plus, cycles qui se suivent, au total ça n'en prendra que 5 (ou plus) parce que lorsque la première phase de l'instruction 1 est terminée, la première de l'instruction 2 s'enclenche. Donc ces "MIPS" ici sont un mauvais indicateur (désavantageant) concernant ce processeur... A moins que ça soit pris en compte dans ce calcul de MIPS ?

Je me demande si ce genre d'architecture PipeLine est valable dans le cadre d'interruptions (ça obligerait plusieurs instructions en cours à se terminer avant de lancer l'interruption)... Au vue de la description de la page Wikipedia, je me demande si le Z80 est un processeur RISC ou CISC ? (il n'y a pas de jeux d'instructio... Je vois sur l'aticle Wikipedia que le Z80 est quand même un sacré processeur et qu'il a 16 broches pour l'adressage. Il a aussi et surtout, des instruction de transferts de bloc mémoire (tout comme le 6309 et les 68k), ce qui manque au Thomson par exemple. Et je me demande alors pourquoi l'Asmtrad avec un tel équipement était evndu moins cher que le Thomson ?.

On peut parler aussi de la finesse de gravure du 6809 est seulement de 5000 nm max (9000 transistors) contre 8000 (3500 transistors max) au 6502 et 5000nm pour leZ80. Au global, je pense que le meilleur était quand même le Z80 (même à fréquence d'horloge égales) du fait des nombreux registres, de l'architecture RISC (pas pris en compte dans le calcul des MIPS ?) des instruction de déplacement de bloc, mais le motorola a l'instruction MUL, et semble plus adapté pour les système multitaches (OS-9). Avoir une instruction MUL en 11 cycle alors que la même instruction optimisée en assembleur avec une boucle par bit, prendrait au moins 32 cycles...

Mais sans doute que le 6309 les dépassent tous en mode natif. Pas simple de se faire une opinion.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 08 Jan 2021, 22:35 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
J'ai l'impression, avec tes propos, que tu te lances sur un projet, plus avec tes acquis qu'avec ton expérience de la machine...


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Mar 2021, 09:31 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
jasz a écrit:
J'ai l'impression, avec tes propos, que tu te lances sur un projet, plus avec tes acquis qu'avec ton expérience de la machine...


:lol: :tourne:


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Mar 2021, 23:40 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Mul est très bien, mais on ne l'utilise pas tant que cela.

Ce qu'il nous manque c'est l'arithmétique rapide sur 2 registres. On est obligé de passer par la mémoire (STA ,-S et ADDB ,S+) ce qui coûte 12 cycles au lieu de 2. Le transfert de A dans B coute 6 cycles alors qu'il devrait se faire en 2 cycles (c'est du registre à registre). Le calcul de A=B+2 est super lent (TFR A,B=6cycles + ADDB #2 = 8 cycles). Ces manips entre registres 8 bits sont tellement lentes que les manips équivalentes avec des registres 16 bits (LEAY D,X pour Y=X+D ou LEAY 2,X pour Y=X+2 ou LEAY ,X pour Y=X) sont plus rapides! Par contre on a pas de quoi faire Y=-X ni A=-B ce qui serait très pratique parfois.

Pour la culture générale, les machines qui n'ont pas de MUL s'en sortent quand même très efficacement en remarquant que ((A+B)² - (A-B)²)/4 = A*B. C'est à dire que si on a une table pré-calculée T[x] = int((x/2.0)²) soit 512 octets pour une multiplication 8x8 = 16bits (signée qui plus est), on réalise le produit en 2 accès à la table et 3 opérations arithmétiques simples: A*B = T[A+B] - T[A-B]. C'est ce que j'ai utilisé dans PiMiTV pour faire une multiplication 12*12 = 24 bits. C'est super rapide. Il faudra que j'utilise ca à un moment pour faire un Mandelbrot super rapide sur Thomson à l'occasion.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Mar 2021, 11:22 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Mul est très bien, mais on ne l'utilise pas tant que cela.

Ce qu'il nous manque c'est l'arithmétique rapide sur 2 registres. On est obligé de passer par la mémoire (STA ,-S et ADDB ,S+) ce qui coûte 12 cycles au lieu de 2. Le transfert de A dans B coute 6 cycles alors qu'il devrait se faire en 2 cycles (c'est du registre à registre). Le calcul de A=B+2 est super lent (TFR A,B=6cycles + ADDB #2 = 8 cycles). Ces manips entre registres 8 bits sont tellement lentes que les manips équivalentes avec des registres 16 bits (LEAY D,X pour Y=X+D ou LEAY 2,X pour Y=X+2 ou LEAY ,X pour Y=X) sont plus rapides! Par contre on a pas de quoi faire Y=-X ni A=-B ce qui serait très pratique parfois.

Pour la culture générale, les machines qui n'ont pas de MUL s'en sortent quand même très efficacement en remarquant que ((A+B)² - (A-B)²)/4 = A*B. C'est à dire que si on a une table pré-calculée T[x] = int((x/2.0)²) soit 512 octets pour une multiplication 8x8 = 16bits (signée qui plus est), on réalise le produit en 2 accès à la table et 3 opérations arithmétiques simples: A*B = T[A+B] - T[A-B]. C'est ce que j'ai utilisé dans PiMiTV pour faire une multiplication 12*12 = 24 bits. C'est super rapide. Il faudra que j'utilise ca à un moment pour faire un Mandelbrot super rapide sur Thomson à l'occasion.


Mouai, j'avais tenté de réfléchir à une matrice avec les digit (0-f) pour mon prochain cours... C'est à dire créer une matrice où on aurait 16x16 et les résultats sur Digit1Digit0. Parce que de toute façon, les résultats par couples de digits sont constant. Ca peut même n'utiliser que 128 octets à la rigueur. Mais le hic est que sur le diguit de poid fort, on est obligé de décaler de 4 pxl à droite...

Remarques:
- l'instruction MUL ne prend que 11 cycles. Combien prend ta routine (en dehors de LDA et LDB)? (et d'ailleurs je me demande comment le MUL est codé dans le 6809)
- Il faut accéder à ladite Matrice qui n'est forcément pas en accès direct (après avoir chargé A et B)
- ca utilise 512 octets pour une multiplication 8 bits... Alors j'imagine pour une multiplication 16 bits, il faudrait 8 milliards d'octets dédié? (ou alors en considérant que l'on travaille octet par octet)... Ta méthode est très bien sans doute pour du 8x8 mais au delà ?
- Je reste sur la méthode globale avec les décalage de bits, qui me parait la plus universelle et rapide pour les multiplication et division entières
- le 6309 permet d'avoir les manque que tu évoque (transfert de régistres, régistres indépendant). Le MUL (16x16) et DIV (32/16) du 6309 prend environ 43 cycles.
- Pour le div ?

Yoan Riou a déjà fait des fractales avec le Thomson en l'optimisant à fond (en démo), http://dcmoto.free.fr/programmes/voxels/index.html


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Mar 2021, 13:12 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
La table contient les carrés des nombres à multiplier, Si les nombres sont sur 8 bits, la table contient 254 valeurs (abs(A+B) vaut 254 au max avec A/B signés sur 8 bits) et chaque valeur fait 2 octets (carré de 8bits). Occupation mémoire 2*254 octets. Avec du 16 bits cela nous ferait 65534*4 .. 128 ko .. trop gros pour thomson mais impec pour 68000 où le mul est très lent.

A noter que c'est une multiplication signée, chose que le 6809 n'a pas. Il nous faut ajouter du code autour, ce qui nous fait allégrement dépasser les 11 cycles au total:
Code:
sMUL8
   STA  ,-S ; 6
   BGE  sM1 ; 3
   NEGA     ; 2
sM1
   TSTB     ; 2
   BGE  sM2 ; 3
   COM  ,S  ; 6
   NEGB     ; 2
sM2
   MUL      ; 11
   TST  ,S+ ; 8
   BGE  sM3 ; 3
   NEGA     ; 2
   NEGB     ; 2
   SBCA #0  ; 2
sM3
   RTS      ; 5 => total = 57 cycles

Le meilleur code 6502 (C64, ORIC) fait une multiplication (signée) 8x8->16 bits entre 47 et 51 cycles avec un table précalculée de 2ko: https://codebase64.org/doku.php?id=base ... iplication

Comme quoi, même sans MUL, il y a moyen d'être rapide.

D'ailleurs en lisant >>ceci<<, on comprends que pour multiplier x*y en signé revient à multiplier x*y en non-signé, et soustraire x de la partie haute si y<0, et soustraire y si x<0. Il y a moyen de gagner quelques cycles avec cela, mais la routine n'est plus en temps symétrique (x*y est parfois plus rapide que y*x)
Code:
sMUL8
    TSTA        ; 2
    BGE  sM1    ; 3
    STB  ,-S    ; 6
    BGE  sM2    ; 3
    STA  ,-S    ; 6
    MUL         ; 11
    SUBA ,S+    ; 6
    SUBA ,S+    ; 6
    RTS         ; 5 => total 48

sM1 TSTB        ; 2
    BGE  sM3    ; 3
    STA  ,-S    ; 6

sM2 MUL         ; 11
    SUBA ,S+    ; 6   
    RTS         ; 5 => total 36 ou 38

sM3 MUL         ; 11
    RTS         ; 5 => total 26 
Le temps minimum est doublé, et le maximum est à peine plus court. Si quelqu'un veut tenter le challenge, ca serait intéressant de voir si on peut faire mieux. :voyons:

(EDIT) J'arrive à un tout petit peut mieux au pire, mais beaucoup moins bon dans le cas du produit de deux nombres entre 0 et 127
Code:
sMUL8
    STD  ,--S   ; 7
    BGE  sM1    ; 3
    TSTB        ; 2
    BGE  sM2    ; 3
    MUL         ; 11
    SUBA ,S+    ; 6
    SUBA ,S+    ; 6
    RTS         ; 5 => 43
   
sM2
    MUL         ; 11
    SUBA  1,S   ; 5
    LEAS  2,S   ; 5
    RTS         ; 5 => 41

sM1 TSTB        ; 2
    BGE  sM3    ; 3
    MUL         ; 11
    SUBA  ,S++  ; 7
    RTS         ; 5 => 38

sM3
    MUL         ; 11
    LEAS  2,S   ; 5
    RTS         ; 5 => 36
Ca reste quand même entre 3x et 4x la vitesse du MUL non signé.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 168 messages ]  Aller à la page Précédente  1 ... 8, 9, 10, 11, 12  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 34 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com