Re: LE BLITTER SUR ATARI ST

[youki]

ouais, bon Bio-Challenge, c'est pas un super jeu je trouve.  A l'epoque j'avais été décu.

Apres oui les couleurs...    si je pense qu'il devait changait de palette toute les X lignes , ducoup tu avais des bandes d'ecran ou tu pouvais avoir toujours que 16 couleurs, mais tu avais 16 couleurs par bandes.. donc tu pouvais avoir a l'ecran , plus de 16 couleurs... mais tu ajouter des contraintres.

[drfloyd]

ATARI avait décidé à la base avec le ST de s'orienter en concurrent du Mac sur le marché dit "pro" (on dira plutot "sérieux")... tout en gardant des ordi 8bit pour le videoludique (XE). D'ailleurs a sa présentation en 1985 PERSONNE n'imginait pouvoir s'en acheter un un jour parmi le public vidéoludique.

Mais avec la chute dingue des prix, et le non succès US, il s'est vite transformé en ordinateur vidéoludique malgré lui... connaissant un bon succès en Europe.

Il etait alors un peu tard pour ATARI de modifier sa machine... Il etait peut etre encore temps de sortir un "STE" en 1987 mais je crois qu'ils n'étaient pas prêt, ca allait trop vite... et l'Amiga 500 n'etait pas encore la... ils ont choisi de rester sur le modele de base, voyant qu'au final les jeux etaient quand meme pas mal (ce qui était vrai, en 87 les Dungeon Master, Morteville Manor, Flight Sim 2... revolutionnaient le jeu vidéo à la maison)

On le sait quand des jeux commencent à connaitre du succès sur une machine, les evolutions de hardware ne servent souvent plus à grand chose car les editeurs ne prennent aucun risque et sortent tout pour la machine de base.

[cosmos99]

Il aurait fallut des bus d'extension comme sur Amiga , l'extension RAM a pu s'imposer comme ça , domage(pour le STF)....

[Jacques Atari]

Ce topic est sans doute l'un des plus pointus que je n'ai jamais lu. On a des bêtes du code qui savent de quoi elles parlent. Très impressionnant.

[youki]

Ce topic est sans doute l'un des plus pointus que je n'ai jamais lu. On a des bêtes du code qui savent de quoi elles parlent. Très impressionnant.

Ca c'est tres relatif.

Moins tu en connais dans un domaine, plus tu peux etre impressionné par quelqu'un qui y connait pas grand chose mais juste un peu plus que toi

[Neotenien]

l'avantage du blitter aussi c'est le gain de mémoire, car faire aussi rapide au 68000 ça demande soit du préshifting, soit des routines généré, et tout ça prend beaucoup de mémoire multiplié par le nombre de sprites/tiles a afficher.

et le blitter sur falcon, il dépote plus que le 030 ?
j'ai pu récuperer un falcon a nouveau et je vais bientôt faire quelques test au blitter pour un projet de portage sur falcon stock, ça va optimiser sec pour essayer de faire un truc propre =)

en tout cas j'ai télécharger super zazai da, j'ai hate de tester cet impressionnante chose

Je ne sais pas encore comment le ST fait pour des copies de mémoires mais sur les Thomson TO8 et MO6, vu que ça marche par blocs de 16kO (ya 14 ou 30 blocs donnat 256 ou 512 kO) et que la RAM logique est gérée sur 64 kO, le Gate Array mode page, permet, par exemple, d'allouer aux 16 premiers kO par exemple,, le bloc à copier et à l'adresse $A000 le bloc de destination.

[Neotenien]

Le soucis, c'est que l'architecture du Falcon n'est malheureusement qu'un STE avec un 68030 à 16Mhz 

Ça c'est faux.
Si c'était le cas, le Falcon n'aurait qu'une puissance de 5.76 MIPS or il développe une puissance de 21.76 MIPS!
Le Falcon est un ordinateur Bi-processeur, pas le STf/e, ce qui fait déjà une grosse différence. 
On ne résume pas l'architecture d'un micro seulement à son bus CPU/Mémoire, surtout quand il en a plusieurs différents....

Bonjour

Heu pardon mais pour avoir fait des test sur POV (Persistance of vision) entre un Atari Falcon 030 et copro et un PC 68030 à 32 MHz, cette assertion ets ARCHI fausse!!

Sur les PC pour le même script POV, le PC était 5 fois plus rapide à minima, parce que ça utilisait à fond la RAM.

Les accès RAM des Ataroi Falcon était LE GROS point faible de la machine qui ralentissaient considérablement la machine. D'ailleurs, quand on voit les différent BENCHMARK entre ST RAM et TT Ram, la différence est flagrante (à processeur égale, entre TT et Falcon c'est flagrant)

[Neotenien]

Bonjour à tous

J'ai eu un Atari Falcon 030 mais il est en panne depuis 2006

J'ai une question : quel est le nombre de cycles d'horloge que met le blitter par octet copié ? A quelle fréquence ? (celle du 68000 ?) lL'hitachi 6309 (un 8-16-32 bits) met 3 cycle par octet.

Je soulève quelques points:
- Le Blitter sert à copier des blocks de ram (pas forcément à la file mais ça peut être aussi des "tableaux en 2D" au sein de la RAM) d'une one vers une autre. Il permet aissi d'autre opération sur les pixel copiés comme transparence sur bit (Not and OR), décalage etc...
- les 68000 sont tous les mêmes que ça soit sur Amiga ou sur ST. Un 68000 à 8 MHz sur Atari ST sera effectivement 12% plus rapide que sur Amiga (7 MHz) pour l'ensemble du processeur.
- Le temps de copie dépend du nombre d'octets à copier! L'Amiga ayant dans certains mode vidéo, plus d'Octets à copier (65 kO) que sur ST (32 kO), il est évident que le Blitter mettra 2 fois plus de temps sur Amiga que sur ST dans ce cas là
- Le Blitter n'a aucune fonction d'opération arithmétique (opérations de bases +, -, * et /) c'est un coprocesseur de copie de ram avec certaines opérations  "boléennes"
- Pour la copie en blocs de RAM linéaire, sur Motorola 6809 on utilise la technique du "Stack Blasting" ! ca consiste à utiliser les instruction d'empilement et de dépilement pour faire cette copie. Ca permet de multiplier jusqu'à 3 fois la vitesse de copie de RAM... Avez vous déjà utilisé cette technique sur 68000 ?
- Pour ce qui est de la vitesse des Falcon, malheureusmeent, j'ai constaté à de multiple reprises que la ST Ram des Falcon était un énorme problème pour tirer profit des 68030 et DSP, notamment pour le RayTracing (POV). à titre de comparaison l'utilisation de scripts POV sur un PC 80386 à 25 MHz mettait 5 fois moins de temps que sur Atari Falcon 38030 à 16 MHz. C'est un fait.

[Jacques Atari]

PETITE MUSIQUE

On demande monsieur Templeton au rayon blitter. Je répète. On demande monsieur Templeton au rayon blitter.

PETITE MUSIQUE

[tophe38]

Le blitter fait des opérations de copies avec quelques opérations de masquage, qui sont très utile pour les sprites (par exemple). C'est bien plus qu'un simple copy de mémoire. Comme tout chip dédié, il travaille de son coté, quand il peut accéder au bus (comme tout chip DMA). Et bien sur, bien plus rapidement que le CPU. Dans le cas de copie mémoire massive, le 68000 propose le Movem.
Je n'ai plus les infos exacts (cela remonte à quelques décennies maintenant), mais il travail de façon bien plus efficace que le CPU.
https://info-coach.fr/atari/documents/_datasheets/BLITTER.TXT

Quand a POV sur Falcon, je doute qu'il utilise le DSP, et c'est une application qui tire pleinement profit des copro arithmétiques (vu qu'il travaille en virgule flottante).

[Templeton]

PETITE MUSIQUE

On demande monsieur Templeton au rayon blitter. Je répète. On demande monsieur Templeton au rayon blitter.

PETITE MUSIQUE

LOL

J'ai eu un Atari Falcon 030 mais il est en panne depuis 2006

J'ai une question : quel est le nombre de cycles d'horloge que met le blitter par octet copié ? A quelle fréquence ? (celle du 68000 ?) lL'hitachi 6309 (un 8-16-32 bits) met 3 cycle par octet.

Le Blitter du Falcon est cadencé à 16 MHz (un Bit permet de le configurer à  8MHz comme sur st) et il est interfacé sur la RAM via un bus 16 bit cadencé lui aussi 16 MHz.

Le Blitter ne transfer pas des octets mais des mots.

Le nombre de cycle dépend de plusieurs paramètres:

- Le type d'opération logique.
- Quelle RAM utilisée ? ST-RAM ou RAM Halftone ?
- Les opérations combinatoires entre ces 2 types de mémoires.

Dans le cas le plus favorable, c'est 4 cycles d'horloges et dans les cas les plus lent, 8 ou 12 cycles.

A noter que la petite mémoire dans le Blitter Atari est sans "wait-state", donc une combinaison avec des datas dans celle-ci est 100 % gratuite.


Concernant tes comparaisons de calculs en raytracing, tu semble un peu confus dans ton esprit.
Tu nous parle d'un PC 68030 à 32 MHz 5 fois plus rapide (SIC!), puis quelques lignes plus bas, ton PC Motorola transitionne en PC Intel 80386 à 25 MHz toujours 5 fois plus rapide! 

Comme l'a fait remarqué tophe38, il n' ya pas de version de P.O.V qui utilise le DSP du Falcon 030.

Ensuite quel type de comparaison as tu fais ?

Avec ou sans copro arithmétique ?
A quelle fréquence était cadencé ces copros ?
Le PC était de type SX ou DX ?

Tu as des benchmarks P.O.V  facilement trouvable sur le NET qui comparent un très grand nombre de machine (même avec des Falcon030 équipés de cartes accélératrices différentes).
Tu verras qu'au pire, sans le DSP, le Falcon030 n'est même pas 2 fois plus lent qu'un PC 386 à même fréquence 
Et la team POV ne s'occupait pas de la plateforme Atari, c'était un programme pas pensé 68k, il faudrait partir en plus sur une base identique (meme compilo optimisé pour chaque plateforme) pour avoir des chiffres vraiment équitables.

[Neotenien]

Salut

Je ne me souviens plus de la config exacte des PC qu'il y avait au centre social où j'étais objecteur de conscience... Mais je pense que c'était des 80386 à 32 MHz (ou peut être des 80486 à 25 MHz ??). Et pour le même script, un de ceux fournis de base, le Falcon mettait plus de 4' et le PC moins d'une minute (je crois même que l'écart était plus conséquent que celà). C'était aux alentours des années 1995/2000. J'avais utilisé la version avec copro 68830 à 32 MHz. Et ça m'avait mis hors de moi à l'époque, parce qu'il était dit que les Motorola étaient 20 à 30% plus rapide que leur équivalents PC (68030<=>80386 etc).et plus tard j'ai appris que le facteur limitant était l'accès avec la ST Ram et que POV utilisait bcp d'échanges de RAM. Le Falcon, à cause de cette ST Ram perdait beaucoup en performance. Oui peut-être que si POV avait été réécrit pour le 68030 ça aurait été largement optimisé (notamment en utilisant la RAM cache)...

Sinon 4 à 12 cycles par "word" pour le blitter, ouai c'est vraiment bien! En ce moment je programme un peu sur le 6309 d'Hitachi en émulation sur les Thomson MOTO et lui fait du 3 cycles par octet copié (donc 6 cycle par "word"). C'est par l'instruction TFM qui était déjà une sorte de Blitter avant l'heure (l'Hitachi 6309 est sorti en 1982). Et la limitation des cycles est due aux accès RAM.C'est sûr que s'il y avait ce genre de mécanisme pour les ordi 8 bits... Mais hélas c'est impossible pour ces machines parce que malheureusement, pour les basses fréquences qu'ils avaient (2 MHZ), un cycle était utilisé pour le processeur et un autre pour le rafraichissement mémoire (enfin c'est ce que j'ai compris d'après ce que m'a raconté Sam Devulder).

L'Hitachi 6309 était quand même un sacré bon proc 8 bits!! L'instruction "TFM" (donc une sorte de blitter Light), les muiltiplication/division 16/32 bits entre 25 et 35 cycles d'horloge... Et les opérations internes entre régistres...

Dernier point, dans mon message où je récapitule tous les points, j'avais indiqué que, sur les Thomson 8 bits avec le Motorola 6809, on utilise la technique du "Stack Blasting" qui permet de multiplier par 2 voire par 3, la copie de blocs RAM (ce qui permet de faire des scrolling relativement correct de plein écran jusqu'à 10 img/s pour 16kO de RAM Video... Cette technique permet de copier coller 10 octets en 40 cycles (4 cycles par octets). Et ceci gràce à l'instruction pile des Motorola. On n'ets pas aux 3 cycles par octet avec l'instruction TFM du 6309 mais on s'en rapproche!
Evidemment il est possible d'utiliser cette technique aussi por les 68k. POur les ST qui n'auraient pas de Blitter ça peut servir.

[oiseau de proie]

L'Hitachi 6309 était quand même un sacré bon proc 8 bits!! L'instruction "TFM" (donc une sorte de blitter Light), les muiltiplication/division 16/32 bits entre 25 et 35 cycles d'horloge... Et les opérations internes entre régistres...

Dernier point, dans mon message où je récapitule tous les points, j'avais indiqué que, sur les Thomson 8 bits avec le Motorola 6809, on utilise la technique du "Stack Blasting" qui permet de multiplier par 2 voire par 3, la copie de blocs RAM (ce qui permet de faire des scrolling relativement correct de plein écran jusqu'à 10 img/s pour 16kO de RAM Video... Cette technique permet de copier coller 10 octets en 40 cycles (4 cycles par octets). Et ceci gràce à l'instruction pile des Motorola. On n'ets pas aux 3 cycles par octet avec l'instruction TFM du 6309 mais on s'en rapproche!
Evidemment il est possible d'utiliser cette technique aussi por les 68k. POur les ST qui n'auraient pas de Blitter ça peut servir.

Le truc amusant c'est que le Falcon (et ses prédécesseurs) ont aussi un Hitachi 630x; ceux qui s'amusaient à coder avec disaient que le ST était une machine bi-processeur et d'autres que c'était un ordinateur dans l'ordinateur (vu qu'il avait sa propre ram/rom, entrés sorties, etc.) !!!

[touko]

J'ai une question : quel est le nombre de cycles d'horloge que met le blitter par octet copié ? A quelle fréquence ? (celle du 68000 ?) lL'hitachi 6309 (un 8-16-32 bits) met 3 cycle par octet.

3 cycles/octet c'est  , pour un CPU 8 bits , je pensais pas que ce CPU pouvait faire aussi bien, ou que même un CPU 8 bits pouvait (sur un 68000, on doit être à quoi ? 4.2/4.5 cycles/octet) .
j'ai vu qu'il avait 4 instructions de transfert de bloc, les perfs sont bien meilleures que le 65c816 plus récent(qui est à 7) .

PS: En plus les instructions de copie sont interruptibles, franchement sacré CPU . 

[Neotenien]

J'ai une question : quel est le nombre de cycles d'horloge que met le blitter par octet copié ? A quelle fréquence ? (celle du 68000 ?) lL'hitachi 6309 (un 8-16-32 bits) met 3 cycle par octet.

3 cycles/octet c'est  , pour un CPU 8 bits , je pensais pas que ce CPU pouvait faire aussi bien, ou que même un CPU 8 bits pouvait (sur un 68000, on doit être à quoi ? 4.2/4.5 cycles/octet) .
j'ai vu qu'il avait 4 instructions de transfert de bloc, les perfs sont bien meilleures que le 65c816 plus récent(qui est à 7) .

PS: En plus les instructions de copie sont interruptibles, franchement sacré CPU . 

Oui c'est un CPU du tonnerre que j'ai testé récemment avec l'émulateur DC Moto dans cette vidéo (le 6309 est en 2ème partie de vidéo et encore c'est pas optimisé à fond, seul le scrolling vertical par pixel utilise à fond le TFM (c'est à dire copie d'un gros bloc d'octet, genre 7.5 kO d'un coup). Alors c'est 3 octets par octet + les 6 cycles initiaux. Dans la communauté Thomson, on fait des trucs autoir du 6309 depuisq uelques années... QUelqu'un est en train d'adapter NitroS9 (des TRS COco 3) sur les TO9 et MO5 avec le 6309.
Certains TRS Coco 3 ont un 6309 à 1.79 MHz en remplacement du 6809.
Sinon, comme je 'lai évoqué, la technique du "Stack Blaster" (utilisant les instructions de pile du 6809 voire 68k) peut évetuellement permettre une copie de bloc de RAM assez rapide (mais on reste à 75% de la vitesse du 6309 grand max).


Le 6309 a aussi et surtout des instruction de division et multiplication de 16<=>32 bis se fiasant entre 25 et 35 cycles d'horloge:

[Neotenien]

Ah bon ? Le ST etc ont un 6309 ? Et il sert à quoi ? de copro ?

Et l'Amiga en a-t-il un ?

Il ne me semble pas avoir vu d'Unités dans Pure Pascal 1.1 parlant de ça (ceci étant je 'nai pas encore tout traduit dans mon site web consacré à Pure Pascal).

[rocky007]

6309 ?  il y a bien un 6301 qui s'occupe de la gestion clavier
de mémoire on pouvait même le détourner et l'utiliser comme copro...

[Copper]

L'Amiga a un 6500/1 basé sur un 6502 pour la gestion du clavier

[Neotenien]

6309 ?  il y a bien un 6301 qui s'occupe de la gestion clavier
de mémoire on pouvait même le détourner et l'utiliser comme copro...

Oui c'est juste un copro comme il y en a dans les Thomson MOTO (pour la getsion de D7, clavier etc), mais ça n'est pas un microcontroleur comme le 6309!

En fait dans les motorola 68xx, ya eu les microprovcesseur (680x) et d'autre, coimme le 6845, qui était chargé d'autres taches (le 6845 sert de controleur graphique en quelque sorte, j'ai récupéré ya peu, un document qui listaitt TOUS les composant 8 bits de motorola (68xx)

Je ne suis pas sûr que ces coprocesseur là puisse vriament servir de microprocesseur.... Ca suppose qu'il y ait des jeu d'instruction de tuype logique, arithmetique, de copie de et vers la RAM etc...

[rocky007]

Plpourtant je me souviens d’un article dans ST MAG qui en parlait , je vais fouiller ça un peu

[rocky007]