Et si on se faisait un ordi?! - Page 1

Bonjour,

Il serait peut être temps de se faire une nouvelle machine, il y a plusieurs années que cela me trotte dans la tête. MyAES c'est bien mais j'aimerais aller plus loin changer un peu. Aujourd'hui ce n'est plus si compliqué, il faut certes pas mal d'huile sous le coude mais à mon avis rien d'insurmontable je sais que cela est passé à la tête de quelques développeurs Français que je connais sans vraiment essayer de le réaliser.

Voilà les grandes lignes:

Coté hardware:
ARM cortex A9 2Ghz type amlogic S802 4 coeurs
2Go de ram
GPU 8 coeurs type Mali 450
RJ45 100Mb
lecteur MicroSD
8Gb de flash ram
Wifi, Bluetooth
HDMI
USB et autres périphs

Coté software:
Kernel type L4 + les couches AES (MyAES) - VDI - GEMDOS pour rester autant que possible compatible niveau source
Emulateur 68000 avec accès à l'API de la machine en natif (programme de Vincent R. déjà utilisé pour la firebee)
Il est probable qu'une partie des périphériques ne seront pas utilisables dans un premier temps il faudra des développeurs.

Coût de l'ordre de 200 euros.

C'est pas gagné, je me donne 2 ans pour y arriver enfin s'il y a du monde intéressé!

Olivier

Je ne veux pas être méchant, mais quel est l'intérêt ?

Vu que c'est de l'émulation et qu'il n'y a pas de périphériques non-standard, pourquoi s'embêter à refaire une carte plutôt que d'utiliser une simple carte mère PC, et profiter ainsi de tout ce qui existe déjà (et des prix bas) ? Quel avantage par rapport à une distribution Linux allégée pour ne faire tourner qu'Aranym ?

Zerosquare (./2) :
Je ne veux pas être méchant, mais quel est l'intérêt ?

Vu que c'est de l'émulation et qu'il n'y a pas de périphériques non-standard, pourquoi s'embêter à refaire une carte plutôt que d'utiliser une simple carte mère PC, et profiter ainsi de tout ce qui existe déjà (et des prix bas) ? Quel avantage par rapport à une distribution Linux allégée pour ne faire tourner qu'Aranym ?

Je n'ai pas dit que je referais une carte (d'ailleurs je n'y connait rien!), le matériel existe déjà, pourquoi pas un PC simplement que si on porte l'API le moindre binaire sera incompatible entre le monde émulé et le monde réel sinon faut tout faire sous l'émulateur (ca j'ai fait il y a pas loin de 10 ans, pas beaucoup d'intérêt)
Cela fait 10 ans que je suis sous Aranym, il y a toujours la possibilité d'utiliser le Natfeat pour étendre, cela devient vite l'usine à gaz, le multicoeur n'est pas accessible (il est d'ailleurs hors de portée de Mint), on veut bricoler le système et s'amuser avec le hard point de salut.

Olivier

OL (./3) :
pourquoi pas un PC simplement que si on porte l'API le moindre binaire sera incompatible entre le monde émulé et le monde réel sinon faut tout faire sous l'émulateur (ca j'ai fait il y a pas loin de 10 ans, pas beaucoup d'intérêt)

Hein ? Mais avec de l'ARM c'est pareil. Je comprendrais le choix d'une architecture proche du 68k (PowerPC, Coldfire), mais quitte à faire le choix d'une archi différente pour simplifier le matériel, je ne comprends pas pourquoi utiliser de l'ARM plutôt que du x86 vu que c'est une machine desktop (donc sans contrainte de consommation).

Enfin bon, j'ai l'impression que tu vas te lancer dans un projet énorme, qui va prendre un temps fou, et au final (si ça aboutit) il restera au mieux 2 développeurs motivés et quelques utilisateurs, comme la plupart des projets hardware sur Atari.

Une couche d'abstraction + un émulateur (pour les anciens programmes) + une nouvelle API propre (pour les nouveaux), qui s'appuierait sur Linux pour ne pas avoir à réécrire les drivers, le scheduler et le reste, et qui pourrait s'installer sur n'importe quel PC, me semble bien plus adapté pour faire évoluer les choses.

-

ou une beaglebone histoire de pouvoir faire mumuse avec les GPIOs?

Orion_ : le Raspberry Pi c'est une bonne idée (c'est pas cher et pas mal de gens en ont), par contre en "bare metal" tu vas t'amuser pour les drivers

-

Ben c'est bien ce que je dis, dans les deux cas c'est réinventer la roue.

Zerosquare (./4) :

OL (./3) :
pourquoi pas un PC simplement que si on porte l'API le moindre binaire sera incompatible entre le monde émulé et le monde réel sinon faut tout faire sous l'émulateur (ca j'ai fait il y a pas loin de 10 ans, pas beaucoup d'intérêt)

Hein ? Mais avec de l'ARM c'est pareil. Je comprendrais le choix d'une architecture proche du 68k (PowerPC, Coldfire), mais quitte à faire le choix d'une archi différente pour simplifier le matériel, je ne comprends pas pourquoi utiliser de l'ARM plutôt que du x86 vu que c'est une machine desktop (donc sans contrainte de consommation).

Enfin bon, j'ai l'impression que tu vas te lancer dans un projet énorme, qui va prendre un temps fou, et au final (si ça aboutit) il restera au mieux 2 développeurs motivés et quelques utilisateurs, comme la plupart des projets hardware sur Atari.

Une couche d'abstraction + un émulateur (pour les anciens programmes) + une nouvelle API propre (pour les nouveaux), qui s'appuierait sur Linux pour ne pas avoir à réécrire les drivers, le scheduler et le reste, et qui pourrait s'installer sur n'importe quel PC, me semble bien plus adapté pour faire évoluer les choses.

ARM et x86 ce n'est pas du tout la même chose, en parlant de binaire je ne pensais pas d'exécutable mais de fichier binaire de données je pense par exemple au .RSC (je crois qu'on ne peut guerre faire pire comme format de fichier!) sur ARM je n'ai rien à retoucher sur x86 va falloir tout remettre en ordre et je dis pas la galère, tout simplement car l'un est big endian l'autre little endian. Le moindre fichier binaire d'une application ce sera la même chose.

Oui le projet est ambitieux, mais si je n'ai pas de projet qui me motive j'arrête tout et MyAES c'est bien mais j'ai l'impression de n'avoir fait que cela ces 10 dernières années et aujourd'hui c'est un projet mature j'ai encore quelques petites choses à faire mais bon rien d'extraordinaire et si je veux aller bien plus loin il faut que je lie VDI et AES chose tout à fait impensable sur les machines actuelles. Si je le fais c'est pour aller plus loin. Je ne me fais pas beaucoup d'illusion non plus, je commence à me faire plus vieux, je vois la vie passer et ce je ne compte plus programmer que pour les longues soirées d'hiver!

Olivier

-

Les ARM sont bi-endian, mais sont tres rarement utilisé en Big Endian.

Et les soucis d'endianess sont de faux problemes.

J'en ai rêvé je ne sais combien de fois !
Comme je ne suis pas développeur vous avez au moins un beta testeur dans la liste :-)

Maintenant je ne suis pas convaincu par le choix d'une plateforme exotique. Quel que soit les difficultés softs que cela puisse représenter, il me semble vital de miser sur une plateforme pérenne.
L'exemple de la firebee me semble assez parlant ; 10 ans pour développer la bête et arriver à un produit utilisable, mais aucun développement du ColdFire qui est resté à la même fréquence depuis le début de projet, sans parler du coût prohibitif des petites séries.

Je rejoins tout à fait Zerosquare : X86 est la plateforme la plus universelle et pérenne. Aujourd'hui on trouve des miniPC à partir de 100€ et des core i3 à 300€.
Ma config sous Linux bootant en 20 sec directement sous Aranym-JIT sur un Core i3 2120 (pas un foudre de guerre) tourne 30x plus vite qu'une CT60-100 ; pas difficile d'imaginer qu'en natif on multiplie tout ca par 5 ou 10. Maintenant si on pouvait booter directement sous GEMDOS + Mint + AES + VDI en natif x86 avec accés direct au HW, faire tourner sous émulateur les softs 68K, porter HATARI afin de faire tourner quasiment 100% des softs ST : le rêve.

La question big / little Endian, me semble dans ce cas mineur. OK, cela nécessitera non seulement une version du programme différente mais aussi de ses ressources et fichiers annexes, mais est-ce réellement un problème ? OSX fonctionne de cette façon, non?
Je comprend Olivier que tu veuilles changer Mint par un noyaux moderne supportant le multicoeur : dans ce cas, j'imagine qu'il fonctionnera sous mémoire protégée, ce qui quasiment élimine la grande majorité des softs 68K existants, à moins de les faire tourner sous une machine virtuelle. Au final une bonne chose, mais qui ne prêche pas nécessairement en faveur d'une compatibilité des ressources.

Je me demande si une première étape ne serait pas développer sous Aranym tous les outils pour compiler et utiliser des applis natives x86, ainsi que les drivers HW natifs ? Ca fait déjà un beau projet ;-)

Godzil: Pas trouve comment regler l'endianess des arm au runtime...

Bit 7, registre 1 (c1) du CP15


http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3956.html

Applies to : ARM926EJ-S

ok, c'est un bit cp, merci.

Godzil (./12) :
Les ARM sont bi-endian, mais sont tres rarement utilisé en Big Endian.

Et les soucis d'endianess sont de faux problemes.

En principe oui, je ne vois pas pourquoi un proc en little ou big irait plus ou moins bien selon l'endian je laisse cela à quelques rares illuminés!
Mais il y a une exception suivant que les protocoles ou fichiers sont gérés en big ou little, j'en reviens à l'exemple du fichier ressource, mettons que j'ai un système 100% natif, la routine va se farder la transformation du big en little déjà pas drôle vu la cochonerie que c'est comme format (j'en sais quelque chose j'y ai passé plusieurs mois à faire fonctionner tous les ressources que je présentais!), maintenant si il y a une couche d'émulation 68K pour faire tourner les softs existants (ce serait bête sinon) qui appel la routine native (c'est mieux quand même) le ressource fourni ne sera pas dans le bon sens et l'appli 68K plantera sauf à faire la moulinette inverse pour donner à l'émulateur, possible mais bof!

OL

ce document est pour les arm926, mais c'est valable pour les autres aussi

J'ai cherché un peu et le problème pourrait être moins ardu que prévu.

De toute évidence peu importe si au boot le systeme est little endian, chaque process peut avoir son propre endian via l'instruction SETEND, cela peut être même très local. Je n'en demande pas franchement plus!


OL

Sauf que ce n'est pas une bonne idee:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0802a/Cjacabbf.html

Note
SETEND is deprecated.

Godzil (./20) :
Sauf que ce n'est pas une bonne idee:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0802a/Cjacabbf.html

Note
SETEND is deprecated.

Ca ne me fait pas de noeud au cerveau, c'est depuis les ARM V8 64 bits, je ne veux surtout pas d'une version 64 bits, tout est en 32 bits dans l'API gem!

Oui enfin si ARM déprécis sur la meme architecture cette instruction (introduite sur les ARMv7, et déprécié sur la même archi) c'est qu'il doit y avoir de gros soucis avec...

En plus cette instruction n'est meme pas présente sur toutes les puces ARMs en ARMv7...

Bonjour à tous

Désolé de déterrer ce thread, mais le projet m'intéresse au plus haut point. J'avais d'ailleurs moi-même, un ou deux ans plus tôt, émis l'hypothèse sur ce même forum d'une implémentation TOS et (My/X)AES sur plateforme ARM et en particulier sur RPi.
Lors de l'achat du RPi model B, j'ai rapidement découvert RISC OS, et j'en suis vraiment devenu fan. Un système léger, rapide, délicieusement surrané, mais disposant d'un univers applicatif encore moderne et actif. J'ai rapidement fait l'acquisition (=acheter) des produits phares de cette plateforme: OvationPro, TechWriter, ArtWorks2, Fireworkz Pro, DataPower 3, et quelques autres applications mineures. Récemment, j'ai décidé de faire la pas et d'acheter DDE. Bref, RISC OS est un coup de coeur qui m'a donné envie de supporter les développeurs de ce monde. Aujourd'hui, mes machines RISC OS (RPi, BeagleBoard-xM, OpenPandora) constituent 70% de mon usage informatiques domestiques (adminisitration, bureautique, programmation, etc...). Seul la gestion de mes photos en RAW et le net banking nécessitent encore mon PC.

Mais ma plateforme de coeur, pour laquelle j'ai une véritable nostalgie, est l'Atari et je rêverais de la voir revivre sur une plateforme pérenne et bon marché comme ARM. Je suis plus que disposé à donné un coup de main, par exemple pour tester.

Alors, est-ce que ce projet a passé le stade de l'idée et est activement poursuivi?

Cordialement

François

Salut, sympa d'avoir déterrer ce thread, je l'avais jamais vu.

L'Atari ST est ma machine de cœur, pour toujours. Je serais intéressé aussi pour voir sortir quelque chose. J'aime bien l'idée d'avoir son propre ordinateur même si je connais pas MyAES ou tout du moins un Atari ST re-carrossé dans un beau boitier sans forcement copier celui d'origine mais avec un vrai clavier. Et pourquoi pas un RPI comme base et une interface à la MyAES ou du type cloanta avec amiga forever.

Si on peut définir des besoins précis avec les ressources existantes, je suis prêt à donner de mon temps. Et j'ai des connaissances de base pour Linux, ce qui est déjà pas mal. Par contre presque rien en électronique.

Cordialement.
Olivier.

(Euh quelle serait l'avantage par rapport à une FireBee, en fait ? A part le prix, mais je ne suis même pas certain qu'arriver à faire moins cher que les 600€ de la FB soit possible en pratique...)

pourquoi pas le mist !

par exemple chez
http://amiga.amedia-computer.com/index.php/catalogue/infos/3/9/ACF_MISTMIDIDB9

Déjà pour le plaisir de le faire ... Avoir son petit système, facilement upgradable.

Et puis un coût peut-être moins élevé, 2* moins que le mist, 3* moins que le firebee (cf prix 1er post en étant large)
90€ avec écran ... http://beagleboard.org/project/gamingcape/

Dans le même esprit, un "vrai" Atari ST avec disque sd et dans ce cas le firebee ou mint ne servent à rien

Bonjour

Ma vision n'est pas de fabriquer une nouvelle machine, mais plutôt de faire vivre l'esprit et le "look-and-feel" typiquement Atari vers une plateforme existante et qui a de l'avenir. Le raspberry pi, c'est moins de 50 euros et cela explose n'importe quelle carte accélératrice pour le falcon.
L'architecture 68K est morte depuis de nombreuses années, mais l'esprit Atari est toujours vivant. Et l'architecture ARM et tous les projets "alternatifs" qui gravitent autour d'elle me semble la plus proche de cet esprit.
Je rêve d'un OS natif ARM qui nous offre la même expérience, le même look-and-feel que le TOS combiné à MiNT et X/MyAES et qui intègre une moteur d'émulation complètement transparent pour les application 68K.
Par exemple, l'émulateur Hatari a déjà été porté sur ARM et fonctionne sous RiscOS.

Je rêve d'une plateforme permettant de développer de nouvelles aplications natives ARM avec les mêmes API que sur Atari tout en bénéficiant de l'émulation des applications qui ont fait la gloire d'Atari.

Ce serait super de pouvoir reprendre la série "développement GEM" de ST Magazine sur un raspberry pi ou une beagleboard
Ou faire tourner "La Gestion Comptable" et "Redacteur 4" en full hd...

Est-ce possible?

François

C'est ça qui me plairait vraiment. Une interface évoluée, même avec un RiscOS moddé , et la possibilité de développer / dessiner sur cette interface pour lancer après dans un environnement 68k comme Hatari.

Le tout dans un bel emballage. Pour moi ce serait le top.

brainois (./28) :

Ce serait super de pouvoir reprendre la série "développement GEM" de ST Magazine sur un raspberry pi ou une beagleboard
Ou faire tourner "La Gestion Comptable" et "Redacteur 4" en full hd...

Est-ce possible?
François

Le beagleboard a l'air puissant, tu sais si un emul marche dessus ?

Salut Tonma

J'ai installé Hatari 1.62.2 sur BeagleBoard-xM sous RiscOS, mais je n'ai pas encore testé.

Pour plus d'info
http://www.riscository.com/2012/hatari-st-emulator-ported/

Cordialement