Aller au contenu

Akira76

Membre
  • Compteur de contenus

    1 157
  • Inscription

  • Dernière visite

  • Jours gagnés

    20

Tout ce qui a été posté par Akira76

  1. Oui, c'est exact, c'est pour ça qu'il n'y aura que deux pcb adaptateurs au final. Là c'est plus compliqué, j'ai sous les yeux des pcb avec maskroms 28 pins où il n'y a pas la place de mettre un 32, donc il y aura bien un pcb différent pour les 28 et 32 pins, un pcb commun pour la programmation et un pcb header pour la programmation 28 pins. Comme expliqué plus haut, les maskroms 28 broches NES peuvent monter à 1Mb (128Ko) ce qui n'est pas le cas des eproms/flash donc il faut pouvoir accéder à A16 et, /WR et VCC pour la programmation du chip. Les premiers prototypes sont déjà prêts, j'attends juste lundi prochain pour voir combien de personnes participent au final.
  2. Si c'est le cas, il a des goûts de chiotte dans ses choix de cartmods ;-) Allez, qui est dans le 31, dénoncez-vous! :mrgreen:
  3. Salut X-death, y'a pas de mal pour tes questions, il y a deux avantages principaux : - les 39sf n'existent qu'en DIL32, pas, les maskrom snes de 256kb à 1Mb sont en 28 pins - le fait de passer par un adaptateur permet de n'avoir aucune redirection, c'est un drop-in replacement Concernant le format, je suis d'accord, le tsop n'est pas le plus facile à souder, mais pour avoir fait 90% de mes mods snes avec du 29f040, avec l'habitude ça devient piece of cake.
  4. Ok, on est déjà à 8, et j'annonce après calcul que si on dépasse les 10 le prix baissera à 25€/personne pour le même nombre de pcb fournis par utilisateur. Je fournirai également une comptablilté de l'usage des fonds au fur et à mesure.
  5. Aaah, c'est bon tout ça! Je comprends mieux pourquoi on voit moins le chef en ce moment ;-)
  6. Ayant fait le tour de la super nintendo (enfin, de ce qui m'intéressait dessus en tout cas), j'ai commencé à regarder de plus près la famicom (surtout depuis que j'ai reçu ma famicom AV et le NESRGB d'eviltim) J'ai fait le tour des différents tutos, des pinouts de la bête etc. et j'ai pensé qu'on pouvait faire des adaptateurs TSOP->DIL sur le modèle de celui des 29f032 sur super nes. En partant de la série microchip 39SF0x0 on a pas mal de possibilités (de 1 à 4Mb suivant le modèle, existe en tsop32, disponible en échantillon gratuit, etc.) Par contre, l'investissement de départ est un peu élevé pour moi, le seul endroit où j'ai trouvé ces chips en stock, c'est chez digikey, et leurs frais de port sont exagérés donc il faudrait partir sur une production à moyenne échelle. S'ajoute à ça la production des prototypes et les erreurs potentielles qu'ils peuvent contenir, bref, j'atteinds un chiffre suppérieur à 100€ que je ne peux pas assumer seul (enfin si, je pourrais mais ça dépasse ce que je compte investir dans mes mods NES). Je lance donc ici un projet en crow funding pour le développement de ces adaptateurs qui seront au nombre de 5 ou 6 (DIL28 et DIL32 vers TSOP32 pour CHR et DIL28 et DIL32 vers TSOP32 pour PRG, ainsi que l'adaptateur qui permettra de les programmer sur GQ ou Wiillem. Le 5 ou 6 vient de là, à déterminer s'il est plus rentable de faire des adaptateurs séparés pour PRG et CHAR ou si c'est faisable proprement sur un dataptateur unique.) Si suffisament de personnes sont intéressées, je pense que pour 30€ par personne il y a moyen de produire ça, et de fournir à chacun : - 3 adaptateurs PRG 28 pins - 3 adaptateurs PRG 32 pins - 3 adaptateurs CHR 28 pins - 3 adaptateurs CHR 32 pins - 1 adaptateur pour la programmation (ou deux si PRG et CHR doivent être séparés) - 12 39SF010A TSOP Soit en combinants tous les éléments ci-dessus de quoi faire 6 mods complets. C'est un travail de longue haleine, parce-que les prototypes que je commande chez oshpark comme chacun le sait ont un délais de livraison de ~3 semaines donc s'il y a un souci de proto, il faut compter 3 semaines de plus pour les nouveaux. Une note assez importante : je ne compte pas faire de bénéfice sur ces adaptateurs, le tarif de 30€ annoncé est révisable à la baisse en fonction du nombre de participants, les schémas et typon des différents pcb seront rendu publics sous license OSH (open source hardware) quand le projet sera bouclé. Donc messieurs-dames, à votre bon coeur, aidez la "recherche" à progresser :wink: Participants au 16/03/2014 : - Akira76 - Exocil - Msieur Citron - Izidor - Redfield1 - footix - baby - SkunK - ltrmars La cloture des candidature se fera le 31/03/2014, date à laquelle le prix exact (et le plus bas possible) sera calculé.
  7. Holà amigo, welcome to our merry forum,hopefully you're going to be able to improve despite the language gap, google always isn't your friend!
  8. Voilà une version qui utilise libtga au lieu de la fonction d'origine. Par contre, j'ai un bug avec le support du RLE, je me pencherai dessus demain je pense. gfx2sfc-1.0.1.121.7z
  9. Ah, le mario bmp c'est ma faute, j'ai oublié de supprimer la couche alpha en exportant de gimp :wink: Pout le TGA, pas fait attention, mais c'est très possible que la palette ait une baffe, je n'ai pas retouché la méthode d'import d'origine, Je peux essayer de la refaire avec libtarga ce qui ferait grossir un peu plus l'exe mais permettrai aussi de supporter les targa avec compression RLE.
  10. Back in love with C

  11. Ça a pris du temps, mais voilà la 1e version de prod de l'outil et un petit résumé des "fonctions" : - correction des problèmes de drag & drop. - correction de divers soucis d'allocation de mémoire. - réécriture complète du générateur de tilemap. - support des formats pcx, bmp, tga et png en couleurs indexées. - centrage de l'image sur l'écran snes si sa taille est inférieure à 256x224. - génération d'une rom avec un checksum correct. - compilation statique de l'exe (pas de dll supplémentaires requises, d'où sa taille) Je n'ai pas encore totalement nettoyé le code (basé sur gfx2snes, pas mal de choses qui ne servent pas pour cette utilisation là, donc c'est encore un peu fouilli). Merci de rapporter les bugs éventuels (et il y en aura j'en suis sûr). gfx2sfc-1.0.0.0.7z
  12. Bon, pas trop eu le temps de bosser dessus ce weekend, mais voilà quand-même une version un peu plus complête. Les trois points du post précédent sont réglés, j'ai légèrement retravaillé la génération du tilemap, maintenant tout est bon... sauf le premier tile qui est blanc. En attendant mieux, j'ai re-joint les sources, l'exécutable, et quelques images de test. Je suis toujours en train de bosser sur le support gf/png mais je ne suis pas loin d'abandonner, ça fait vraiment trop longtemps que je n'ai pas fait de C, j'ai pas mal perdu ;-) gfx2sfc.7z
  13. Je suis toujours en train de bosser dessus. J'ai : - séparé les différentes fonction du programme en modules - récupéré le support bmp/tga du gfx2snes d'Alekmaul. - réglé le problème de drag&drop de fichiers J'ai encore des soucis de calcul du tilemap (maintenant j'ai les deux tiles en bas à gauche de l'image qui sont décalées d'un pixel vers le bas. Bref, je suis sur le job, je reviens vers toi pendant le weekend avec une autre version "stable"
  14. Ouaip, j'ai vu le souci avec le dernier tile, pas encore trouvé de quoi ça vient. Par contre, moi je n'ai pas de soucis avec le pcx sous photoshop image > mode > indexed colors file > save as ...
  15. Je suis en train de réécrire le tout, c'était juste pour vérifier que ça fonctionnait en fait. Je vais essayer d'ajouter le support d'un max de formats de fichiers, une fois que le bitmap est chargé en ram, c'est la même routine pour l'encodage de toute façon.
  16. Ah, oui, je n'ai pas fourni le code pvsneslib, mais c'est le plus simple du monde : #include <snes.h> extern char pad_patterns1, pad_patterns2; extern char pad_palette, pad_map; int main(void) { consoleInit(); setMode(BG_MODE3,0); bgSetDisable(1); bgSetDisable(2); bgInitTileSet(0, &pad_patterns1, &pad_palette, 0, 0x0, 0x200, BG_256COLORS, 0x0000); dmaCopyVram(&pad_patterns1, 0x0000, 0x8000); dmaCopyVram(&pad_patterns2, 0x4000, 0x8000); bgInitMapSet(0, &pad_map, 0x800, SC_64x64, 0x6000); setFadeEffect(FADE_IN); while(1) { } return 0; }
  17. Ah oui, j'ai oublié de répondre à ta question, oui, une fois que c'est terminé, ça ne me dérange pas du tout que tu proposes ça à TRAF, moi perso, je ne suis pas assez doué en romhacking pour que ça me serve vraiment ;-)
  18. Ok, j'ai quelque chose, Ce n'est pas exactement ce que tu veux, et pour l'instant c'est juste un hack quick & dirty de pcx2snes mais bon... Actuellement ça fonctionne avec des images pcx en 256 couleurs quelle qu'en soit la taille (dans la limite de celle de l'écran snes, bien sûr), il faut plus voir ça comme un proof of concept qu'un outil réel. Dans l'archive attachée tu trouveras un pcx2sfc.exe qui est l'outil qui va convertir une image pcx en .sfc, le source du programme ainsi que les deux images qui m'ont servi pour mes tests. Ce n'est pas du python, c'est du C, ça se compile sans soucis avec mingw sous windows, avec gcc sous linux, donc je suppose avec gcc sous macos aussi (je ne peux pas tester ça). Dis-moi ce que tu en penses et si je dois continuer dans cette voie ou si tu pensais à quelque chose de totalement différent. Edit : Bon, tapé trop vite, du coup je viens de corriger mes fautes pour obtenir un post intelligible... pcx2sfc.7z
  19. C'est exactement ce que je suis en train de faire, étant donné que les sources de pcx2snes sont disponibles, ça devrait être faisable sans trop de soucis (sachant qu'il faut gérer les différents modes/palettes) mais j'ai confiance pour l'instant.
  20. Je pense que c'est possible en utilisant pvsneslib déjà, mais là je parle du kit complet, pas seulement d'un outil en ligne de commande. Je vais voir si je peux te bidouiller un truc qui le fait comme ça mais je ne promets rien, je ne suis pas un champion ;-)
  21. Le CIC est une protection matérielle, il n'est pas détectable de façon logicielle à ce que je sais.
  22. Oups, je me serais trompé de rubrique en postant? Désolé. Je ne comprends pas bien le menu de mopoz, je suis en train de regarder les instructions du 65c816 pour en savoir un peu plus.
  23. J'entends par là mettre plusieur jeux dans une seule eprom. Je sais qu'il existe la solution du compteur binaire couplé au reset pour choisir une rom, mais est-ce qu'on peut (oui, on peut) le faire de façon logicielle? En gros, si je veux faire une compilation avec top gear (4Mb) et top gear 2 (8Mb) avec un menu au démarrage pour choisir quel jeu lancer, est-ce qu'il existe un outil pour reloger top gear 2 dans les banques supérieures de la rom (qui changerait tous les jumps, etc.)? C'est juste une idée comme ça, mais si quelqu'un pouvait me mettre sur la voie ça serait pas mal.
×
×
  • Créer...