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

iop,
mon idée n'est pas, comme pour le HcX, de se limiter au lecteur de disquettes, mais de faire un truc plus dans l'esprit de la Multiface 2, permettant d'accéder à la RAM du CPC, de modifier des trucs dedans, éventuellement d'avoir une interface de debug sur laquelle un programme tournant dans le cpc pourrait envoyer des infos... ça pour la partie "aide au développeur amstrad".
L'autre interêt, c'est de mettre par exemple, une possibilité pour connecter plusieurs ordis en réseau (amstrad ou pas ) pour quelques jeux par exemple...

Enfin, beaucoup de choses sont possibles mais ça va nécessiter de pouvoir se connecter au bus extension du CPC, qui est quand même un peu gros. Faut voir

PulkoMandy (./541) :
iop,
mon idée n'est pas, comme pour le HcX, de se limiter au lecteur de disquettes, mais de faire un truc plus dans l'esprit de la Multiface 2, permettant d'accéder à la RAM du CPC, de modifier des trucs dedans, éventuellement d'avoir une interface de debug sur laquelle un programme tournant dans le cpc pourrait envoyer des infos... ça pour la partie "aide au développeur amstrad".
L'autre interêt, c'est de mettre par exemple, une possibilité pour connecter plusieurs ordis en réseau (amstrad ou pas ) pour quelques jeux par exemple...

Enfin, beaucoup de choses sont possibles mais ça va nécessiter de pouvoir se connecter au bus extension du CPC, qui est quand même un peu gros. Faut voir

oki. En parlant de multiface Giants (et moi dans une moindre mesure) travaille sur son reverse engineering. Avec un peu de chance un multiface3 sortira.

ça avance encore ce projet ? bon à savoir

Oui. cet été les equations d'un des PAL ont été retrouvées. le schema du multiface2 fait au propre etc.
Reste a "casser" les 2 autres PAL et ça devrait etre ok.
ici le schema:
http://jeanfrancoisdelnero.free.fr/vrac/multiface2.pdf

Le fpga est une solution mais la mise en oeuvre n'est pas aussi accessible, je ne connais pas trop les fpga et surtout les moyens de debug....
le cout des outils de dev/debug sur pic se limite a un icd2, de plus pour nos besoins un pic 32 doit suffir.

en effet c'est plus vraiment de l'µC : Motorola Powerquicc en ce moment je ne pas travail sur ce projet, mais avec le recul je m'apercois que plus on a de la puissance
plus on utilise un os gourmand, un langage de prog dit évolué et au bout du compte on perd un peu l'objectif de départ...
enfin je m'égare ......

ce connecter sur le bus Amstrad possible tu as une liste des signaux ?

quand je parlais emulation cartouche la multiface peut en etre une.

sur le synoptique le bus externe est en faites le bus parallele du pic (masters ou slave), en 16 bits data (on peut l'utiliser en 8 bits) 17/18 bits adr
+ signaux read / write , on peut ecrire en direct ou en dma (interne au pic)

par contre pour la gestion des signaux de controle (les pals) c'estr moins evident quoique il faudrais connaitre leur rapidité et si on peut l'emuler en soft...

il reste une trentaine d'i/o ,3 irq avec tous ca on a de quoi faire quelque chose ?

Le bus de l'amstrad est simplement le bus complet du Z80 (voir le schéma). Au niveau pal 2 gèrent le décodage d'adresse et un autre d'une machine d'état de surveillance et prise en main du Z80.
La rapidité c'est 4Mhz.
Je peux me tromper mais je doute que l'émulation de ce genre du truc soit super évidente avec un micro (il surveiller X signaux en // et agir au cycle près, sachant que l'horloge du z80 et du Pic ne seront pas en phase).
Généralement les uC présents sur les émulateurs s'occupent seulement du chargement du soft dans une ram/flash.
Ensuite la machine cible accède directement a cette ram/flash simplement a travers un jeux de portes logiques/décodeurs.
A ce moment là le uC n'a plus de rôle dans le fonctionnement de la cartouche. (c'est grosso-modo le fonctionnement de la cartouche de Torlus avec son uC,CPLD et eeprom).
Tous ça pour dire que l'émulation de ce type de cartouche directement par uC me semble difficile. Il faudra toujours un minimum de logique a coté.

Autre chose : au niveau mécanique coté cartouche tu penses a quoi ? Parce que là aussi les contraintes sont souvent spécifiques.
Torlus a déjà expérimenté la création d'une cartouche multi-système. Il a peut être quelques idées.

sundance (./545) :
Le fpga est une solution mais la mise en oeuvre n'est pas aussi accessible, je ne connais pas trop les fpga et surtout les moyens de debug....

Franchement, si tu as l'opportunité, penche-toi sur le sujet. Les premiers modèles ne coûtent pas cher et permettent déjà de faire énormément de trucs.

Pour se débarrasser de toute la glue logic, c'est le pied, beaucoup plus adapté que les µC. Si vous voulez gérer de la DRAM ou d'autres trucs, pareil, soit l'interface est déjà prévue en hard (il y en a plein de supportées de base), ou au pire il suffit d'un peu de VHDL pour le faire.

Et en plus il est possible d'intégrer l'équivalent d'un petit µC dedans en "soft", si le VHDL pur ne suffit pas.

Question outils de développement, pour les Altera par exemple, un simple port parallèle et quelques composants pas chers suffisent pour faire la prog par JTAG (ça revient nettement moins cher qu'un ICD2).

Oulà, ça part dans tous les sens ce projet
Dans la série 3615 mavie, j'avais donc en projet de faire une cartouche multi-systèmes, sur le principe carte mère / cartes filles. J'ai bricolé un truc qui marchait sur la SNES et la PCE. Ensuite j'ai fait un prototype de cartouuche 2600.
Mes observations :
- Pour la SNES, le chip de sécurité n'a à ma connaissance pas été "reversé", donc à moins d'en récupérer un (ce que j'ai fait) point de salut. C'est pour cette raison que les linkers SNES existants disposent d'un port cartouche sur lequel il faut placer une cartouche originale.
- Pour la PCE, c'est beaucoup plus simple, ça revient à refaire une bête EEPROM (pour la plupart des jeux).
- Pour la 2600, c'est tout un poême Il existe un paquet de mécanismes de bankswitching utilisés pour surmonter la barrière des 4Ko adressables par le proc. Il y a pas mal d'infos sur le sujet sur AtariAge et le site de Kevin Horton par exemple. A noter qu'il existe un projet de cartouche nommée Chimera, qui utilisera un FPGA, un MCU et de la RAM partagée entre les deux.
Honnêtement, je suis assez sceptique concernant la cartouche multi-systèmes (couplée en plus à un émulateur floppy, un adaptateur pour joysticks, une machine à café, etc.), je pense qu'il serait plus raisonnable de cibler quelques objectifs bien précis, d'évaluer les coûts et de s'y tenir
Après c'est sur qu'en partant sur une base d'un MCU assez puissant, un FPGA, de la RAM partagée entre les deux, on peut imaginer plein de trucs

heureux de te lire Torlus.

Ta connaissance dans le monde des cartouches est a capitaliser, si on peut profiter de ca, c'est énorme.
il est évident qu'il y auras des cartes filles ne serais-ce que pour les différents types de connections au consoles.(l'idéal c'est quelles soient passives)

j'ai lu un peu sur le bank switching de la vcs 2600...

il me parait évident qu'un fpga ou cpld pourrais régler pas mal de chose, comme le Jeff le précise pour les décodage d'adresse ou signaux de controle (ou la synchronisation est de mise).

il est vrai qu'il faut se réduire au niveau des fonctionnalités, cependant l'émulation floppy ne poseras pas trop de problème , entre l'expérience acquise par Jeff et moi même.

une incrustation vidéo ne poseras pas de problème non plus, voir même la génération de signaux vga, la dessus j'ai un peu de bouteille.(la gestion d'un LCD on en parle même pas)

la gestion de la sdcard ne poseras de problème non plus, on peut laisser de coté l'adaptateur joystick etc

tout ca pour dire que de nos débats, idées et propositions on devrais arriver a un projet concret et stabiliser (on a jusqu'a janvier pour avoir un schéma et une implante qui tiennent la route ca laisse un peu de temps).

ce qui est sur c'est qu'avoir une occasion de travailler ensemble, d'être plus ou moins financer pour une prod est une chance. (D’ailleurs si vous avez des questions la dessus: atariamiga@free.fr)

Avec un MCU + FPGA + RAM il y a vraiment de quoi s'amuser je pense...

dans les précédent poste j'ai commencé une ébauche de schéma fonctionnel (document word est joint),n'hesitez pas a le compléter / modifier.


Zerosquare:

je sais bien pour l'interface jtag mais pour le debug de soft je sais pas trop comment ca se passe, surtout si on veut implanter un micro 32 bits >> gros fpga (boitier BGA, approvisionnement réservé au professionnel etc.), quoique qu'un petit fpga est le bien venus ....cf juste au dessus ! (si tu as quelque chose a proposer n'hésite pas!)
L’intérêt du pic est aussi d'ouvrir le projet.

quand au VHDL je vais m'y mettre certainement via mon boulot....

L'idéal ce serait un pic+un fpga, le pic peut être débuggé facile, pour le fpga par contre, on peut simuler sur pc, après si ça marche en simulation et pas au final ça devient vite le bordel. Mais c'est pas plus chiant que de la glue logic à base de 74xx ou autres portes diverses

A mon avis, ce qui peut être très intéressant c'est que le pic reprogramme le fpga en fonction des besoins, à partir de là on peut faire vraiment n'importe quoi, le fpga s'adapte aux besoins, on a un gros tas d'i/o qu'on peut surveiller, on peut y mettre à peu près n'importe quoi, et le pic reste derriere pour surveiller. La conséquence c'est aussi qu'on peut faire une série de cartes sans trop savoir ce qu'on va mettre dedans, on peut reconfigurer le fpga selon les besoins et le connecter, en gros, à n'importe quoi

J'ai travaillé sur différents projets a base de FPGA en pro (notamment une carte accélératrice gérant 4Go de sdram avec 8 contrôleurs en //, des algos hard codé etc) et l'ensemble uC+FPGA est un ensemble très puissant.
Dans notre cas un Cyclone II EP3C5 ou EP3C10 (ou un équivalent chez xilinx ou autre) pourrai etre une bonne base pour des chose "simple" : contrôleur sdram, décodage divers et variés, émulation floppy avancé (variable bitrate/ capture haute résolution...), génération signal video, etc.
Maintenant reste a voir le coup final. (Un FPGA a besoin d'au moins 2 alims. Pour le cyclone 3 c’est 3. Voir pour les adaptations de niveau vers le monde extérieur, etc).

Et ne pas oublier que certains ont reproduit des machines complètes avec ce genre de solution .

ca a l'air d'etre un peu de l'artillerie lourde, après faut voir le cout et la j'avoue j'ai un peu peur ...
coté alim on a de base du 5v et 3.3v (euh le 12v seras inutile je pense) reste 1.8v ca veut dire un regulateur en +
je n'ai pas regarder coté consommation (la aussi on est limité)
quand je vois la doc de 468 pages!!(cyclone III) je me dis on doit pouvoir faire pas mal de chose avec ca !!


le faite de pouvoir claquer le fpga a partir du pic est vraiment un plus (surtout si on stock le programme a claquer sur la sdcard)
j'ai regarder de plus près cyclone II et III euh vi c'est pas mal
coté cout c'est autour des 15 $ a l'unité sur site, c'est pas donner

reste avoir si facilité d'appro et tarif en france...

sundance (./550) :
je sais bien pour l'interface jtag mais pour le debug de soft je sais pas trop comment ca se passe, surtout si on veut implanter un micro 32 bits >> gros fpga (boitier BGA, approvisionnement réservé au professionnel etc.), quoique qu'un petit fpga est le bien venus ....cf juste au dessus ! (si tu as quelque chose a proposer n'hésite pas!)

On trouve des FPGA entrée et moyen-de-gamme en boîtier TQFP chez Altera et Xilinx (un "petit" Cyclone 3 ou Spartan 3 permet déjà de faire plein de choses), et l'approvisionnement ne pose pas de problème (on en trouve chez Farnell et Radiospares par exemple). Les alimentations multiples sont quelque chose d'un peu casse-pieds, c'est vrai, mais on trouve des composants d'alimentation à découpage qui font quasiment tout eux-mêmes, il y a juste 2 ou 3 trucs à rajouter autour.

Pour l'implantation d'un processeur en VHDL, un 32 bits va bouffer de la place, mais est-ce vraiment nécessaire ? Un 8 bits bien conçu peut déjà avoir des performances assez surprenantes (il faut regarder un peu ailleurs que chez Microchip pour avoir des exemples )

Par contre, je n'ai jamais essayé en pratique, donc je ne sais pas comment se fait le debug.

sundance (./553) :
ca a l'air d'etre un peu de l'artillerie lourde, après faut voir le cout et la j'avoue j'ai un peu peur ...
coté alim on a de base du 5v et 3.3v (euh le 12v seras inutile je pense) reste 1.8v ca veut dire un regulateur en +
je n'ai pas regarder coté consommation (la aussi on est limité)
quand je vois la doc de 468 pages!!(cyclone III) je me dis on doit pouvoir faire pas mal de chose avec ca !!


le faite de pouvoir claquer le fpga a partir du pic est vraiment un plus (surtout si on stock le programme a claquer sur la sdcard)
j'ai regarder de plus près cyclone II et III euh vi c'est pas mal
coté cout c'est autour des 15 $ a l'unité sur site, c'est pas donner

reste avoir si facilité d'appro et tarif en france...

de memoire le Cyclone III a besoin d'un VIO (3.3 par exemple), d'une alim PLL a 2.5V, et de l'alim de coeur (1.2V). La conso est relativement limitée:
http://www.altera.com/products/devices/cyclone3/overview/power/cy3-power.html

Le chargement du fpga a partir d'un pic ou autre est un jeu d'enfant : tu generes un binaire a partir du soft de dev et ensuite il suffit de le serialiser vers le fpga (le protocole est inclu dans le fichier)

quand je vois la doc de 468 pages!!(cyclone III) je me dis on doit pouvoir faire pas mal de chose avec ca !!

Ce n'est pas le plus important. Le plus important c'est que tu disposes d'une matrice de logique important pour pouvoir faire ce que tu veux en terme de logique câblée. Plus de problème de "puissance". Les trucs sont massivement parallélisés etc.: Tu te fais ton "asic" reconfigurable pour pas un rond (enfin a 15$ ;-) )
Ensuite chaque FPGA a son petit "plus", mais c'est la cerise sur le gâteau ;-).

ok on recapitule

un fpga
un pic

mais au faites peut on prevoir la gestion de sdram par le fpga mais accessible aussi par le pic ?

car dans ce cas la on peut economiser le cout de la sram en la remplacant par de la sdram.(2 fois moins chere au mini.

quand au fpga son cout est a etudier de prèt .....

je sais dans chaque gamme de fpga, certain sont typé DSP/ETH etc
de mon coté je vais essayer de trouver un moyen d'appro le moins chere possible mais c'est pas gagné...
mais dans le principe je suis pour l'implantation d'un fpga

sundance (./556) :
ok on recapitule

un fpga
un pic

mais au faites peut on prevoir la gestion de sdram par le fpga mais accessible aussi par le pic ?

car dans ce cas la on peut economiser le cout de la sram en la remplacant par de la sdram.(2 fois moins chere au mini.

quand au fpga son cout est a etudier de prèt .....

Oui complètement : Un bus local entre le fpga et le pic. Le fpga fonctionne comme un contrôleur de sdram (avec d'autres fonctions a coté...) et le tour est joué.
Coté PIC32 on utilise le "Parallel Master Port" et en avant.
Petit défaut coté pic : il n'y a pas d'entrée WAIT/READY sur le module "Parallel Master Port". Donc apparemment ce n'est pas possible de mettre en attente le PIC pour attendre la réponse du contrôleur SDRAM (selon la situation cette attente peut varier). Il faudra donc passer par un système de mémoire paginée -> envois du commande au fpga pour charger 1Ko de la sdram (en burst) vers la ram interne du fpga et lecture directe (sans wait state) dans cette dernière. De toute façon vu le nombre d'adresse disponible avec cette interface (A0-A14), on sera obligé d'utiliser une telle astuce pour accéder a 1Mo de mémoire (plus maintenant vu qu'on utilise de la sdram).

Les Xilinx sont moins cher :

http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=122-1479-ND (100kportes tqfp100 7.3Euros)
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=122-1478-ND (100kportes tqft144 8.55Euros)
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=122-1340-ND (200kportes tqfp144 11 euros)
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=122-1340-ND (250kportes tqfp144 11.6 euros)

(mais Altera Quartus 2 est meilleur que Xilinx ISE )

Zerosquare (./560) :
(mais Altera Quartus 2 est meilleur que Xilinx ISE )

<<Atari Pipi - Amiga Caca!>>

Meuh non, c'est objectif, j'ai pas de préférence particulière pour l'une ou l'autre marque
Si j'avais voulu troller, je t'aurais dit ce que je pense des PIC

pour les échanges entre sdram fpga et le pic ou peut mettre en place un systeme de wait state/ready via irq, on est pas obligé d'utiliser parrallèle master port, le dma interne peut débiter sur un port 16 bits sans pb (j'ai déja fait avec un lattice et sram double port cypress dans le temps)

en effet les prix sont plus acceptable, mais c'est au US...

on va prendre le problème dans l'autre sens que peut-on avoir de mieux pour +- 12€

dans l'ideal il faudrais trouver un distributeur en france, dès le fpga choisi je pourrais de mon coté ....

quel est le plus adapté des Spartans pour notre projet sachant que nos sasefaipu ont peut de chance de faire de l'ethernet et autre nouvelles technologies (on ne rigole pas dans la salle quand je dis nouvelle technologie!!!)

ba moi j'avais les 2 ..... Atari et Amiga bien sur.

une petite question les gars serez vous présent a la RGC ?

Sundance: je me suis "offert" une carte de dév Cyclone II d'Altera. Comme je n'ai vraiment pas le temps de m'en occuper, je veux bien te la prêter pour que tu te fasses la main dessus.
Et je serai à la RGC si besoin

Volontier (c'est vraiment cool comme proposition, le temps te manque pour te plonger dedans?)
on se veras a la RGC profite pour enmener ton Sdsik on le connecteras sur un de tes Amigas si ce n'est déja fait.
(je te ferais une petit mise a jour)

Ok, impec. J'y serai le samedi. J'amènerai mon Amiga 500... J'ai quelques travaux à faire dessus en plus, ça sera l'occasion (extension à 1Mo de chip, etc).

sundance (./564) :
une petite question les gars serez vous présent a la RGC ?

Sauf empechement de derniere minute, je serai là.

sundance (./564) :
une petite question les gars serez vous présent a la RGC ?

Tu n'es pas inscrit ou j'ai mal vu ?

La RGC va finir en rencontre 'hardware', colision de la nouvelle technologie appliqué aux anciennes machines


GT