Comment creer ses programmes sur EPROM ? - Page 1

C'est une question que je me pose car j'ai actuellement un projet electronique et je voudrais savoir comment on boot sur le port cartouche du ST/FALCON. En fait, la cartouche (ou il n'y a pas qu'une EPROM mais des circuits aditionnels) doit contenir un ACC qui sera le "pilote" du peripherique cartouche, en l'occurence :

-soit une SD MMC pilotée serielement (standard SPI, hélas lent mais suffisant pour s'en servir comme disque dur) ou par interface 4 bits avec des composants ultra courants (pas de controleur speciale)

-soit un controleur USB maitre pour connecter à peu prés tout les periph USB (dont les specifications sont ouvertes) dont des clef flash. ce module usb maitre est un VDIP1 fabriqué par vinculum (FTDI pour les connaisseurs) et dès que j'ai vue ce genre de module dans un mag d'electronique (elektor, je crois), j'ai tout de suite pensé au ST/FALCON car le port cartouche peut etre bidirectionnel (astuce utilisé dans le fameux streplay 4) et ce "module" usb maitre est doté d'un port bi-directionnel 8 bits + signaux R/W (il est commandable aussi en SPI et RS232 par un jeux d'instruction trés simple en ce qui concerne la gestion des clef USB ). pour ce module, les renseignements sont ici: http://www.vinculum.com/documents.html

Ceci dit, je fais peut etre doublon avec un autre projet et que j'ai posté ce message pour rien, dans ce cas, 10000000000 excuses

-

Oui, mais l'interface que j'ai en projet utilise des composants courants (hormis pour l'USB, mais ce module est facilement accessible via le site lextronic) du style 74HC245 / 74HC541 et autre 74hc688, etc et non des FPGA ou des circuits PQFP à souder (RTL8019AS bien plus difficile et plus couteux qu'un module VDIP1 ) ...

Le plus gros du travail serais au niveau de l'EPROM (vue par le systeme comme une unitée de disque et comportant un dossier AUTO avec le fameux ACC à l'interieur ) qui sera embarquée sur la platine.
D'aprés le site VINCULUM, il suffit d'envoyer des codes ascii sur le bus choisi du module (SPI, // ou RS232) pour effectuer une operation du style "file_open" (avec le nom du fichier en parametre bien sur) pour ce qui est des clef USB.

pour ce qui est de l'ethernet, il serais possible d'utiliser un adaptateur usb > ethernet (bon, on est daccord: le pilote sera la partie la plus gonflante), mais ca ferais un peu "usine à gaz".

Bref, je trouve dommage de ne pas utiliser ce module, d'autant plus qu'il nous "mache" le travail

Je posterais prochainement un lien vers le schema de mon projet (qui, pour ne pas squatter trop de lignes d'adresses, utilisera idealement 1 eprom de type 28F256, à moins que le port cartouche n'utilise la totalité des 16 bits, auquel cas, il en faudra deux ) pour que ce soit plus clair .

Merci bien pour ta réponse

-

odyssee_fanou (./1) :
C'est une question que je me pose car j'ai actuellement un projet electronique et je voudrais savoir comment on boot sur le port cartouche du ST/FALCON. En fait, la cartouche (ou il n'y a pas qu'une EPROM mais des circuits aditionnels) doit contenir un ACC qui sera le "pilote" du peripherique cartouche

Il y a un point que je ne comprends pas bien, si tu bootes sur le port cartouche, ça veaut dire que tu squizes tout ce qu'il y a sur la partition de boot du disque dur ou de la disquette.

Alors certes, ça chargerait ton accessoire driver, mais rien d'autre, pas le dossier auto personalisé, pas les autres accessoires, pas le bureau...
Ca pourrait coller pour des jeux ou programmes autonomes, mais pour de tels périphériques, je pense que les utilisateurs voudront leur Mint, Magic ou autres...
Parce que même pour gérer des SD o udes clefs USB, je ne suis pas sur que tu arriveras à booter sur la SD ou la clef USB...

Le mieux, c'est encore de fournir le driver en accessoire à part, à installer sur disque de boot, non ?

Fadest (./5) :

Alors certes, ça chargerait ton accessoire driver, mais rien d'autre, pas le dossier auto personalisé, pas les autres accessoires, pas le bureau...
Ca pourrait coller pour des jeux ou programmes autonomes, mais pour de tels périphériques, je pense que les utilisateurs voudront leur Mint, Magic ou autres...
Parce que même pour gérer des SD o udes clefs USB, je ne suis pas sur que tu arriveras à booter sur la SD ou la clef USB...

Le mieux, c'est encore de fournir le driver en accessoire à part, à installer sur disque de boot, non ?

Justement, je sais pas si il existe une procedure pour placer l'ACC contenue dans l'eprom en memoire centrale et continuer le boot sous GEM.
Si c'est possible, pas besoin de disque de boot (ca évite de la perdre ou d'etre embeté si le lecteur de disquette est HS). pour le cas de Mint ou autre, tu a raison (on ne peux pas se permettre de charger l'ACC de gestion sous GEM et démarrer mint, d'où le fait de voir la partie soft differement).

De mon coté, c'est en prog que je suis nul car j'ai arreté il y a fort longtemps (mais atari était toujours dans mon coeur ).

odyssee_fanou (./6) :
Justement, je sais pas si il existe une procedure pour placer l'ACC contenue dans l'eprom en memoire centrale et continuer le boot sous GEM. Si c'est possible, pas besoin de disque de boot (ca évite de la perdre ou d'etre embeté si le lecteur de disquette est HS).

A ma connaissance non, à la limite, un programme en auto-boot pourrait lire les infos de driver sur l'eprom, mais le problème est identique : il faut un programme en auto-boot.
Ensuite, il reste le problème des mises à jour, imaginons qu'il reste un bug dans ton driver ou que tu fasses une version plus évoluée, comment mettre à jour la cartouche ?
Franchement, un accessoire (et/ou prog auto, ou CPX) autonome, disponible sur le net (en cas d'effacement accidentel, de toutes manières, sans la partie hard, c'est inutile) est la meilleure solution à mon avis.

Juste pour donner une info, la CT60 (et probablement la CT2 et consorts) est capable de booter sur sa ROM sans l'aide de personne puis de booter le lecteur de boot. Mais elle est branchée sur le port d'extension Falcon, pas sur le port cartouche.

Pour la mise à jour, j'en conviens, c'est chaud car il faut un programmateur d'EEPROM.
Bon, ca met à mal mon projet (surtout si cette fameuse routine pour port cartouche n'existe pas), mais c'est pas grave,
il faut que je remette en question mon projet (que serait une vie sans remise en question ?? ) et tant mieux,
ca va peut etre me simplifier la tache !
J'étais cependant trés attaché à l'EPROM qui rendais ce montage autonome.

Bon, je refais mon schema (ca va aller plus vite cette fois ci) de ce pas !

Odyssee: vois le livre du développeur qui explique comment faire ça.

Bon, j'ai fait un PDF dispo icihttp://perso.orange.fr/odyssee.fanou/schema_interface_usb_pour_atari_st.pdf.

J'ai fait le schema (encore imparfait, je pense) avec les moyens du bord.
Je ne suis pas certain du cablage de ROM3/4 , UDS/LDS...

Slt,

ton acc, tu peux le mettre sur ta prom, au boot, il se charge et te permettra de gerer ta SD.
Tu peux prendre une 29fxx qui te permettra de flasher un nouveau firm.
De plus, pourquoi n'utile tu pas un Pic pour delester un peu le 68k?

A+

Sur le wiki de stabylo, http://wikipendium.free.fr tu as la plupart des docs pour les Atari,
dont http://removers.free.fr/wikipendium/wakka.php?wiki=RomCartridgesProgramming.

Donc sur une cartouche préparée spécialement, tu peux non seulement l'utiliser comme ROM disk, mais aussi de choisir si les progs contenus dessus seront exécutés et quand (valeur de CA_INIT pour chaque prog).

spectre128 (./11) :
De plus, pourquoi n'utile tu pas un Pic pour delester un peu le 68k?

salut

tout simplement pour réaliser une version de base tte simple et facile à réaliser.

Ca me fait penser que j'ai un pic16f876_10 qui dort dans un tiroir tiens...

Pourtant des PIC, ça se trouve aissement....

Il pourait gerer une pagination permetant de faire des cartouches de plusieurs Mega et gerant l'ecriture...

Salut,

Je ne suis pas du tout "spécialisé" Atari, par contre je connais assez bien l'électronique en général, et ce genre de choses en particulier.

Première remarque : arrêtez de vouloir mettre des PICs partout

1) Parmi les microcontrôleurs, il y a mieux ailleurs...
2) Un microcontrôleur n'est pas toujours la meilleure solution...

Je pense que ce serait plus intéressant de rejeter un coup d'œil sur les CPLD et FPGA. C'est plus adapté qu'un microcontrôleur pour ce genre d'applications, ça remplace avantageusement les circuits logiques discrets (reconfigurable à volonté, routage de la carte largement simplifié, facilité à utiliser des fréquences élevées, etc.) et les modèles pas trop récents existent en PLCC (avec le support adapté, c'est aussi facile à souder que le DIP classique). Et d'ailleurs, la puce Vinculum existe peut-être en DIP grâce une carte toute faite, mais tu vas la payer fort cher...

Sinon, en ce qui concerne le schéma : c'est une représentation simplifiée, non ? Parce que sinon, il va falloir penser à rajouter quelques condensateurs de découplage

Pour le reste du projet, quelques remarques :

- Je ne vois pas l'intérêt des cartes SD. Sur les Falcons, l'IDE est disponible de base, donc ce serait plus logique d'utiliser une Compact Flash avec un adaptateur. Pour les ST, un projet IDE me semble aussi plus adapté : ça permet d'utiliser les CF ET les disques durs classiques, plutôt que de se traîner une SD en SPI.

- C'est possible d'intégrer un système de fichiers supplémentaire de façon transparente avec un accessoire ?

- Dans l'absolu, le projet USB fait double emploi avec celui en cours de développement, tout en étant moins puissant. Par contre, ça va être beaucoup plus simple question drivers, et certains seront intéressés par le fait de pouvoir utiliser leurs clés USB dès maintenant, au lieu d'attendre (longtemps ?) que quelqu'un écrive le code.

- Ta remarque sur le fait que tu n'aimes pas faire de soft me surprend... tu es conscient que tu ne vas pas pouvoir y couper pour ces projets ?

Slt,

Je sais qu'il y'a mieux ailleurs, c'est certain (perso, je prefere les SX et les AVR) mais pourquoi se compliquer la tache
quand on peut faire simple....
C'est certain que les FPGA sont puissant...pourquoi utilisé unFPGA si une GAL suffit ?
un prog de GAL est plus difficile à faire qu'un prog de PIC, d'ou mas reponse.

L'USB c'est genial, mais pour un ST franchement je doute fort d'un reel besoin.
par contre les memoire de masse SD ou IDE revienne moins chere que le SCSI cher à l'Atari.
les cartes SCSI se font rare et les HD sont chere vu les performances inexploité.

Quand qqun me devellopera un compatible ST avec un core 68XXX à 1Ghz en VHDL, je penserai à me passer de
mon PC pour imprimer mes photo sur ST par exemple.

Mais pour l'instant, ce n'est pas d'actualité.

spectre128 (./16) :
Je sais qu'il y'a mieux ailleurs, c'est certain (perso, je prefere les SX et les AVR) mais pourquoi se compliquer la tache quand on peut faire simple....

On est d'accord, mais personnellement je ne trouve pas les AVRs plus compliqués à programmer que les PICs, juste plus puissants et mieux conçus . D'un autre côté, vu que c'est mon métier, je n'ai pas forcément le même point de vue que quelqu'un qui ne bricole ça qu'occasionnellement.

spectre128 (./16) :
C'est certain que les FPGA sont puissant...pourquoi utilisé unFPGA si une GAL suffit ?

Pas faux, je n'y avais pas pensé.

spectre128 (./16) :
un prog de GAL est plus difficile à faire qu'un prog de PIC, d'ou mas reponse.

Hmmm. Pour quelqu'un qui a l'habitude de faire de la programmation séquentielle, probablement. Par contre, quelqu'un qui maîtrise les circuits logiques classiques, je ne pense pas que c'est très dur d'utiliser une GAL.

spectre128 (./16) :
L'USB c'est genial, mais pour un ST franchement je doute fort d'un reel besoin.

Non, mais honnêtement il n'y a pas de réel besoin non plus d'utiliser un Atari en 2006 (pas taper !)
Pourtant, Rodolphe Czuba a des clients pour ses CT6x, il y a des gens intéressés par l'EtherNAT, etc. Il y a peut-être plus de personnes intéressées que tu pourrais le penser.

Zerosquare (./17) :

spectre128 (./16) :
L'USB c'est genial, mais pour un ST franchement je doute fort d'un reel besoin.

Non, mais honnêtement il n'y a pas de réel besoin non plus d'utiliser un Atari en 2006 (pas taper !)
Pourtant, Rodolphe Czuba a des clients pour ses CT6x, il y a des gens intéressés par l'EtherNAT, etc. Il y a peut-être plus de personnes intéressées que tu pourrais le penser.

Comme l'a dit Zero, certaines personnes utilisent leur Atari pour des choses courantes, perso mon PC sert qu'a surfer sur le Net, tout le dev Jaguar se fait sur Falcon, ca plante pas, ca boote vite, et je connais très bien la machine, que vouloir de plus ?


GT Heureux sur Atari

Slt,

Pourquoi j'utilise un ST en 2006 ?
Ma reponse est tres simple, depuis le temps que je l'utilise je la connait tres bien.
Pas comme le Pc qui fait tourner des process dont je ne connait vraimment pas l'utilité. (entre autre les Spyware).
Sur ST, je connait le deroulement systeme parfaitement et donc pas de probleme que mon st me gruge des cycles
d'horloges .
L'utilisation que j'en fait est purement informatique comme les passionnés des années 80 (comme mon C64).
l'overscan et le hardscroll en est la preuve, des esprits inventif,creatif, et necessairement tordue
Pour le PC cela n'est qu'une pure machine qui me simplifie la vie dans les taches courantes.

Vive le ST!

PS: Zerosquare, que me conseil tu mon bouquin pour débuter en VHDL?

spectre128 (./19) :
PS: Zerosquare, que me conseil tu mon bouquin pour débuter en VHDL?

Je peux pas trop te conseiller.

Même si je me tiens au courant sur le sujet, je n'ai jamais vraiment fait de projet conséquent en VHDL (à 24 ans, j'ai pas encore tout expérimenté à fond non plus ), et de toute façon perso je préfère utiliser des docs "officielles" et compléter sur le tas.

SCPCD, vince, Kochise, Ximoon... pourront probablement te donner une réponse.

Perso, je ne connais pas de bouquin de VHDL (à part peut être : le VHDL pour les grenouilles ici )
J'ai eu des cours à l'école et j'ai appris sur le tas en regardant des exemples et des infos trouvés sur le net et en testant par moi même.

Tu peux trouver facilement des cours sur le vhdl sur internet.

Bonsoir,

j'ai vu le lien mais il ne refere à rien

Le VHDL je connais pas , j'ai vu des exemple de porte logique et ça a l'air simple (bascule d en VHDL).
Par contre, quand je vois des sources de different projec, je capte que dalle !!

Existe t'il un convertisseur de schema logique vers le VHDL ??
Sinon prefere gerer la logique pa PIC

Le VHDL je connais pas , j'ai vu des exemple de porte logique et ça a l'air simple (bascule d en VHDL).
Par contre, quand je vois des sources de different projec, je capte que dalle !!

Le VHDL c'est simple, même hyper simple, mais il faut savoir un minimum de chose sur la facon dont procede le "compilateur" pour générer la logique derriere, sinon tu peux perdre rapidement enormement de place dans ton fpga et aussi et surtout de la "puissance" de ton fpga.
Et il ne faut surtout pas coder à la facon C, c'est la grosse erreur que certaines personnes font.

Existe t'il un convertisseur de schema logique vers le VHDL ??
Sinon prefere gerer la logique par PIC

pour la convertion schéma->VHDL je presume que ca doit exister quelque part dans un coin du web, mais c'est completement le contraire des opérations logiques
Car en fait, le VHDL ca permet de générer facilement les schémas logique de ton cablage.
Car tout faire en shéma logique, dès que l'on depasse plusieurs 100ene d'elements logique du fpga, ca devient vraiment la galere
c'est bien pire que de coder un OS complet en ASM.

Par contre, gerer la logique par un pic, c'est pas forcement interessant
En fait, l'avantage d'un PIC (ou autre) c'est qu'il est pratique pour faire la gestion du protocole (grace au séquentiel qui est "compliqué", dès que le protocole est complexe, à faire sur un FPGA), par contre il n'est pas du tout pratique pour faire la gestion hardware : c'est le facteur le plus limitant dans la vitesse des transferts par exemple.
C'est pour ca qu'il faut determiner à l'avance les performances que l'on souhaite obtenir avec l'interface avant de partir dans une direction

Après il y a aussi la solution de mettre tout dans le FPGA c'est à dire en integrant un mini-processeur qui permettrera de faire facilement la gestion du protocole, et d'utiliser en même temps les capacités du FPGA au niveau gestion logique

spectre128 (./22) :
Bonsoir,

j'ai vu le lien mais il ne refere à rien

Laisse tomber, c'est SCPCD qui fait joujou avec une private joke

SCPCD (./23) :

Existe t'il un convertisseur de schema logique vers le VHDL ??
Sinon prefere gerer la logique par PIC

pour la convertion schéma->VHDL je presume que ca doit exister quelque part dans un coin du web, mais c'est completement le contraire des opérations logiques

Parce que tu es habitué à réfléchir en VHDL, SCPCD

La plupart des logiciels de développement FPGA te permettent, en plus de VHDL, de saisir ton circuit sous forme graphique, c'est-à-dire en câblant des blocs tout faits (portes logiques, multiplexeurs, comparateurs, additionneurs, etc.) ; donc tu n'as quasiment qu'à refaire ton schéma d'origine. C'est moins barbare qu'il n'y paraît, sachant que l'implémentation des blocs que tu vas utiliser - qui ont leur équivalent VHDL - est normalement bien optimisée pour l'architecture du FGPA choisi (du moins, si le fabricant a fait son boulot). De même, si tu n'utilises pas toutes les possibilités du bloc (par exemple, si certaines entrées ne changent jamais d'état), certains compilateurs sont suffisamment "intelligents" pour optimiser l'implémentation en conséquence.

spectre128 (./22) :
Sinon prefere gerer la logique pa PIC

La programmation séquentielle, c'est plus facile en effet, mais par contre les performances sont très largement en-dessous de ce que tu peux obtenir avec un FPGA bien programmé.

Parce que tu es habitué à réfléchir en VHDL, SCPCD

je voulais dire que ce n'était pas logique de convertir schéma -> VHDL avec un logiciel alors que l'on passe après du VHDL -> schéma

Ben le probleme c'est ma façon de percevoir un objectif en electronique (j'suis electronicien en etude et en hobby, mais
pas dans le travail).
Soit je realise mon projet avec des microcontroleur ou soit avec un schema logique.
Quand je vois du code VHDL de base, je pige (bascule D, JK, ET, OU )
mais quand je vois du code qui resemple à du C avec des delais, je capte que dalle.
en logique pure, j'suis un BOOLISTE (ps: je suis de la vieille ecole, le VHDL jamais vu)
C'est certain que c'est puissant, encore faut il savoir ecrire en VHDL.
Je sais concevoir en porte logique pas en VHDL et donc je n'ai pas d'autre alternative que convertir un schema
pour concevoir un FPGA. (:

Voilà un bouquin que j'utilisais au CNAM : http://www.dunod.com/pages/ouvrages/ficheouvrage.asp?id=44755
Très bien fait et étant aussi de la vieille école, j'ai tout pigé avec ce bouquin !!!
Ceci dit, passez obligatoirement par un FPGA pour tout développement électronique n'est pas nécessairement rentable !!!
Pour ma part, pour les petites applications, j'utilise des microcontroleurs, voir même des sytèmes à microprocesseurs 8 bits , pour pouvoir gérer "les conditions logiques" (tableaux de Karnaugh).
Mais bon, chacun fait comme bon lui semble !!!