Quelques précisions : ▶ Sur les premiers PC, on pouvait choisir entre une carte CGA 4 couleurs, ou une carte MDA en mode texte haute résolution. ▶ En fait, à l'époque des cartes CGA, il y avait suffisamment de place dans l'espace d'adressage pour 736 Ko de mémoire conventionnelle. C'est avec l'arrivée des cartes EGA puis VGA que la limite à 640 Ko s'est vraiment imposée. ▶ Avec MS-DOS 5.0, le driver EMM386.EXE permet, entre autres, de simuler de la mémoire EMS avec la mémoire étendue du 80386. ▶ Le Motorola 68020 avait effectivement un bus d'adresses sur 32 bits, mais aussi un bus de données sur 32 bits. ▶ Sur l'Atari TT, le 68030 n'est pas le seul à pouvoir accéder à la TT-RAM. Les puces DMAC (SCSI et port série SCC) peuvent aussi y accéder.
Salut Vincent, excellent ta petite vidéo sur le sujet. Tu comprendras aisément que j'y ai particulièrement apprécié le ton que tu as employé sur le coté 'obsolète dès sa naissance' des processeurs 8086. Et bien évidemment, que j'adhère totalement à ta conclusion. J'avis oublié de m'abonner, c'est fait ;-) Eric
Ah ça y est je comprends enfin ces histoires de mémoire conventionnelle/EMS/XMS (soucis dont heureusement mes Atari m'ont préservé!). Très intéressant et très agréable à regarder, merci Vincent!
excellente vidéo, j'ai essayer pendant des années de faire mon propre petit OS sur PC et j'ai tellement galérer a comprendre ces histoires de segments et de mode protégé, c'est vraiment la misère absolue a gérer ! Pareil avec les segments de 8k sur le 6502 amélioré de la PC Engine (21bits adressable), mais quel enfer pour gérer des tableaux de niveaux souvent volumineux et dépassant les segments ! (sans parler des registres 8bits ou les calculs 16bits deviennent assez rapidement une grosse prise de tête) C'est pour ça que je suis toujours revenu vers mon bon vieux 68000 a adressage linéaire et ces registres 32bits tellement plus confortable !
Je me souviens avoir galéré pour apprendre à coder en assembleur sur mon PC à l'époque. Quelle galère, c'était l'enfer avec ces segments à la noix. Et si je laissais le truc de côté pendant 2 semaines, je n'y comprenais plus rien. Ensuite j'ai appris l'assembleur 68000 sur mon vieux ST et je crois que je sais toujours en faire !
Une très bonne vidéo qui fait vraiment le tour de la question. J'ai commencé à programmer en BASIC sur Atari 800XL puis sur 520STf avec le très bon GFA BASIC 3.0 compilable, mais aussi en assembleur 68000. Sur 520STf j'avais programmé un jeu en 3D semblable au Star Wars des salles d'arcade (de 1983). Mais sur mon premier PC 486sx avec Turbo Pascal, j'ai été complètement déstabilisé par la gestion mémoire des segments limités a 64kio et l'offset. Impossible de réécrire mes anciens programme avec ce type de gestion mémoire. J'ai dû tout reprendre en plaçant mes données dans le TAS sous la forme d'une chaîne doublement liée car mes tableaux des programmes sur ST ne rentraient pas en mémoire avec ces segments limités à 64 Kio. Le seul avantage du 486sx sur le ST était sa vitesse de calcul.
@@Vretrocomputing J'en avais un peu entendu parlé mais avec mon vieux Turbo Pascal je suis toujours resté en mode compatible 8086, le fameux mode réel 16 bit mais qui s'apparente plus à du super 8 bit. En faite j'ai passé mon temps à apprendre puis à oublier puis à réapprendre la programmation dans des environnements différents. Maintenant je suis sur GNU Linux et G++ en C avec Allegro 5 pour le multimédia. J'aime pas le python.
De mémoire, le 80286, qui démarrait bien sûr en mode réel et devait donc être basculé en mode protégé, ne permettait pas de revenir ensuite au mode réel, ce qui rendait son usage problématique. Le problème a été corrigé sur le 80386.
J'aurais dit qu'a partir de NT 4.0 et son noyau specifique, ben la limite de 640ko... elle n'existait que pour les softs sous MSDOS, dans windows ca allait, on s'en fichait un peu :) Super video comme toujours :p merci
Super intéressant, merci pour cette vidéo qui rappelle plein de souvenirs ! Par contre, petite question : as tu pensé à mettre en fond une petite musique en sourdine ? Ca manque un petit peu de ponctuation musicale je trouve. Quoi qu'il en soit, abonné, pouce bleu déposé et vidéo partagée sur mes réseaux !
Merci pour ce retour chaleureux 🙂 Pour la musique de fond, en effet, j'y ai pensé, car je suis d'accord, ça fait un peu vide. J'évite volontairement de mettre une musique de fond dans les vidéos tutos, pour une attention maximale. Pour les vidéos plus légères, ou a titre informatif, ça m'est arrivé d'en mettre. Et pour celle-ci, je me suis posé la question.
@@Vretrocomputing , mais c'est bien naturel :) je te suggère de regarder comment LGR fait, je pense que c'est le style et la manière de faire qui correspondrait le mieux à ton format.
Once again a really good video! I have to admit that I was a bit sceptic at first and afraid it would contain no Atari content, but in the end I was quite pleased. I don't know if you take requests, but would it be at all possible for you to do a video on GEM programming? I have tried to get up and running using modern tools, but failed... A good tutorial to get us all started could possibly breathe new life to our beloved platform!
Une autre raison de la non utilisation du mode protégé du 286 est le fait qu'on ne pouvait pas sortir de ce mode sans redémarrer la machine. IBM avait néanmoins créé un moyen d'y parvenir sans redémarrer, mais c'était lent, pas terrible si on veut faire un OS rétrocompatible qui saute entre mode réel et mode protégé ^^
En effet ! Et justement, à ce propos, il y a une question à laquelle je n'ai pas trouvé de réponse. Est-ce que Windows en mode "Standard" sur 286 permettait de lancer des programmes DOS ? En utilisant l'astuce d'IBM ?
Dommage tu n'as pas parlé de dos/4gw ou d'autres gestionnaires pour le mode 'flat'. Ça consistait à passer en mode protégé redéfinir la taille des registres de segment a 32 bits puis repasser en mode réel. grâce à ce truc , on pouvait simplement adresser 32 bits en mode réel.
Oui, c'est tout ce qui est devenu possible à partir du 386. Mais dans cette vidéo j'ai souhaité me focaliser sur ce qui existait avant. Heureusement, grâce au mode flat, le PC est devenu une très bonne machine.
Hop Hop , rectificatif , la combinaison de 2 registres 8 bits pour former un registre 16 bits est TRES COURANT , ces fameux registres 16 bits servent à l'adressage indexé de la totalité de mémoire adressable , sans ces registres 16 bits pour travailler en indexage sur la mémoire totale , il ne pourrait pas y avoir par exemple ......... le travail sur la mémoire vidéo et les sprites , soit transférer les octets d'un sprite à son emplacement mémoire vers la mémoire vidéo , si si , les registres 16 bits combinés sont obligatoirement très obligatoire , sinon on ne pourrait rien en faire de ces microprocesseurs inutiles CQFD , d'ailleurs vous faites du blit software d'image sur Atari ST en assembleur , donc j'en déduis que vous n'avez jamais écrit de programme en assembleur sur processeur 8bits qui équipent nos légendaires machines 8 bits , Thomson , etc , et même sans jamais avoir programmé en assembleur 8bits , il est facile de concevoir que sans registres d'adressage indexé de la mémoire totale physique , on ne peut rien faire merci
En fait, seule la zone entre 0 et 640 Ko contient de la RAM. Entre 640 Ko et 1 Mo, la Upper Memory Area (étrangement traduite par "mémoire supérieure" en français) est une zone de l'espace d'adressage qui contient autre chose que de la RAM... notamment la ROM du BIOS.
Quelques précisions :
▶ Sur les premiers PC, on pouvait choisir entre une carte CGA 4 couleurs, ou une carte MDA en mode texte haute résolution.
▶ En fait, à l'époque des cartes CGA, il y avait suffisamment de place dans l'espace d'adressage pour 736 Ko de mémoire conventionnelle. C'est avec l'arrivée des cartes EGA puis VGA que la limite à 640 Ko s'est vraiment imposée.
▶ Avec MS-DOS 5.0, le driver EMM386.EXE permet, entre autres, de simuler de la mémoire EMS avec la mémoire étendue du 80386.
▶ Le Motorola 68020 avait effectivement un bus d'adresses sur 32 bits, mais aussi un bus de données sur 32 bits.
▶ Sur l'Atari TT, le 68030 n'est pas le seul à pouvoir accéder à la TT-RAM. Les puces DMAC (SCSI et port série SCC) peuvent aussi y accéder.
Salut Vincent, excellent ta petite vidéo sur le sujet. Tu comprendras aisément que j'y ai particulièrement apprécié le ton que tu as employé sur le coté 'obsolète dès sa naissance' des processeurs 8086. Et bien évidemment, que j'adhère totalement à ta conclusion. J'avis oublié de m'abonner, c'est fait ;-) Eric
Ah ça y est je comprends enfin ces histoires de mémoire conventionnelle/EMS/XMS (soucis dont heureusement mes Atari m'ont préservé!). Très intéressant et très agréable à regarder, merci Vincent!
Merci pour ce retour chaleureux 😊
excellente vidéo, j'ai essayer pendant des années de faire mon propre petit OS sur PC et j'ai tellement galérer a comprendre ces histoires de segments et de mode protégé, c'est vraiment la misère absolue a gérer ! Pareil avec les segments de 8k sur le 6502 amélioré de la PC Engine (21bits adressable), mais quel enfer pour gérer des tableaux de niveaux souvent volumineux et dépassant les segments ! (sans parler des registres 8bits ou les calculs 16bits deviennent assez rapidement une grosse prise de tête) C'est pour ça que je suis toujours revenu vers mon bon vieux 68000 a adressage linéaire et ces registres 32bits tellement plus confortable !
Merci pour ce retour d'expérience du terrain ! 68000 rulez.
Je me souviens avoir galéré pour apprendre à coder en assembleur sur mon PC à l'époque. Quelle galère, c'était l'enfer avec ces segments à la noix. Et si je laissais le truc de côté pendant 2 semaines, je n'y comprenais plus rien. Ensuite j'ai appris l'assembleur 68000 sur mon vieux ST et je crois que je sais toujours en faire !
@@frostsct1 Tu traines ici ? (GT aussi la)
Encore une superbe vidéo, j’attendais une vidéo sur ce sujet depuis longtemps, merci!
très bonne vidéo vivement la suite
Une très bonne vidéo qui fait vraiment le tour de la question. J'ai commencé à programmer en BASIC sur Atari 800XL puis sur 520STf avec le très bon GFA BASIC 3.0 compilable, mais aussi en assembleur 68000. Sur 520STf j'avais programmé un jeu en 3D semblable au Star Wars des salles d'arcade (de 1983). Mais sur mon premier PC 486sx avec Turbo Pascal, j'ai été complètement déstabilisé par la gestion mémoire des segments limités a 64kio et l'offset. Impossible de réécrire mes anciens programme avec ce type de gestion mémoire. J'ai dû tout reprendre en plaçant mes données dans le TAS sous la forme d'une chaîne doublement liée car mes tableaux des programmes sur ST ne rentraient pas en mémoire avec ces segments limités à 64 Kio. Le seul avantage du 486sx sur le ST était sa vitesse de calcul.
Heureusement qu'ensuite il y a eu les DOS extenders 😄
@@Vretrocomputing J'en avais un peu entendu parlé mais avec mon vieux Turbo Pascal je suis toujours resté en mode compatible 8086, le fameux mode réel 16 bit mais qui s'apparente plus à du super 8 bit. En faite j'ai passé mon temps à apprendre puis à oublier puis à réapprendre la programmation dans des environnements différents. Maintenant je suis sur GNU Linux et G++ en C avec Allegro 5 pour le multimédia. J'aime pas le python.
De mémoire, le 80286, qui démarrait bien sûr en mode réel et devait donc être basculé en mode protégé, ne permettait pas de revenir ensuite au mode réel, ce qui rendait son usage problématique. Le problème a été corrigé sur le 80386.
J'aurais dit qu'a partir de NT 4.0 et son noyau specifique, ben la limite de 640ko... elle n'existait que pour les softs sous MSDOS, dans windows ca allait, on s'en fichait un peu :)
Super video comme toujours :p merci
Merci 🙂 Eh oui, Windows NT a fait sauter plein de limitations. Et cette architecture moderne s'est démocratisée pour le grand public avec Windows XP.
Super intéressant, merci pour cette vidéo qui rappelle plein de souvenirs ! Par contre, petite question : as tu pensé à mettre en fond une petite musique en sourdine ? Ca manque un petit peu de ponctuation musicale je trouve. Quoi qu'il en soit, abonné, pouce bleu déposé et vidéo partagée sur mes réseaux !
Merci pour ce retour chaleureux 🙂 Pour la musique de fond, en effet, j'y ai pensé, car je suis d'accord, ça fait un peu vide. J'évite volontairement de mettre une musique de fond dans les vidéos tutos, pour une attention maximale. Pour les vidéos plus légères, ou a titre informatif, ça m'est arrivé d'en mettre. Et pour celle-ci, je me suis posé la question.
@@Vretrocomputing , mais c'est bien naturel :) je te suggère de regarder comment LGR fait, je pense que c'est le style et la manière de faire qui correspondrait le mieux à ton format.
Excellente vidéo :)
Merci ☺️
Once again a really good video! I have to admit that I was a bit sceptic at first and afraid it would contain no Atari content, but in the end I was quite pleased. I don't know if you take requests, but would it be at all possible for you to do a video on GEM programming? I have tried to get up and running using modern tools, but failed... A good tutorial to get us all started could possibly breathe new life to our beloved platform!
This video is actually a troyan horse to bring Atari and Motorola stuff to PC people 😁
@@Vretrocomputing Good one!
Unfortunately, I don't know much about GEM, except basic stuff. So don't expect anything great from me in that area.
@@Vretrocomputing understandable. Though just getting up and running would be fine for me... But, anyway I will be looking forward to the next video!
Une autre raison de la non utilisation du mode protégé du 286 est le fait qu'on ne pouvait pas sortir de ce mode sans redémarrer la machine.
IBM avait néanmoins créé un moyen d'y parvenir sans redémarrer, mais c'était lent, pas terrible si on veut faire un OS rétrocompatible qui saute entre mode réel et mode protégé ^^
En effet ! Et justement, à ce propos, il y a une question à laquelle je n'ai pas trouvé de réponse. Est-ce que Windows en mode "Standard" sur 286 permettait de lancer des programmes DOS ? En utilisant l'astuce d'IBM ?
@@Vretrocomputing je ne sais pas, faudrait que j'essaie ^^
Dommage tu n'as pas parlé de dos/4gw ou d'autres gestionnaires pour le mode 'flat'. Ça consistait à passer en mode protégé redéfinir la taille des registres de segment a 32 bits puis repasser en mode réel. grâce à ce truc , on pouvait simplement adresser 32 bits en mode réel.
Oui, c'est tout ce qui est devenu possible à partir du 386. Mais dans cette vidéo j'ai souhaité me focaliser sur ce qui existait avant. Heureusement, grâce au mode flat, le PC est devenu une très bonne machine.
Pourquoi ne pas parler du 80186 ? ;)
Je ne me souviens pas avoir rencontré de PC à base de 80186 😉 Mais c'est vrai que j'aurais pu au moins le citer.
Hop Hop , rectificatif , la combinaison de 2 registres 8 bits pour former un registre 16 bits est TRES COURANT , ces fameux registres 16 bits servent à l'adressage indexé de la totalité de mémoire adressable , sans ces registres 16 bits pour travailler en indexage sur la mémoire totale , il ne pourrait pas y avoir par exemple ......... le travail sur la mémoire vidéo et les sprites , soit transférer les octets d'un sprite à son emplacement mémoire vers la mémoire vidéo , si si , les registres 16 bits combinés sont obligatoirement très obligatoire , sinon on ne pourrait rien en faire de ces microprocesseurs inutiles CQFD , d'ailleurs vous faites du blit software d'image sur Atari ST en assembleur , donc j'en déduis que vous n'avez jamais écrit de programme en assembleur sur processeur 8bits qui équipent nos légendaires machines 8 bits , Thomson , etc , et même sans jamais avoir programmé en assembleur 8bits , il est facile de concevoir que sans registres d'adressage indexé de la mémoire totale physique , on ne peut rien faire merci
Bonjour, effectivement j'ai peu programmé en assembleur 8 bits. Merci pour ces précisions.
"c'est là qu'on trouve le BIOS", dans la mémoire RAM.. heu, plutot une copie du BIOS non ?
En fait, seule la zone entre 0 et 640 Ko contient de la RAM. Entre 640 Ko et 1 Mo, la Upper Memory Area (étrangement traduite par "mémoire supérieure" en français) est une zone de l'espace d'adressage qui contient autre chose que de la RAM... notamment la ROM du BIOS.