Aller au contenu

Akira76

Membre
  • Compteur de contenus

    1 157
  • Inscription

  • Dernière visite

  • Jours gagnés

    20

Messages posté(e)s par Akira76


  1. Oups, je viens de me relire et c'est chez digikey que les taxes sont systématiques, mouser jamais essayé, farnell encore moins mais bon, il y a deux avantages à commander sur des sites pro, c'est les délais de livraison et le fait d'être sûr de ne pas se retrouver avec genre des 7032S qui ne sont que des 7032 en fait (Ichi sait de quoi je parle).

    Par contre, clair que ce n'est pas le même tarif mais en commandant en quantité moyenne ça peut devenir rentable.


  2. Bon, je vais répondre brièvement alors :

    - Pour le problème d'isolation de l'alim, le transfo était à titre d'exemple, dans le cas où on part d'une alimentation AC, évidement, en DC on ne branche pas directement un transfo ou alors ça fait un joli court-jus.

    Maintenant pour les feignasses comme moi il existe des convertisseurs DC-DC isolés a pas cher (~1.5€)

    - L'optocoupleur dont bulletz parle est en effet celui qu'il faut, mais très cher, peut-être chez conrad ou à l'Aldi du coin, mais en cherchant un peu on le trouve à 2€.

    - Enfin, je suis d'accord, on ne travaille pas avec la tension pour de l'audio à moins d'y être contraint, mais en suivant le premier lien de la page que j'ai linkée, on tombe sur ça : http://www.sonelec-musique.com/electronique_realisations_interface_opto_audio_002.html

     

    Enfin, c'est peut-être moi qui suis à fleur de peau donc désolé de la réaction un peu vive mais j'ai d'autres petits soucis qui font que je monte facilement dans les tours.


  3. Petite remarque sur la partie audio: comme je l'explique sur mon site, la solution qu'on voit partout à base de pont diviseur est potentiellement dangereuse pour certaines cartes JAMMA, c'est pour ça que j'ai opté pour le double transfo d'isolation, qui permet de gérer toutes les configurations (mono, mono H-bridge, stéréo)... Je suis ouvert aux suggestions ceci dit  :)

     

    Yop, je suis bien d'accord avec ça, on oublie trop souvent l'isolation galvanique, dans le meilleur des cas ça bourdonne et dans le pire on peut flinguer la partie audio du pcb ou de l'écran sur lequel on branche le supergun...

    Par contre, et là c'est pour citer la réflexion de X-death, je confirme, les transfo audio sont en général assez cher ($10 c'est abordable, mais ça fait grimper le prix du bouzin quand-même).

    Il y a des solutions moins coûteuses en composants mais plus coûteuse en espace pcb (moindre mal, parce-qu'un supergun doit au moins faire la largeur du connecteur lui-même).

    Le plus courant c'est l'optocouplage, sur ce site il y a un joli article qui explique très bien comment ça fonctionne :

    http://www.sonelec-musique.com/electronique_realisations_interface_opto_audio_001.html

     

    Maintenant vous n'avez plus d'excuses, il faut vous mettre au boulot  :mrgreen:


  4. Après une première analyse, pas de possibilité de généraliser la rom de ribbit comme ça a été fait pour les autres, en tout cas pas aussi facilement.

    Je m'explique, les autres jeux vérifient simplement que le résultat renvoyé par le chip de protection correspond à ce qui est attendu, pour ribbit, et à priori twin squash d'après les sources de mame le résultat obtenu est utilisé entre autres pour organiser les palettes.

    La seule solution "facile" que je vois est d'implémenter en assembleur 68k ce que fait le chip de protection. Heureusement l'algo est dans les sources de mame mais je ne touche pas ma bille en 68000 donc il faudrait trouver quelqu'un qui connait, et grosso modo insérer un call vers la sous-routine à la place de l'appel au lockchip.

    Je continue à plancher là dessus demain.


  5. Pour faire simple il faudrait que le temps d'adressage de la sram série + le temps de lecture de l'octet à l'adresse sélectionnée + les temps de codage/décodage série/parallèle, bref tous ces délais additionés soient inférieurs à 100ns (là je parle de la snes, je sais qu'avec des flash 120ns c'est déjà limite)


  6.  

    Au risque de passer pour un casse-burettes, non ce n'est pas possible, le principe des everdrive c'est de programmer une RAM ou SRAM parallèle qui sert de buffer, et la console lit les données contenues dans ce buffer.

    Malheuruesment les temps d'accès des flash et RAM série sont beaucoup trop longs pour permettre le codage/décodage série/parallèle/série sans provoquer des interruptions dans le flux de données. (en tout cas, pas pour un budget restreint ;-))

    Sur cet everdrive ci, la SRAM en question c'est le chip ISSI, qui est programmé depuis un fichier séléctionné sur la sdcard par l'intermédiaire du joli cpld qu'on voit en plein milieu de la carte (cpld qui est d'ailleurs un clone d'un Latice, mais l'original devait être trop cher)

    Bref, si c'était faisable c'est clair que ça serait une belle économie, mais à moins de le faire pour des systèmes super lents (style atari 2600) ça ne marche pas pour l'instant.

    Maintenant le dieu de la Master system qu'est Ichi pourra peut-être confirmer que pour le cas précis de la sms c'est faisable étant donné qu'une des pin du port cartouche sert à mettre le cpu en pause (le temps de préparer l'octet suivant) mais idem, pas sûr que les autres périphériques de la console apprécient ça.

×
×
  • Créer...