SONDAGE PROJET HARDWARE - Page 3

ok un peu de concret

une carte sur le port cartouche qui regroupe le maximum de fonctionnalités.

mais avant d'aller plus je vais éplucher le fonctionnement de ce port.(doc/analyseur logic)

(si vous avez des infos sur le sujet ca peut me faire gagner du temps)

une fois les suppositions étayées, dresser une spec avec les fonctionnalités réalisables

à l'aide de vos propositions en tenant compte des réalités techniques bien sur.

après selon les personnes voulant "travaillées" dessus lancement du projet ou pas.

figer les composants utilisés (dépendra des personnes impliquées)

je réalise un certain nombre de protos (dépendra du nombre de personnes impliquées aussi)

et en avant la music !



le but étant de faire un projet participatif dans la communauté de yaro
donc rien est figé dans le déroulement.

maintenant qui est intéressé ?

Je te soutiens à 520 %

ça fait plaisir !

bon je viens de regarder le port cartouche coté hard, c'est pas très compliqué, il y a moyen de lire et écrire facilement, et de
mettre au point un mode de transfert "rafale" qui devrait améliorer nettement le débit.

quand à la redirection pour un hdd ( c:\ ) sur le port cartouche c'est faisable via les vecteurs: $472 / $476 / $47A / $47E
cela nécessite bien sur l’écriture d'un driver simplifié coté st.

Pour l'USB, tu peux prendre ça : http://www.ftdichip.com/Products/ICs/VNC2.htm

C'est prévu directement pour supporter un adressage parallèle classique (enfin on peut l'utiliser en SPI ou port série aussi, mais ça n'a pas d'intérêt si on utilise le port cartouche), et ça supporte directement des fonctions pour lire/écrire des fichiers sur clé USB, gérer les souris/claviers, etc.

Pour ce qui est du driver ST, je pense qu'il y a moyen de faire un driver "propre", voire de l'inclure dans une ROM qui serait sur la cartouche. Il faudrait voir comment Steem fait pour partager un répertoire PC de manière transparente.

ca m'a l'air d’être une trés bonne solution surtout si comme tu dis ca supporte directement la lecture et écriture.

je regarde de plus prêt comment marche la bête...

as tu déjà utilisé ?

Non, seulement lu la doc il y a quelques années (c'était pour un projet au boulot qui est tombé à l'eau assez vite).

A ok,

séduisant, le chip est a environ 5€ et visiblement pas mal de bibliothèque precompiler donc pourrais utilisé rapidement.

tu peux compter sur moi aussi je fais aussi de super topic dans la rubrique blabla

plus serieusement je te souhaite d'arriver au bout de ton projet et si t'y arrives je t'en acheterai une de carte.

personellement je prendrais un PIC24FJxxxGBxxx http://ww1.microchip.com/downloads/en/devicedoc/39897b.pdf

qui a l'USB on thego, I2C, SPI

associé à un ENC28J60 on peux avoir une liaison etrhernet

jchn

j'ai déjà sous le coude plusieurs pic 24 en module pim et sur smartboard dont des FJxxxGB, j'ai des modules eth en ENC28J60 et wiznet.
je vais aussi commander un module FTDI VNC2 pour l'évaluer.
j'attends que le PIC24E soit dispo pour en commander.

je connais bien le 24. tu as déjà dev dessus ?

j'ai acheter un kit de dev, entre deux boulots, mais j'ai retrouvé du taf avant de m'y mettre ...

ok


je viens de m'apercevoir, il y a un port cartouche sur le Falcon.

cela intéresserait-il quelqu'un d'avoir ce projet porté sur Falcon ?

Alors la, si le projet et sur Falcon aussi, je te soutiens à 68000 % (2 falcons)

oui falcon aussi ^^

sundance (./70) :
j'attends que le PIC24E soit dispo pour en commander.

mouais, je ne sais pas si c'est une bonne idée de prendre une nouvelle série.
connaissant microchip, il y aura quelques mois après un errata listant tous les bugs.

Non non. La liste complète des bugs, elle ne sera connue qu'au bout d'un ou deux ans

ils ont déjà édité la liste de bugs....




le problème je n'ai jamais développer sur Falcon donc si personne ne s'y met

ça ne verra jamais le jours ...

Ben je pense qu'on doit pouvoir réutiliser directement le programme ST sur Falcon.

ba je connais pas le Falcon et le ST non plus.

j'ai une question, comment faites vous pour dev. sur ST,

directement sur la machine ou sur un émulateur ?

Ben pour ma part, je cross-compile, je teste sur émulateur et une fois que tout est au point je fais une vérification sur le hardware réel.

Par contre, je préviens tout de suite : si vous utilisez des PICs, je refuse de participer

je suis curieux avec quel cross compil ?


tu veux utiliser quoi ?

sundance (./81) :
je suis curieux avec quel cross compil ?

Comme je fais essentiellement de l'assembleur, j'utilise celui du kit de développement Jaguar (il accepte de générer du code au format exécutable Atari ST, et il y a une version qui tourne sous DOS). Si tu préfères le C, il existe une version de GCC qui peut cross-compiler pour Atari ST, ainsi qu'une version de VBCC aussi je crois.

sundance (./81) :
tu veux utiliser quoi ?

Des Atmel AVR, ste question
C'est nettement moins bugué que les PIC (tant sur le hardware que les outils de dév), l'assembleur est beaucoup plus puissant et agréable à coder, le nombre de MIPS est de 2 à 4 fois plus élevé qu'un PIC à fréquence d'horloge égale, et le hardware est globalement mieux pensé je trouve.

je connais pas le kit de dev Jajuar mais je demande qu'a apprendre.
l'assembleur me suffit. (vbcc ? c'est quoi?)
le c a la rigueur pour utiliser bibliothèques existantes...

pour les AVR j'y ai bien pensé, certes ça me parait vraiment bien et je voudrais bien pratiquer.
ce qui me gène c'est de lancer un projet sans réel expérience sur les Atmel.
si tu participes et que tu maitrise déjà alors pas de problème, je postasse , éventuellement te poses quelques questions,
et je serais efficace rapidement.

aussi pratiquant le "c" mais étant "accro" a l'assembleur, le µp genre standard noyau MK4 et compagnie ne m’intéresse pas,(la c'est du vécu >> in-débugable si gros soucis)

je vais faire un tour sur le web Atmel pour voir ce qui ce fait.

tu pensais a quel micro dans la gamme ?

Petite question : Pourquoi vouloir intégrer un uC dans ce contexte ? Avec le port cartouche le 68000 peut gérer pas mal de choses directement :

Exemple : Pour gérer une SD quelques portes logiques/buffer et c'est fini. Avec le bon soft/driver coté ST, il va parfaitement gérer ça sans l'aide d'un uC (surtout que le soft/driver est en grande partie déjà là ).

A la limite un petit CPLD en + pour sérialiser / dé sérialiser le bus SD pour gagner en vitesse.

Simple question

Utiliser un uC peut servir de buffer, c'est l'uC qui va lire et stocker, s'occuper de la FAT sans avoir besoin de driver. Le 68000 est déjà pas mal occupé à plein d'autres choses sur ST, alors si tu lui colles en plus la lecture/écriture sur le port cartouche, tu vas ramer un max (le débit du port cartouche en PIO doit pas dépasser les 200 KiB/s à cause des latences)

Kochise

pourquoi ne pas utiliser les plans de ppera pour faire des interfaces ide tout simplement? il veut pas en fabriquer car il a pas l'argent le ppera donc du coup tous les beaux projets hardware sont des licornes...

http://atari.8bitchip.info/astide.php

Une carte SD de 2GiB ne coûte quasiment rien (6 ou 7 euros) et n'a pas besoin d'alimentation, n'occupe pas de place, est lisible sur n'importe quel ordinateur, pas un disue dur IDE formaté Atari.

Kochise

c'est vrai Jeff on pourrait, tous faire par le 68K et de cette façon faire chuter le prix, de ce coté la tu as raison.
en plus une cpld qu'on pourrait re-claquer a partir du 68k serais le top.

mais je voudrais faire un peu plus pour délester le 68K et surtout intégrer de nouvelles fonctionnalités (ex:copro math etc)
gérer de l'usb /stockage /io/vidéo/ voir eth et la, ça devient plus complexe sans surbooker le 68k et difficile a faire dans une cpld.
sachant qu'on va être limité à 2 ou 3 capots max.(µp + ram ou chip dedié ou cpld ou???)
de plus pour l'instant il n'y a pas de développeur coté st...

Ppera est un bon projet en effet ça a l'air de bien marché seulement pour le mettre en place il faut ouvrir l'Atari et sortir sont fer a souder
déja tu n'a pas un produit plug and play, après le 68K gère l'interface ide en direct donc une charge supplémentaire.
l'ideal dans ce cas c'est de sortir le bus request et bus grant du 68K et de faire les transferts en dma dans la ram du st mais alors au niveau câblage


Kochise: tu as raison
quoiqu'une compact flash ne coute pas plus chère
surtout 3/4 connections seulement sont nécessaires sur une sd

une démonstration du controleur ide sur port cartouche

http://www.youtube.com/watch?v=c_Pi9gSJdYo

Kochise (./85) :
Utiliser un uC peut servir de buffer, c'est l'uC qui va lire et stocker, s'occuper de la FAT sans avoir besoin de driver. Le 68000 est déjà pas mal occupé à plein d'autres choses sur ST, alors si tu lui colles en plus la lecture/écriture sur le port cartouche, tu vas ramer un max (le débit du port cartouche en PIO doit pas dépasser les 200 KiB/s à cause des latences)

Kochise

Je ne pense pas que rajouter une surcouche logique va diminuer en quoi que ce soit la charge du port cartouche: Si il faut passer un fichier de 1Mo via ce port, uC ou pas c'est a quelques octets près la même quantité de donnée qui passera.
Seule la latence changera, et je ne suis pas sur que celle d'un uC sera la plus avantageuse

Et concernant la gestion de la fat, ne pas sous estimer pas le ST/68000
Quelques exemples de gestion directe de la FAT32 (emulation HDD a travers l'interface floppy via un HxC ) :
http://hxcmount.atomas.com/
http://www.youtube.com/watch?v=nMc6u7T2PyQ
Ou encore :
http://www.youtube.com/user/JeffHxC2001#p/u/4/8O74GgYcA3w

Sans trop m'avancer je pense qu'il y a moyen de faire aussi bien qu'un SatanDisk voir mieux ( Pas de problème avec des chips DMA buggés ) pour moins cher via le port cartouche.

Et si la chose est suffisamment bon marché j'en connais un qui se lancera sans hésiter dans la prod .