Re: Amiga/st vs Archimede

[ArchieForEver]

Voilà un des points que tu ne met pas assez en avant, et qui fait la force de l archi, outre son cpu, ce sont ses capacités 3D .
Pour le sort oui tu peu faire des filtres sont sur archi, tout comme l amiga peut faire des musiques sur 7 voix en soft, et bien d autre choses .

Le copper et le blitter permette des choses à un amiga qui sont simplement impossible sur l archi, même si le contraire est aussi vrai dans certains cas .
La force de l'archi est dans la 3D et non la 2D .
Ensuite pour le talent des profs, pas besoin d'en avoir des million si l archi était si puissant ,on aurai déjà vu des effets impossible à faire pour les autres 16bit.

Tu me parles de la qualité du son, je te réponds sur la qualité du son.
Pour le nombre de voies (ce que tu évoques) l'Archie monte à 16 voies (voir player DigitalSymphony).

Avec si peu de programmeurs je ne pense pas comme toi : à mon avis justement on n'a pas tout vu sur cette machine.
La preuve par l'exemple : il n'y a qu'un jeu comme StarFighter3000.
Si son programmeur ne l'avait pas fait, je lirais ici que la 3D sur Archie ça s'arrête à Zarch (Virus) ...
Pour la 3D temps réel, je n'ai même pas envie d'en parler : l'Archimedes gagne haut la main.

Ce qui m'intéresse c'est de démontrer qu'en 2D, justement là où il est perçu comme faiblard, il en a en fait beaucoup sous le capot, car bien peu de 'bidouilles hard' ont été tentées.
Et même en soft, il y a encore bcp d'optimisations à réaliser (code généré, code auto modifiable, précalculs, disposition mémoire différente des datas sources pour gains de traitement).
J'ai des sources ARM pour des effets brouillards, déformations, zooms et rotations qui tournent très bien en 50 images par seconde, et il n'y a aucune de ces optimisations dedans, c'est du délire.
Comme la machine était suffisamment puissante, personne n'a décidé de suer un peu : c'est tout le contraire du programmeur ST ou Amiga qui a intérêt à être vraiment feinteux pour extraire du jus de sa petite machine limitée.

[Invité]

Il n'est pas faiblard en 2D, mais tu ne peux pas faire la même chose qu'un machine développé spécialement pour elle comme l'amiga ou les consoles .
Sur amiga outres ses copros, tout est DMA, c'est ce qui fait sa force, si en plus de la chip, tu utilise de la fast, ses perfs sont boostées .

Le jour ou on verra un shadow of the beast sur archi .
Dans les demos amiga tu as tout un tas d'effet impossible (en théorie) à faire sur un amiga, et pourtant c'est un temps réel .



Ok c'est de l'AGA, mais quand même, c'est autre chose.

[MacDeath]

Ensuite pour le talent des profs, pas besoin d'en avoir des million si l archi était si puissant ,on aurai déjà vu des effets impossible à faire pour les autres 16bit.

Pas aussi simple...
une machine puissante n'en est pas pour autant facile a programmer ou maitriser.

La Jaguar, et certaines playstations non ? (je sais plus)...

Les programmeurs de l'époque étaient limités par leur connaissances qu'ils avaient aquis sur les autres machines qui laisse souvent de mauvaises habitudes, mais aussi le fait qu'un machine n'était pas très bien documenté bien souvent (undocumented features, lol), que les accés aux info techniques n'étaient pas aisées non plus.
voire étaient simplement dépassé par l'évolution technique des machines lol... les années 90 ont prouvé que le passage systématique à la 3D était bien souvent hyper foireuse.

on ne pouvait pas simplement télécharger des pdf à l'époque. Et les codeurs gardaient jalousement leurs secrets techniques aussi.

Enfin explorer une machine soi-même ça prend du temps, temps que les ados boutonneux vraiment passionné avaient parfois, mais qu'un programmeur professionnel n'avait pas (plus).

Et puis plus une machine avait de bits, plus elle était longue a "explorer".

Quand on sait que les 8bit comme le CPC ou les Atari8bit (par exemple) ont bien mis 20ans pour être plus ou moins maitrisés... et que ça c'est surtout fait après la vie de ces machines grâce aux échanges d'info permis par internet... et fut permis aussi parceque ces machines ont réussit à vendre quelques millions d'exemplaires aussi.


Si l'Archimedes avait vendu euh... ils s'en est vendu combien d'ailleurs ?

Mais si ils en avaient vendu autant que des CPC (genre 2-3 millions) ça aurait sans doute bien changé la donne...

Ah, il y a aussi le publique visé.

les Amiga, ST et CPC ont très souvent finis entre les mains d'ados boutonneux, qui donc avaient le temps et la patience de les explorer parfois.

Les Archimedes, peu ont du vraiment finir comme "jouets"..


Et puis le problème de l'archi c'est qu'il est tellement rare qu'il a peu de chance de finir entr les mains d'un passionné lambda comme pourrait le faire un ST ou autre que l'on toruve aisément a un vide grenier.

L'amiga n'est pas une machine parfaite, ça c'est clair, mais en 2D que ce soit par rapport au st ou à l'archi, il est intouchable .

Bof, si la Megadrive avait un clavier, un lecteur de D7 et 512K (ou 1024K) de RAM... seule la palette 512 (au lieux de 4096) serait un poil faiblarde et encore...

[Invité]

Pas aussi simple...
une machine puissante n'en est pas pour autant facile a programmer ou maitriser.

Ca c'est le dogme des faignants, car machines simples, ne veut pas dire que t'en chie pas pour faire des effets quand rien ne t'aide dans le hard ..
C'est ce qui s'est passé avec la snes, les progs trop feignants (et manquant de temps aussi) pour utiliser correctement la machine perstaient sur son CPU à 3 mhz .
Quand on voit ce que donne le 6502 @ 0.967 mhz du C64, ca fait rigoler .

De toutes façons, l'amiga n'est pas réputée pour être un machine difficile à programmer, certe surement plus que le ST vu que seul le CPU est programmable, mais va dire à un prog ST de faire un scrolling fluide sur ST, il va en chier de la vaisselle cassée .

Toutes machines recelles des possibilités même les plus simples, mais celles avec des customs, en ont bien plus, car tu peux bcp plus jouer avec le hard, et surtout, garder du CPU pour avoir de meilleurs effets .Je sais que dans des jeux comme alien breed sur amiga, qui pourtant en jette, le 68000 est programmé avec les pied .

Sinon je programme sur le CPU de la nec qui est un peu l'ancêtre de l'arm, et franchement ces CPU sont géniaux à programmer, mais ne plaisent pas aux fans des Z80 et autres 68000, qui ne savent rien faire sans 60.000 registres .

[ArchieForEver]

En attendant rien d impressionnant dans les démos que tu montre .

On fait bien mieux sur amiga et même sur st .
Comparer le dma de l archi avec les 25 canaux de l amiga lol quoi .

Et quand je parle de custom ce sont des puces style blitter que n à pas l archi .
Certe il a aussi des atouts, mais bon .
Le son est bon, mais pas aussi clair que sur amiga .

Stp donne moi plus d'info sur tes 25 canaux... quant aux DMA sur Archie, ils sont bien évidemment plusieurs : pour la mémoire vidéo, pour la mémoire du sprite hard, pour la mémoire son.
Pour le son, si quelqu'un peut comparer avec l'Amiga, voilà son codage sur Archimedes :
Sound data field format :
sur 8 bits nommés D0 à D7 :
D0 : signe
D1-D4 : point sur la corde
D5-D7 : sélection de la corde

Caractéristiques de la lecture par le DAC : 8 segments linéaires sont lus (cordes).
Chaque corde est constituée de 16 parties, et chaque partie dans une corde dure 2 fois la durée de la corde précédente.
Cela donne une approximation de la 'loi mu255".
http://en.wikipedia.org/wiki/%CE%9C-law_algorithm

C'est comment sur Amiga ou St ?

[ArchieForEver]

Le jour ou on verra un shadow of the beast sur archi .
.

Ce jour n'est peut-être pas si loin que tu ne le penses.

[Invité]

Stp donne moi plus d'info sur tes 25 canaux... quant aux DMA sur Archie, ils sont bien évidemment plusieurs : pour la mémoire vidéo, pour la mémoire du sprite hard, pour la mémoire son.
Pour le son, si quelqu'un peut comparer avec l'Amiga, voilà son codage sur Archimedes :
Sound data field format :
sur 8 bits nommés D0 à D7 :
D0 : signe
D1-D4 : point sur la corde
D5-D7 : sélection de la corde

Caractéristiques de la lecture par le DAC : 8 segments linéaires sont lus (cordes).
Chaque corde est constituée de 16 parties, et chaque partie dans une corde dure 2 fois la durée de la corde précédente.
Cela donne une approximation de la 'loi mu255".
http://en.wikipedia.org/wiki/%CE%9C-law_algorithm

C'est comment sur Amiga ou St ?

pour le DMA sur amiga là par exemple : http://membres.multimania.fr/synapse/fonction/dma.html

Pour le DMA sprite de l'archi rassures moi, c'est pas un seul est unique sprite
Pour le son ça correspond à rien ..

Sur amiga c'est 4 canaux DMA, en 8 bit mais pouvant aller jusqu'a 14 bits (en combinant 2 voix) ,fréquence d'échantillonnage 28 khz (plus pour les AGA), et un rapport signal bruit de 70 db.

[ArchieForEver]

Il n'est pas faiblard en 2D, mais tu ne peux pas faire la même chose qu'un machine développé spécialement pour elle comme l'amiga ou les consoles .
Sur amiga outres ses copros, tout est DMA, c'est ce qui fait sa force, si en plus de la chip, tu utilise de la fast, ses perfs sont boostées .

Le jour ou on verra un shadow of the beast sur archi .
Dans les demos amiga tu as tout un tas d'effet impossible (en théorie) à faire sur un amiga, et pourtant c'est un temps réel .



Ok c'est de l'AGA, mais quand même, c'est autre chose.

Ma preview de démo avec les 3 gros sprites, c'est aussi en théorie impossible sur Archimedes... tu sais, cette machine avec 'un bus lent' et pourtant voilà, dès 92 ça existait.

Maintenant si tu me parles d'AGA je te mets en face le RISC PC sorti un an après, ou bien la version cut-down (A7000) et Acorn gagne haut la main ( en 3D et 2D ).
Faut comparer ce qui est comparable, sinon on ne va plus s'en sortir.

[Invité]

Attention, ne te méprend pas, l'archi est pour moi une super machine, mais je reste convaincu que la 2D n'est pas son point fort du tout .
Et mes critiques n'était pas pour ta demo qui est pas du tout finie, mais les précédentes postées .

C'est une machines comme toutes les autres qui à certe des qualités mais aussi des faiblesses, manque de pot elle est sortie au moment ou la 2D dominait .

[ArchieForEver]

Stp donne moi plus d'info sur tes 25 canaux... quant aux DMA sur Archie, ils sont bien évidemment plusieurs : pour la mémoire vidéo, pour la mémoire du sprite hard, pour la mémoire son.
Pour le son, si quelqu'un peut comparer avec l'Amiga, voilà son codage sur Archimedes :
Sound data field format :
sur 8 bits nommés D0 à D7 :
D0 : signe
D1-D4 : point sur la corde
D5-D7 : sélection de la corde

Caractéristiques de la lecture par le DAC : 8 segments linéaires sont lus (cordes).
Chaque corde est constituée de 16 parties, et chaque partie dans une corde dure 2 fois la durée de la corde précédente.
Cela donne une approximation de la 'loi mu255".
http://en.wikipedia.org/wiki/%CE%9C-law_algorithm

C'est comment sur Amiga ou St ?

pour le DMA sur amiga là par exemple : http://membres.multimania.fr/synapse/fonction/dma.html

Pour le DMA sprite de l'archi rassures moi, c'est pas un seul est unique sprite
Pour le son ça correspond à rien ..

Sur amiga c'est 4 canaux DMA, en 8 bit ,frequ d'echantillaunage 8 bit, mais pouvant aller jusqu'a 14 bits, en 28 khz (plus pour les AGA) et un rapport signal bruit de 70 db.

Intéressant. En ce sens aussi l'Archimedes a plus de DMA (sur ses ports d'extension) mais un seul vers la video car il ne fonctionne pas en bitplans mais en 'chunky' donc un seul DMA pour lire la mémoire vidéo.
Combien de sprites hard gère l'Amiga et quelles sont les vraies caractéristiques (y compris les contraintes, parceque les descriptions élogieuses qui oublient toujours les contraintes, comme pour le C64, ça me fatigue).

[ArchieForEver]

Attention, ne te méprend pas, l'archi est pour moi une super machine, mais je reste convaincu que la 2D n'est pas son point fort du tout .
Et mes critiques n'était pas pour ta demo qui est pas du tout finie, mais les précédentes postées .

C'est une machines comme toutes les autres qui à certe des qualités mais aussi des faiblesses, manque de pot elle est sortie au moment ou la 2D dominait .

Ok ok.
J'essaie juste de comprendre cette espèce d'intime conviction qui à mon sens ne repose sur rien de concret : juste la vision du travail d'excellents programmeurs (sur ST et Amiga) face à des fainéants (sur Archimedes).
C'est anormal par exemple qu'un type comme moi ait fait à mon coup d'essai un truc qui explose la concurrence alors que je débutais en assembleur.
Ca me fait vraiment penser que pour ce qui est jeu et démo l'Archie n'a pas eu les programmeurs qu'il méritait.

[Invité]

Oui la scene archi est petite comme celle du CPC, donc forcement la demo sur cette machine ne peut que faire évoluer lentement les connaissances .

Un question sur les demos rasters que tu as posté, tu est sur que ce sont de vrais rasters ??
On dirai juste un swap de palette pour donner l'effet de rasters !! .

[Invité]

Intéressant. En ce sens aussi l'Archimedes a plus de DMA (sur ses ports d'extension) mais un seul vers la video car il ne fonctionne pas en bitplans mais en 'chunky' donc un seul DMA pour lire la mémoire vidéo.
Combien de sprites hard gère l'Amiga et quelles sont les vraies caractéristiques (y compris les contraintes, parceque les descriptions élogieuses qui oublient toujours les contraintes, comme pour le C64, ça me fatigue).

Normal ,qu'un seul DMA, ca n'a rien à voir avec le chunky ou le BP, mais sur le fait que sur AMIGA, outre le CPU, Tout les custom y ont accès aussi .
car la mémoire de base de l'amiga la chip ram, est une mémoire unifiée .

Pour les sprites l'amiga en gere 8 hard, mais via le blitter et même le copper tu peux en gérer bcp plus .
Les contrainte sont la taille, je sais plus qu'elle taille il peut gerer, mais ca s'efface grâce au blitter .
L'amiga à 2 plans de scroll, mais il est en 16 couleur si tu es sur 1 plan, et 8 par plan en 2 plans.
Les problème sont surtout dans la gestion des sprites et tiles, pas de swap de sprite sur X et Y comme les consoles, donc tu uses 2 * plus de ram pour le même nombre d'anims .
Le son, 4 voix ca devient vite limite .

Après je dev pas sur amiga, donc je pourrais pas t'en dire vraiment plus .
La gestion des sprites, tiles, et ses 2 plans limités sont pour moi de gros défaut face aux console s 16 bits.

[ArchieForEver]

Oui la scene archi est petite comme celle du CPC, donc forcement la demo sur cette machine ne peut que faire évoluer lentement les connaissances .

Un question sur les demos rasters que tu as posté, tu est sur que ce sont de vrais rasters ??
On dirai juste un swap de palette pour donner l'effet de rasters !! .

La CopperSine demo je pense que c'est du swap de palette 256 couleurs.

Les autres c'est bien du raster.

[MacDeath]

houlà, la guerre se réveille, on voit qu'on est en pleine élections...
:)

bon c'est vrai que Shadow of the beast, c'est le truc toujours cité, du genre "tiens quand ta machine fera shadow of the beast comme sur Amiga elle sera aussi bonne qu'un Amiga...

euh lol...

Quand l'Amiga500 fera Wing Commander aussi bon que sur PC, ils sera... ah bin non tiens.

Bon, SotB fut une "Démo presque jouable" taillée spécialement autour de l'Amiga... Mais un jeux n'as pas beson de tout ça pour être bon, lol.

De mémoire il me semble que l'Amiga500 avait quand même pas mal de limitations concernant le nombre de couleurs sur les sprites, ils étaient limités en largeur mais pas en hauteur (sorte de multiplexing vertical "intégré quoi).


L'Archimede n'a qu'un théoriquement seul sprite Hard ?
juste pour le curseur souris ou quoi ?

y compris les contraintes, parceque les descriptions élogieuses qui oublient toujours les contraintes, comme pour le C64, ça me fatigue

De ce côté là je suis bien d'accord...
on casse trop souvent du sugar sur le dos du CPC comme quoi les graphismes ont de gros pixels moches alors que sur C64, c'est fin, y'a plein de couleures et c'est les meilleurs graphismes du monde...muarf...


En tout cas une chose est sûr... l'Atari ST est une bonne machine largement exploitable et exploité, l'Archimede est forcément largement "mieux".

C'est anormal par exemple qu'un type comme moi ait fait à mon coup d'essai un truc qui explose la concurrence alors que je débutais en assembleur.

[ArchieForEver]

Intéressant. En ce sens aussi l'Archimedes a plus de DMA (sur ses ports d'extension) mais un seul vers la video car il ne fonctionne pas en bitplans mais en 'chunky' donc un seul DMA pour lire la mémoire vidéo.
Combien de sprites hard gère l'Amiga et quelles sont les vraies caractéristiques (y compris les contraintes, parceque les descriptions élogieuses qui oublient toujours les contraintes, comme pour le C64, ça me fatigue).

Normal ,qu'un seul DMA, ca n'a rien à voir avec le chunky ou le BP, mais sur le fait que sur AMIGA, outre le CPU, Tout les custom y ont accès aussi .
car la mémoire de base de l'amiga la chip ram, est une mémoire unifiée .

???
Bien sûr que si ça a rapport avec le fait d'être un mode chunky.
Pour un mode chunky tu n'as besoin que d'un seul DMA.
Pour un mode bitplan il te faut un DMA par plan.

Ensuite heureusement que tes copros graphiques travaillent sous DMA.
Sur Archie j'ai le processeur graphique et son (VIDC), et pas de copro dédié donc évidemment ça nécessite moins de DMA.

Que le controleur disk bosse sous DMA ça c'est bien.
Je ne connais rien au 1772 de l'Archie, mais je vois mal comment ça pourrait fonctionner autrement que sous DMA.

En vérité ce concept de DMA n'a rien d'extraordinaire, et est juste cohérent avec les différents composants d'une bécane.
C'est l'interaction avec le bus du CPU, et les interactions entre les différents accès DMA quand ils se font en même temps, qui doit faire toute la différence.

[ArchieForEver]

houlà, la guerre se réveille, on voit qu'on est en pleine élections...
:)

bon c'est vrai que Shadow of the beast, c'est le truc toujours cité, du genre "tiens quand ta machine fera shadow of the beast comme sur Amiga elle sera aussi bonne qu'un Amiga...

euh lol...

Quand l'Amiga500 fera Wing Commander aussi bon que sur PC, ils sera... ah bin non tiens.

Bon, SotB fut une "Démo presque jouable" taillée spécialement autour de l'Amiga... Mais un jeux n'as pas beson de tout ça pour être bon, lol.

De mémoire il me semble que l'Amiga500 avait quand même pas mal de limitations concernant le nombre de couleurs sur les sprites, ils étaient limités en largeur mais pas en hauteur (sorte de multiplexing vertical "intégré quoi).


L'Archimede n'a qu'un théoriquement seul sprite Hard ?
juste pour le curseur souris ou quoi ?

y compris les contraintes, parceque les descriptions élogieuses qui oublient toujours les contraintes, comme pour le C64, ça me fatigue

De ce côté là je suis bien d'accord...
on casse trop souvent du sugar sur le dos du CPC comme quoi les graphismes ont de gros pixels moches alors que sur C64, c'est fin, y'a plein de couleures et c'est les meilleurs graphismes du monde...muarf...


En tout cas une chose est sûr... l'Atari ST est une bonne machine largement exploitable et exploité, l'Archimede est forcément largement "mieux".

C'est anormal par exemple qu'un type comme moi ait fait à mon coup d'essai un truc qui explose la concurrence alors que je débutais en assembleur.

Oui l'Archimedes n'a qu'un seul sprite hard, pensé pour afficher le curseur de la souris sous l'OS ... alors qu'on peut faire bien mieux avec.
N'importe quelle forme dans un rectangle de 32 pixels de large x hauteur max, avec sa propre palette de 3 couleurs parmi 4096, quand on dispose à côté d'un timer à 2 Mhz, ça donne beaucoup de possibilité de forme et de couleurs par ligne... hé hé ...

[Invité]

Non un canal DMA est 1 accès mémoire direct par une puce .
Donc si seul le CPU par exemple à un canal DMA, il peut accéder à la RAM/VRAM .
Le chunky ou le BP, defini seulement comment sont organisé les données en vram .
sur le chunky c'est contigu pour modifier la couleur d'un pixel, sur du BP, il faut modifier les 4 plans pour modifier un pixel .

Donc quand tu envoie des données par DMA, tu modifies ce que tu veux, ca depend du nombre de données que tu y envoie .
Comme je te l'ai dit, la ram de base de l'amiga sert pour tout, ram/vram/ram audio, donc toutes les chips y ont 1 ou plusieurs canaux DMA (ex paula pour le son, 1 canal/voix) .

@MacDeath: y'a pas de guerre, on essaye juste de se comprendre .

[ArchieForEver]

Non un canal DMA est 1 accès mémoire direct par une puce .
Donc si seul le CPU par exemple à un canal DMA, il peut accéder à la RAM/VRAM .
Le chunky ou le BP, defini seulement comment sont organisé les données en vram .
sur le chunky c'est contigu pour modifier la couleur d'un pixel, sur du BP, il faut modifier les 4 plans pour modifier un pixel .

Donc quand tu envoie des données par DMA, tu modifies ce que tu veux, ca depend du nombre de données que tu y envoie .
Comme je te l'ai dit, la ram de base de l'amiga sert pour tout, ram/vram/ram audio, donc toutes les chips y ont 1 ou plusieurs canaux DMA (ex paula pour le son, 1 canal/voix) .

@MacDeath: y'a pas de guerre, on essaye juste de se comprendre .

OK l'Archie c'est pareil : c'est aussi un système de RAM unifiée.
Rassure moi quand même : quand mon Archie envoie les données au VIDC pour qu'il les affiche, cette lecture a lieu sous DMA. Comme c'est un système chunky, le VIDC n'a besoin que d'un DMA.
Quand ton Amiga lui doit lire les différents plans, il faut donc que ton chip graphique accède via DMA à chacun des plans, non ? Donc si tu as 8 plans possibles sur Amiga tu as 8 DMA pour cette tâche de lecture de la vidéo écran hors le reste : sprites hards, etc ...) ?

Si ça marche comme sur mon Archie, ça remplit une pile FIFO pour ton processeur graphique qui va la lire pour former les données à envoyer au DAC.

En cela le nombre de DMA supérieur chez l'Amiga par rapport à l'Archie ne signifie pas qu'il est meilleur.
C'est juste qu'en chunky un seul DMA suffit et il te faut en mode bitplan autant de DMA que de plans nécessaires à la formation d'un data de pixel à afficher.

Je me trompe ou bien on ne se comprend toujours pas ?

PS : Dans les faits ce n'est pas pour un pixel à la fois, mais toute une série.
PS 2 : je n'ai peut être rien compris à la formation des pixels dans un système bitplan.

[ArchieForEver]

Intéressant. En ce sens aussi l'Archimedes a plus de DMA (sur ses ports d'extension) mais un seul vers la video car il ne fonctionne pas en bitplans mais en 'chunky' donc un seul DMA pour lire la mémoire vidéo.
Combien de sprites hard gère l'Amiga et quelles sont les vraies caractéristiques (y compris les contraintes, parceque les descriptions élogieuses qui oublient toujours les contraintes, comme pour le C64, ça me fatigue).

Normal ,qu'un seul DMA, ca n'a rien à voir avec le chunky ou le BP, mais sur le fait que sur AMIGA, outre le CPU, Tout les custom y ont accès aussi .
car la mémoire de base de l'amiga la chip ram, est une mémoire unifiée .

Pour les sprites l'amiga en gere 8 hard, mais via le blitter et même le copper tu peux en gérer bcp plus .
Les contrainte sont la taille, je sais plus qu'elle taille il peut gerer, mais ca s'efface grâce au blitter .
L'amiga à 2 plans de scroll, mais il est en 16 couleur si tu es sur 1 plan, et 8 par plan en 2 plans.
Les problème sont surtout dans la gestion des sprites et tiles, pas de swap de sprite sur X et Y comme les consoles, donc tu uses 2 * plus de ram pour le même nombre d'anims .
Le son, 4 voix ca devient vite limite .

Après je dev pas sur amiga, donc je pourrais pas t'en dire vraiment plus .
La gestion des sprites, tiles, et ses 2 plans limités sont pour moi de gros défaut face aux console s 16 bits.

Heuuu excuse moi mais pour flipper via copro des tiles sur X tu as juste ta routine de lecture et d'affichage à enrichir de cette fonction, et pas à avoir les tiles déjà flippés en RAM ....
En tout cas sur mon Archie sans blitter pas de soucis dans le shoot em up que je code : tous les chargements et affichage de tiles sont faits en soft et gèrent les flips.
Peut-être qu'en bitplan et comme tout doit passer par votre blitter, c'est un soucis... M'enfin à nouveau s'il sait copier des data, le flip par rapport à x ne devrait pas poser de soucis.(celui par rapport à y : oui).

Quand je vois toutes ces contraintes que vous avez avec l'usage de vos copros, dont les fonctions sont limitées et incomplètes, je me dis que la pureté du concept de l'Archimedes (un CPU puissant et hyper simple à programmer) est LA force de la machine d'Acorn.

PS : J'ajouterai que l'Archie a, lui, dès sa version de base 1 Mo de RAM, et son OS est dans une ROM de 512 Ko.
C'est sûr on est loin du concept console de jeux avec clavier de l'Amiga de base et ses 512 Ko.
Sur Archie, travailler sans disque dur, et sans un 2è lecteur de D7, ne pose pas de soucis, d'autant plus que l'OS gère le RAMdisk comme un filing system... sur le A500 on en est loin, bien loin de cette intelligence de conception. Ah évidemment l'Archie était plus cher, mais c'était bien justifié.

[MacDeath]

Lol au final (toute proportion gardée) comparer un Amiga500 et a Archimedes, c'est comme comparer un CPC6128 avec un TO8D finalement.

Sauf que l'Archimedes n'est pas si mauvais en sons, lol...

Concernant le "plan sprite" de l'archimedes...
Quid du multiplexage ?

C'est une seule "zone sprite" par scanline ?
verticalement, on peut l'étirer sur toute la hauteur... comme les sprites Amiga d'ailleurs si j'ai bonne mémoire, ou comme le multiplexing classique (C64...).

Y'a t'il des tricks pour en a fficher plus sur une même ligne ?

clignoter d'un affichage à l'autre déjà... (genre passer en 2x25hz au lieux de 50hz par exemple)
Il est "pointé" (C64) ou uploadé dans la puce (Amstrad PLUS) ?

N'importe quelle forme dans un rectangle de 32 pixels de large x hauteur max, avec sa propre palette de 3 couleurs parmi 4096, quand on dispose à côté d'un timer à 2 Mhz, ça donne beaucoup de possibilité de forme et de couleurs par ligne... hé hé ...

3 couleurs (donc 4 plus transparence en fait) c'est aussi peu que pour les sprites d'une NES ça (ou d'un C64 en pixels larges)

mais j'ai pas compris le coup du timer 2mhz par contre ?

Après bon, si faire du sprite en soft est plus lourd, ce n'est pas tant un handicap non plus qui empèche de faire quoi que ça soit non plus, la puissance brut de la machine suffit souvent a bien se démerder... on n'est plus justement sur un spectrum, CPC ou MO6... :)

[ArchieForEver]

Lol au final (toute proportion gardée) comparer un Amiga500 et a Archimedes, c'est comme comparer un CPC6128 avec un TO8D finalement.

Sauf que l'Archimedes n'est pas si mauvais en sons, lol...

Concernant le "plan sprite" de l'archimedes...
Quid du multiplexage ?

C'est une seule "zone sprite" par scanline ?
verticalement, on peut l'étirer sur toute la hauteur... comme les sprites Amiga d'ailleurs si j'ai bonne mémoire, ou comme le multiplexing classique (C64...).

Y'a t'il des tricks pour en a fficher plus sur une même ligne ?

clignoter d'un affichage à l'autre déjà... (genre passer en 2x25hz au lieux de 50hz par exemple)
Il est "pointé" (C64) ou uploadé dans la puce (Amstrad PLUS) ?

N'importe quelle forme dans un rectangle de 32 pixels de large x hauteur max, avec sa propre palette de 3 couleurs parmi 4096, quand on dispose à côté d'un timer à 2 Mhz, ça donne beaucoup de possibilité de forme et de couleurs par ligne... hé hé ...

3 couleurs (donc 4 plus transparence en fait) c'est aussi peu que pour les sprites d'une NES ça (ou d'un C64 en pixels larges)

mais j'ai pas compris le coup du timer 2mhz par contre ?

Après bon, si faire du sprite en soft est plus lourd, ce n'est pas tant un handicap non plus qui empèche de faire quoi que ça soit non plus, la puissance brut de la machine suffit souvent a bien se démerder... on n'est plus justement sur un spectrum, CPC ou MO6... :)

Ton lol me fait pitié : t'as à peine 1 MIPS de puissance CPU au niveau du 68000 de l'Amiga, et t'en as 4 chez l'Archimedes avec son ARM2 à 8Mhz...
Faut bien comprendre dans toutes nos discussions que je m'abaisse à rester au niveau du jeu et de la démo.
On peut parler raytracing, dessin vectoriel, DTP et autres logiciels sérieux où l'Archimedes PULVERISE l'Amiga et le ST tellement le lent 68000 est une poubelle, et de toute façon les ST et Amiga dans leur version de base ne sont pas fonctionnels pour faire tourner correctement de tels softs, à la différence de l'Archimedes de base qui lui le peut (c'est normal : l'Archimedes est un ordinateur, l'Amiga et le ST des consoles de jeu avec clavier).
Après vos petites machines doivent s'équiper de cartes accélératrices hors de prix là où sur Archimedes je sors mon ARM3 à 25 ou 33 Mhz que j'installe en lieu et place de l'ARM2, et à nouveau je suis loin devant, pour un cout moindre.

Tu n'as pas compris le coup du timer à 2 Mhz...ben il permet de faire s'executer une routine tous les x/2 000 000 è de seconde... ahhhhhh soudain tu entrevois quelques possibilités niveau changement de palette etc ?

Je ne comprends rien à ton histoire de multiplexing.
Je te reprends sur le sprite : chaque pixel est codé sur 2 bits donc 4 couleurs possibles par pixel, sauf que la couleur 0 (donc 00b) est la transparence. Ca laisse donc 3 couleurs (01b 10b 11b) pour former un sprite, et chcune des couleurs peut être n'importe laquelle parmi la palette de 4096 couleurs de l'Archimedes.
Ce que je peux te dire du sprite hard sur Archimedes, c'est qu'à chaque lecture sous DMA de la mémoire vidéo à afficher, toutes les 2 lignes raster, la lecture du buffer du sprite a lieu (sous DMA) (toutes les 2 lignes car une lecture lira 2 lignes de définition du sprite hard).
Le contenu de la lecture est superposé au contenu de chaque raster, avec 0 (couleur sprite) pour la transparence.
Donc, non, il n'y aura pas de trick pour 2 affichages par ligne.
Par contre tu peux bien sûr faire un affichage par 25è de seconde pour en avoir 2 à l'écran. Selon les couleurs ça flashotera plus ou moins mais ça peut être super intéressant : par exemple dans mon shoot em up vertical ça me fera des tirs laser.(et pas forcément dans une verticale, mais n'importe quelle déformation en X, puisqu'avec le timer à 2 Mhz je peux altérer le x de l'affichage du sprite hard à chaque scan line. Et je m'occuperai de sa palette aussi).

Verticalement tu es toute hauteur.
Tu peux l'afficher au pixel près où tu veux, il a un pointeur de début et de fin de lecture que tu peux altérer, à la fois en x et en y.
Le buffer est fixe à côté de la mémoire vidéo (oui il faut le remplir si on veut chnager le sprite hard, on ne peut pas pointer n'importe où en mémoire. Mais on peut pointer n'importe où dans le buffer du sprite hard donc si tu veux animer un petit sprite et que tes différentes images sont dans le buffer, il suffira de pointer sur chaque image successive de l'animation.).
Il n'y a pas de fonction d'étirement, maintenant tu sais pour recopier 32 pixels en 2 bits (donc une ligne du sprite) ça correspond à lire 8 octets et les recopier...whaou ! 16 cycles dis donc : terrrrriiiible .... lol (16 cycles car chaque ligne du buffer est sur une adresse multiple de 4 donc on peut utiliser LDMIA / STMIA, on aura 2 mots de 32 bits à lire et mettre en registre, et les mêmes registres à stocker ensuite en mémoire, soit 2 x 4 cycles à chaque fois)
M'enfin peut-être que tu devrais mieux regarder ma preview de démo où je suis en 256 couleurs, overscan, en 50 images par seconde.
Imagine donc la tuerie que ce serait en 16 couleurs... mais je ne m'abaisserai pas à un mode graphique de ST ou d'Amiga.
Tu devrais voir que l'Archie rien qu'avec son ARM est bien né pour manipuler de la donnée 2D.
Les routines que je suis en train de finir ajouteront la déformation en X et seront encore un peu plus rapide.
Tu fais ça sur Amiga ? En 256 couleurs ? Ah oui avec le HAM super flashy qui te détruit les yeux au bout de 30 secondes, bien sûr.
Un autre point sur les fameux super copros de l'Amiga : faire des déformations plasma et autres c'est bien mignon, mais si ensuite tu ne peux de toute façon rien afficher dessus, car tu as bouffé tous les plans disponibles, ou bien tu es en changement de pointeur video en temps réel ligne à ligne, pour moi c'est bullshit.
Ca en met plein la vue dans les démos, mais pour quoi que ce soit d'autres ça ne sert strictement à rien, puisque tu ne peux rien afficher dessus, ou alors ce sera en monochrome.

Sur Archie, comme sur un PC, tu as 256 couleurs et elles sont là pour tout : ton scrolling background, tes sprites, ton HUD, etc ...

[65c02]

Vous êtes marrant à vous mettre sur la gueule comme ça :)

Sérieux, si l’Archimède est un "vrai ordinateur" et les st amiga "des consoles avec des claviers" : pourquoi les comparer ?
Et si le proc de l'Archimède et si puissant, l'honneur va aux dév st et amiga pour avoir fait tant avec si peux :)

Bon, j’arrête de troller (surtout que c'est pour déconner)

En tout cas, en lisant Archiforever, je regrette de ne pas avoir connu l’Archimède en son temps.

[Invité]

archiforever j'ai l'impression que tu sais pas trop à quoi sert un copro .

Le copper est un chip programmable, qui te permet d'avoir le contrôle entier sur le faisseau, ainsi que sur la palette.
Avec ce qu'on appelle le copper list il fait des distorsions d'écrans ou du swap de palette comme un grand, pendant que le CPU fait autres chose .

Le plasma est juste un effet pour monter sa flexibilité, et ce qu'on peut faire avec 0% de CPU .
Toi pour le faire tu dois faire des routines entierement synchro avec un affichage sous timer (vachement pratique hein) .
Le St fait la même chose que l'archi, il à 2 timers, bah il est à la ramasse .
Bien sur que tu peux faire tout les effets du monde en soft, mais à force de tout faire en soft, bah t'as plus de cycles pour faire le reste.
Dans une demo ca va, mais dans un jeu, bah c'est problématique .

L'amiga peut faire tourner un jeu avec quasiment très peu de CPU, c'est d'ailleurs à cause du fait que dans une architecture amiga de base, donc juste avec de la chip ram, le CPU, est celui qui à la priorité la plus basse pour l'accès à la ram .
Donc les codeurs amiga, ont appris à s'en passer le plus possible,contrairement aux codeurs ST .
il y a des demos en mode HAM, et qui ne flashent pas du tout .
Mais si on suit ton résonement les japs sont des cons d'avoir mis des copros dans leurs consoles .

Les perfs du blitter sont bien meilleures à ton arm @ 8mhz, bien meilleures .
Car il peut déplacer de gros bloc de données en mémoire, sans solliciter le CPU .
Et chose importante, il ne bloque pas le 68000 pendant ses transferts .

Bien sur en perfs pure l'arm explose le 68000, ca c'est sur .

Le multiplexing de sprites,est une astuce pour avoir plus de sprites à l'écran, que la machine ne peut en gérer
Ex ton sprite tu le mets en haut à gauche de l'écran (on va dire qu'il fait 16*16 pixels)
et bien à la ligne 17 tu le déplace en bas à droite, donc visuellement tu aura 2 sprites hard à l'écran .
En bref ca consiste à déplacer des sprites hard déjà affichés dans zones écran qui ne le sont pas encore.

En plus n'oublies pas que l'archi est sorti 3 ans après l'amiga .

Tu peux voir des infos technique sur le blitter ici: http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0118.html

[MacDeath]

The sprite multiplexing technique is based on the idea that before the video hardware displays the next frame, the computer program will program the hardware to display those sprites that are first to be displayed. After those sprites have been displayed, the program then reprograms the hardware to display the remaining sprites. That way, the number of sprites that appear on the screen may be doubled, or increased even more.

The programmer must carefully consider the layout of the screen. If the video graphics hardware is not reprogrammed in time for the extra sprites to be displayed, they will not appear.

The technique relies on the program being able to identify what part of the screen is being drawn at the moment, or being triggered by the video hardware to run a subroutine at the crucial moment.

Mais cette technique n'est plus d'actuallité à partir du moment ou le sprite peut nativement avoir une hauteur variable, il te suffit d'une ligne à l'autre de simplement l'afficher ailleurs en axe X, je suppose.


La comparaison CPC6128 et TO8D était surtout sur le côté RAM dispo... (128 pour le CPC, 256 pour le TO8D) et divers truc genre le 6809 qui passe pour être un bon processeur...
Et la différence de prix des deux machines aussi.

Après je te l'accorde, c'est spécieux comme comparaison et a ne pas prendre trop formellement.


Bin c'est quand même un peu dommage que l'Archimedes n'ai pas eut un peu plus de slots de sprites je trouve.
8 sprites (comme celui qu'il a) ça aurait largement suffit pour en faire une bonne console de jeux ou améliorer le panel d'effets 2D de type démo...


ça coutait combien un Archi à l'époque ?

On peut parler raytracing, dessin vectoriel, DTP et autres logiciels sérieux où l'Archimedes PULVERISE l'Amiga et le ST tellement le lent 68000 est une poubelle, et de toute façon les ST et Amiga dans leur version de base ne sont pas fonctionnels pour faire tourner correctement de tels softs, à la différence de l'Archimedes de base qui lui le peut (c'est normal : l'Archimedes est un ordinateur, l'Amiga et le ST des consoles de jeu avec clavier).

Ok pour la supériorité du systeme ARM...

Mais sinon je te trouve un peu dure avec l'Atari ST... si il y a bien un ordinateur qui ne peut être qualifié de console de jeux, c'est bien l'Atari St.

"Peu puissant" comparativement, peut être, mais de la a en faire une console...

C'est par la force des choses que le ST est devenue une machine de jeux : pas cher, il a finis dans les chambres des gamins...
Mais moi mon PC286 EGA 12mhz... il a aussi finis en machine de jeux finalement, et de ce côté là un ST aurait presque été mieux alors (du son, une meilleur palette en simple mode 320x200) pour 3x moins cher.
(même si sur les simulateurs de vol en 3D, mon PC déchirait bien... 12mhz quand même...)

L'Atari St n'est il pas d'ailleurs un poil plus performant en 3D que l'Amiga500 d'ailleurs ? aidé par le fait que des sprites 2D ça aide peu, et que il est plus léger en affichage (32K de "VRAM", ou pas plombé par certains trucs des coprocesseurs justement...

Et puis un Atari ST, ça coutait pas 2x moins cher qu'un Archimede ? sachant qu'il était aussi équippé bien souvent avec pas mal de RAM.

un 1040STE c'était pas cher et assez bien quand même, et il avait la bonne idée d'avoir sa RAM sur barrettes...

De ce côté là, le 68000 se place bien comme le Z80 des 16/32bit.
une technologie maitrisée et relativement peu couteuse.

ça coutait combien un Archi à l'époque, déjà ?


Bon, y'a pas eut de postage de photos des machines me semble t'il..

Les modèles compacts... la classe.


A3020
(sortis en 1992)

J'aime bien la forme plus arrondis de la coque, il ressemble furieusement a un Amstrad PLUS d'ailleurs.

Le 3010 est le modèle familial à £500. On le reconnais à ses touches de fonction grises et non rouges. il intègre deux ports joysticks, une sortie TV et un ou deux Mo de RAM.

Le 3020 est le modèle avancé à £1000. Il est destiné à l'éducation. Sans sortie TV ou port joystick, il dispose d'un connecteur réseau ou peuvent se mettre une carte Ethernet ou Econet. Il a un disque dur 60Mo.

Le 4000 est un 3020 dans un boîtier d'Archimedes 5000 à clavier séparé et coûte £1100.

mmm je ne sais pas trop ce que ça donne les prix.
500£ pour un 3010 ? ça peut sembler relativement pas trop cher quand même... ça faisait 5000frs non ?
Mais on est en 1992 alors...

Archimedes est une série d'ordinateurs de plusieurs modèles. Retenons :

la première série 300 et 400 (305, 310, 410, 420 et 440), en 1987,
le modèles 3000 sort en mai 1989,
les modèles 410/1, 420/1 et 440/1 en juillet 1989
le 540 avec processeur ARM 3,
5000 puis A4 et 4000 ont suivi avec un ARM250.
les 3010 et 3020 qui remplacent le 3000 en août 1992,
le 4000, un 3020 en format desktop,
le RiscPC, serie 600, A7000 en 1995
la seconde génération de RiscPC avec la série 700 en juillet 1995

[ArchieForEver]

Vous êtes marrant à vous mettre sur la gueule comme ça :)

Sérieux, si l’Archimède est un "vrai ordinateur" et les st amiga "des consoles avec des claviers" : pourquoi les comparer ?
Et si le proc de l'Archimède et si puissant, l'honneur va aux dév st et amiga pour avoir fait tant avec si peux :)

Bon, j’arrête de troller (surtout que c'est pour déconner)

En tout cas, en lisant Archiforever, je regrette de ne pas avoir connu l’Archimède en son temps.

Et je suis bien d'accord : chapeau bas aux développeurs ST et Amiga.

[Invité]

Normal qu'il n'avait pas plus de sprites, la machine était faite pour la 3D et non la 2D .

Pour la supériorité du ST sur l'amiga en 3d ,c'est un mythe, forcement, si le jeu est juste fait via CPU sur amiga comme sur ST (simple portage) là oui .

[ArchieForEver]

archiforever j'ai l'impression que tu sais pas trop à quoi sert un copro .

Le copper est un chip programmable, qui te permet d'avoir le contrôle entier sur le faisseau, ainsi que sur la palette.
Avec ce qu'on appelle le copper list il fait des distorsions d'écrans ou du swap de palette comme un grand, pendant que le CPU fait autres chose .

Le plasma est juste un effet pour monter sa flexibilité, et ce qu'on peut faire avec 0% de CPU .
Toi pour le faire tu dois faire des routines entierement synchro avec un affichage sous timer (vachement pratique hein) .
Le St fait la même chose que l'archi, il à 2 timers, bah il est à la ramasse .
Bien sur que tu peux faire tout les effets du monde en soft, mais à force de tout faire en soft, bah t'as plus de cycles pour faire le reste.
Dans un demo ca va, mais dans un jeu, bah c'est problématique .

L'amiga peut faire tourner un jeu avec quasiment très peu de CPU, c'est d'ailleurs à cause du fait que dans une architecture amiga de base, donc juste avec de la chip ram, le CPU, est celui qui à la priorité la plus basse pour l'accès à la ram .
Donc les codeurs amiga, ont appris à s'en passer le plus possible,contrairement aux codeurs ST .
il y a des demos en mode HAM, et qui ne flashent pas du tout .
Mais si on suit ton résonement les japs sont des cons d'avoir mis des copros dans leurs consoles .

Les perfs du blitter sont bien meilleures que ton arm @ 8mhz, bien meilleures .
Car il peut déplacer de gros bloc de données en mémoire, sans solliciter le CPU .
Bien sur en perfs pure l'arm explose le 68000, ca c'est sur .

Le multiplexing de sprites,est une astuce pour avoir plus de sprites à l'écran, que la machine ne peut en gérer
Ex ton sprite tu le mets en haut à gauche de l'écran (on va dire qu'il fait 16*16 pixels)
et bien à la ligne 17 tu le déplace en bas à droite, donc visuellement tu aura 2 sprites hard à l'écran .
En bref ca consiste à déplacer des sprites hard déjà affichés dans zones écran qui ne le sont pas encore.

En plus n'oublies pas que l'archi est sorti 3 ans après l'amiga .

Mouais.

Alors comment expliquer que les jeux sont à mille lieues sous le niveau des démos ?
Parce que vos copros, qui fonctionnent avec des tables précalculées, ça ne servira à rien pour un jeu où il y a du 'temps réel' à gérer.
Ensuite non les Japonais n'étaient pas des cons : ils avaient juste de vrais copros puissants et utilisables pour les jeux, ce que, désolé, n'a pas l'Amiga.
C'est bien pour ça qu'une Megadrive ou une Snes explose l'Amiga.

Je reviens toujours à ma question : sur Amiga tu arrives à afficher quoi sur un écran dont le background est déformé par changement du x à chaque rasterline ? Il te reste quoi en terme de bitplan ? Tu vas mettre 1 sprite monochrome et te gargariser de la puissance de ton super ordi au CPU faiblard doté de copros ?
Il est où l'équivalent de Thunderforce IV de la Megadrive sur l'Amiga ?
Non, soyons sérieux : c'est très sympa dans des démos, où tout est fixé à l'avance et précalculé, mais après : bof.

Pour ce qui est du déplacement des gros blocs de mémoire par le blitter, mais arrêtez donc de ne jurer que par ça sur Amiga ! Tu regardes ma preview de démo : j'en fais autant, et en 256 couleurs, ce que l'Amiga ne saura jamais faire (et il n'y a aucune optimisation alors qu'elle serait possible puisque j'affiche 2 fois le même sprite (sphère). Tu verras ça dans ma prochaine publication).
En 16 couleurs j'aurais le double de data à l'écran, les doigts dans le nez.
Quand tu dis :
'Les perfs du blitter sont bien meilleures que ton arm @ 8mhz, bien meilleures .
Car il peut déplacer de gros bloc de données en mémoire, sans solliciter le CPU .' c'est du bidon : l'Amiga n'est pas une Neo Geo. Sont où les jeux avec des personnages où des bosses énormes ?
Ahhh oui on peut faire un super jeu avec N fois le même élément recopié à l'écran, de haut en bas au fur et à mesure que le canon à électrons trace l'image, ben ça c'est super intéressant, ça va être très très beau. Beau pour une démo quoi, inutilisable pour un jeu.

Ta 'non sollicitation de CPU' c'est aussi de la propagande, personne ne mange gratuit, et surtout tu omets bien de lister les limitations du blitter, les temps de latence sur le bus, les pertes de cycles quand il y a télescopages entre différentes demandes de lecture via DMA.
Bref, tu joues du pipeau à la gloire de l'Amiga comme tous les pro Amiga.

De mon côté, sous ARM, je suis libre, par le coding, de véritablement créer mes routines. Ca sort de ma tête et ce n'est pas contraint pas des composants limités et donc limitant.
Donc mon ARM2 à 8 Mhz, il est mille fois plus intéressant que ton sous produit 68000+copros faiblards.


L'archi est sorti en 1987, date de sortie de l'Amiga500, soit 2 ans après la sortie de l'Amiga1000.
Encore heureux que ce soit une meilleure machine.
Et c'est bien le cas : c'est une meilleure machine.

[ArchieForEver]

Normal qu'il n'avait pas plus de sprites, la machine était faite pour la 3D et non la 2D .
.

Mais non, même pas.
Acorn a juste voulu créer un ordinateur puissant pour continuer de distribuer ses produits dans son marché captif de l'éducation britannique.(créer un successeur du BBC B et du Master).

[ArchieForEver]

MacDeath, ta référence

'5000 puis A4 et 4000 ont suivi avec un ARM250.'
est fausse.
Le A5000 a un ARM3, tout comme le portable A4 (la carte mère du A5000 est dérivée de celle du A4).
Le A4000 a un ARM250.
L'ARM250 est la première macrocell ARM, présente également dans le A3010 et le A3020, à 12 Mhz interne et externe (bus). C'est en fait un ARM3 sans cache, avec le VIDC, le MEMC et l'IOC, sur un seul 'die'.
Pour rappel : l'ARM3 c'est un ARM2 avec 4 Ko de cache et tournant + vite, jusqu'à 35 Mhz, ET disposant d'une instruction supplémentaire : SWP, capable de faire de l'échange (contenu de registre) <> (mémoire RAM) tout en étant ininterruptible.
Bien utile pour implémenter des sémpahores.

[65c02]

ahahah
Pourquoi vous nous feriez pas une petite compète de démo pour comparer ?
On pourrait juger sur pièce :)