Re: GUERRE ST-AMIGA, FIGHT ! (Mauvaise foi assurée)

[Zarnal]

D'ailleurs, il faudra m'expliquer ceci, les chiffres ne sont pas les mêmes puisqu'ils parlent ici de bobs en 64*64 en basse et moyenne résolution. C'est le tableau 2 qui nous intéresse (et l'A2000) :

http://obligement.free.fr/gfx2/amiga1200_performances.jpg

Alors après, quid du protocole ?

[babsimov]

Et celui de l'Amiga ne bloque pas le processeur,

Rohh mais on t'a déjà expliqué que c'était faux plusieurs fois (même touko). Le Blitter de l'Amiga bloque le processeur comme celui du ST.

Le Blitter Amiga qui travaille dans son coin pendant que le 68000 fait ses calculs est une légende créé involontairement par les journalistes de l'époque! 
Ces derniers pensaient que l'Amiga était multitâche parce-que tous ses customs chips fonctionnaient en parallèle...  ce qui est loin d'être le cas! C'est l'O.S qui permet à l'Amiga d'être multitâche pas son Hardware.
Bref, sur Amiga (comme sur Atari) le Blitter et le 68000 partage les mêmes cycles et donc ne peuvent pas travailler simultanément, et ce n'est pas l'ajout de Fast qui va corriger totalement ce problème (Ça accélère juste les performances en amont).

Par contre le BLITTER de l'Amiga est mieux interfacé, car il rend la main plus vite. 

Bref ! Quand l'un fonctionne, l'autre est stoppé, c'est systématique ! 

Si tu regardes le contenu du registre DMACON sur Amiga, tu t'apercevras que le Bit numéro 10 permet de définir la priorité entre le 68000 et le Blitter.
Quand le Blitter a la priorité, le CPU va s'arrêter au prochain accès aux registres ram / custom de la puce, quand au bit numéro 14 (Appelé BBUZY) il permet de savoir si le Blitter travaille, ça peut être utile pour éviter de gaspiller des cycles si le cpu se tourne les pouces, car il va voler des cycles de bus pour rien en testant le BBUSY pour voir si il peut prendre la main.
Seulement il y a un problème avec ce BIT car il y a un Bug Hard dans Agnus qui fait qu'il ne fonctionne pas toujours. Il y a plusieurs Bugs Hardware sur Amiga, certains ont été corrigés au fil des versions Amiga (celui-ci par exemple), d'autres jamais!
Les bugs Hardwares et OS ne sont pas une exclusivité Atari hein !

La plus-parts des journalistes à l'époque n'étaient pas des programmeurs, on peut donc les excuser, d'autant plus que cette légende du Blitter// est entretenue par de nombreux utilisateurs de l'Amiga qui ne sont pas eux aussi programmeurs comme Dlfrsilver par exemple.

Si tu décides un jour de te lancer dans la programmation Amiga, je te conseilles de suivre les excellents cours en français de FLEURET (un amigafan pure jus) parues en 87. La première chose qu'il dit après avoir présenté le Blitter, est que celui-ci partage avec le 68000 les mêmes cycles et donc qu'ils ne peuvent travailler simultanément ensemble. J'avais été choqué à l'époque quand j'avais lu ça.... ahhh les journalistes...

Comme je l'expliquais, c'était un peu de la provocation. 
Mais, je reconnais que je ne suis pas assez expert technique et probablement mal interprété les propos de Stapha92. Il expliquait que justement la gestion des cycles sur Amiga étaient mieux pensé que sur ST et que de ce fait le blitter du ST bloquait le 68000 (c'est ce que j'avais cru comprendre à l'époque). 
En tout cas merci pour ces précisions. C'est dommage que tu ne sois pas intervenu dans le débat à ce moment là, je pense qu'un échange contradictoire entre toi et Stapha92 aurait été des plus instructif et intéressant pour tous les lecteurs.

Petites questions, au sujet des bugs hardware qui n'ont jamais été corrigés dans l'Amiga, je serais curieux que tu puisses, si tu en as le temps, en faire une liste. C'est une information qu'on trouve rarement. Ca m'intéresserait de savoir ce que Commodore à jugé inutile de corriger. 
Il me semble que Dave Haynie avait dit dans une interview qu'il avait identifié un bug matériel dans l'AGA qu'il avait corrigé logiciellement pour éviter une révision supplémentaire avant la sortie. Peut être que les bugs matériels dont tu parles ont fait l'objet d'un correctif logiciel ?

[Templeton]

Si tu décides un jour de te lancer dans la programmation Amiga, je te conseilles de suivre les excellents cours en français de FLEURET (un amigafan pure jus) parues en 87.

Tu aurais des liens ?

Je ne sais pas ou on peut trouver les cours originaux parues en 87/88. 
Mais ce dont je suis certain, c'est qu'ils ont été publiés (tous?) un peu plus tard dans le magazine Génération4 en 1989 (plusieurs numéros). Tu trouveras les canards sur Abandonware Magazine, les cours sont dans les cahiers programmation Amiga situés dans les dernières pages.

D'ailleurs, il faudra m'expliquer ceci, les chiffres ne sont pas les mêmes puisqu'ils parlent ici de bobs en 64*64 en basse et moyenne résolution. C'est le tableau 2 qui nous intéresse (et l'A2000) :

http://obligement.free.fr/gfx2/amiga1200_performances.jpg

Alors après, quid du protocole ?

Hé bien je vais t'expliquer mon gros lapin.

Un BOB n'est pas forcement un sprite software. Un vrai Sprite (qu'il soit Hard ou Soft) doit masquer les autres sprites environnant et le décor, or ici il s'agit apparemment d'un simple transfert de bloc 64*64 sans masquage.
On est dans un cas particulier qui n'a comme objectif que de tromper le lecteur, en lui faisant croire qu'il a une borne d'arcade entre les mains.
Bref, c'est un benchmark sans intérêt pour un jeu... 

Imagine, 39 BOB de 64*64 en 16 couleurs sur Amiga 500 c'est l'équivalent (un peu moins en réalité)... de 156 Sprites Soft de 32*32 16 couleurs ! 
Ça laisse rêveur quand on sait que la Mégadrive affiche 80 sprites de 32*32 ! 


Le protocole BOB ST/AMIGA que tu vois dans les deux vidéos propose le cas le plus courant et le plus défavorable dans un jeu micro (Masquage total + restitution du décor).
Sachant que tu dois retirer à ce résultat entre 2 et 5 BOB si tu rajoutes des routines de scrolling, des IA, des collisions, la gestion du son, etc... 

Dans la vidéo Amiga, le codeur affiche 13 BOB de 32*32 16c, ce qui n'est pas normal car d'après les calculs, le Blitter Amiga était sensé afficher presque 15 BOB, soit seulement 2 de moins que les 17 BOB du ST. 

Petites questions, au sujet des bugs hardware qui n'ont jamais été corrigés dans l'Amiga, je serais curieux que tu puisses, si tu en as le temps, en faire une liste. C'est une information qu'on trouve rarement. 

Es tu fou ?
Lister tous les bugs hardware de l'Amiga, c'est peindre une cible sur mon front ! Il y a des sacrés zigotos dans la communauté Amiga, je ne veux pas devenir l'homme à abattre ! 

Bon je peux quand même t'aiguiller sur le bug Hard le plus célèbre qui n'a pas été corrigé. 
Charge Battle Squadron avec WinUAE, déclenche une NOVA BOMBE, fait une pause et regarde bien les sprites hardwares.

[babsimov]

Petites questions, au sujet des bugs hardware qui n'ont jamais été corrigés dans l'Amiga, je serais curieux que tu puisses, si tu en as le temps, en faire une liste. C'est une information qu'on trouve rarement. 

Es tu fou ?
Lister tous les bugs hardware de l'Amiga, c'est peindre une cible sur mon front ! Il y a des sacrés zigotos dans la communauté Amiga, je ne veux pas devenir l'homme à abattre ! 

Il y aura surement ceux qui listeraient les bugs hardware du ST en retour 
Ca pourrait être une autre façon de relancer le débat 

Bon je peux quand même t'aiguiller sur le bug Hard le plus célèbre qui n'a pas été corrigé. 
Charge Battle Squadron avec WinUAE, déclenche une NOVA BOMBE, fait une pause et regarde bien les sprites hardwares. 

J'essaierais ça. Merci de l'info.

[Tryphon]

Si tu décides un jour de te lancer dans la programmation Amiga, je te conseilles de suivre les excellents cours en français de FLEURET (un amigafan pure jus) parues en 87.

Tu aurais des liens ?

Je ne sais pas ou on peut trouver les cours originaux parues en 87/88. 
Mais ce dont je suis certain, c'est qu'ils ont été publiés (tous?) un peu plus tard dans le magazine Génération4 en 1989 (plusieurs numéros). Tu trouveras les canards sur Abandonware Magazine, les cours sont dans les cahiers programmation Amiga situés dans les dernières pages.

Merci, je mets ça de côté...

[Alfaccc]

Il avait aussi une rubrique dans Amiga revue,c'était "Elémentaire mon cher Watson" si mes souvenirs sont bon.

[nemokantio]

Templeton, dans le protocole de test des bobs, sont ils aussi clippés ?

Et c'est quand même malheureux que le stf soit sorti sans blitter (avec juste l'emplacement) !

[dav1974]

Budget peut etre...je sais pas combien ça coutait un blitter a l’époque.

[Templeton]

Templeton, dans le protocole de test des bobs, sont ils aussi clippés ?

Je ne sais pas si la routine de clipping est intégrée, mais dans la vidéo le programmeur regarde si le BOB touche les bordures, donc il peut basculer facilement sur une autre routine avec clipping.

"Cipper" un sprite avec le Blitter c'est vraiment très facile, l’algorithme est super simple.
Horizontalement tu n'as que 4 registres à modifier et verticalement tu changes juste l'adresse ou la taille.
De toute façon, lorsque le BOB sort un peut de l'écran il prend automatiquement moins de cycles, car il perd directement un mot en largeur ou quelques lignes verticalement.

Budget peut etre...je sais pas combien ça coutait un blitter a l’époque.

Le prix du BLITTER était de 98,50 francs chez Atari France.

Il y avait aussi un article dans ST MAG qui proposait un petit montage hardware pour intégrer le Blitter sur le ST de 1985 (il fallait changer le TOS également). A l'origine, le BLITTER était prévu pour être soudé sur le 68000 (il Possède les signaux du 68000 et dans le même ordre en plus).

[Invité]

Bon ça serait bien de poster les bonnes vidéos, hein templeton 
La dernière routine qui affichait 13 bob en affiche maintenant 21 .



Petite quote de leonard sur pouet dans les coms de sa dernière démo ST (we were):

@axis: it's only CPU based. ATARI blitter is not as powerfull as AMIGA one ( and it does not work in // )

Btw I love your mandelzoom in Planet rocklobster, really, really impressive.

Ou ici :
http://atari-forum.com/viewtopic.php?f=68&t=28469&start=25

Some numbers: in general the Amiga Blitter is exactly two times faster in clock cycles for each memory operation. So the "cookie cut" method uses a total of 8 cycles. Compared to the new blitting method above this speed can only be achieved on the Atari on sprite areas where the ENDMASK is $ffff. 

Par contre ce qui est sur, c'est que le blitter ne bloque pas le CPU(sauf en mode nasty)ou si le CPU accède à de la fast pendant que le blitter accède lui à la chip,ce qui me semble n'est pas le cas sur le ST, où les 2 se partagent le même bus..

Le gros avantage du blitter du ST,c'est qu'il peut accéder à toute la RAM,et que c'est une très bonne puce, dommage qu'elle fut pas bcp utilisée au temps du STE .

Bon en réalité on s'en branle de savoir qui fait quoi maintenant, le seul truc que je remarque,c'est que la scène amiga est morte en terme de jeux .

PS: Le bug des sprites a été fixé dans l'ECS .

[TotOOntHeMooN]

Imagine, 39 BOB de 64*64 en 16 couleurs sur Amiga 500 c'est l'équivalent (un peu moins en réalité)... de 156 Sprites Soft de 32*32 16 couleurs ! 
Ça laisse rêveur quand on sait que la Mégadrive affiche 80 sprites de 32*32 ! 

La MD c'est en 60fps, pas 6.

[Templeton]

>>Bon ça serait bien de poster les bonnes vidéos, hein templeton 

Ce n'est pas moi qui a posté ces vidéos, hein Touko  
Et j'ai même précisé que l'Amiga pouvait en afficher plus.  

Et dans ta vidéo des 21 sprites, le gars triche car il utilise de la Fast ram pour une partie du traitement et a déjà copié le décor dans un Buffer (+une autre bidouille).
En plus il utilise WINUAE donc on ne sait même pas si il utilise les cycles exacts (il y a eu des mauvaises surprises récemment avec un essai de moteur de Street of Rage 2 sur Amiga, voir sur EAB).
Enfin, à l'époque, les gens comme toi et moi avaient des extensions mémoires avec de la chip ram et non de la FAST.

Avec ce protocole, le max avec le BLITTER Amiga normalement c'est 15 sprites de 32*32 4 bitplan et pas 13 ou 21.

De toute façon, même si le Blitter du ST affiche 2 sprites supplémentaire ça ne fait pas une grosse différence, et dans un cas concret, l'Amiga prend largement l'avantage si on utilise en + les 8 sprites hardwares ( 4 en mode 16 couleurs). Tu rajoutes les 2 bitplans supplémentaires qui te permet de séparer la palette en deux et éviter le masquage (mais tu divises le nombre de couleurs par 2) et la messe est dite...

Touko a écrit:
>>Petite quote de leonard:
>> Anima a écrit:

Touko a écrit:
>Par contre ce qui est sur, c'est que le blitter ne bloque pas le CPU(sauf en mode nasty)ou si le CPU accède à de la fast pendant que le blitter accède lui à la chip,ce qui me semble n'est pas le cas sur le ST, où les 2 se partagent le même bus..

Dit donc petit chenapan, quand tu vas chercher des informations pour détailler le  Blitter AMIGA, évite ATARI-FORUM et les commentaires des programmeurs ATARI qui ne maîtrisent pas l'Amiga (Anima ne code même pas dessus), mais passe plutôt par des programmeurs Amiga. 

Voila ce que dit François Fleuret (programmeur et démomaker AMIGA) à propos du Blitter page 106: "Le Blitter et le 68000 partagent les mêmes cycles et donc ne peuvent travailler simultanément (sur 512 ko)"

Quand tu n'as pas de mémoire dédié et que tu partages le même bus avec les mêmes cycles pour accéder à la même RAM, il n' y a pas de miracle... tu peux faire passer un pouce dans une narine, pas les deux hein!

De plus il n'y a pas 36 façons de lancer un transfert avec cette puce, il suffit de regarder la configuration DMACON. Avec le BIT n°10, soit le  BLITTER à la priorité sur le 68000, soit l'inverse, et le BIT 14 n'est pas la pour faire beau non plus (j'ai bien détaillé son fonctionnement), sinon quel est l'utilité de savoir si le BLITTER est occupé ? 
L'utilisation de ce registre est bien expliqué dans la documentation développeur (et jamais elle ne dit que le BLITTER tourne en parallèle d’ailleurs).

Et DMA ne veut pas dire que le 68000 peut faire ce qu'il veut pendant ce temps-là (et tu le sais très bien en tant que codeur)! Le BLITTER du ST fonctionne lui aussi en DMA, sauf que celui-ci est moins bien interfacé sur le BUS (encore un avantage du BLITTER Amiga).

>>Le gros avantage du blitter du ST,c'est qu'il peut accéder à toute la RAM,et que c'est une très bonne puce, dommage qu'elle fut pas bcp utilisée au temps du STE .

Je suis d'accord avec toi. Par contre pour moi le plus gros avantage du BLITTER ST (celui de l'Amiga en a d'autre) selon moi, c'est sa toute petite ram dédiée (sans Wait Stat) qui est une vraie seconde source ultra rapide.
Ça permet de tracer des motifs sans frais (les trames de mes polygons HD dans la Monogatari sont réalisés avec, tout comme la pluie animée dans Crash Time Plumber) ou de faire d'autre truc comme changer la palette plusieurs fois par ligne par exemple bien plus rapidement.

Avec cette ram tu peux afficher 64 couleurs indépendantes par lignes (contrairement au mode HalfBright de l'Amiga) ce que le copper ne peut pas faire non plus en Basse Déf.
Voici que ça donne sur un STe (image entrelacée):


Pas de conflits de proximité comme avec le HAM.
C'est beau la RAM HalfTone nan ?

[Invité]

C'est marrant templeton, tu cites 1 mec,donc comme ce qu'il dit t'arrange tu squizes ce que disent des mecs comme leonard(je te rappelle qu'il a codé sur les 2 machines) ou les dires de demomakers(personne n'a démenti ce fait depuis le temps), ou de docs amiga .
Donc en gros tous mentent,sauf ton démonstrateur  .. 
Rahlala , ici la mauvaise fois est aussi présente que sur le snes vs md 

Le blitter si il n'est pas en mode nasty ne bloque pas le CPU, par contre tu n'utiliseras pas le blitter à 100% ni le CPU,le blitter utilise les cycles(DMA) restants non utilisés par le CPU, mais peut lui voler des cycles si besoin .
Les 2 ne fonctionneront à 100% (et encore c'est toujours pas vrai pour le blitter) qu'avec de la fast,ce qui est impossible sur ST/STE .
Le seul moyen pour que le blitter amiga soit à 100% est de déactiver tous les DMA pour qu'il les utilise .

Par contre dire que le mec triche, ça vous dérange pas de montrer un GnG sur STE avec 4Mo de RAM 

Bon je sais que c'est de bonne guerre, de toutes façons, le meilleurs c'est le falcon 

Ps: Tu notes que j'emploie pas le mot parallèle, c'est peut être ça qui te gène, car effectivement on pourrait croire que les 2 tournent ensemble à 100% .

[Templeton]

>>Rahlala , ici la mauvaise fois est aussi présente que sur le snes vs md  

Haha mais carrément !
Egalité 1 partout !  

PS: Le bug des sprites a été fixé dans l'ECS .

Mais pas sur AGA apparemment, voila ce que dit le programmeur AMIGA Lionel Guillang (AmigaNew) :

 A noter que le plus gros point noir n'a pas été résolu : toute surcharge du bus (écran en suraffichage par exemple) entraînera encore et toujours la disparition d'un à sept sprites (snif !).

Quand je parle d'AMIGA, mes sources proviennent TOUJOURS de la communauté Amiga et pas de la communauté Atari, hein vieux grigou ! 

[Templeton]

Par contre dire que le mec triche, ça vous dérange pas de montrer un GnG sur STE avec 4Mo de RAM   

Dans ce cas la tu as raison, je considère ça aussi un peu comme de la triche.

Ps: Tu notes que j'emploie pas le mot parallèle, c'est peut être ça qui te gène, car effectivement on pourrait croire que les 2 tournent ensemble à 100% .

Voila tu as bien choisi tes mots, la je suis d'accord, c'est pour ça que j'avais précisé que le BLITTER amiga était mieux interfacé, l'échange entre les deux est mieux optimisé et permet de gratter plein de cycle. 

Finalement on est d'accord, c'est mieux que sur le Topic MEGADRIVE VS SNES du coup (prenez en de la graine les consoleux ).

[Invité]

Dans ce cas la tu as raison, je considère ça aussi un peu comme de la triche.  

C'était pour te charrier, j'aime bcp ce que fait anima(et j'aimerai que la scène amiga soit aussi prolifique que lui),et bon convertir GnG t'as pas le choix, faut de la place si tu veux un port fidèle .

[Zarnal]

Enfin, à l'époque, les gens comme toi et moi avaient des extensions mémoires avec de la chip ram et non de la FAST.


Nop, c'était de la slow, pas de la chip (sur le 500).
 




Avec cette ram tu peux afficher 64 couleurs indépendantes par lignes (contrairement au mode HalfBright de l'Amiga) ce que le copper ne peut pas faire non plus en Basse Déf.
Voici que ça donne sur un STe (image entrelacée):


Pas de conflits de proximité comme avec le HAM.
C'est beau la RAM HalfTone nan ?

Tu oublies de parler les modes Sliced sur Amiga qui arrangent bien les choses pour la proximité même en basse réso. Modes sliced pouvant être utilisés en 5bits ou HB. Bien sur tu me répondra avec raison que l'on fait la même chose sur ST. Mais pas en HR. Ni en moyenne réso.

[Invité]

Par contre faut préciser que l'appellation slow RAM sur amiga ne vient pas du fait que la carte contient de la "chip ram" et que c'est pour ça,mais du fait qu'elle n'est pas sur le bus dédié à la fast,en fait elle est sur la partie inutilisée par la chip RAM,donc impactée(mais dans une bien moindre mesure) par l'accès du chipset, contrairement à de la vraie fast .

[Zarnal]

Bon reprenons l'exemple de l'image de Templeton et passons là à la moulinette sur A500 (j'ai juste coupé en 320*200 le PNG et je l'ai passé en IFF v24bits, n'ayant pas l'originale STE cela crée des dégats à la réduction, c'est fait de façon brute), l'image originale comporte 4051 couleurs (le PNG) voyons ce que cela donne :


Ham standard comme on l'aime, bien crade et bien baveux  :





Brilliance (HAM standard, semble l'améliorer un peu) :



On remarque tout de suite les conflits générés par ce mode (les bords du halo de lumière au dessus du robot et les bords de certaines chaises)

Passons au HAM6 Sliced :



Observez les contours de la lampe au dessus de la tête du robot. Pouf, disparues les bavures.

Allons plus loin et voyons ce qu'il se passe en 5 bits (32 couleurs)  Sliced :



Aucun dither sur les images.
Ne me demandez pas d'où vient l'effet carton. Probablement d'un souci technique avec hamlabplus. J'ai le même effet carton avec du ham standard et ce programme.

[Templeton]

Tu oublies de parler les modes Sliced sur Amiga qui arrangent bien les choses pour la proximité même en basse réso. Modes sliced pouvant être utilisés en 5bits ou HB. Bien sur tu me répondra avec raison que l'on fait la même chose sur ST.  Mais pas en HR. Ni en moyenne réso.

On a ce genre de mode sur ST/e, le max c'est le HRM 2 en 704*440i.
Le résultat est moins précis que la Basse Réso forcement (47 couleurs sur une ligne 2 fois plus large), mais c'est très étonnant pour une machine qui est sensé n'afficher que 2 couleurs en 640*400 ou 4 en 640*200.
Sur un CRT le résultat est encore meilleur (overscan un peu tronquée sur emu...):



Et si l'image ne possède pas trop de teintes dominantes et prononcées, le résultat est carrément impressionnant (Avec full overscan cette fois):





Pas mal nan ? 

Passons au HAM6 Sliced :

En effet, c'est très supérieur au HAM standard et Brillance. Mais ce n'est pas aussi précis que sur STe (voir le motif de la couronne et certaines bordures) et l'algo peut causer de grosses erreurs:

5 bits (32 couleurs)  Sliced :

Effectivement là c'est vraiment beau (merci Zarnal je ne connaissais pas ce mode), on gagne encore en précision (les bordures sont presque parfaite) et on s'approche beaucoup de la version STe mais il y a toujours des erreurs (plus négligeable cependant):


En tout cas on peut afficher des images en basse def de très bonne qualité sur ces machines avec ces bidouilles, je ne pense pas que leurs concepteurs eurent imaginé un tel résultat, c'est quand même bluffant. 

[Urbinou]

Juste pour ma culture, ce ne sont pas des modes graphiques "passifs", il faut que la bécane turbine derrière, c'est bien ça ?

[Templeton]

Juste pour ma culture, ce ne sont pas des modes graphiques "passifs", il faut que la bécane turbine derrière, c'est bien ça ?

C'est bien ca.
Le ST c'est seulement 3 modes graphiques avec une palette de 512 couleurs (4096 pour le STE):

-Basse Définition 50/60Hz (320*200 en 16 couleurs par ligne)
-Moyenne résolution 50/60Hz (640*200 en 4 couleurs par ligne)
-Haute résolution en 72 hz sans entrelacement (640*400 en noir et blanc).

[Invité]

ce serait marrant pour l'exemple d'avoir la meme image affichée via tous les modes différents sur les 2 matos.

[Urbinou]

Templeton, le fait de dire par ligne implique à nouveau du process derrière

[Zarnal]

En tout cas on peut afficher des images en basse def de très bonne qualité sur ces machines avec ces bidouilles, je ne pense pas que leurs concepteurs eurent imaginé un tel résultat, c'est quand même bluffant. 

Je n'ai pas posté la version HB sliced car j'ai eu un doute par rapport au résultat. Allez je le fait :





La version Half Bright non sliced (même image 24bits en source sans dither sous hamlab) :




OCS/ECS A500 kickstart 3.1
Bluffant oui.

Ce qui est dommage c'est que ce programme ne fonctionne qu'en ham6. Exit donc le 1200.




@Urbinou


Tu ne feras pas d'anim dans ces modes spéciaux. Ils consomment.

@Templeton

L'erreur que tu as montrée en 32 couleurs sliced n'en est certainement pas une, c'est juste le bout de mon pointeur de souris que j'ai tenté de planquer.  

[babsimov]

>>Rahlala , ici la mauvaise fois est aussi présente que sur le snes vs md  

Haha mais carrément !
Egalité 1 partout !  

Ah ben non là, si en plus ceux qui on la connaissance technique induisent en erreur par mauvaise foi, là je dit non alors !  C'est pas cool 

Parce que du coup, j'avais quand même bien compris ce qu'expliquait Stapha92 avec la bonne gestion des cycles entre le chipset et l'Amiga et donc le "parallèle", dans le sens que le blitter ne bloque pas le 68000, alors que sur ST ca semble être assez souvent le cas (peut être pas à tous les coups). Shiraz Shivji l'avait même dit dans une interview que le blitter du ST faisait ça. 

PS: Le bug des sprites a été fixé dans l'ECS .

Mais pas sur AGA apparemment, voila ce que dit le programmeur AMIGA Lionel Guillang (AmigaNew) :

 A noter que le plus gros point noir n'a pas été résolu : toute surcharge du bus (écran en suraffichage par exemple) entraînera encore et toujours la disparition d'un à sept sprites (snif !).

Quand je parle d'AMIGA, mes sources proviennent TOUJOURS de la communauté Amiga et pas de la communauté Atari, hein vieux grigou !  

Ben c'est étonnant du coup. Parce que l'AGA est compatible ECS et il me semble basé dessus. Donc pour être compatible il faut avoir les mêmes réactions matériel dans le même cas non ?
Est ce à dire que le bug n'aurait pas été corrigé sur l'ECS ? T'as une source Touko pour la correction dans l'ECS ? C'est bizarre qu'un bug corrigé aurait été remis dans une version plus "moderne" du chipset ?

[dlfrsilver]

Bon, j'ai enfin reçu le dongle SCART pour mettre le cable péritel ST/STE sur mon Falcon. 

Mon Falcon fonctionne (je l'ai briqué pendant 4 heures ce cochon, tellement il était sale et terreux ! ouhhhh !!  )

Alors première impression :

* Aucun Atariste ne vient se vanter de l'immonde, que dis-je, du totalement honteux Haut Parleur interne du falcon, IMPOSSIBLE à régler par molette ! on est obligé de le couper en soft ou de le débrancher, car le son n'est pas rerouté via le dongle ! Je vais devoir acheter un cable jack 3.5mm vers RCA male pour connecter la machine à un kit d'enceinte, voir ma téloche. 

* Le cout de possession de la machine est prohibitif :

200 euros pour le Falcon
  55 euros de Gotek
  82 euros (condos alim, module NVRAM, clock buffer patch+socket)
150 euros de condos pour recapper la carte mère (acheté chez le même vendeur, soit 27 condos !)
 55 euros pour l'extension de RAM + RAM de 16mo pour passer le falcon à 14mo de ram
 
Remettre en état un 600 ou 1200 voir 500, ça coute peanuts en comparaison.

[Templeton]

L'erreur que tu as montrée en 32 couleurs sliced n'en est certainement pas une, c'est juste le bout de mon pointeur de souris que j'ai tenté de planquer.   

Haha, tu pourrais mieux faire le ménage quand même ! 

Templeton, le fait de dire par ligne implique à nouveau du process derrière

Oui bien-sur, la je présentai juste les caractéristiques techniques sans bidouille. Le changement de palette à la ligne est prévu d'origine car le MFP (la puce qui gère les interruptions entre autre) est câblée sur le shifter (le processeur vidéo) et d'autre puces. 
Le process derrière est négligeable par rapport à l'Overscan et le dépassement des 16 couleurs par ligne. 

Je n'ai pas posté la version HB sliced car j'ai eu un doute par rapport au résultat. Allez je le fait :

J'allais te demander cette option, car je voulais voir si les demi-teintes non modifiables allaient changer la luminosité entre les parties claires et sombres.
Il n'y a plus les grosses erreurs, juste quelques rares débordements. Bref, c'est encore mieux. 

Tu ne peux vraiment pas corriger "l'effet carton"? Car la couronne est vraiment floue.
Ça ne met pas en valeur ce mode et on ne peut pas avoir une comparaison précise. Le problème c'est plutôt WINUAE nan ?

* Aucun Atariste ne vient se vanter de l'immonde, que dis-je, du totalement honteux Haut Parleur interne du falcon, IMPOSSIBLE à régler par molette ! on est obligé de le couper en soft ou de le débrancher

Bah c'est une option, tu n'es pas obligé de l'utiliser. Ce Haut Parleur c'était un truc malin et sympa de la part d'Atari pour ceux qui branchaient le Falcon030 sur un moniteur VGA (pas de HP dessus à l'époque), et qui n'avaient pas un kit d'enceinte.

Concernant tout le ravalement, à part le changement obligatoire de la pile DALLAS pour la NVRAM, je ne connais aucun possesseur de Falcon030 ayant remplacé les condos sur la carte mère, ça ne fuit pas encore, contrairement aux 1200, CD32 et MEGACD par exemple. 

[Invité]

Parce que du coup, j'avais quand même bien compris ce qu'expliquait Stapha92 avec la bonne gestion des cycles entre le chipset et l'Amiga et donc le "parallèle"

Disons que le mot "parallèle" est un raccourci assez facile pour en parler .
Mais dire plutôt que le CPU n'est pas bloqué serait plus juste,le blitter va essayer de laisser des accès au bus au CPU, et cela va donc dépendre de ce que tu vas faire avec le blitter .
Bien sur cela est valable que si le CPU accède à la chip, avec de la fast le problème ne se pose plus est les 2 fonctionnent normalement et pour le coup en // .

Bah c'est une option, tu n'es pas obligé de l'utiliser. Ce Haut Parleur c'était un truc malin et sympa de la part d'Atari pour ceux qui branchaient le Falcon030 sur un moniteur VGA (pas de HP dessus à l'époque), et qui n'avaient pas un kit d'enceinte.

Je suis d'accord, c'est un faux problème si tu peux le désactiver facilement .

[TotOOntHeMooN]

Le cout de possession de la machine est prohibitif

Tien donc... Mais tu raques !  

- 200 euros pour le Falcon -> la bonne affaire
- 55 euros de Gotek -> l'arnaque, ça coute 20€ au max
- 82 euros (condos alim, module NVRAM, clock buffer patch+socket) -> idem
- 150 euros de condos pour recapper la carte mère (acheté chez le même vendeur, soit 27 condos !) -> idem
- 55 euros pour l'extension de RAM + RAM de 16mo pour passer le falcon à 14mo de ram -> normal
 

Remettre en état un 600 ou 1200 voir 500, ça coute peanuts en comparaison

Bah c'est sur, si tu payes une fortune des choses plus ou moins dispensables...
Le Gotek aurait été au même prix vu ton fournisseur et pour l'extension RAM le double.

[Invité]

150 euros de condos pour recapper la carte mère (acheté chez le même vendeur, soit 27 condos !

effectivement il doit bien se gaver le mec .

55 euros pour l'extension de RAM + RAM de 16mo pour passer le falcon à 14mo de ram ->

y a pas un souci là ??