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

Concernant le GDRom d'autres se sont déjà posé la question :
http://www.dcemu.co.uk/vbulletin/archive/index.php/t-2529.html

le taux de transfert est pas terrible sur une sdcard, sur une sdhc c'est mieux mais pas encore ca, l'ideal est un port ide pour la vitesse de transfert et la taille des hdd , mais ce qui me fait peur aussi c'est qu'il va devenir obsolete (en hdd 2'5 pouces c'est déja un peu vrai) ,après il y a le cout d'un hdd mème petit.

par contre:

"y reflechir aussi pour avoir un vrai mode sdcard avec les 4 fils de data -> partage des signaux entre le fpga et le pic: demarrage de la sdcard par le pic (fpga pas programmé) puis passage a travers le fpga en mode SD."

ca me dit beaucoup plus, et dans l'esprit je trouve pas mal , gestion via le pic et exploitation a haut débit via le fpga.

un protocole entre le fpga et le pic est a mettre au point de façon générale.

est ce suffisant pour le besoin Gdrom de la DC?

Oui programmer le FPGA dynamiquement à partir d'un fichier de la SD ça me semble méga bien.

et le SATA? c'est über compliqué à coder sur un fpga? opencores a pas ça? (hmm j'imagine que la clock de 1.5 GHz doit poser pbm... (sauf avec un adapteur sata-ide) )

Le SATA demande des transceivers specialisés et un routage/pcb pile poil sinon ça ne marche pas (hf oblige...).

oui c'est ce que j'ai pensé après coup

Concernant la vitesse d'écriture sur une sdhc ( et je parle pour moi ), cela ne me generais pas trop que cela prenne du temps parce que je le ferais une fois pour toute. Et bien sur, plus la carte est grande et plus je mettrais de jeux dessus. Je me posais la question du format des images de jeux ( iso ? autre ? ) et surtout, je me demandais comment faire une image de mes originaux ( j'en ai près de 80, oui j'aime vraiment cette console ).
Et pour terminer, que cette idée aille au bout, ou non, je vous remerçie déja d'avoir pris la peine d'y réfléchir

Tiki

Et puis, sur amigaimpact, un p'tit nouveau viens de réaliser un émulateur de D7 voici un lien vers la vidéo de son projet : http://cid-7d4e789e36dba616.skydrive.live.com/self.aspx/Public/TEST1.mpg

Tiki (./606) :
Concernant la vitesse d'écriture sur une sdhc ( et je parle pour moi ), cela ne me generais pas trop que cela prenne du temps parce que je le ferais une fois pour toute. Et bien sur, plus la carte est grande et plus je mettrais de jeux dessus. Je me posais la question du format des images de jeux ( iso ? autre ? ) et surtout, je me demandais comment faire une image de mes originaux ( j'en ai près de 80, oui j'aime vraiment cette console ).
Et pour terminer, que cette idée aille au bout, ou non, je vous remerçie déja d'avoir pris la peine d'y réfléchir

Tiki

Et puis, sur amigaimpact, un p'tit nouveau viens de réaliser un émulateur de D7 voici un lien vers la vidéo de son projet : http://cid-7d4e789e36dba616.skydrive.live.com/self.aspx/Public/TEST1.mpg

Le mec qui a conçu cette carte c'est moi ;-)
Tu trouveras tout le necessaire pour la fabriquer ici :
http://hxc2001.free.fr/floppy_drive_emulator/index.html#SDCARDFloppyemulator
http://hxc2001.free.fr/floppy_drive_emulator/sdcardfloppyemulator.jpg

Excelent......
(j'allais te poser la question Jeff)

j'ai remis le synoptique a jour:
(a chaque nouvelle idée/modif je le remetterais à jour)




va falloir aussi s'organiser un dossier en partage pour le projet serais utile.(je regarde pour mettre ca en place)

pour info j'ai recuperer la lib spartan et créé le composant pic 32 sous eagle...

vous utilisez quoi comme cao ? (Torlus/Jeff/Zerosquare...)

Tant qu'à faire, il n'y a pas moyen de coller un petit CPU 8 bit dans le FPGA ? Histoire de limiter le nombre de connexions, etc.

sundance (./608) :
vous utilisez quoi comme cao ? (Torlus/Jeff/Zerosquare...)

Protel (j'avais récupéré une licence pour une vieille version).
Mais question prix il est assez inabordable en "amateur".

On peut mettre ce qu'on veut dans le FPGA, mais c'est clair qu'un sous-diagramme pour détailler serait utile

Sinon, j'ai un serveur subversion personnel, si y'a besoin... ça peut dépanner

Pour la CAO je dessine mes circuits avec eagle version demo (sous linux), mais bon, je suis prêt à faire un effort si on me fournit autre chose

Un truc embêtant quand même, c'est le FPGA qu'il faut programmer à chaque allumage du circuit. Il me semble qu'il existe des circuits spécialisés pour cela, à voir si ça vaut le coup question finances.

mh... ça dépend du fpga que l'on utilise...
De toutes façons ce qui est programmé dedans ne s'efface pas quand on le débranche.
Si on peut rentrer assez de choses dedans, y'a pas de raison de l'effacer à chaque fois. Par exemple, la partie gestion de la carte SD risque de rester en place; mais une éventuelle interface avec un bus ide ou scsi ou disquette ou cartouche ou ... peut être mise en place ou enlevée selon les besoins. Si on utilise le truc toujours dans la même situation, il n'y a pas lieu de le reprogrammer une fois en place...

l'avantage avec eagle c'est que la version demo est exploitable.

Frost:
en faites c'est le pic qui va envoyé sa config/programmation au fpga, le fichier peut ètre stocké en dur dans la flash du pic ou sur la sdcard ce qui permet d'avoir un max de flexibilité pour les mises à jour et évolutions.

via l'incrust video ou le lcd on pourra meme choisir le binaire a envoyé par défaut.

et on est pas obligé de la reclaquer a chaque fois.

pour les fpga, les spartan3 peuvent s'autoprogrammer a partir d'une eeprom spi il me semble.

Oui mais je pense que le plus pratique et le moins couteux c'est la prog a partir du PIC.

Ouais, mais il faut voir si le FPGA n'impose pas une fréquence trop élevée pour le SPI pour le PIC (surtout qu'en mode slave, c'est généralement plus lent qu'en mode master).

Pour le projet JagCF, on a une petite Flash qui est partagée entre le FPGA pour la lecture, et un microcontrôleur Atmel pour l'écriture (reprogrammation par USB).
(Vu qu'à priori on ne s'amuse pas à changer la config du FPGA tous les jours). En pratique ça marche nickel

Tu peux programmer un fpga avec n'importe quoi a n'importe quelle vitesse (il ne faut cependant pas depasser 100Mhz ;-) ):
Cela s'appelle le mode "Slave Serial" chez Xilinx, ou "Passive serial" chez Altera. J'ai déjà fait des routines pour la prog d'un chip altera a partir d'un PIC18.

(note: cela n'a rien a voir avec le SPI : Le fpga est esclave dans ce mode)

Exemple chez altera (meme principe chez xilinx)
http://www.altera.com/literature/hb/cfg/cfg_cf51001.pdf

Passive Serial Configuration
PS configuration can be performed by using an Altera download cable, an
Altera enhanced configuration device or configuration device, or an
intelligent host, such as a microprocessor. During PS configuration,
configuration data is transferred from a storage device, such as a
configuration device or flash memory, to the FPGA on the DATA (FLEX
6000) or DATA 0 (Stratix series, Cyclone series, APEX II, APEX 20K,
Mercury, APCEX 1K, and FLEX 10K) pin. This configuration data is
latched into the FPGA on the rising edge of DCLK. Configuration data is transferred one bit per clock cycle.

)

Maintenant il est vrai que si l'application necessite un chargement rapide du fpga a l'allumage il faut se poser la question de l'utilisation d'une flash spécialisée.

Ah oui c'est vrai, j'avais oublié cette possibilité

(dans mon cas il n'y avait pas de stockage de masse susceptible de contenir la config, donc il fallait rajouter une EEPROM ou Flash de toute façon)

rien a voir avec ce qui précède
j'en profite pour vous annoncer la mise en ligne sur le site atariamiga du nouveau firmware du SDisk

Version 2.19F

les améliorations :

Optimisation routine crc
Optimisation main
Autoboot par défaut
Mémorisation last path

la mise à jour est dispo en .bin pour mise à jour via la sdcard ou en .hex pour flasher le pic sur un programmateur ou via un icd2.

Ah oui j'oubliais (20ans après ;-) ) : Moi j'utilise la suite Cadence Orcad / Layout.

Sur le coup, j'avais pas lu la fin et j'ai pensé : "ah ben, il a du blé, lui "

apparemment y'a de bon softs libres sur www.opencollector.org

par exemple, Kicad semble bien, je l'ai pas encore testé mais j'en ai entendu du bien.

Je sais que c'est HS, mais est-ce que ces petits génies de l'électronique qui se battent pour que l'ont puisse encore utiliser nos machines pourraient nous faire des scandoublers pour que l'on puisse utiliser nos Atari ST et nos Amiga sur un écran SVGA

faudrait faire un topic pour ça. Ca mériterait de l'étudier en effet, mais là ils sont assez concentrés sur le lecteur dikette

peut-être qu'après s'être concentrés sur le lecteur de disquette, ils tournerons leurs regards vers l'écran


En tout cas, ça serait top en effet !



ColdFire

Déjà debatu ici :
http://torlus.com/floppy/forum/viewtopic.php?t=153

A mon avis ce n'est pas viable de travailler sur des scandoubleurs : il y a déjà X solutions dans le commerce à des prix que l'on ne pourra jamais atteindre.

en effet les scandoubleurs ca va pas ètre notre preoccupation pour l'instant, il existe x solutions certes pas toujours faciles a trouver.

mais on ne peut tout faire.

j'ai déja étudier ce problème, si on veut faire quelque chose de clean il faut des convertisseurs AN flash (specialisés video) de la mémoire etc , tout de suite ca devient plus rentable
une solution du commerce devient + intérréssante.

par contre ouvrir un topic pour concentrer les achats intérrésserais peut ètre pas mal de monde....

sundance (./628) :
j'ai déja étudier ce problème, si on veut faire quelque chose de clean il faut des convertisseurs AN flash (specialisés video) de la mémoire etc , tout de suite ca devient plus rentable une solution du commerce devient + intérréssante.

Si c'est du scandoubling pur (et non pas un rapport non-entier et/ou un changement de fréquence de rafraîchissement, parce que çà c'est vraiment compliqué à faire proprement, et d'ailleurs les convertisseurs de bonne qualité sont assez ruineux ), il y a au moins un circuit qui intègre tout ça on-chip : l'AL250/251 d'Averlogic. Jamais testé personnellement, mais sur le papier, c'est intéressant.

Ah, c'est Individual Computers qui a sorti une jolie bête sur Amiga 1200: http://jschoenfeld.de/news/news130_e.htm.
Sur base de FPGA évidemment, c'est assez bluffant de voir comment le machin fonctionne: il est clippé sur le chip vidéo de l'Amiga et à rien d'autre et il est mis à jour par ce biais, c'est plutôt bien fait. Maintenant, c'est un projet qui a dû leur demander énormément de temps et il a le gros défaut de n'avoir qu'une sortie VGA.