SONDAGE PROJET HARDWARE - Page 2

johnz (./29) :
donc on fait rien vu que tout est voué a ramer le cul

Ben ça sert à rien de faire un truc qui va ramer plus que la vidéo intégrée, et qui sera compatible avec rien, en effet. Par contre l'USB c'est quelque chose qui n'existe pas de base.

HuggyOne76 (./30) :
Quant à vos discussions relatives aux modifs hardwares et à la compatilibité, quand on voit ce qu'une CT60 apporte sur un Falcon, est-il bien utile de se demander si on doit rester compatible ou pas ? La réponse est oui, on doit se poser la question. Mais est-ce une obligation ? Non, à mon avis, non.

Sur Falcon, la CT60 sert surtout à faire tourner les logiciels "sérieux" et pas trop mal codés. Sur un ST, quel serait l'intérêt d'une carte graphique qui ne marcherait qu'avec les programmes GEM par exemple ? Pour ce genre d'utilisation, tu n'utiliseras pas un ST de toute façon.

bon bah alors c est quoi le prog? usb sur port cartouche et carte accel avec ttram integré?

-2 besoin inter-connectivité

mais par contre si on veut accélérer facilement un Atari il y a un autre moyen... (suite prochain post)

le port cartouche est en 16 Bits (pas le acsi), moyennant quelques sciouxerie le 68K peut y faire des accès rapides.(on est d'accord ca seras pas le gigabits/s)
il présente l'avantage d'être présent sur le st et ste.


donc comment accélérer le st:

pour les softs gem qui utilisent des trap et autre fonction du tos bios , intercepter les traps (faire pointer les vecteurs sur une routine dans l'espace mémoire du port cartouche)
afin de traiter plus rapidement ces requêtes ou redirigé sur un port, un stockage géré par l'homebrew.

on peut aussi imaginé accéder:
a un lecteur virtuel de cette façon.
" " " " " " " port rs232 " " " . (à 115200 Dbs bien sur)
" " " " " " " " USB " " " . (avec gestion mouse et reprise port db9)
" " " " " " " " SPI " " " .
" " " " " " " espace de stockage " . (16 OU 32 Go par ex. accès rapide)
" " " " " " " copro math. " .
" " " " " " " pré calculateur 3D " .
" " " " " " " pré calculateur sprite " .

bien sur les demos ne seront pas concernées (mais quel est l'intérêt)
l'autre moyen est directement modifié les pointeurs des irq (trap etc) dans la rom et donc refaire un nouveau jeux(la c'est carrément plus galère)
quoique avoir des roms modifiables a volonté j'en aurais rêvé à la grande époque...

sundance (./33) :
mais par contre si on veut accélérer facilement un Atari il y a un autre moyen... (suite prochain post)

le port cartouche est en 16 Bits (pas le acsi), moyennant quelques sciouxerie le 68K peut y faire des accès rapides.(on est d'accord ca seras pas le gigabits/s)
il présente l'avantage d'être présent sur le st et ste.


donc comment accélérer le st:

pour les softs gem qui utilisent des trap et autre fonction du tos bios , intercepter les traps (faire pointer les vecteurs sur une routine dans l'espace mémoire du port cartouche)
afin de traiter plus rapidement ces requètes ou redirigé sur un port, un stockage géré par l'homebrew.

on peut aussi imaginé accéder:
a un lecteur virtuel de cette façon.
" " " " " " " port rs232 " " " . (à 115200 Dbs bien sur)
" " " " " " " " USB " " " . (avec gestion mouse et reprise port db9)
" " " " " " " " SPI " " " .
" " " " " " " espace de stockage " . (16 OU 32 Go par ex. accès rapide)
" " " " " " " copro math. " .
" " " " " " " pré calculateur 3D " .
" " " " " " " pré calculateur sprite " .

bien sur les demos ne seront pas concernées (mais quel est l'intérêt)
l'autre moyen est directement modifié les pointeurs des irq (trap etc) dans la rom et donc refaire un nouveau jeux(la c'est carrément plus galère)
quoique avoir des rom modifiable a volonté j'en aurais rêvé a la grande époque...

quoi qu'il en soit c'est total soutient avec toi

-3 Amélioration graphique

c'est clair le st ne sort pas de vga, le plus simple est de le connecté a une TV LCD.

sur ce sujet je pense avoir pas mal travaillé cf topics/140688-carte-acceleratrice-3d-pour-atari-st/2 post ./49

idéalement il faut remplacer le shifter vidéo, capturer le bus 68K afin d'avoir une vue sur les registres, voir en implémenter.

émuler les "bug" du shifter pour l'overscan etc

et enfin implémenté des ressources graphiques particulièrement gourmandent en mips et en ram rapide.

la mise en œuvre et l'installation dans l'Atari est compliquée et fastidieuse.

je ne parle pas du cout....

et bien sur seul les logiciels spécifiquement développés pour, en tireront la quintessence.

quand a faire un convertisseur simple VGA, acheter directement une tv lcd coute moins chère.

par contre on peut faire certaines choses a moindre cout:

wah vivement la suite

soit on refais un gpu (voir précédent post)
pour l'existant on ne peut rien faire.

soit on rajoute (incrustation vidéo)

on laisse le shifter et le 68k/blitter générer leur image (la compatibilité est a 100% ) et on vient après au niveau de la sortie vidéo incruster un sprite ou un fond
l'effort dans ce cas est a faire au niveau des synchros afin d'avoir une incrust parfaitement stable et net, certes il faut absolument utiliser des multiplexeurs vidéos

mais dans ce cas on peut imaginer avoir un µprocesseur sur le port cartouche qui incrust des sprites sur la sortie vidéo, pour le st ca se résume a envoyer l'image du sprite
sur le port cartouche avec les coordonnées,puis mettre à jour les coordonnées
de cette façon on peut délester le 68K.

le top serait d'être parfaitement synchrone avec le shifter (pas du tout évident)

et seul les nouveaux dev pourrait bénéficier de cette amélioration... le jeu en vaut-il la chandelle ?



ps:la suite demain

ça me rappelle presque le principe des premières cartes accélératrices 3DFX sur PC

sundance (./37) :
l'effort dans ce cas est a faire au niveau des synchros afin d'avoir une incrust parfaitement stable et net, certes il faut absolument utiliser des multiplexeurs vidéos

Non, il y a beaucoup plus simple (et je m'étonne que tu n'y aies pas pensé vu ce que tu as posté avant ).

Tu reprends la sortie vidéo du shifter juste avant les convertos N/A et l'horloge vidéo (qui est la même que l'horloge système sur ST), tu utilises cette dernière pour cadencer un FPGA qui pourra upscaler la sortie vidéo du shifter et inscruter ce que tu veux par dessus, et tu mets un convertisseur N/A et une prise VGA derrière.

Comme ça, pas de multiplexage vidéo analogique chiant, pas de souci de compatibilité, pas de conversion A/N, pas de problèmes de jitter

ouais enfin l'installation de la carte sur un ST ne sera pas forcément un jeu d'enfant pour le coup

Quelques fils à souder... certes c'est pas à la portée de tout le monde, mais c'est loin d'être insurmontable. Pour la CT2 de Rodolphe c'était plus complexe que ça, et les gens les ont installées quand même.

D'autre part, si ça divise par deux le coût de la carte par rapport à une solution "plug& play", c'est pas négligeable.

vu comme ça, c'est sûr

sundance (./23) :
le problème 68020/030 = composant chère et +- difficile a avoir
les performances sont moyennes (4mips a 20 mhz pour le 020 et 11 mips a 33mhz pour le 030)
ce sont des gros composants = circuit imprimé cout élevé

Une alternative serait un FPGA avec un core 68000, les sources sont dispos sur le net puisque plusieurs projets utilisent déjà cette technique.
L'avantage c'est d'avoir une compatibilité quasi parfaite et de compenser le manque de cache (entre autre) du 030 par une fréquence de fonctionnement surboostée.
Par contre je n'ai aucune idée du prix

Selon la taille du FPGA tu pourrais aussi inclure ton ancien projet de carte gfx dedans.
Il y a pas mal de logiciels GEM sur Mega ST/TT utilisant des modes 256 couleurs qui pourraient fonctionner sans rien faire si tu proposes des modes graphiques des cartes 'PC' de l'époque.
Il est probable aussi que certains softs Falcon fonctionnent dessus si tu proposes le même mode 16bits ou le mode 256 couleurs planar si on exclu Rainbow et autres Apex qui triturent trop les entrailles du rapaces.

Kochise (./2) :
C'en est où le remplacement du GD-ROM de la Dreamcast ?

Kochise

Je complète les réponses déjà faites en disant qu'il y a maintenant des soft (il s'agit d'un OS/boot loader) sur DC permettant de lancer une iso DC a partir d'une SDCard pour quelques centimes d'euros . Apparemment ça marche plutôt bien.

Donc arriver avec une carte FPGA pour ça a 120 euros ou plus c'est mort

Quelques demo :
http://www.youtube.com/watch?v=0gTpylJi9wk
http://www.youtube.com/watch?v=r-b1JfRo5Zo&feature=related
http://www.youtube.com/watch?v=zn-jATpRtAY&feature=related

Xerus (./43) :

sundance (./23) :
le problème 68020/030 = composant chère et +- difficile a avoir
les performances sont moyennes (4mips a 20 mhz pour le 020 et 11 mips a 33mhz pour le 030)
ce sont des gros composants = circuit imprimé cout élevé

Une alternative serait un FPGA avec un core 68000, les sources sont dispos sur le net puisque plusieurs projets utilisent déjà cette technique.
L'avantage c'est d'avoir une compatibilité quasi parfaite et de compenser le manque de cache (entre autre) du 030 par une fréquence de fonctionnement surboostée.
Par contre je n'ai aucune idée du prix

Selon la taille du FPGA tu pourrais aussi inclure ton ancien projet de carte gfx dedans.
Il y a pas mal de logiciels GEM sur Mega ST/TT utilisant des modes 256 couleurs qui pourraient fonctionner sans rien faire si tu proposes des modes graphiques des cartes 'PC' de l'époque.
Il est probable aussi que certains softs Falcon fonctionnent dessus si tu proposes le même mode 16bits ou le mode 256 couleurs planar si on exclu Rainbow et autres Apex qui triturent trop les entrailles du rapaces.

Faut il en déduire que ta proposition est de faire une carte pour ST qui en fasse un Falcon ?

Xerus (./43) :

sundance (./23) :
le problème 68020/030 = composant chère et +- difficile a avoir
les performances sont moyennes (4mips a 20 mhz pour le 020 et 11 mips a 33mhz pour le 030)
ce sont des gros composants = circuit imprimé cout élevé

Une alternative serait un FPGA avec un core 68000, les sources sont dispos sur le net puisque plusieurs projets utilisent déjà cette technique.
L'avantage c'est d'avoir une compatibilité quasi parfaite et de compenser le manque de cache (entre autre) du 030 par une fréquence de fonctionnement surboostée.
Par contre je n'ai aucune idée du prix

Selon la taille du FPGA tu pourrais aussi inclure ton ancien projet de carte gfx dedans.
Il y a pas mal de logiciels GEM sur Mega ST/TT utilisant des modes 256 couleurs qui pourraient fonctionner sans rien faire si tu proposes des modes graphiques des cartes 'PC' de l'époque.
Il est probable aussi que certains softs Falcon fonctionnent dessus si tu proposes le même mode 16bits ou le mode 256 couleurs planar si on exclu Rainbow et autres Apex qui triturent trop les entrailles du rapaces.

Il vaudrait pas mieux prendre un minimig, C-one ou équivalent à base de FPGA et faire un noyau ST dessus ?

Une machine Amiga pour faire tourner un Atari ? Pouah

(ceci dit, ce que tu dis est très logique)

C'est bien ce qu'ils ont fait pour le Kit de dev officiel Lynx (handy)

Ouais, mais ça leur plaisait tellement pas qu'ils ont mis des autocollants (je crois) pour cacher le logo Amiga ^^

t'es sûr ? l'équipe d'origine restait pourtant des amigaïstes

Yep, mais Atari n'avait pas apprécié que le kit tourne sur un Amiga (un peu logique, en même temps ), et ils avaient grossièrement "déguisé" les machines pour cacher la marque :

Je ne me souviens plus des dates exactes, mais un jour, longtemps avant la sortie officielle de la Jaguar, je me rend avec Rodolphe chez Atari France. Là, on nous fait penetrer dans un hangar, et sur une table, juste à coté d'un système de développement Lynx (un Amiga 2000 dont les gars chez Atari avait ôté le logo pour le remplacer par "Lynx Development System", on savait rire chez Atari), se trouvait un prototype de Jaguar.

(source)

Zerosquare (./51) :
Yep, mais Atari n'avait pas apprécié que le kit tourne sur un Amiga (un peu logique, en même temps ), et ils avaient grossièrement "déguisé" les machines pour cacher la marque :

Je ne me souviens plus des dates exactes, mais un jour, longtemps avant la sortie officielle de la Jaguar, je me rend avec Rodolphe chez Atari France. Là, on nous fait penetrer dans un hangar, et sur une table, juste à coté d'un système de développement Lynx (un Amiga 2000 dont les gars chez Atari avait ôté le logo pour le remplacer par "Lynx Development System", on savait rire chez Atari), se trouvait un prototype de Jaguar.

(source)

d'un autre coté, c'est le problème d'Atari, ils rachètent un truc, ils auraient pu financer la reconception du kit de dev si c'était à ce point un sacrilège de développer sur amiga...

Bah, ils étaient connus pour être super pingres

bah voilà, et dans ce cas, on ferme sa gueule.

pour le fpga j'ai trouvé 2 sources pour le 68000

une payante et une dispo sur opencores mais dans les 2 cas l'émulation n'est pas complète

je vous rappel que le minimig est composé d'un fpga et d'un 68000


seul la version sur altera ce passe de 68000

./43
en utilisant un fpga a la place du 68000
on peut accélérer mais ram et periph ne suivant pas donc il faut ajouter de la sram locale
puis aller moins vite avec les périphériques st, le gain en performance en souffrira
le cout grimpe et la mise en place dans le st est alors compliqué

ce qui peut être séduisant est d'ajouter de nouvelles fonctions soft et hard en effet

Jeff tu fais bien de préciser pour la dreamcast.

./39

j'y ai bien penser mais clairement il faut de la sram si on veut bien faire les chose, 1mo minimum à 10 ns + flash + alim spécifique fpga
au niveau installation c'est un peu compliqué
quand tu regarde la derniere photo de post ./49

topics/140688-carte-acceleratrice-3d-pour-atari-st/2

tu aperçois une carte que je plug par dessus le shifter vidéo, le cout n'est pas trop élevé, mais c'est quand même bricole...
quand a l'alimentation il faut dériver le cordon du lecteur de d7
et après pour sortir la connectique c'est encore plus compliqué

mon scan doubleur marchait sur ce principe lisait une ligne sur les sorties numériques du shifter et recréait un port vga.
j'utilisai la clock du shifter pour être parfaitement synchrone.

mais je ne faisait qu'une ligne a la fois (que je doublait en vga donc) avec un µp à 5€

cependant la mise en œuvre du fpga et l'intégration dans le st rebutera la plupart des utilisateurs

en imaginant une install facile (sans soudure) il te faut un fpga de quelle taille ?

et le jeu en vaut-il la chandelle ?

si c'est pour ne jamais être utilisé par les dev ...

ou il faut trouver un moyen d'être transparent.

cependant cela ne veut pas dire qu'on ne peut rien faire en vga sur le port cartouche

implanté un chip vidéo ou un fpga qui reçoit ces ordres du 68K est possible

il faut juste prévoir quelque chose qui pédale un peu...








maintenant si on veut avoir un cout faible, une étude super courte, une dispo quasi immédiate, une distribution planétaire, il y a bien une solution (suite prochain post )

l'autre solution est de prendre un kit de dev et juste de faire l’interconnexion avec le port cartouche de l'Atari, voir un boitier pour le tout, le dev hard est vraiment minimum.
il faut choisir un kit avec pas mal de connecteur externe : usb / video / sdcard etc
le cout d'un kit de dev peut être faible mais ca ne seras pas 50 €
avec des possibilités toutes autres et rapport qualité prix imbattable !!!

après il faut savoir ce que l'on veut une carte maison et on vise les 50 € ou adaptation d'un kit de dev plus chère ?

que choisiriez-vous comme solution ?

il y a une autre source pour un 68k sur FPGA :
http://www.experiment-s.de/en

en effet ce que je vois sur le net c'est plein de projets fpga débouchant sur des cartes à environ 500 / 600 €

dans un premier temps puis une version light autour des 300 € (minimig & suska III T)

dans le 1er cas il n'y a pas débouché et dans le 2eme un petit marché,
pour l'instant seul le hxc peut devenir un std (ou est)
mérite et a des devs, sont prix raisonnable y est pour beaucoup.

pour la CT63 c'est plutôt historique et bénéficie donc de beaucoup de dev spécifique.

je ne m'engagerais pas dans un dev hard chère car à mon humble avis son succès dépend principalement de son prix.

donc concretement tu vas faire quoi?