Flipper TimeShock! ? ? ?

[romain]

Oui, mais le I-PAC ne gère que des interupteur ouverts ou fermé. Une borne = un contact, il ne peut pas gérer de matrice.
Faudrait faire une interface dédié, matrice de 10x10 (voir plus, pourquoi se limiter au standards de WMS?) vers le PC, mais ca je n'ai absolument aucune compétences pour l'envisager =)

ce que j'ai ça ne me pose aucun problème à priori, ainsi que le fait d'interfacer le tout en USB

Moui, mais d'une c'est pas 16, parceque 16 fils = 64 lampes, donc.... pas assez =) Et puis il y a les bobines....
En fait c'est le même problème que pour les contacts, ca complique carrément les choses. Enfin si quelqun est capable de faire ca, respect a lui =)

non, ce n'est pas bien compliqué, en réalité ça l'est autant que de commander chaque lampe une à une au regard du bazard de fils et de composants nécessaire... une matrice 10*10 par exemple (comptez 100 lampes commandables) demande autant de travail qu'une matrice 8*8, ce genre de détail est fourni lors de l'élaboration du cahier des charges.

Ben non, c'est pas la même chose. C'est beaucoup plus simple et ca ne tiens pas compte du débit du port.
De toute facon le débit du port est correct puisque les cartes drivers de PinBall2000 marchent avec un port // tout a fait standard (bi-directionel, même)

rien à voir Damien pour le port parallèle, le débit indiqué reste une simple indication du nombre max de changements dans l'état d'une pin que tu peux faire par seconde. mais le problème ne se pose pas, car l'USB permet de brancher TOUT le système à un pc portable...

Même si TOUT faire passer en USB paraît bien plus judicieux... à toi de voir

Ben, je ne sais pas comment ca marche tout ca donc bon =)
Si tu l'dis.... =)

on considère juste le prix du composant réalisant l'interface (soit une dizaine d'euros grand max, mais largement compensé par le non achat d'I-PAC...)

@+

[romain]

Il suffit de mettre 2 i-pac, chaque i-pac étant programmable rien n'empèche d'associer des touches différentes sur les 2 non ?

le souci est bien plus complexe que ça en réalité. Les contacts par matrice ne fonctionnent pas par rapport à la masse, mais par rapport aux lignes/colonnes.
Pour expliquer simplement le principe :
chaque contact est cablé sur une ligne et une colonne d'un tableau (soit 8 contacts par ligne/colonne pour une matrice 8*8, logique).
Lorsque tu met à 1 l'état d'une ligne, tu lis l'état de toutes les colonnes et ainsi tu verra les contacts fermés et ouvert en fonction de l'état des colonnes... Si c'est pas clair je ferai un schéma !

Pour les lampes c'est très facile de simuler une matrice avec un microcontroleur qui avale les données (la vitesse n'est pas critique) et qui gère la rotation de la matrice de façon indépendante, en gros le pc envoie une salve de 8x8bits, le µC la stocke et gère la matrice de façon autonome.

exactement, c'est même la solution la plus simple et la plus efficace qui existe : la solution idéale selon moi.

matrice = beaucoup moins de fils, beaucoup moins de transistors, transfo moins gros, mais oblige à une diode par ampoule de plus on peut pas cabler n'importe comment et ça a les défauts qu'on connait tous, plus il y a d'ampoules allumées sur une colonne, plus l'intensité baisse, défaut qui n'existe pas avec les lampes commandées 1 à 1 (sauf si le transfo est sous-dimensioné bien sur et que la tension s'effondre en fct du nombre d'ampoules)

l'intensité baissera si les transistors sont sous-dimensionnés, mais dans le cas contraire ce sera à peine perceptible. (à moins de pousser le zèle à contrôler l'intensité circulant et de faire un hachage de la tension d'alimentation : AUCUN changement de luminosité )

Un port // est très rapide et suffit largement à commander les ampoules, même sans passer par un µC avec simplement un registre à décalage et une commande d'ampoules 1 par 1 (je crois d'ailleur que pinmame-hw première version marchait comme ça)

entièrement d'accord avec toi, d'ailleurs il reste bien plus rapide que l'interface série des PC, mais infiniment plus lent que la plus pourrie des connexions USB

Ce que je propose :
-interface USB du PC vers la carte.
-circuit de conversion USB->serie sur la carte, une liaison que je connais bien.(ce qui permet de l'interfacer soit en usb soit avec le port serie sur un vieux PC)
-microcontrôleur sur la carte pour commande des lampes, bobines, affichage et retour de tous les contacts vers le PC.
-interface de puissance 1pour1 pour les bobines, matrice 10*10 pour les lampes
-entrée 10*10 des switch sur le microcontrôleur.
-Transformateur torique pour l'alimentation de tout ce bazard !

voilà, @+

[damien d.]

le souci est bien plus complexe que ça en réalité. Les contacts par matrice ne fonctionnent pas par rapport à la masse, mais par rapport aux lignes/colonnes.
Pour expliquer simplement le principe :
chaque contact est cablé sur une ligne et une colonne d'un tableau (soit 8 contacts par ligne/colonne pour une matrice 8*8, logique).
Lorsque tu met à 1 l'état d'une ligne, tu lis l'état de toutes les colonnes et ainsi tu verra les contacts fermés et ouvert en fonction de l'état des colonnes... Si c'est pas clair je ferai un schéma !

Heu, on sais comment marche une matrice de contact tout de même...
L'idée, c'était d'utiliser deux I-PAC en même temps, et de faire 112 contact, sans matrice.

Ce que je propose :
-interface USB du PC vers la carte.
-circuit de conversion USB->parallèle sur la carte.(ce qui permet de l'interfacer soit en usb soit avec le port parallèle sur un vieux PC)
-microcontrôleur sur la carte pour commande des lampes, bobines, affichage et retour de tous les contacts vers le PC.
-interface de puissance 1pour1 pour les bobines, matrice 10*10 pour les lampes
-entrée 10*10 des switch sur le microcontrôleur.
-Transformateur torique pour l'alimentation de tout ce bazard !

Ca va ramer abominablement, je le vois d'ici.
bing, la bille touche un bumper.
.
Retour du contact vers le PC...
Traitement de la tache dans le programe...
retour de la commande de bobine vers la carte (avec le port USB qui est surchargé par l'update de l'afficheur)...
mise en ouvre de la commande...
.
BANG!, le bumper fappe =)

Plusieurs interfaces (une pour les contacts, une pour les afficheurs, une pour les lampes, une pour les bobines) serait a mon avis, d'une, beaucoup plus flexible (pas assez de contacts? hop, on plug une autre carte) et a mon avis plus fiables.

Alors tu veux un cahier des charges? =)
On y va, soyons fous:
-Une carte pour les contacts, qui gère une matrice de contact de 10x10, et qui envoie le retour sur un port USB de PC.
-une carte driver pour les lampes, qui gère une matrice de lampe de 10x10 commandé par un port USB de PC.
-une carte driver de bobines / flashers / moteurs / etc, capable de commandés, mettons, 25 sorties (soyons fous! voir plus! =) ), commandés par un port USB de PC.
-une carte driver d'afficheur capable de piloter un afficheur Williams 2x16 digit Alphanumérique de Sys11 ou WPC. Allez, je vais etre gentil, pour t'éviter de faire une alim haute tension, je n'utiliserait que des afficheurs PinLED (soit les références 10001, 10003 ou 10007 chez PinLED)
-une carte d'alim qui alimentera tout ce bazard avec les tension qu'il faut ET qui integrera une alimentation ATX de PC!

[romain]

Ca va ramer abominablement, je le vois d'ici.
bing, la bille touche un bumper.
.
Retour du contact vers le PC...
Traitement de la tache dans le programe...
retour de la commande de bobine vers la carte (avec le port USB qui est surchargé par l'update de l'afficheur)...
mise en ouvre de la commande...
.
BANG!, le bumper fappe =)

pas "totalement" faux, mais à moins de mettre tout le programme ou du moins une partie dans le microcontrôleur en local j'ai pas mieux à proposer. Cependant pour les afficheurs, je ne vois pas en quoi la liaison serait saturée s'il n'y a mise à jour que lors du changement du message a afficher (admettons une moyenne de mise à jour toutes les secondes, environ 1 octet de donnée par digit soit 32 octets... sur 1Méga on est large non ? )

Plusieurs interfaces (une pour les contacts, une pour les afficheurs, une pour les lampes, une pour les bobines) serait a mon avis, d'une, beaucoup plus flexible (pas assez de contacts? hop, on plug une autre carte) et a mon avis plus fiables.

pourquoi pas (tout est à définir) cependant une dizaine de câbles USB vers le PC c'est pas un peu surdimensionné ??

Alors tu veux un cahier des charges? =)
On y va, soyons fous:
-Une carte pour les contacts, qui gère une matrice de contact de 10x10, et qui envoie le retour sur un port USB de PC.
-une carte driver pour les lampes, qui gère une matrice de lampe de 10x10 commandé par un port USB de PC.
-une carte driver de bobines / flashers / moteurs / etc, capable de commandés, mettons, 25 sorties (soyons fous! voir plus! =) ), commandés par un port USB de PC.
-une carte driver d'afficheur capable de piloter un afficheur Williams 2x16 digit Alphanumérique de Sys11 ou WPC. Allez, je vais etre gentil, pour t'éviter de faire une alim haute tension, je n'utiliserait que des afficheurs PinLED (soit les références 10001, 10003 ou 10007 chez PinLED)
-une carte d'alim qui alimentera tout ce bazard avec les tension qu'il faut ET qui integrera une alimentation ATX de PC!

Tout ceci est matériellement réalisable, sans grande difficulté, par mes soins.
Reste la programmation du soft sur PC, le script ressemble fortement à du script VB, langage que je connais, avec lequel je programme déjà mais depuis très peu de temps, c'est peut-être jouable...

quelques questions pour toi maintenant :
comment comptes-tu t'y prendre pour réaliser le plateau de 3Angels ? C'est un plateau bien plus complexe que la plupart des flips existants... pour l'impression je suppose que tu fera imprimer ça chez un imprimeur mais as-tu une montagne de pièces détachées pour la mécanique et les lampes ??
Pour les afficheurs, tu es prêt à mettre 300€ dans un kit PinLED ?

Si tu veux qu'on puisse en discuter plus facilement, msn est l'idéal... histoire qu'on voit si c'est jouable, réalisable et en combien de temps...
@+

[Papo06]

L'usb ne sert pas à grand chose si on utilise pas de µC, avec un port // on atteint plus de 50ko/s même avec une vieille brouette et le mode le plus pourri (ni EPP ni ECP), de plus l'électronique est super simpliste et on peut cascader autant de cartes qu'on veut, soyons fous un flip avec 128 activateurs (bobines, moteurs, etc) et 128 lampes même sur un pc à 50ko/s pourra encore mettre à jour la totalité des bobines et lampes 1600 fois/seconde (50*1024) / (4*8 )

c'est exactement comme ça que marche pinmame hw première version.

c'est simpliste, ça marche, mais la quantité de filasse et de transistors est ahurissante puisqu'il faut 64 fils au lieu de 16 par matrice.

voir la photo : http://www.pinmame-hw.com/aconner-pinma ... sh-pdb.jpg

par contre on ne peut pas faire le matricage des lampes avec le pc, le moindre 'glitch' de l'os et la matrice s'arrete de tourner une fraction de seconde, fraction suffisement longue soit pour cramer les ampoules, ou moins pire ça se verra et ça sera moche visuellement car irrégulier, il faut impérativement que l'horloge soit indépendante du PC et stable avec 1/8 de temps pile pour chaque colonne.

donc µC, dans la future version je sais qu'il voulaient utiliser un atmel atmega, le pc envoi toute la matrice et même l'afficheur directement en mémoire du atmel et c'est le µc qui gère le matricage et l'afficheur, par contre les switch sont toujours gérés par un ipac, car c'est simple et ça marche.

l'avantage des ipac c'est que le buffer est intégré et aucune touche fantome ni touche perdue, même si la bille tape très rapidement sur 2 cibles en même temps ou entre les bumper tout est sérialisé et renvoyé mais reste le pb comme dit damien du delta T entre l'instant ou la bille touche une assiette de bumper, que l'ipac code le caractère et l'envoi sur l'interface clavier (relativement lente), que le programme récupère la touche, calcule l'action (activer bobine bumper), et renvoie une trame complète sur le port // (ou dans le µC via usb ou autre) et que le transistor soit activé.

faut pas que tout ça dépasse 30-40ms je pense sinon ça commence à se voir, un temps de réaction de 100ms est parfaitement perceptible par exemple la bille aura presque rebondit d'un slingshot avant qu'il se mette en marche.

Pascal

[damien d.]

pourquoi pas (tout est à définir) cependant une dizaine de câbles USB vers le PC c'est pas un peu surdimensionné ??

Ben, non, 4, et ca tombe bien, la pluspart des cartes-mères de PC ont 4 ports sur le panneau d'E/S

pas "totalement" faux, mais à moins de mettre tout le programme ou du moins une partie dans le microcontrôleur en local j'ai pas mieux à proposer.

Oui, c'est une bonne idée, mais il faut aussi pouvoir commander la bobine et lire le contact indépendament de cette méthode "directe", histoire de rester flexible.

Reste la programmation du soft sur PC, le script ressemble fortement à du script VB

L'idée est d'avoir un programme sur le PC qui gère le materiel, et dans lequel tourne un script, qui se contente de définir les règles du jeu, les choses a afficher, les lampes a allumer, etc.
Ben, comme le fait Visual/Future Pinball, mais avec un vrai flip derrière.
Faudrait pas que le programmeur du jeu doive se taper les routines pour acceder au microcontroleur a chaque fois qu'il veux changer une lampe d'état =)

mais as-tu une montagne de pièces détachées pour la mécanique et les lampes ??

La plusparts des éléments mécanique de ce flip n'existent pas actuellement, mais sont tous déja concus, shématisés sur papier voir dans ma tête dans le pire des cas. Les tables concues par BlindMankind Pinball sur Future Pinball sont crées dans un souci de réalisme total et dans l'idée de pouvoir etre construites. Et c'est moi qui m'occupe (entre autre) de cette partie du boulot =)
Donc non, les seules pièces mécaniques réutilisables serait les platines de flips et les mechs de bumpers, le reste, faut se le taper a la main =) Mais la mécanique de flip n'est pas super compliqué, je refait déja des pièces manquante de flips existant, alors en fabriquer pour un flip qui n'existe pas encore, aucune difference.
Les plots / douilles / vis etc, sont dispos neufs.

Pour les afficheurs, tu es prêt à mettre 300€ dans un kit PinLED ?

Bah, 300E (+ impressions, le bois, les bricoles, la fabrication des cartes, etc, mettons 1500E total) pour un flip INEDIT, NEUF et UNIQUE, c'est pas cher payé non?
Y'a le boulot bien sur, mais bon, v'la la motivation quoi =)

Si tu veux qu'on puisse en discuter plus facilement, msn est l'idéal... histoire qu'on voit si c'est jouable

Ouais, histoire de voir si tu te paye pas de ma tête surtout =)

[damien d.]

faut pas que tout ça dépasse 30-40ms je pense sinon ça commence à se voir, un temps de réaction de 100ms est parfaitement perceptible par exemple la bille aura presque rebondit d'un slingshot avant qu'il se mette en marche.

Le PinBall2000 de Williams avait un temps de réponse de 2ms dans cahier des charges!

[Papo06]

A mon avis t'auras jamais 2ms de delais entre la fermeture du switch d'un plateau et l'activation d'une bobine, en particulier si tu utilises un truc aussi pourri que le VBscript ou autre langage interprété de ce genre. ça marche sur vp / fp parce que c'est aussi vp/fp qui gère la bille, il peut donc faire tourner le programme entre chaque image de façon synchrone et il sait ou est la bille, là c'est asynchrone et sur du hardware moisi (wms utilisait une carte bien spécifique directement sur le port pci il me semble non ? (prism) et avec un os minimal et tout le soft était compilé, pas interprété

Pascal

[damien d.]

Ha mais je disait pas que c'était possible en amateur, je disait juste que Williams l'avait fait =)

Avec un port // donc

[Papo06]

Avec un port // donc

Pas si tu utilises un µC externe, le port // est totalement inadapté car il bouffe beaucoup trop de lignes d'E/S.

Le port // c'est parfait si électronique simpliste avec des registres à décalage.

Si µC il faut passer par l'i2c ou usb.

Remarque on peut aussi faire de l'i2c directement depuis le pc et le port // l'avantage de l'i2c c'est la simplicité de mise en oeuvre des cartes en particulier pour les afficheurs il y a deja des composants tout faits

Pascal