Pour tuer le confinement je me suis remis à programmer

SergioVE

Grand Maître
#21
celui là je ne connais pas mais il se rapproche du Basic de mes 1ère machines en 8bit
TO7/70 et MO5
a les goto et do / loop un vrai bonheur ;-)
C'est le Basic des premiers IBM PC.
 

andre.gerald

Grand VidéaVizir
#22
:hello:
ça c'est le vrai basic de base avec N° de ligne et pas compilable ?? je pense
Le VB6 et déja orienté objet
Un jeu de carte que j'avais commencé en turbo Pascal, je l'ai terminé en VB en faisant un copie collé du code turbo pascal où j'ai du corriger quelques erreurs de syntaxe.
ça m'a étonné d'avoir pu installé VB6 (qui date de 98) sous W10
 

Foreveryoung35

Habitué
#23
ahah on partage ses vieux souvenirs :) moi je me rappelle avoir débuté la "programmation" (je mets des guillemets hein) en m'autoformant sur de l'assembleur car il existait des compileurs/décompileurs qui permettaient d'accéder au code assembleur de fichier .exe et permettait notamment de craquer des logiciels. A l'époque je m'exerçais sur ACDsee ! Je l'ai jamais vraiment craqué en Assembleur mais j'avais réussi à écrire "Cracked by me" tout fièrement dans l'info du logiciel :lol: j'ai des vagues souvenirs de registres AX/BX dans lesquels on écrivait ou on allait lire des bits ou octets je ne sais plus....
 

magellan

Modérâleur
Staff
#24
:hello:
ça c'est le vrai basic de base avec N° de ligne et pas compilable ?? je pense
Le VB6 et déja orienté objet
Un jeu de carte que j'avais commencé en turbo Pascal, je l'ai terminé en VB en faisant un copie collé du code turbo pascal où j'ai du corriger quelques erreurs de syntaxe.
ça m'a étonné d'avoir pu installé VB6 (qui date de 98) sous W10
Oui... mais non selon moi. VB6 prétend faire de l'objet sans réellement en faire. C'est toute la difficulté de ce langage car tout le reste est tellement évident que c'en est enfantin.
C'est retors comme notion: on ne construit/détruit pas d'objet au sens premier du terme. C'est en revanche à partir de .NET qu'on a des langages réellement objet côté MS.

EDIT: Et puis je suis allé retourner voir les exemples de code "objet" VB6. Cela singe de l'objet, mais ce sont des handlers de comportement, pas de l'objet natif à mon sens. Mais ça se discute.

Je trouve d'ailleurs plus qu'ambigu ce que Wikipedia dit concernant le produit: non, ce n'est pas parce que tu as une palanquée de librairies déjà établies et disponibles ("objets") que ça en fait un langage objet. Orienté? Le terme est piégeux!

Après c'est un avis personnel et pas une vérité absolue. Je programme depuis tellement longtemps que je peux dire sans trop me tromper qu'on a:
- Du langage "machine" où tout est à ta charge comme l'assembleur
- Du séquentiel à la Cobol/BASIC et j'en passe (et on peut y inclure le bash Linux qui permet littéralement de programmer tout comme du ruby et autres)
- Du "Pseudo" objet parce qu'orienté objets graphiques (VB6 etc)
- Du "vrai" langage objet (Java, C++, C# etc)
- Du "faites gaffe c'est tordu" à la Python

A partir de là, on peut même enrichir par générations et types de conception d'objet. Un Java 1.4 n'a plus grand-chose à voir avec une dernière version actuelle par exemple.

Le pire? C'est qu'on peut faire du "non objet" avec un langage objet! Et là... aspirine, viens nous sauver du calvaire!
 

Foreveryoung35

Habitué
#25
Oui... mais non selon moi. VB6 prétend faire de l'objet sans réellement en faire. C'est toute la difficulté de ce langage car tout le reste est tellement évident que c'en est enfantin.
C'est retors comme notion: on ne construit/détruit pas d'objet au sens premier du terme. C'est en revanche à partir de .NET qu'on a des langages réellement objet côté MS.

EDIT: Et puis je suis allé retourner voir les exemples de code "objet" VB6. Cela singe de l'objet, mais ce sont des handlers de comportement, pas de l'objet natif à mon sens. Mais ça se discute.
j'ai bossé 2 ans en VB6 pour une société de gestion d'actifs parisienne. Tout était en VB6 (début dans années 2000). effectivement on avait une architecture qui s'apparentait à des briques objets mais je ne sais plus par quel subterfuge on faisait cela. Mais ce n'est effectivement pas un langage objet Natif.
 

magellan

Modérâleur
Staff
#26
j'ai bossé 2 ans en VB6 pour une société de gestion d'actifs parisienne. Tout était en VB6 (début dans années 2000). effectivement on avait une architecture qui s'apparentait à des briques objets mais je ne sais plus par quel subterfuge on faisait cela. Mais ce n'est effectivement pas un langage objet Natif.
Le truc est que nativement on peut "imiter" ce comportement mais sans être aussi puissant et précis qu'un langage totalement conçu pour. Pire: on peut mélanger du tout et n'importe quoi là-dedans, ce qui finit à coups de hacks en effet.
J'ai développé sur du VB1,4,5,6, et .Net. Tu peux voir la nette différence entre le premier du nom qui était un BASIC, et le dernier un langage' 100% objet.
 

SergioVE

Grand Maître
#27
:hello:
ça c'est le vrai basic de base avec N° de ligne et pas compilable ?? je pense
Le basic des premiers PC était en ROM, on y accédait en démarrant la machine sans support de boot et ce n'était bien sûr pas compilable. Mais si on lançait PC-DOS ou MS-DOS, on avait accès à un Basic plus complet qui était bien évidemment compilable.

Pour @magellan : langage machine et assembleur, c'est différent. L'assembleur admet par exemple l'adressage symbolique des données ou des instructions ce qui facilite plus que largement la programmation et encore plus la maintenance.
Dans les "séquentiels", on peut mettre à part les langages type Pascal qui bannissent le Goto.
Et on peut ajouter à ta catégorisation ce qu'on pourrait dénommer les "spaghetti" comme ASP ou PhP...
 

magellan

Modérâleur
Staff
#28
Le basic des premiers PC était en ROM, on y accédait en démarrant la machine sans support de boot et ce n'était bien sûr pas compilable. Mais si on lançait PC-DOS ou MS-DOS, on avait accès à un Basic plus complet qui était bien évidemment compilable.

Pour @magellan : langage machine et assembleur, c'est différent. L'assembleur admet par exemple l'adressage symbolique des données ou des instructions ce qui facilite plus que largement la programmation et encore plus la maintenance.
Dans les "séquentiels", on peut mettre à part les langages type Pascal qui bannissent le Goto.
Et on peut ajouter à ta catégorisation ce qu'on pourrait dénommer les "spaghetti" comme ASP ou PhP...
Je caricature évidemment... la compilation est entre les deux;)
 

SergioVE

Grand Maître
#29
Je caricature évidemment... la compilation est entre les deux;)
Tout à fait d'accord ! Cela dit, le premier assembleur, il a bien fallu l'écrire en langage machine... Il y avait aussi la vieille étape du link après compilation qui consistait à intégrer les bibliothèques externes (aujourd'hui on dirait dll).
 

magellan

Modérâleur
Staff
#30
Tout à fait d'accord ! Cela dit, le premier assembleur, il a bien fallu l'écrire en langage machine... Il y avait aussi la vieille étape du link après compilation qui consistait à intégrer les bibliothèques externes (aujourd'hui on dirait dll).
Plus ou moins. C'est un poil plus vicieux (et tu le sais je ne t'apprends rien à ce que je lis). On peut caricaturer en .dll en effet... mais pour ceux qui ne savent pas (et ils sont sûrement de plus en plus nombreux)
- Librairies: Aujourd'hui on parlerait de .dll sous Windows. A l'époque, on ne "compilait" pas vraiment séparément la librairie. A la compilation, on liait lesdites librairies qui se cumulaient d'une manière ou d'une autre dans l'exécutable. Après, on avait des langages produisant des fichiers tiers (.lib par exemple) pour avoir comportement de ".dll". La différence? Le référencement. Sous un langage moderne, il y a une notion de signature complexe afin qu'un programme donné n'utilise que la .dll qui lui est réellement destiné. (et c'est encore plus vicieux avec le .NET où on peut référencer une version donnée du framework qui se cumulent dans l'OS au lieu de se remplacer purement et simplement).
- La notion de segments: quand on n'avait que 640Ko de mémoire basse, on devait jongler avec des segments mémoire. Concrètement: ces 640 se voyaient occupés de la gestion de clavier, de différents pilotes tiers, pour arriver, quand on étzait bon en configuration config.sys et autoexec.bat à 570Ko (mon record personnel pour mes clients de l'époque). Cela donnait quoi? Qu'on devait se dire "pas plus de 500Ko en mémoire basse, le reste en mémoire étendue). Et là ... vive les magouilles!
 

andre.gerald

Grand VidéaVizir
#31
La notion de segments: quand on n'avait que 640Ko de mémoire basse, on devait jongler avec des segments mémoire.
Bin OUI j'ai développé un soft de "controle" pour mes éléves qui a fait la joie du collègue qui bossait en techno avec moi:
Pendant mes 10 dernières années je n'ai eu plu rien à corrigé !!!
Je l'avais fait en turbo basic et il était en plusieurs segments de 64 KO !!!
P...Obligé de programmer entièrement la page d'édition des contrôles comme celles des élève d'ailleurs.
Il étaient très bien foutu je l'ai même fait essayé à une collégue prof d'anglais car le Jeudi on se partageait une classe de 3ème.
Elle m'avait donne la vieille son contrôle qu'en 1/2 h j'ai adapté à mon soft !
Toute étonnée le lendemain elle m'a dit: il corrige comme moi !!

Mais les profs dans l'ensemble ne sont pas très malins et à part le collègue qui bossait avec moi.....peu en ont vu l'intérêt.
Ok en techno on avait deux salles avec 14 ordi par salle environ ...Il fallait évidemment avoir accès à une salle correctement équipée pour en profiter.
Ayant des classes techno où les élèves étaient pas très doués en orthographe j'avais fait une correction pratiquement phonétique modulable.
 

Patakesse

Grand Maître
#32
Ahhh le code...

Pour moi le code c'est ça :
Code:
        MOVEM.L D2/D3/D4/A2,-(SP)
        LSR.W   #1,D1        ; half the buffer
        LEA     (A0,D1.W),A2    ; points to even bits
        LSR.W   #2,D1        ; # of longwords (for half)
        SUBQ.W  #1,D1        ; DBRA entered at top
        MOVE.L  #$55555555,D4    ; mask for clock bits
        MOVEQ   #0,D0        ; initial checksum
ou ça :
C:
    ch = **string;
    if (ch >= 0xD800 && ch <= 0xDBFF) {
        ch2 = *string[1];
        if (ch2 >= 0xDC00 && ch2 <= 0xDFFF) {
            ch = ((ch - 0xD800) << 10) + (ch2 - 0xDC00) + 0x0010000UL;
            ++read;
        }
    }
J'y vois un poème naissant, sans blague. :)

Tout le reste m'ennuie beaucoup. J'ai programmé avec de très nombreux langages, parfois exotiques (BCPL, E), mais jamais avec la passion de l'assembleur et du C. Ce sont les seules façons naturelles de programmer pour moi. Avec le typage, un ramasse-miettes, sans pointeurs et son arithmétique fabuleuse, je suis perdu, tout me semble compliqué.

J'ai débuté avec le langage machine (pas l'assembleur), j'ai ensuite été contrait de faire du Basic sur beaucoup de machines entre le début et le milieu des années 80, mais c'est l'assembleur que j'ai le plus longtemps pratiqué (Z80, 68k puis x86), puis ensuite le C. Lorsque j'ai découvert le PC, c'était un cauchemar avec son modèle mémoire segmenté par rapport au modèle FLAT du 68k. Par contre lorsque j'ai dû programmer le firmware d'un petit appareil avec une puce ARM il y a 4 ans (à titre de hobby, en open source), j'ai mis très peu de temps à me familiariser avec le jeu d'instructions que je ne connaissais pas du tout.

Je ne comprends pas grand chose à des langages comme les C# ou le Java (et je n'ai pas envie de faire d'effort pour ça). Il faut potasser des encyclopédies ennuyeuses de fonctions, comme lorsque j'avais dû apprendre l'intégralité des ROM Kernel de l'Amiga, des API Win32 et du framework WDM. C'est pas drôle. Sur l'Amiga c'était facile, on prenait le contrôle total du hardware au boot et on faisait ce qu'on voulait sans se soucier de la ROM (en gros équivalente au BIOS). Piloter le matériel était possible en partant de rien et sans aucune librairie. J'avais par exemple, pour une démo, fait jouer de la musique au lecteur de disquette en pilotant le moteur pas à pas. Cela avait eu son effet :) C'est pas la même aujourd'hui, on démarre sur un OS et lui nous dit : "ah non, t'as pas le droit d'accéder directement à ce périphérique pour allumer sa led mon coco, je supervise tout, va falloir te farcir les modèles WDM et KMDF.". C'est pas rigolo.

Même si je ne travaille plus du tout dans ce domaine depuis longtemps, la programmation m'a passionnément dévoré depuis jeune, il y a 40 ans, et je continue de temps à autre à programmer. Cela a du sens dans mon parcours plus artistique que technique. Faire des films, concevoir ou programmer une machine et composer de la musique, c'est pour moi la même chose : on crée quelque chose à partir de rien, on concrétise une idée. L'aspect créatif des programmeurs n'est pas assez mis en avant il me semble. C'est magique de partir d'une feuille blanche puis de faire naitre peu à peu un programme, un jeu, quelque chose avec lequel d'autres vont pouvoir interagir, travailler, s'amuser et même éprouver des émotions.

Je développe mes sites web, et ça, ça m'ennuie prodigieusement, ça ne n'amuse pas du tout. Je trouve ça plus compliqué, moins drôle et moins gratifiant que de développer un firmware en assembleur ou C. Ce n'est qu'un site web parmi tant d'autres interprété dans le navigateur d'un OS, alors qu'un firmware, c'est ce programme entièrement autonome qui donne "vie" à l'appareil et permet de l'utiliser. :) Mais heureusement que tout le monde ne pense pas comme moi :D
 

andre.gerald

Grand VidéaVizir
#33
:hello: David
MOVEM.L D2/D3/D4/A2,-(SP)
LSR.W #1,D1 ; half the buffer
LEA (A0,D1.W),A2 ; points to even bits
LSR.W #2,D1 ; # of longwords (for half)
SUBQ.W #1,D1 ; DBRA entered at top
MOVE.L #$55555555,D4 ; mask for clock bits
MOVEQ #0,D0 ; initial checksum

Traduction ...SVP
7 lignes de code qui font quoi ?

Tu donnes des cours ? ...Non t'es un peu loin ..MDR...
Clair que tous les jeux du commodore 64 étaient surement développé en assembleur ou langage machine
J'avais acheté un jeux d'échec pour le commodore :
Sur la boite écrit:
100% langage machine :D

Si j'ai bien compris tu pourrais entrer dans le code source qui est Open source, de StockFish ..Du haut de ses 3500 point ELO il a parfois une analyse absurde sur une certaine position...
 

magellan

Modérâleur
Staff
#34
Ahhh le code...

Pour moi le code c'est ça :
Code:
        MOVEM.L D2/D3/D4/A2,-(SP)
        LSR.W   #1,D1        ; half the buffer
        LEA     (A0,D1.W),A2    ; points to even bits
        LSR.W   #2,D1        ; # of longwords (for half)
        SUBQ.W  #1,D1        ; DBRA entered at top
        MOVE.L  #$55555555,D4    ; mask for clock bits
        MOVEQ   #0,D0        ; initial checksum
ou ça :
C:
    ch = **string;
    if (ch >= 0xD800 && ch <= 0xDBFF) {
        ch2 = *string[1];
        if (ch2 >= 0xDC00 && ch2 <= 0xDFFF) {
            ch = ((ch - 0xD800) << 10) + (ch2 - 0xDC00) + 0x0010000UL;
            ++read;
        }
    }
J'y vois un poème naissant, sans blague. :)

Tout le reste m'ennuie beaucoup. J'ai programmé avec de très nombreux langages, parfois exotiques (BCPL, E), mais jamais avec la passion de l'assembleur et du C. Ce sont les seules façons naturelles de programmer pour moi. Avec le typage, un ramasse-miettes, sans pointeurs et son arithmétique fabuleuse, je suis perdu, tout me semble compliqué.

J'ai débuté avec le langage machine (pas l'assembleur), j'ai ensuite été contrait de faire du Basic sur beaucoup de machines entre le début et le milieu des années 80, mais c'est l'assembleur que j'ai le plus longtemps pratiqué (Z80, 68k puis x86), puis ensuite le C. Lorsque j'ai découvert le PC, c'était un cauchemar avec son modèle mémoire segmenté par rapport au modèle FLAT du 68k. Par contre lorsque j'ai dû programmer le firmware d'un petit appareil avec une puce ARM il y a 4 ans (à titre de hobby, en open source), j'ai mis très peu de temps à me familiariser avec le jeu d'instructions que je ne connaissais pas du tout.

Je ne comprends pas grand chose à des langages comme les C# ou le Java (et je n'ai pas envie de faire d'effort pour ça). Il faut potasser des encyclopédies ennuyeuses de fonctions, comme lorsque j'avais dû apprendre l'intégralité des ROM Kernel de l'Amiga, des API Win32 et du framework WDM. C'est pas drôle. Sur l'Amiga c'était facile, on prenait le contrôle total du hardware au boot et on faisait ce qu'on voulait sans se soucier de la ROM (en gros équivalente au BIOS). Piloter le matériel était possible en partant de rien et sans aucune librairie. J'avais par exemple, pour une démo, fait jouer de la musique au lecteur de disquette en pilotant le moteur pas à pas. Cela avait eu son effet :) C'est pas la même aujourd'hui, on démarre sur un OS et lui nous dit : "ah non, t'as pas le droit d'accéder directement à ce périphérique pour allumer sa led mon coco, je supervise tout, va falloir te farcir les modèles WDM et KMDF.". C'est pas rigolo.

Même si je ne travaille plus du tout dans ce domaine depuis longtemps, la programmation m'a passionnément dévoré depuis jeune, il y a 40 ans, et je continue de temps à autre à programmer. Cela a du sens dans mon parcours plus artistique que technique. Faire des films, concevoir ou programmer une machine et composer de la musique, c'est pour moi la même chose : on crée quelque chose à partir de rien, on concrétise une idée. L'aspect créatif des programmeurs n'est pas assez mis en avant il me semble. C'est magique de partir d'une feuille blanche puis de faire naitre peu à peu un programme, un jeu, quelque chose avec lequel d'autres vont pouvoir interagir, travailler, s'amuser et même éprouver des émotions.

Je développe mes sites web, et ça, ça m'ennuie prodigieusement, ça ne n'amuse pas du tout. Je trouve ça plus compliqué, moins drôle et moins gratifiant que de développer un firmware en assembleur ou C. Ce n'est qu'un site web parmi tant d'autres interprété dans le navigateur d'un OS, alors qu'un firmware, c'est ce programme entièrement autonome qui donne "vie" à l'appareil et permet de l'utiliser. :) Mais heureusement que tout le monde ne pense pas comme moi :D
Pour moi l'assembleur et les limitations mémoire, c'est quand j'ai commencé dans l'industrie et qu'on programmait des 68000 pour le pilotage hard de machines (automates, machines outils...)

Ce qui m'a marqué c'est la programmation... avec une machine à ruban perforé pour les tours et autres CNC.
 

Nicolas3366

Grand Maître
#35
Moi je fais des petits programmes sympathiques sur ma calculette casio graph 25. Franchement ca a beau avoir que 20 Ko de mémoire mais ca suffit large lol la plupart de mes programmes font quelques dizaines d'octets. Le seul problème c'est que je galère car programmer une calculette c'est long et j'ai casiment jamais fait de la programmation ne serait ce sur ordinateur :)
 

magellan

Modérâleur
Staff
#36
Moi je fais des petits programmes sympathiques sur ma calculette casio graph 25. Franchement ca a beau avoir que 20 Ko de mémoire mais ca suffit large lol la plupart de mes programmes font quelques dizaines d'octets. Le seul problème c'est que je galère car programmer une calculette c'est long et j'ai casiment jamais fait de la programmation ne serait ce sur ordinateur :)
tout s'apprend j'"en suis la preuve.
 

Patakesse

Grand Maître
#37
7 lignes de code qui font quoi ?
Pas grand chose, j'ai pris ça au hasard, c'est le tout début (l'initialisation) d'une routine du pilote assurant la gestion du codage MFM des disques du Kickstart d'AmigaOS (une sorte de BIOS). :)
Tu donnes des cours ? ...Non t'es un peu loin ..MDR...
Je l'ai fait à une époque ! On me l'avait demandé parce qu'on aimait mon approche plus artistique que technique. Je passais pour un déluré avec mes longs cheveux rouges et mon tempérament passionné :D
Clair que tous les jeux du commodore 64 étaient surement développé en assembleur
Beaucoup étaient développés en C. Mais à cette époque, on pouvait parfaitement développer un jeu seul 100% en assembleur (et donc adieu la portabilité). Ce n'est pas le cas aujourd'hui, bien qu'une petite bande de malades développe depuis des années un OS 100% en assembleur (MenuetOS). Je trouve ça fascinant de voir leur avancée.
Si j'ai bien compris tu pourrais entrer dans le code source qui est Open source, de StockFish ..
D'une c'est du C++, de deux je ne connais pas assez les échecs pour me plonger dans ce genre de code et de trois des gens bien plus qualifiés que moi (en C++ et en échecs) doivent pulluler y compris sur ce forum :)
Moi je fais des petits programmes sympathiques sur ma calculette casio graph 25.
C'est génial pour apprendre et pour s'amuser ! Pas besoin d'une machine de malade avec 1To de RAM. :)
Pour moi l'assembleur et les limitations mémoire, c'est quand j'ai commencé dans l'industrie et qu'on programmait des 68000 pour le pilotage hard de machines (automates, machines outils...)
Putain qu'est-ce que j'ai aimé cette architecture... Elle avait ses défauts mais tellement de qualités face aux x86 puants de l'époque.
 

andre.gerald

Grand VidéaVizir
#39
Moi je fais des petits programmes sympathiques sur ma calculette casio graph 25. Franchement ca a beau avoir que 20 Ko de mémoire mais ca suffit large lol la plupart de mes programmes font quelques dizaines d'octets
J'ai commencé la logique de programmation et celle du calcul avec itération avec la Texas instrument TI 57 :lol:
Il fallait bien 24h pour qu'elle calcule PI avec 7 décimale (peut être moins je me souviens plus) :D
Puis quand tu avais programmé un truc avec une fois éteinte ..Bin il resté que dalle fallait tout recommencer
7 mémoires si je me souviens et le nombre de pas de programme était assez limité aussi.
C'était en 82 je crois !!! TI la ventait comme un objet de sience fiction à l'époque. Puis sont sortis en masse les Oric Commodore TO7 ..Etc...Et puis les ATARI avec leur 6800 Motorola 8 Mhz et 32 bits en interne (y)
Et le lecteur de disquette du commodore 64 qui valait l'équivalent à l'aise de 500 600€ de maintenant ..80 KO si j'ai bon souvenir par disquette :D
Et si on le boostait pas chargé 30 KO mettait presque 5 mn :D (au moins 2 mmn en tout cas)
Mais c'est un temps que les moins de .... ne peuvent pas connaître ...MDR...:lol:

Avant d'avoir un PC Je m'étais fait acheter par le collége un boitier qui transformait L'Atari en PC 8086 ..
Personne n'a connu ça ici ? il avait son processeur un Nec V30 (meilleur que le 8086 de Intel) ..comment je branchais ça sur l'Atari je me souviens plus :confused:
 

magellan

Modérâleur
Staff
#40
J'ai commencé la logique de programmation et celle du calcul avec itération avec la Texas instrument TI 57 :lol:
Il fallait bien 24h pour qu'elle calcule PI avec 7 décimale (peut être moins je me souviens plus) :D
Puis quand tu avais programmé un truc avec une fois éteinte ..Bin il resté que dalle fallait tout recommencer
7 mémoires si je me souviens et le nombre de pas de programme était assez limité aussi.
C'était en 82 je crois !!! TI la ventait comme un objet de sience fiction à l'époque. Puis sont sortis en masse les Oric Commodore TO7 ..Etc...Et puis les ATARI avec leur 6800 Motorola 8 Mhz et 32 bits en interne (y)
Et le lecteur de disquette du commodore 64 qui valait l'équivalent à l'aise de 500 600€ de maintenant ..80 KO si j'ai bon souvenir par disquette :D
Et si on le boostait pas chargé 30 KO mettait presque 5 mn :D (au moins 2 mmn en tout cas)
Mais c'est un temps que les moins de .... ne peuvent pas connaître ...MDR...:lol:

Avant d'avoir un PC Je m'étais fait acheter par le collége un boitier qui transformait L'Atari en PC 8086 ..
Personne n'a connu ça ici ? il avait son processeur un Nec V30 (meilleur que le 8086 de Intel) ..comment je branchais ça sur l'Atari je me souviens plus :confused:
Si si je me souviens très bien. J'ai eu un Atari ST, et il y avait un port dédié cartouche. Je n'avais pas les moyens de m'offrir ce machin, mais ST Mag en parlait régulièrement. Il y a eu au aussi la cartouche pour faire tourner une "émulation" (le terme n'est pas vraiment le bon mais c'est le seul qui colle un peu) pour faire de son Atari un Mac!
 
Vous devez vous inscrire ou vous connecter pour répondre ici.
Staff en ligne
  • AccroPC2
    Fou du PC
  • magellan
    Modérâleur
Membres en ligne
  • AccroPC2
  • magellan
  • Roro020
Derniers messages publiés
Statistiques globales
Discussions
838 201
Messages
7 494 457
Membres
1 583 360
Dernier membre
Mathys_lr
Partager cette page
Haut