Voilà bien ton esprit étriqué et réducteur: j'ai d'autres choix qu'aller au ciné ou rester chez moi.
Ceci étant, rassure-toi, je vais éviter ce film, garder mes sous, ce qui potentiellement en fait moins pour le milieu professionnel dont tu te revendiques. J'envisage difficilement que cela te satisfasses sans envisager quelques troubles psychiques.
A+ JF
*.-pipolin-.* a écrit :
t'as raison, reste chez toi
Voilà bien ton esprit étriqué et réducteur: j'ai d'autres choix qu'aller
au ciné ou rester chez moi.
Ceci étant, rassure-toi, je vais éviter ce film, garder mes sous, ce qui
potentiellement en fait moins pour le milieu professionnel dont tu te
revendiques. J'envisage difficilement que cela te satisfasses sans
envisager quelques troubles psychiques.
Voilà bien ton esprit étriqué et réducteur: j'ai d'autres choix qu'aller au ciné ou rester chez moi.
Ceci étant, rassure-toi, je vais éviter ce film, garder mes sous, ce qui potentiellement en fait moins pour le milieu professionnel dont tu te revendiques. J'envisage difficilement que cela te satisfasses sans envisager quelques troubles psychiques.
A+ JF
Cumbalero
*.-pipolin-.* a écrit :
le marché, c'est une réalité
La réalité de la masse, du nombre, de la consommation, des idoles.
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.
a+, -- G.T
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.
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.
a+, -- G.T
Cumbalero
*.-pipolin-.* a écrit :
Professeur Méphisto a formulé la demande :
Le Fri, 11 Sep 2009 10:22:03 +0200, *.-pipolin-.* a écrit :
préposé à la sauvegarde
ne parlez pas de ce que vous ne comprenez pas.
parle pour toi !
Donne-nous ta définition de ce qu'est une sauvegarde, et après on verra.
A+ JF
*.-pipolin-.* a écrit :
Professeur Méphisto a formulé la demande :
Le Fri, 11 Sep 2009 10:22:03 +0200, *.-pipolin-.* a écrit :
préposé à la sauvegarde
ne parlez pas de ce que vous ne comprenez pas.
parle pour toi !
Donne-nous ta définition de ce qu'est une sauvegarde, et après on verra.
Le Fri, 11 Sep 2009 18:22:30 +0200, *.-pipolin-.* a écrit :
ha oui pardon, le linuxien... la race supérieur...
Que nenni, mais ce sont des problématiques qui se posent.
Sébastien Kirche
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) j'en fais encore de l'assembleur. Pourtant je ne suis pas (encore) un dino, juste un sympathisant du Club des Vieux Cons.
Pas de gros projets, plutôt de petits tools graphiques qui tiennent dans quelques ko en asm win32 (avec RosASM). Mon boulot habituel c'est plutôt les L3G / L4G, mais il m'arrive encore assez souvent de sortir le désassembleur et d'inspecter du code "en direct" :o)
-- Sébastien Kirche
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) j'en fais encore de l'assembleur.
Pourtant je ne suis pas (encore) un dino, juste un sympathisant du Club
des Vieux Cons.
Pas de gros projets, plutôt de petits tools graphiques qui tiennent dans
quelques ko en asm win32 (avec RosASM). Mon boulot habituel c'est plutôt
les L3G / L4G, mais il m'arrive encore assez souvent de sortir le
désassembleur et d'inspecter du code "en direct" :o)
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) j'en fais encore de l'assembleur. Pourtant je ne suis pas (encore) un dino, juste un sympathisant du Club des Vieux Cons.
Pas de gros projets, plutôt de petits tools graphiques qui tiennent dans quelques ko en asm win32 (avec RosASM). Mon boulot habituel c'est plutôt les L3G / L4G, mais il m'arrive encore assez souvent de sortir le désassembleur et d'inspecter du code "en direct" :o)
-- Sébastien Kirche
Sébastien Kirche
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 ? -- Sébastien Kirche
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 ?
--
Sébastien Kirche
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 ? -- Sébastien Kirche
