Re: * AMSTRAD CPC * TOPIC OFFICIEL

[youki]

Ca aurait été une machine géniale avec un 6502 à 2Mhz.

Un 6502 à 2Mhz ? difficile vu les coûts de la RAM, la machine aurait coûtée bien plus cher .

Il y avait déjà des machines à l'époque avec ça.  Mais l'Atari XL avait un 6502 à 1.79mhz ,  le BBC Micro un 6502 à 2mhz.   Je suis pas sur que ca aurait augmenté tant que ca le prix de la machine. peut-etre un peu , mais de quelques  francs.

Oui mais à quel prix ? et le BBC est d'abord sorti avec 16/32ko, c'est le B+ qui a eu 64ko .
@2mhz il faut de la RAM @4mhz .L'avantage c'est que le GA aurait pu utiliser la seconde phase du CPU, et non brider le Z80 qui passe à 3.3/3.5mhz pendant l'affichage au lieu des 4 .

Le BBC valait 235£ pour Model A(16ko) et £335 Model B(32ko)(but increased almost immediately to £299 and £399 due to higher costs.), après je sais pas si c'est de la RAM @4mhz, ou avec WS .

Il faut quoi comme RAM pour un z80 à  3.5 mhz? Question con, mais pourquoi il faudrait des RAM différentes avec un 6502 par rapport à  un Z80?  Le c128 utilise les mêmes RAM pour les 2 proc.

[touko]

Il faut quoi comme RAM pour un z80 à  3.5 mhz

Le Z80 comme le 68000 se contente de RAM très lente, 4x plus lente que le CPU vu que les accès sont tous les 4 cycles .
Donc après ça dépend des composants derrières comme le circuit vidéo et si la RAM est partagée ou pas, souvent ils accèdent à la RAM en 1 ou 2 cycles pour le DMA vidéo .
Le problème du z80, c'est qu'il ne partage pas le bus entre les accès d'une instruction contrairement au 68000, donc une puce vidéo aura la priorité sur le Z80 et bloquera le CPU tant que le bus n'est pas libre, contrairement au 68000 où les accès peuvent être faits sur les cycles inutilisés du CPU, comme sur amiga .

mais pourquoi il faudrait des RAM différentes avec un 6502 par rapport à  un Z80?  

Comme expliqué pour le C64, le 6502 est un CPU 2 phases, il accède au bus tous les 1/2 cycles (et pas 1 cycles) pendant la 2nde phase, laissant 1/2 cycles d'accès de la phase 1 pour un autre composant comme un circuit vidéo, donc cela donne une RAM accédées non pas à 1 cycle=>vitesse du CPU, mais en 1/2 cycle=>vitesse du cpu x2 .

Sur le CPu de la PCE ils ont supprimé ces accès en 2 phases, et ramené les accès à 1 cycles, d'où le fait qu'il puisse tourner à 7.16 avec une RAM à vitesse du CPU, ce qui est logique vu que le CPU n'a pas besoin de partager ses accès avec un autre composant .
Ce procédé a été aussi fait pour le SA-1 de la snes, et il me semble pour les accélérateurs (65816) du 2GS et du C64 pour éviter d'avoir une RAM x2 hors de prix .

Le c128 utilise les mêmes RAM pour les 2 proc.

Qui peut le plus peut le moins je dirais .

Donc il te faut une RAM à vitesse du composant le plus rapide y accédant .

[youki]

Merci pour tes explications,  donc si j'ai bien compris (rien n'est moins sur!!!).

un 6502 à 1Mhz aura besoin de RAM à 2 Mhz.

un Z80 à 4 Mhz aura besoin de RAM à 1 Mhz.

C'est bien ça?

[kawickboy]

https://www.sellmyretro.com/offer/details/64558

Zaxon a upgradé son DDI-5 vers le DDI-6. C'est une upgrade fabuleuse pour le CPC 464. 
La nouveauté c'est de proposer la rom du CPC 6128 (basic 1.1...). C'est un peu ce que proposait la carte FO.DOS de Duchet Computers pour ceux qui ont connu.

Sont toujours inclus dans la boitier: gotek, 512ko RAM, 512ko ROM, connecteur pour brancher un 2e lecteur (comme le DDI-1 d'Amstrad) et switch pour inverser les drive A/B. 130£, pas de douane car vendeur Polonais.
Le mec bosse bien mais n'est pas toujours aimable, un peu comme Lotharek.

Un truc pareil pour 464+ ce serait top, cela deviendrait mon CPC+ de base.

[TotOOntHeMooN]

Ca fait 5 ans que je lui dis de mettre le FW3.0 et le BASIC 1.1 au démarrage, je lui avais même proposé les schémas pour le faire... Jamais eu de réponse. Il y va upgrade par upgrade pour faire de la vente. 130£ (pour marger plus qu'en euro, sa devise d'origine) c'est vraiment claqué du cul comme prix. Business is business.

[touko]

Merci pour tes explications,  donc si j'ai bien compris (rien n'est moins sur!!!).

un 6502 à 1Mhz aura besoin de RAM à 2 Mhz.

un Z80 à 4 Mhz aura besoin de RAM à 1 Mhz.

C'est bien ça?

C'est ça  .
Bien sur si tu as un DMA ,la RAM doit être en conséquence, surtout côté Z80.

[kawickboy]

Ca fait 5 ans que je lui dis de mettre le FW3.0 et le BASIC 1.1 au démarrage, je lui avais même proposé les schémas pour le faire... Jamais eu de réponse. Il y va upgrade par upgrade pour faire de la vente. 130£ (pour marger plus qu'en euro, sa devise d'origine) c'est vraiment claqué du cul comme prix. Business is business.

Ce n'est pas donné, mais au prix actuel d'un 6128 et du lecteur k7 externe, upgrader son 464 pour celui qui n'a que cela... La Pologne n'est pas à l'Euro mais ce n'est pas la 1ère fois qu'en Europe de l'Est je vois des prix en £ en effet.
L'upgrade à petit feu, c'est le fond de commerce de Terraonion, qui se sont installés par dessus cela en Andorre (donc sauf si frontalier, les prix TTC sont en fait HT).

[TotOOntHeMooN]

Ce n'est pas donné, mais au prix actuel d'un 6128 et du lecteur k7 externe, upgrader son 464 pour celui qui n'a que cela... 

C'est parce que les prix des extensions augmentent, que les machines se vendent logiquement plus cher, et non l'inverse... Les acheteurs compulsifs rétro creusent eux-même leurs tombes.

[kawickboy]

A sa décharge, même s'il a toujours été cher, il n'augmente pas ses prix, donc bientôt il sera super compétitif à ce rythme là.

[TotOOntHeMooN]

Les prix :
- DDI-1 = 50£
- DDI-2 = 69£ (je l'ai acheté pour moi)
- DDI-3 = 69£ (je l'ai acheté pour un amis)
- DDI-4 = 49£ (je l'ai acheté pour un amis)
- DDI-5 = 99£
- DDI-6 = 130£

Les DDI-5 et DDI-6 ne devraient pas couter plus de 75£ vu le contenu.

[kawickboy]

Je n'ai suivi le bonhomme qu'à partir du 5 je n'ai pas ton historique, mais tu chipotes. 30£ pour une rom et un switch A/B ce n'est rien.
Par contre j'ai l'impression que l'on a perdu parados dans l'opération.

Mais il demeure le seul à s'occuper réellement du 464. Nous autres Français gavés de 6128 on s'en moque peut-être mais les Anglais et surtout Espagnols ont majoritairement eu un 464.

[TotOOntHeMooN]

Ironique ?  

Pour 30£, je fais toute l'interface et je marge (un peu).

[kawickboy]

Un batch unique de 200 cartes (Ok faut le financer) et tu ruines son business. Ainsi utilisé le 464 est une bonne alternative car il est nettement moins cher que le 6128.

[TotOOntHeMooN]

Aucune intension de ruiner quelconque business. D'expérience, les gens achètent en pensant que le prix proposé est toujours juste... Plus envie de me prendre la tête à expliquer en vain pourquoi ça ne peut pas couter autant et que les marges de 100$ par extensions sont devenu la norme... J'ai bien compris que le CPC est passé de l'autre coté de la "passion" et que les prix ont augmenté en conséquent.

[cerberus]

Le Z80 n'est pas à 3 ou 3.3 ou 3.5, il est à 4MHz tout le temps...

Le Gate Array envoie des wait-states 3 cycles sur 4 mais ça ne change en rien la fréquence du Z80. Il attend parfois c'est tout (et ça n'a rien à voir avec l'affichage, c'est pas plus lent ou plus rapide selon qu'il affiche quelque chose, ce n'est pas comme ça que ça fonctionne).

En performances ça va être plus lent qu'un Z80 à 4MHz tout seul dans son coin, SELON les instructions exécutées. Vouloir donner un équivalent en MHz c'est aussi doigt mouillé que parler de Mips. D'ailleurs, à propos de Mips, je m'étais amusé à ajouter un compteur de Mips sur un émulateur et sans surprise, ça dépend fortement du code utilisé. Du code optimisé avec des instructions simples ça tourne autour de 0.75 mips, du code plus complexe avec les registres d'index on tombe à 0.4 mips. Et mettre des zéro partout dans la mémoire, on est à 1Mips, pleine vitesse :)

[touko]

Le Z80 n'est pas à 3 ou 3.3 ou 3.5, il est à 4MHz tout le temps...

Non il tourne pas à 4mhz(CAD les 80.000 cycles/frame qu'il devrait avoir) qd il y a de la contention, CAD pendant l'affichage, le G.A bouffe bcp de cycles, et on est dans les 3.3/3.4(c'est une moyenne), si tu désactives l'affichage et pendant le vblank, tu es à 4mhz .

Il y a une bonne explication ici :
https://cpcrulez.fr/coding_z80frequence.htm

Comme sur CPC c'est le CRTC qui a la priorité, il peut lire les données au moment où il en a besoin. Le Z80 sera obligé d'attendre que le 6845 lui laisse le champ libre. Ainsi, la fréquence de 3,33 MHz est une moyenne calculée à partir des ralentissements que subit le Z80 à cause du CRTC.

Donc si tu veux dire que la fréquence effective ne change pas, tu as raison, mais le CPU va subir de nombreux "Wait states" pendant l'affichage, ce qui le ramènera comme si il tournait à 3.3 sans contention .

[cerberus]

Le Z80 n'est pas à 3 ou 3.3 ou 3.5, il est à 4MHz tout le temps...

Non il tourne pas à 4mhz qd il y a de la contention, CAD pendant l'affichage, le G.A bouffe bcp de cycles, et on est dans les 3.3/3.4(c'est une moyenne), si tu désactives l'affichage et pendant le vblank, tu es à 4mhz .

Il y a une bonne explication ici :
https://cpcrulez.fr/coding_z80frequence.htm

Comme sur CPC c'est le CRTC qui a la priorité, il peut lire les données au moment où il en a besoin. Le Z80 sera obligé d'attendre que le 6845 lui laisse le champ libre. Ainsi, la fréquence de 3,33 MHz est une moyenne calculée à partir des ralentissements que subit le Z80 à cause du CRTC.

Donc si tu veux dire que la fréquence effective ne change pas, tu as raison, mais le CPU va subir de nombreux "Wait states" pendant l'affichage, ce qui le ramènera comme si il tournait à 3.3 sans contention .

Ta "source" parle d'équivalence, c'est un raccourci que tu as compris de travers, suffit de regarder les schémas du CPC ou de lancer une simu sur flooh, c'est pas comme ça que ça fonctionne (bis repetita)

L'affichage n'entre pas en compte, c'est pas un spectrum

[touko]

Ecoutes, pourtant c'est justement ce qui es dit :

Comme sur CPC c'est le CRTC qui a la priorité, il peut lire les données au moment où il en a besoin. Le Z80 sera obligé d'attendre que le 6845 lui laisse le champ libre. Ainsi, la fréquence de 3,33 MHz est une moyenne calculée à partir des ralentissements que subit le Z80 à cause du CRTC.

Donc tu vois bien que l'affichage a un impact, ce qui est logique vu que le Z80 ne sait pas partager le bus .Sur spectrum c'est exactement le même souci, l'affichage va faire perdre des cycles au Z80 .

Pourquoi dit-on dans certaines documentations que le Z80 du CPC est cadencé à 4MHz, et dans d'autres qu'il est à 3,33 MHz ?
Les deux fréquences sont correctes ! Tout dépend du point de vue : Le CPC possède un quartz à 16 MHz dont la fréquence est divisée par 4 avant d'arriver au Z80. On a donc bien quatre Mhz. Cependant la RAM du CPC est utilisée à la fois par le CPU et le processeur vidéo (il faut bien qu'il lise les octets pour les afficher à l'écran). Pour des raisons techniques, le Z80 et le CRTC6845 ne peuvent accéder à la mémoire en même temps. Il a donc fallu faire un arbitrage : On a préféré privilégier l'affichage, le CRTC a donc la priorité sur le Z80

C'est clair pourtant ?, et ça vient pas d'un forum lambda qd même, et je vois pas comment il pourrait avoir tous ses cycles, sachant que le proc vidéo à la priorité et que les 2 se partagent la même RAM .

Par contre autant pour moi, je pensais que le CRTC étant dans le G.A, mais ca semble être une puce à part .

[cerberus]

Ecoutes, pourtant c'est justement ce qui es dit :

Comme sur CPC c'est le CRTC qui a la priorité, il peut lire les données au moment où il en a besoin. Le Z80 sera obligé d'attendre que le 6845 lui laisse le champ libre. Ainsi, la fréquence de 3,33 MHz est une moyenne calculée à partir des ralentissements que subit le Z80 à cause du CRTC.

Donc tu vois bien que l'affichage a un impact, ce qui est logique vu que le Z80 ne sait pas partager le bus .Sur spectrum c'est exactement le même souci, l'affichage va faire perdre des cycles au Z80 .

Pourquoi dit-on dans certaines documentations que le Z80 du CPC est cadencé à 4MHz, et dans d'autres qu'il est à 3,33 MHz ?
Les deux fréquences sont correctes ! Tout dépend du point de vue : Le CPC possède un quartz à 16 MHz dont la fréquence est divisée par 4 avant d'arriver au Z80. On a donc bien quatre Mhz. Cependant la RAM du CPC est utilisée à la fois par le CPU et le processeur vidéo (il faut bien qu'il lise les octets pour les afficher à l'écran). Pour des raisons techniques, le Z80 et le CRTC6845 ne peuvent accéder à la mémoire en même temps. Il a donc fallu faire un arbitrage : On a préféré privilégier l'affichage, le CRTC a donc la priorité sur le Z80

C'est clair pourtant ?, et ça vient pas d'un forum lambda qd même, et je vois pas comment il pourrait avoir tous ses cycles, sachant que le proc vidéo à la priorité et que les 2 se partagent la même RAM .

Nah mais ta source raconte n'imp...  

Celui qui a la priorité, c'est le Gate Array, c'est lui le métronome à 16MHz et il donne du 4MHz au CRTC et au Z80. Il se réserve le bus TOUT LE TEMPS 3 cycles sur 4.

Le CRTC génère des adresses et ne lit pas la mémoire. C'est le Gate array qui lit la mémoire aux adresses données par le CRTC. Et c'est toujours le gate array qui génère les signaux vidéos...

Je n'ai pas dit qu'il avait tous ces cycles, j'ai dit qu'il était tout le temps à 4MHz. Et que donner une équivalence plus basse c'est du doigt mouillé, ça va dépendre uniquement du programme exécuté (et pas du tout de l'affichage).

Pitié, un électronicien sérieux pour venir débunker ces âneries (oui, ça fait des décennies que des âneries circulent sur le CPC, comme l'histoire du stock de lecteurs de disquette pourtant récemment démenti par Roland Perry himslef, comme quoi, les légendes urbaines ont la vie dure)

En infos correctes, t'as ça https://www.cpcwiki.eu/index.php/Gate_Array#DRAM_refresh

[cerberus]

Et juste au dessus du lien encore

The Gate Array fetches 2 bytes for each address. /CPU_ADDR is a 1MHz signal. So these 2 bytes are fetched sequentially. They are not interleaved with Z80 access. These bytes are fetched even when the border is on as this is required for DRAM refresh.

Traduction, si le gate array arrête de lire la RAM pendant la vblank ou le border, le refresh de la RAM ne se fait plus, donc il lit tout le temps

[touko]

j'ai dit qu'il était tout le temps à 4MHz

Mais sur ça je suis d'accord, la fréquence change pas, on perd juste des cycles car le CPU est bloqué pendant les accès du G.A, ce qui est comme si le CPU tournait à 3.3 .
Après je suppose qu'il y a moyen de minimiser l'impact en fonction des instructions utilisées, mais putain le casse tête .

Traduction, si le gate array arrête de lire la RAM pendant la vblank ou le border, le refresh de la RAM ne se fait plus, donc il lit tout le temps

Le refresh est inévitable avec de la DRAM .

[cerberus]

j'ai dit qu'il était tout le temps à 4MHz

Mais sur ça je suis d'accord, la fréquence change pas, on perd juste des cycles car le CPU est bloqué pendant les accès du G.A, ce qui est comme si le CPU tournait à 3.3 .
Après je suppose qu'il y a moyen de minimiser l'impact en fonction des instructions utilisées, mais putain le casse tête .

Traduction, si le gate array arrête de lire la RAM pendant la vblank ou le border, le refresh de la RAM ne se fait plus, donc il lit tout le temps

Le refresh est inévitable avec de la DRAM .

Nah mais ton 3.3 il sort de nulle part.

Écoute, t'as des tonnes d'ému cycle accurate depuis longtemps, tu fous que des instructions de 1 nop dans la RAM, t'en auras 4 millions d'exécutées par seconde. Ce 3.3 ne veut rien dire et n'est représentatif de rien.


Manipulation encore plus simple : Lancer Winape ou ACE, F7 débogueur => reset du compteur de nops, tu laisses tourner 1 min, tu reviens, 60 millions ( et pas 49.5)

[touko]

Les 3.3 viennent des 80.000 cycles / frame du CPU - les cycles pris par le G.A, soit 1 cycle / 4 pendant l'affichage des 200 lignes .

bref au cours d'une milliseconde soit 4 T-cycles, y'en a déjà 2 qui sont reservés au circuit vidéo du CPC (le gate array) pour lire 2 octets (et les traduires en niveaux de couleurs pour le tube cathodique). Reste 2 T-cycles, suffisant lors d'une instruction "simple" pour récupérer l'octet de l'instruction. Mais bon imaginons une instruction qui lit plein de choses dans la mémoire genre LD HL,(xxxx). Au cours de cette dernière instruction, le bus est souvent requis lors de l'exécution pour récupérer en xxxx les 2 octets. Manque de pot, le gate array est prioritaire, et donc le Z80 qui lui aussi demande le bus est mis en attente (WAIT STATE?).
calculons...
si 4 T-Cycles, arrondi à 4, + 0%
si 5 T-Cycles, arrondi à 8, + 60%
si 6 T-Cycles, arrondi à 8, + 33%
si 7 T-Cycles, arrondi à 8, + 14%
si 8 T-Cycles, arrondi à 8, + 0%
si 9 T-Cycles, arrondi à 12, + 33%
si 10 T-Cycles, arrondi à 12, + 20%
si 11 T-Cycles, arrondi à 12, + 9%
En supposant que les instructions sont équitablement réparti sur ces 8 catégories (arbitraire!!!), çà fait déjà en moyenne 20% de temps en plus. Soit en inversant pas 4 Mhz mais au max 4/(100+20%)= 3,33 Mhz. Héhé

Et c'est pas moi qui le dit là, mais roudoudou(que tu dois surement connaitre, donc pas le 1er venu) . 

In fact, the Gate Array allows the Z80 to access the RAM in only 1 out of every 4 cycles. As a result, all instruction timings are stretched so that they are all multiples of a microsecond (1µs), and this gives an effective CPU clock of 3.3Mhz.

https://www.cpcwiki.eu/index.php/Gate_Array

[cerberus]

Les 3.3 viennent des 80.000 cycles / frame du CPU - les cycles pris par le G.A, soit 1 cycle / 4 pendant l'affichage des 200 lignes .

bref au cours d'une milliseconde soit 4 T-cycles, y'en a déjà 2 qui sont reservés au circuit vidéo du CPC (le gate array) pour lire 2 octets (et les traduires en niveaux de couleurs pour le tube cathodique). Reste 2 T-cycles, suffisant lors d'une instruction "simple" pour récupérer l'octet de l'instruction. Mais bon imaginons une instruction qui lit plein de choses dans la mémoire genre LD HL,(xxxx). Au cours de cette dernière instruction, le bus est souvent requis lors de l'exécution pour récupérer en xxxx les 2 octets. Manque de pot, le gate array est prioritaire, et donc le Z80 qui lui aussi demande le bus est mis en attente (WAIT STATE?).
calculons...
si 4 T-Cycles, arrondi à 4, + 0%
si 5 T-Cycles, arrondi à 8, + 60%
si 6 T-Cycles, arrondi à 8, + 33%
si 7 T-Cycles, arrondi à 8, + 14%
si 8 T-Cycles, arrondi à 8, + 0%
si 9 T-Cycles, arrondi à 12, + 33%
si 10 T-Cycles, arrondi à 12, + 20%
si 11 T-Cycles, arrondi à 12, + 9%
En supposant que les instructions sont équitablement réparti sur ces 8 catégories (arbitraire!!!), çà fait déjà en moyenne 20% de temps en plus. Soit en inversant pas 4 Mhz mais au max 4/(100+20%)= 3,33 Mhz. Héhé

Et c'est pas moi qui le dit là, mais roudoudou(que tu dois surement connaitre, donc pas le 1er venu) . 

Oui, je le connais bien

Cette valeur est donc bien une équivalence basée sur des suppositions purement arbitraires (sic) et non une fréquence réelle du Z80, c'est dans ce que tu cites. J'essayais simplement (oui, parce que roudoudou heu...  c'est moi pour ceux qui ne le savent pas...) de trouver l'origine de cette légende urbaine, pas de la confirmer en quoi que ce soit!

En plus ce que je disais à l'époque est incomplet/approximatif puisque le Gate Array monte le wait 3 cycles sur 4 (ce que j'ignorais visiblement au moment où j'ai écrit ce truc) ET aussi je n'avais pas encore eu accès aux informations précises de timings qui ont circulé quand des électroniciens se sont amusés à faire des tables de timing des instructions.

tables type ça

[cerberus]

j'ai retrouvé ta source, ce n'est pas moi qui ait écrit ça (ouuuuuuuuuuuuuuuf!) c'est cski...

Cet article a été rédigé par CSKi, d'après des indications de MadRam.
https://cpcrulez.fr/coding_z80frequence.htm

C'est un peu le souci d'accumuler des infos en vrac sur un site sans les mettre à jour quand elles sont fausses...
J'vais envoyer un tit message à Hermol quand même (d'un côté ce sont des vieux écrits pour archivage, de l'autre ça continue de propager des bêtises)

[touko]

Fais corriger le cpc wiki aussi alors(si tu peux) .

Car on y trouve ça :

In fact, the Gate Array allows the Z80 to access the RAM in only 1 out of every 4 cycles. As a result, all instruction timings are stretched so that they are all multiples of a microsecond (1µs), and this gives an effective CPU clock of 3.3Mhz.

https://www.cpcwiki.eu/index.php/Gate_Array

Et au final combien le CPU perd exactement de cycles / frame ?
As tu quelque chose de fiable là dessus ?

(oui, parce que roudoudou heu...  c'est moi pour ceux qui ne le savent pas...)

Tu es là incognito ? 

PS: L'image même agrandie est pas lisible

[Copper]

En tout cas j'espère qu'utiliser les cycles arrondis en NOP c'est valable parce que c'est ceux que j'utilise pour optimiser

[touko]

1 NOP c'est 4 cycles non ?

[Copper]

Oui mais par exemple le JR fait 3 NOP / 12 cycles alors que le JP fait 3 NOP mais seulement 10 cycles donc c'est pour ça que j'espère que c'est toujours valable...

[cerberus]

En tout cas j'espère qu'utiliser les cycles arrondis en NOP c'est valable parce que c'est ceux que j'utilise pour optimiser

Oui, en fait, les instructions ne durent pas plus longtemps, c'est la suivante qui démarre plus tard car le Fetch de l'instruction se recale sur son cycle de lecture. Si on considère qu'attendre ce fetch ne fait pas partie de l'instruction, les instructions ont tout le temps la même durée. Considérer ce temps d'attente comme faisant partie de l'instruction qui fetche (variable selon l'instruction précédente),c'est uniquement destiné à perdre les gens pour rien...

Le graph de timing, c'était pour l'exemple, je peux retrouver la source de tous les timings si ça intéresse certains (c'est en tous cas inutile comme info pour un codeur CPC)

[touko]

Oui mais par exemple le JR fait 3 NOP / 12 cycles alors que le JP fait 3 NOP mais seulement 10 cycles donc c'est pour ça que j'espère que c'est toujours valable...

Ah effectivement .