MS Win 7 est tellement mauvais...

Sébastien Kirche a écrit :

Le 9 septembre 2009 à 22:56, seb a formulé :

Sébastien, c'est avec toi que je devais voir pour récupérer le STE de
Djamé :)

Héhé, salut :o)

J'ai depuis trouvé un STE avec 1Mb de RAM (bientôt 4) dans mon coin.
Et 1Mb, une fois enlevé l'OS, bon sang ce que c'est court quand on y
pense ! On se remet à calculer en Kb quand une seule image bouffe à
elle seule 5% des ressources RAM !

Pour ton projet de codage ST, si tu as besoin de relecteurs ou de bêta
(alpha ?) testeurs, ou simplement de motivation je suis volontaire :o)
Quand je pense à mes projets qui restent à l'état d'idée parce que je
prends pas le temps de m'y coller vraiment je me dis qu'il y a plein de
bonnes idées qui ne voient pas le jour. Et puis je voudrais bien
m'intéresser de plus près au 68000 (au Z80 aussi mais ceci est une autre
histoire :o)

Quels outils utilises-tu pour coder sur STe ?

Moi sur Atari j'utilise Assemble.
C'est beau, c'est intégré, ca assemble vite! (9 secondes sur un TT pour
un source de plus de 600ko).

Guillaume.

Le 11-09-2009, ? propos de
Re: MS Win 7 est tellement mauvais...,
G.T ?crivait dans fr.comp.ordinosaures :

Rhello,

Non. Par rapport à un 6809, c'est une bouse infâme. Ça veut tout
faire, mais au final, ça ne fait rien correctement et surtout, on se
retrouve pour un vrai développement à avoir plus de composant sur sa
carte que si on avait directement pris un vrai µP.

On en avait déjà parlé, c'est vrai que tu préfères les µP.
Le µC, pour les "petits" projets, est bonnard : un composant, toutes les
fonctions, enfin celles dont tu as besoin suivant les versions...
Et ça, ils l'ont compris chez Microchip : le rfPIC c'est une idée. Bonne ou
mauvaise, je n'ai pas autorité pour le dire.
D'un autre côté, le PIC, on a vite fait de faire du C avec, parce que
l'assembleur n'est pas forcément une sinécure. Mais pour écrire un octet en
EEPROM, il *faut* une routine en assembleur, pour ouvrir / fermer les
verrous :-) Par contre, c'est roots (et ça peut être sympa en apprentissage)
: faut écrire ta gestion d'interruptions toi-même, tout ça. Même si, du
coup, on bouffe de la ROM programme (et quelques cycles) "à rien" là où il
suffit de renseigner les adresses des vecteurs sur le 6809, sauf erreur de
ma part (le plus proche du 6809 que j'ai eu la chance de toucher,
c'était -ça va pas te plaire- le 68HC11).

L'IDE fournie d'office était
pas mal, j'ai essayé la 8 j'me suis un peu paumé au début, plus
confortable
mais bien plus lourde aussi.

Comme quoi, les goûts et les couleurs...

On a vu pire. Et puisque tu parles de couleurs, c'est ça : la mise en
couleur automatique, c'est un peu de confort.
J'ai tâté du monochrome. J'imagine bien que quand on a connu les cartes
perforées, c'était déjà une révolution. Et puis dans le fond, c'est pas une
IDE, bonne ou mauvaise, qui va pousser les programmeurs à faire du code
propre et rapide.

Le problème, ce n'est pas l'IDE en tant que tel, c'est le fait de
masquer tout le fonctionnement intrinsèque de la bête. Ce n'est pas
pareil de se palucher l'écriture d'un vecteur d'interruption en
assembleur et de le générer automatiquement. Après, on trouve des
types qui ne font plus la différence entre un processeur vectorisé
et un auto-vectorisé et on va très rapidement dans le mur. On ne
peut pas avoir le cul assis entre deux chaises, soit on touche au
matériel, soit on a une couche d'abstraction entre les deux (style
carte de développement). Utiliser directement un composant quel
qu'il soit en collant pour les développements une couche
d'abstraction telle qu'un IDE avec un compilo C est une connerie
sans nom et aboutit à tous les problèmes qu'on a actuellement avec
les développements pas chers et rapides. Je te donne simplement un
exemple : dans l'automobile, il y a des tas de modules à base de
microcontrôleurs pour gérer des bus (oui, le câble est devenu trop
cher et est trop fiable, on colle des multiplexages partout !). Ces
modules tournent sur des µC de compétition, avec du code écrit en C.
Manque de bol, le C n'a pas assez de granularité pour assurer un
truc fiable à temps réel (au sens informatique tu terme). En
assembleur, on pourrait le faire, sur des processeurs largement
moins puissants et plus éprouvés. Je passe aussi sur le fait que le
C n'est pas un bon langage (il faut récupérer les erreurs à la main
et surtout _savoir_ programmer proprement, parce que je ne compte
plus les bouts de codes où on voit des sendto() sans vérification
d'erreur !). Résultat des courses, on est continuellement emmerdés,
il n'y a pas d'autres termes avec des modules électroniques qu'il faut
redémarrer parce qu'ils sont buggués jusqu'à la moëlle !

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 11-09-2009, ? propos de
Re: MS Win 7 est tellement mauvais...,
Sébastien Kirche ?crivait dans fr.comp.ordinosaures :

Le 11 septembre 2009 à 18:45, JKB a dit :

Ouaips, enfin, ben, euh... Il y a vraiment longtemps que je
n'ai plus vu autre chose qu'un dinosaure pour coder en
assembleur. [...]

JKB, qui a fait ses armes en assembleur sur PDP et VAX, ça ne
nous rajeunit pas...

Ben moi qui ne connais que les Intel depuis le 386 (et qui ai fait _une_
seule fois du 68000 - dommage j'ai toujours entendu que le x86 étaient
de sombres bouses à côté des Motorola)

C'est assez vrai ;-)

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

On Fri, 11 Sep 2009 18:22:26 +0200, *.-pipolin-.* wrote:

les animations sont de la motion capture et pour ce qui est des
visages, c'est le système est un système de capture facial"surfacique"
qui est capable de saisir des variations et des déplacements de l'ordre
du 10eme de millimètres, alors si tu veux, ce que tu en penses...

C'est dommage que tu n'arrives pas à envisager que malgré la technique
de pointe employée cela puisse ne pas être suffisant.
C'est bien joli ces capteurs mais j'ai comme l'impression que malgré
leur sensibilité, leur nombre reste insuffisant ou que le traitement qui
est fait des informations captées n'est pas encore au top.
Ca a énormément progressé mais ce n'est pas encore ça et du coup même
si le rendu est peut-être "le meilleur jamais réalisé", cela me parait
décevant.

Décevant non pas en regard de l'état de la technique ou du travail
réalisé mais décevant au niveau de la sensation transmise,

Ce que je dis est objectif et il n'y a pas la moindre agressivité dans
mon discours.

C'est mon point de vue de spectateur, si tu n'es pas capable de l'apprécier
c'est dommage car c'est bien pour faire réver le spectateur que tu fais
tout ce travail n'est-ce pas ?

--
Doug713705

Le vendredi 11 septembre 2009, JKB a écrit :

Ouaips, enfin, ben, euh... Il y a vraiment longtemps que je n'ai
plus vu autre chose qu'un dinosaure pour coder en assembleur.

Je code en assembleur bizarre et je ne suis pas un dinosaure.

Le 12 septembre 2009 à 10:44, Khanh-Dang vraute :

Le vendredi 11 septembre 2009, JKB a écrit :
> Ouaips, enfin, ben, euh... Il y a vraiment longtemps que je n'ai
> plus vu autre chose qu'un dinosaure pour coder en assembleur.

Je code en assembleur bizarre et je ne suis pas un dinosaure.

^^^^^^^^^^^^^^^^^^
C'est quoi ?
--
Sébastien Kirche

JKB a écrit :

Ben moi qui ne connais que les Intel depuis le 386 (et qui ai fait _une_
seule fois du 68000 - dommage j'ai toujours entendu que le x86 étaient
de sombres bouses à côté des Motorola)

C'est assez vrai ;-)

Disons que ce sont deux philosophies différentes.
Les registres du 68000 sont plus généraux et peuvent être considérés
comme des variables à tout faire. Sur un 8086 les registres sont dédiés
et on doit pas mal jongler...
Mais les deux sont intéressants.
J'ai programmé le TI-Compiler en 8086, ca m'a bien plu! Suffit d'être
organisé.
Maintenant, quand on passe au Pentium, beaucoup de choses se sont
arrangées et les registres ont un usage général assez semblable au 68k.

Guillaume.

On 12 sep, 10:25, doug713705 <doug.leto...@free.fr> wrote:

On Fri, 11 Sep 2009 18:22:26 +0200, *.-pipolin-.* wrote:
> les animations sont de la motion capture et pour ce qui est des
> visages, c'est le système est un système de capture facial"surfaciq ue"
> qui est capable de saisir des variations et des déplacements de l'ord re
> du 10eme de millimètres, alors si tu veux, ce que tu en penses...

C'est dommage que tu n'arrives pas à envisager que malgré la techniqu e
de pointe employée cela puisse ne pas être suffisant.
C'est bien joli ces capteurs mais j'ai comme l'impression que malgré
leur sensibilité, leur nombre reste insuffisant ou que le traitement qu i
est fait des informations captées n'est pas encore au top.
Ca a énormément progressé mais ce n'est pas encore ça et du coup même
si le rendu est peut-être "le meilleur jamais réalisé", cela me par ait
décevant.

Décevant non pas en regard de l'état de la technique ou du travail
réalisé mais décevant au niveau de la sensation transmise,

Ce que je dis est objectif et il n'y a pas la moindre agressivité dans
mon discours.

C'est mon point de vue de spectateur, si tu n'es pas capable de l'appré cier
c'est dommage car c'est bien pour faire réver le spectateur que tu fais
tout ce travail n'est-ce pas ?

--
Doug713705

Non, pour gagner de la thune, le spectateur, c'est accessoire.. Tant
qu'il paye ....

Le 12-09-2009, ? propos de
Re: MS Win 7 est tellement mauvais...,
Guillaume Tello ?crivait dans fr.comp.ordinosaures :

JKB a écrit :

Ben moi qui ne connais que les Intel depuis le 386 (et qui ai fait _une_
seule fois du 68000 - dommage j'ai toujours entendu que le x86 étaient
de sombres bouses à côté des Motorola)

C'est assez vrai ;-)

Disons que ce sont deux philosophies différentes.
Les registres du 68000 sont plus généraux et peuvent être considérés
comme des variables à tout faire. Sur un 8086 les registres sont dédiés
et on doit pas mal jongler...
Mais les deux sont intéressants.
J'ai programmé le TI-Compiler en 8086, ca m'a bien plu! Suffit d'être
organisé.
Maintenant, quand on passe au Pentium, beaucoup de choses se sont
arrangées et les registres ont un usage général assez semblable au 68k.

Je parlais du 6809 et non du 68000. Le passage du 6809 (ou mieux
6309) au 68000 a été une régression lorsqu'on programmait en
assembleur ne serait-ce que par les deux piles _simultanées_ du
6809. Sans parler du fait que le 6x09 était entièrement câblé alors
que le 68000 était microcodé, ce qui fait qu'en général, un
programme optimisé aux petits oignons sur un 6809 tournait bien
mieux qu'un programme de la même génération sur un 68000. Je ne
parlerais pas non plus des bricolages du 68000 pour accéder au bus
(les données sont présentes sur les deux octets du bus de données à
des moments _différents_) et de certains choix technologiques
discutables. Si le 6x09 avait un tas de périphériques fabuleux (y
compris un composant d'interface SCSI _direct_ des canaux DMA, des
interfaces de tout ordre, pouvait fonctionner en multiprocesseur
nativement), il fallait bricoler avec les 68000. Je ne
dis pas que rien n'existait, mais que la famille s'est
considérablement appauvrie. Je me suis toujours demandé pourquoi
Motorola n'avait pas fait un 68000 sur la base de ce qui existait
dans le 6809 plutôt que de bricoler un truc à partir d'un 6800. Idem
d'ailleurs pour la famille des 6811 et suivants. Le 6809 est assez
unique dans l'histoire des microprocesseurs et même tellement
irremplaçable que 30 ans après sa sortie, il est toujours utilisé,
produit (voir le catalogue NTE) et qu'il existe en VHDL (et ça, ce
n'est pas simple parce que les chemins de données internes au 6809
sont asynchrones).

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

"G.T" <g.t6@worldonline.fr> a écrit dans le message de news:
4aaa7ce9$0$3603$426a74cc@news.free.fr...
| Salut,
|
| > Et voilà ! les jeunes ne savent plus de quoi on parle ;-)
| Si, si :-)
|
|
Bah! Ça dépend peut-être de ce qu'on entend par "jeune" ;-D
|
|
| Et même si des fois on perd du temps pour du code "à la con" en
| apprentissage genre clignotement d'une LED, quand on attaque du plus
costaud
| (et surtout en assembleur), c'est peut-être du temps perdu, mais surtout
un
| investissement quand ça va pas.
|
|
Bravo pour l'approche raisonnée ! C'est trop rare, de nos jours

--
IOBA