SDisk Emul project Final et pré-commandes - Page 18

sundance (./508) :
Bonsoir,

Des nouvelles:

Le SDisk V2 :

Comme vous avez pu le voir le schéma et le typon ont été mis a jour sur le site, le projet pour réaliser la carte est disponible aussi.

Dans un deuxième temps le fichier .hex du pic seras mis en ligne.
A partir de ce moment tout un chacun pourras réalisez son SDisk. (J’assisterais les premiers à ce lancer dans l’aventure)

Enfin le troisième acte verra la mise en ligne des sources. (Oui je suis en train de « normaliser « et documenter ces dernières)

D’ici la il y aura quelques évolutions du coté firmware.

Tous ca pour vous annoncer la mise en chantier d’un nouveau projet, toujours dans le domaine de l'émulation de floppy, cartouche, hdd. Le financement est en partie supporté par un mécène à partir de janvier 2009.

L’étude est déjà entamée mais pas encore terminée, certain composants sont déjà en cours d’approvisionnement.

Cependant tout n’est pas encore finalisé si vous avez des idées elles sont les biens venues.

Bien sur nous ne pourrons supporter l’étude, le développement logiciel, la maintenance du site internet, la fabrication et le suivi de 2 projets simultanément sans un accroissement de notre effectif.

Donc si l’aventure vous intéresse... Contactez-nous.
(Sachant que tous les domaines seront les biens venus)

La mise en place de ce nouveau projet explique notre discrétion ces derniers temps et le report de la fabrication prévue au mois de septembre.

L’équipe Atariamiga

Moi je suis interressé par le sujet !
Mais vous cherchez quel type de profil exactement ?
Il y a aura une capacité de prod "serieuse" ? (Oui parce que souder 200 cartes à la main c'est marrant, mais pas longtemps en fait... )

Ouaip, pareil que Jeff
Si y'a moyen de filer un coup de main, j'essaierai, malgré le peu de temps que j'ai en ce moment (bébé powah).

(risette à ton bébé)

et GG les gars c'est vraiment une tuerie votre projet.

une nouvelle serie a été lancé et sera dispo a la RGC ?

Comme Sundance l'a ecris il semble que non.

pardon j'avais pas vus ce post là, je me referais à leur site qui en parlait encore c'est pour ça

Kuk

je ne t'ai pas oublié j'ai garder un SDisk pour toi seras tu la pour la prochaine RGC ?

Bonjour,

Pour les personnes qui souhaitent nous rejoindre (ou le contraire on peut rejoindre d'autres personnes, la n'est pas la question)

Dans l'ordre :
PulkoMandy, Jeff, Torlus, et les autres potentiellement interressés ....


pas question de souder la totalité des composants (uniquement les composant piqués , en gros les connecteurs et encore...) car la plupart des composants sont en cms
Moi aussi j'en ai ras le bol de souder.....
Donc une option sur 100 circuits imprimés câblés avec une présérie de 10 pièces. (cette partie ne pose pas de problème)

Je laisse la liberté a chacun d'être moteur sur ce qu'il souhaite, en gros on intègre après discutions.
Sachant que le thème générale sont les sasefaipus .

Pour l'instant Pic32 tqfp 100 pins et 1 mo de Sram, lm 1881, mais comme je le dis rien est figé on peut rajouter ou enlever beaucoup de choses


Les profils souhaités :

Bien sur ingénierie électronique

Développement (c’est vaste vhdl / c/ asm/ etc.)

Beta testeur (oui déjà je n’ai pas toutes les machines pour tester le SDisk actuel...)

Marketing international de masse (la c’est de l’humour)

Mais ce n’est pas exhaustif si quelqu’un estime qu’avoir une doc en béton avec de belle photo est nécessaire ca place est réservée etc.

Le but avoué est d'utiliser les compétences de chacun au mieux afin d'avoir une base flexible sur un projet ou tout le monde y trouve son compte.

si vous avez des questions de toutes sortes, je suis dispo

sundance (./517) :
Kuk

je ne t'ai pas oublié j'ai garder un SDisk pour toi seras tu la pour la prochaine RGC ?

\o/

Oui, et encore Merci

ah oui avec un PIC32 et 1Mo de buffer il y a moyen de faire un bel émulateur floppy, avec support du formatage (dans un mode transparent : on branche le truc sur une machine dont le format floppy est "inconnu" et ça roule...) et des disquettes protégées (support du variable bitrate: voir si ça ne nécessite pas de glue en +).
Coté IHM je pense qu'il faut laisser la possibilité d'y ajouté une éventuelle petite carte fille LCD+boutons. Un bus I2C et une ligne d'IT suffit et ça ouvre le truc sur des machines ou attaqué la vidéo n'est pas praticable (je pense aux synthés par exemple). Avec ça il y a possibilité de faire du business (beaucoup de demande coté musique, et dans l'industrie...).
Si possible pouvoir brancher le truc via USB a une autre machine (PC/MAC...). Je peux t'assurer que les développeurs adorent ça (compilation -> génération de l'image -> et envoi du truc en direct vers le sasfepu en quelques secondes).

Sinon coté tests sur machine l'un des moyens efficace est se mettre en relation avec des assos comme MO5 (en difficulté en ce moment) ou Silicium.
Je pense qu'ils possèdent tous ce que la création a fait en terme de machine ;-). J'ai l'occasion de faire mes tests chez MO5, mais en ce moment les machines sont bloquées dans les cartons.
Sinon Torlus est membre de Silicium ;-).

Sinon coté compétence de mon coté: électronique (conception/routage/etc), dev fpga et co (vhdl), dev C/C++ (sur uC, linux (appli&driver), windows (appli&driver), etc), dev asm là ou il le faut (mon premier langage ;-) )

Mais je m'égare :

En fait il y a encore quelques points pas trop clair. Tu parles "de domaine de l'émulation de floppy, cartouche, hdd": ça signifie que la carte sera multifonctions? (Attention au coût...)
Ou s'agit t'il de cartes/projets différents ?
Tu parles d'un mécène : Il y aura t'il possibilité de mettre truc par exemple en "open source" ou le deal verrouille t'il la chose?

Kuk:

si tu peux amener ta machine a la rgc je t'installe le SDisk (indique moi le type de machine je preparerais le SDisk)

merci il s'agit d'un mega ST1

Bon on va rentré dans le vif du sujet,

oui un 1 mo est un mini, pour l'instant j'ai vu de sram sur farnell en 12ns ou 55ns en 256ko par 16 bits cependant j'ai aussi une centaine de barrettes edo sur les bras et j'en recupere regulierement,mais il y a peut etre d'autre alternative...

j'ai aussi approvisionner 40 lecteur 3 1/2 avec nappes (la c'est du neuf) tu l'as bien compris le but est aussi bien d'emuler que de lire une disquette.

oui une carte fille lcd seras la bien venus pour le machine dont l'incrust video est compliqué ou impossible trés bonne idée.
les boutons je suis en train de voir aussi ....

le pic 32 possede un port usb dispo

un port rs 232/i2c est dispo aussi

cartouche = genre vcs 2600 ou autre console

hdd = acsi

une carte mutifonctions peut etre pas au depart, mais part la suite oui certainement.

le cout va etre primordial donc il va falloir faire les bons choix.

mécène aucun verrouillage , on décide de tout comme on veut, quand a moi c'est ok

oui un 1 mo est un mini, pour l'instant j'ai vu de sram sur farnell en 12ns ou 55ns en 256ko par 16 bits cependant j'ai aussi une centaine de barrettes edo sur les bras et j'en recupere regulierement,mais il y a peut etre d'autre alternative...

oui le choix de la ram est important. Le problème de la SRAM de cette taille c'est l'appro et le prix. Le problème de la DRAM (EDO,FPM,etc) c'est sa gestion et les perfs optenues avec un contrôleur "soft"(rafraîchissements, sélection ligne/colonne etc.). Choix problématique.

j'ai aussi approvisionner 40 lecteur 3 1/2 avec nappes (la c'est du neuf)

Ah carrement ;-)

Tu l'as bien compris le but est aussi bien d'emuler que de lire une disquette.

Oui c'est un truc que j'ai dans les cartons et qui manque effectivement : un espèce de Catweasel USB (ou autre) pour faire des dumps "haute résolutions" des disquettes (protégées ou non). Le truc que j'avais fait envois par USB l'écart (en nombre coup d'horloge) entre 2 pulses en provenance du lecteur. Avec ces données l'image obtenue est une copie quasi physique de la disquette. L'efficacité du truc dépend de la résolution du sampling (ça tourne dans un fpga donc je n'avais pas de pb de ce coté là). La grosse partie est ensuite dans le soft d'analyse de ces infos (retrouver les secteurs/détections des erreurs/ des bitrates/ flakeys bits/etc).
ça c'est un truc sympa a faire.

oui une carte fille lcd seras la bien venus pour le machine dont l'incrust video est compliqué ou impossible trés bonne idée.
les boutons je suis en train de voir aussi ....

voir pour un chip gpio i2c capable de generer des IT (http://www.standardics.nxp.com/products/gpio.expanders/i2c/)

le pic 32 possede un port usb dispo

un port rs 232/i2c est dispo aussi

cartouche = genre vcs 2600 ou autre console

Torlus c'est amusé avec ça il y a pas longtemps http://www.torlus.com/

hdd = acsi

une carte mutifonctions peut etre pas au depart, mais part la suite oui certainement.

le cout va etre primordial donc il va falloir faire les bons choix.

mécène aucun verrouillage , on décide de tout comme on veut, quand a moi c'est ok

ok s'il y a besoin de faire des outils pour générer/décoder des images, je suis partant.

A ce sujet le code de l'application de l'HxCFloppyEmulator a été ouvert cet été et est dispo là : http://hxc2001.free.fr/floppy_drive_emulator/HxC_Floppy_Emulator_soft_src.zip
Il s'agit principalement d'un chargeur/convertisseur d'image (*.ST/*.MSA/ADZ,DSK,etc) vers du MFM brut (un outil dérivé permet de convertir toute une arborescence automatiquement). Vu que tu supportes déjà du track mode, je peux si tu veux rajouter un format adapté pour le Sdisk (un format track mode bien sur ;-) ).

Jeff_HxC2001 (./524) :

oui une carte fille lcd seras la bien venus pour le machine dont l'incrust video est compliqué ou impossible trés bonne idée.
les boutons je suis en train de voir aussi ....

voir pour un chip gpio i2c capable de generer des IT (http://www.standardics.nxp.com/products/gpio.expanders/i2c/)

ou encore un petit uC (microchip pour pas changer ;-) ) avec un i2c slave pour la gestion lcd + boutons.

en effet la sram est assez chère, mais facile a exploiter, la sdram (en chip) en beaucoup moins chère (et taille + élevée) mais a exploiter c'est compliqué....

pour la lecture de disquette, la vitesse de sample est importatnte avec le pic je vais voir si 25 ns est possible....

je regarde le un chip gpio i2c capable de generer des IT (http://www.standardics.nxp.com/products/gpio.expanders/i2c/) ou un pic de plus
ou si on peut intégré le tpus dans le pic32, c'est vrai qu'un autre capot ca serais pas mal.

une question quel le coup pour intégré une cpld genre altera ?

de mon coté je vais e renseigner pour les appros de cpld ....

connais tu la marque lattice ?

Cool je n'avais pas vu que Torlus avait fais une carte pour les cartouches VCS.

du developpement il va y en avoir pas mal


Torlus,(risette à ton bébé),si tu peux nous donner un coup de main dans le peu de temps qu'il te reste (les enfants ca occupe ... j'en ai 2...mais ils sont grand...)
on voudrait aussi avoir ton avis, et surtout par quoi serais tu intéressé, quelles sont tes idées etc


PulkoMandy meme question que Torlus (sans (risette à ton bébé))?

je vous soumet une petite idée : convertir clavier / joy pc usb pour attaquer nos vieux sasefaipu (je sais bien ca deja été fais mais..)

va falloir mettre sur papier tout ca pour savoir ou on va, je vais faire un synoptique grossier qu'on modifiera au fur et a mesure.
ca nous permettras de voir l'etendu des dev, de figer des specs etc.

Mh, ça serait quoi l'idée à la fin ? une carte énorme qui fait le café avec tout ça dessus ? parce que dans ce cas, ça risque de couter cher avec tous ces pics

Moi je sais faire de la prog sur pc en C, C++ et quelques autres, un peu d'assembleur z80 sur Amstrad CPC, puis je m'adapte en fonction des besoins, je suis encore étudiant en électronique et j'apprend de nouveaux trucs chaque semaine
A priori pour le moment je risque d'être plus à l'aise dans un éventuel soft pour pc si y'a besoin de communiquer avec quelque chose, je cherche toujours une interface pas cher pour faire communiquer efficacement mon amstrad cpc avec mon pc et balancer des données de l'un à l'autre, par exemple. Une extension ram pour le cpc, ou de quoi lire une carte sd directement, ça peut éventuellement être de mon ressort.
Les autres machines, j'avoue pas très bien les connaitre, alors je sais pas trop, faut voir

ok tu as raison il faut surveiller le cout de pret , mais pour l'instant un pic + sram + lm 1881 + .....

j'aimerais bien rajouter une cpld, voir un petit pic.

ca va pas trés loin, derriere tout ca une serie de 100 qui va nous permettre de reduire un peu les couts.

les entrées et sortie de cette carte:

en gros:

un port floppy
un bus configurable a volonté (port cartouche, acsi, extension memoire cpc, avec irq etc )
un port sdcard (pour notre stockage de masse sachant qu'on peut y stocké des datas mais aussi une petite appli pour le pic)
un port usb (liaison avec un pc)
un lien serie (emulation des peripherique serie gerne floppy atari 8 bits ou autre)
un port LCD (pour affichage optionnel)

si un 2eme petit pic

un port usb
un port i2c
un port gpio



le pic dispose de 85 pins I/O et tourne a 80mhz (de 128 ko a 512 ko de flash + 32 ko de sram interne)

c'est la plateforme de base.

la ou il va falloir bien cogité c'est le bus configurable...

après les fonctionnalités a y intégrer on décide.Si tu veux mettre en place un système de com avec un CPC pas de problème.

au niveau logiciel embarqué plusieurs solution, on develloppe nos propre fonctionnalité appelable en C sous forme de bibliotheque.

(pour cette partie je pense que Jeff et moi serons moteur)

de cette facon on faciliteras le develloppement du soft, on met au point un petit protocole de com avec un pc via usb ou 232 ou autre.

après viens les softs coté PC (bon la vu mon faible niveau en VB, je pense pas étre trés utile),la tu peux intervenir si tu le désire.


par contre la ou on est trés léger, on a pas ou peut de personne competente sur les machines cible si il faut develloper sur Amstrad/ Atari/ Amiga

un driver ou une apli ca va poser problème.

Je suis ok pour le dév. côté pc (en C++ et Qt, ça marche sous linux et windows comme ça)

Pour info, j'ai déjà du code utilisé par le club de robotique de mon école d'ingénieurs, qui marche bien pour communiquer via un port rs232 de pc, l'astuce c'est qu'on utilise des puces de chez ftdi qui font la conversion usb/série et sortent du 5v directement pour brancher sur le pic. Donc y'a moyen de réutiliser ça a priori, ou de faire autre chose si on a une gestion usb différente. L'avantage de ce truc c'est que ça ne nécessite pas de drivers spéciaux.

Je peux ausi développer et tester du bazar sur amstrad cpc, je connait bien le matériel et pas trop mal le logiciel

Pour le bus reconfigurable, l'idéal serait de mettre un fpga reprogrammable par le pic en fonction de l'utilisation qu'on veut en faire. C'est possible, par contre j'ai pas trop idée de la façon de s'y prendre, et surtout, ça pose de gros problèmes car les fpga travaillent en 3.3v et le reste en 5v, donc y'a de l'adaptation à faire...

PulkoMandy (./529) :
Je suis ok pour le dév. côté pc (en C++ et Qt, ça marche sous linux et windows comme ça)

Pour info, j'ai déjà du code utilisé par le club de robotique de mon école d'ingénieurs, qui marche bien pour communiquer via un port rs232 de pc, l'astuce c'est qu'on utilise des puces de chez ftdi qui font la conversion usb/série et sortent du 5v directement pour brancher sur le pic. Donc y'a moyen de réutiliser ça a priori, ou de faire autre chose si on a une gestion usb différente. L'avantage de ce truc c'est que ça ne nécessite pas de drivers spéciaux.

Je peux ausi développer et tester du bazar sur amstrad cpc, je connait bien le matériel et pas trop mal le logiciel

Pour le bus reconfigurable, l'idéal serait de mettre un fpga reprogrammable par le pic en fonction de l'utilisation qu'on veut en faire. C'est possible, par contre j'ai pas trop idée de la façon de s'y prendre, et surtout, ça pose de gros problèmes car les fpga travaillent en 3.3v et le reste en 5v, donc y'a de l'adaptation à faire...

arf je crois que le truc que tu d'écris existe déjà... :
http://hxc2001.free.fr/floppy_drive_emulator/index.html#USBFloppyemulator
sources ici : http://hxc2001.free.fr/floppy_drive_emulator/HxC_Floppy_Emulator_soft_src.zip
Il Utilise le chip FTDI et fonctionne pour CPC (images DSK). La generation du systeme de fichier a la volée (deja fonctionnel pour ST/Amiga/PC) pour cpc est prévu pour très bientôt.

Ceci dit contrairement a ce que tu dis, les chips ftdi ont besoins d'un driver. Certes il est bien maintenu par FTDI.


le PIC32 fonctionne a max 3.3V donc le design sera forcement 3.3V... le 5V c'est pour les trucs du siecle dernier ;-).

Pour le bus bah moi je vois un bus 8bits classique sur lequel on pourra brancher extensions/interfaces/etc. Vu l'ambition du projet, il va falloir travailler par étapes, et surtout découper le truc en options (l'affichage sur LCD en est une). Un petit bus comme ça le permettra.

rigolo : coupe robot m6 j'ai participer a 2 (les premieres), dev automate (a base de pic) piloter par un palm pilot en rs232 ...

ah le HxC va intégré des fonctionalité qui t'intérèsse PulkoMandy !

en effet le PIC32 fonctionne en 3.3v mais .... les ports en sorties sont parametrables en collecteurs ouverts (18ma) et est ttl compatibel en input.
donc on a une certaine libertée de ce coté la, on peut mettre ce qu'on veut fpga/cpld. Pouvoir le reprogrammer a partir du pic est une bonne idée pour les mises a jour du soft.

Tu as raison Jeff il va falloir travailler par étapes.

le debut :
Fichier joint : Ba faut lui trouver un nom.doc Fichier joint : (Couper_2.jpg)

Encore un peu et ça pourra être un ordinateur indépendant votre carte

Zerosquare (./533) :
Encore un peu et ça pourra être un ordinateur indépendant votre carte

avec un PIC32 sans problème ;-). Son coeur est basé sur du MIPS32

J'ai cru voir quelques tentatives de portage d'uClinux/linux deçu.

c'est vrai avec un pic 1mo de ram et le restant ou seras plus puissant que la plupart des machines cibles !!!

Jeff le LCD a gerer bus du type 8 bits + rs + e + r/w ?

je te demande car il existe un bibliotheque pour gérer du vga sur pic 32 640/480 !! (je pense très penalisant pour les performances generales mais...)

sundance (./535) :
Jeff le LCD a gerer bus du type 8 bits + rs + e + r/w ?

Oui c'est les plus courant/populaire. (au passage on peut le faire fonctionner en 4 bits)

Mais a la limite ça n'a pas d'importance : le truc c'est juste de fournir une liaison i2c (ou spi). Un pic (genre 16f84) se chargera de faire le pont entre les 2 interfaces.

un linux sur pic 32 non pas très raisonable, j'utilise une distrib linux sur un microcontroleur au boulot mais le bordel tourne a 400mhz (motorola) !!!

c'est de l'artillerie lourde, pas interressant dans notre cas, lourd a mettre en oeuvre et le paradoxe les couts de dev ne sont pas anodins...

et la solution de tout mettre dans un FPGA au lieu d'avoir 36 composants différents pour chaque truc ?

SCPCD (./538) :
et la solution de tout mettre dans un FPGA au lieu d'avoir 36 composants différents pour chaque truc ?

Oui c'est une autre stratégie. En fait le choix de la solution FPGA est viable si l'on choisi un chip assez gros pour y inserer un proc soft (il y a pas mal de soft a faire tourner.). Mais malheureusement elle ne resoudra pas le problème des interfaces, ni la necessité d'avoir de la mémoire externe.

sundance (./537) :
un linux sur pic 32 non pas très raisonable, j'utilise une distrib linux sur un microcontroleur au boulot mais le bordel tourne a 400mhz (motorola) !!!

c'est de l'artillerie lourde, pas interressant dans notre cas, lourd a mettre en oeuvre et le paradoxe les couts de dev ne sont pas anodins...

400Mhz ? c'est plus vraiment de l'uC mais plus du CPU embarqué que l'on retrouve dans les pda (genre PXA255 ou encore iMX27-> je travaille la dessus en ce moment.)