Re: Le vrai successeur des ST et AMIGA : L'ARCHIMEDES

[chiss]

L'archimede fait  cela   ?????



ou cela  ????




Donc la réponse est : NON !!! L'Archimede n'est pas le Digne successeur de l'Atari ST ou de l'Amiga ......cqfd !!!!

[Invité]

[ArchieForEver]

L'archimede fait  cela   ?????



ou cela  ????




Donc la réponse est  : NON  !!!  L'Archimede n'est pas le Digne successeur de l'Atari ST ou de l'Amiga  ......cqfd  !!!!

Chuuuut malheureux !
Ca va devenir un topic de fight sinon 
Faut pas leur dire que même s'il n'était que coopératif, RISC OS n'a pas été programmé par CroSoft, mais par Acorn, du coup il était stable et rapide, et via le contrôleur mémoire MEMC, il y a même un embryon de système de protection mémoire ...
Bien sympa par exemple d'avoir un RAMDISK protégé.
Quand je codais, j'étais bien content de toujours tout retrouver dans le RAMDISK quand j'avais méchamment planté la machine et que je faisais un hard reset.

[TotOOntHeMooN]

En même temps, si ça ne plantait pas ! 

[ArchieForEver]

En même temps, si ça ne plantait pas ! 

Ca plantait sur RISC OS si les applis étaient vraiment mal programmées, ou bien si tu commençais, en temps que codeur, à faire joujou avec les interruptions, les timers, l'envoi direct de données mal formatées au contrôleur mémoire par exemple, sans passer par les routines système.
En gros ça pouvait fort planter quand tu voulais coder (bien) des démos ou des jeux pour que ça aille vite.

Je suis étonné qu'après 5 minutes on n'ait pas vu Babsimov rappliquer pour nous expliquer que JAMAIS il n'a eu de Gurus sur son Amiga.
Ca ne saurait tarder, sur 3 pages, 7 paragraphes, 34 sous sections et 18913 caractères 

[Invité]

En même temps, un ordi ne plante pas tout seul hein, c'est bien qu'un prog, et donc un codeur,a fait quelque chose de mauvais avec le hardware  .

[ArchieForEver]

En même temps, un ordi ne plante pas tout seul hein, c'est bien qu'un prog, et donc un codeur,a fait quelque chose de mauvais avec le hardware  .

On peut t'aider ou non à faire des bêtises.
Une appli bien codée n'a aucune raison d'aller taper directement dans le hardware : elle se doit d'utiliser uniquement les routines système, qui elles ont été bien codées, par le fournisseur de l'OS, pour tourner vite et bien dans l'environnement de l'OS ( et aussi pour ne pas planter le système en cas d'erreur, mais la traiter ).
Je ne partirai pas dans un comparatif entre les OS des 3 machines ST Amiga Archimedes mais le système de l'Archie avec quelques applis de base ( RISC OS ) tient dans 2 Mo ... ça veut dire qu'il y a un sacré paquet de routines système bien codées fournies par Acorn, le programmeur n'a pas à ré inventer la roue par lui-même, avec le risque de bug lié.
Les 5 ou 6 tomes détaillant les fonctions système de RISC OS font de mémoire environs 3000 pages.
Pas un mot sur la programmation direct du hardware, si vous voulez taper directement par exemple dans les registres du contrôleur graphique et son, ou du contrôleur mémoire, allez vous faire cuire un oeuf ! Merci Acorn. Il aura fallu se procurer la doc des chips ARM auprès du fondeur VLSI pour pouvoir enfin savoir comment taper direct dans le hardware. ( ok certains savaient déjà un peu en ayant désassemblé RISC OS )

[babsimov]

L'archimede fait  cela   ?????



ou cela  ????




Donc la réponse est  : NON  !!!  L'Archimede n'est pas le Digne successeur de l'Atari ST ou de l'Amiga  ......cqfd  !!!!

Chuuuut malheureux !
Ca va devenir un topic de fight sinon 

Je pense que c'était du second degré au départ. Un Archimedes doit planter comme toute plateforme, de temps à autre.

Faut pas leur dire que même s'il n'était que coopératif, RISC OS n'a pas été programmé par CroSoft, mais par Acorn, du coup il était stable et rapide, et via le contrôleur mémoire MEMC, il y a même un embryon de système de protection mémoire ...

Ben justement ce serait bien de donner un peu d'explication sur ce point. Quelque chose de simple pour un simple utilisateur comme moi. Un embryon de protection mémoire sans MMU, comment ils ont fait ?

Bien sympa par exemple d'avoir un RAMDISK protégé.
Quand je codais, j'étais bien content de toujours tout retrouver dans le RAMDISK quand j'avais méchamment planté la machine et que je faisais un hard reset.

Ben l'Amiga il avait ça, ça s'appelait le RAD: et c'était dès l'AmigaOS 1.3 :
http://obligement.free.fr/articles/amigaos_raddisk.php

A l'époque je me suis un peu servis pour tester, mais c'est surtout sur le 1200 avec plus de mémoire que je l'ais utilisé couramment comme tous les Amigaïstes autour de moi. 

Mais, ça pour moi, c'est pas de la protection mémoire.

En même temps, un ordi ne plante pas tout seul hein, c'est bien qu'un prog, et donc un codeur,a fait quelque chose de mauvais avec le hardware  .

Pas si vrai que ça : une appli bien codée n'a aucune raison d'aller taper directement dans le hardware : elle se doit d'utiliser uniquement les routines système, qui elles ont été bien codées, par le fournisseur de l'OS, pour tourner vite et bien dans l'environnement de l'OS ( et aussi pour ne pas planter le système en cas d'erreur, mais la traiter ).
Je ne partirai pas dans un comparatif entre les OS des 3 machines ST Amiga Archimedes mais le système de l'Archie avec quelques applis de base ( RISC OS ) tient dans 2 Mo ... ça veut dire qu'il y a un sacré paquet de routines système bien codées fournies par Acorn, le programmeur n'a pas à ré inventer la roue par lui-même, avec le risque de bug lié.

C'était en général les logiciels du domaine public qui provoquaient les plantages, surtout quand on en utilisait plusieurs ensemble. Mais les utilisateurs avaient vite fait de faire le tri de ceux qui n'étaient pas fiable et avec les collections DP qui existaient à l'époque les créateurs de ces collections faisaient en partie cette sélection, mais ils pouvaient en laisser passer malgré tout.
Les logiciels commerciaux avaient eux passé une phase de test et respecté les consignes de programmation de Commodore. Car, évidemment que l'AmigaOS (donc le kickstart) contient les routines qu'il faut pour que le programmeur n'ait pas à tout réécrire de zéro à chaque fois. C'était pas l'apanage d'Acorn ce genre de choses à mon avis.

Le guru méditation sur Amiga c'est surtout un mode débug plus qu'un plantage. J'avais lu qu'avec un terminal connecté sur la prise série de l'Amiga, un programmeur avait alors accès à un débugueur pour corrigé la source du plantage.

Je suis étonné qu'après 5 minutes on n'ait pas vu Babsimov rappliquer pour nous expliquer que JAMAIS il n'a eu de Gurus sur son Amiga.
Ca ne saurait tarder, sur 3 pages, 7 paragraphes, 34 sous sections et 18913 caractères 

Je n'ai pas prétendu que l'Amiga ne plantait pas, j'ai juste dit que contrairement à ce qu'un AtariSTe roi de la mauvaise foi prétendait, ce n'était pas guru à gogo, voir même rien qu'en allumant.
Bien entendu que j'ai eu des guru et que j'ai pesté parfois en les ayant. De là à dire que l'Archimedes ne plantait jamais... tu le laisse entendre. Le maintiens tu ?

Excuse moi de répondre souvent un peu longuement, mais en général je réponds sur plusieurs points, d'ou les paragraphes différents. Je l'ai d'ailleurs fait au départ sur demande d'un modérateur ici pour justement ne pas avoir plein de réponses les unes après les autres.

[ArchieForEver]

Je ne suis malheureusement pas assez calé concernant le hardware pur et dur du MEMC avec ses tables de translation mémoire logique / mémoire physique, mais de ce que j'ai compris, par tranche d'un certain nombre de kilo octets (4 ko je crois) la mémoire est vérouillable en lecture seule ... Je pense que c'est comme ça que mon RAM Disk était protégé.
J'imagine qu'à chaque fois que j'écrivais dans le RAM Disk ( forcément via les fonctions de l'OS dont les applis comme mon éditeur de texte par exemple se servaient ) et bien l'OS déprotégeait la fonction d'écriture et reprotégeait en fin de sauvegarde.
Quand moi je lançais mon prog et crashait tout et bien comme le RAM Disk était verrouillé je ne risquais pas d'écrire sur mon source, mes graphs, etc ...
Suis vraiment pas très connaisseur du MEMC, en dehors de ce qui sert pour un jeu ou une démo : la programmation des adresses des différents DMA.


Le guru pas un plantage seulement si tu peux récupérer et poursuivre ton travail : ok.
Crasher en mode debug, ça reste toujours crasher.

Pour les plantages de l'Archie, on a eu des 'Filecore in use' sur Archie, car les programmeurs n'avaient pas bien pigé certains trucs, mais sinon, je confirme, pour avoir aussi utilisé un Amiga, que le nombre de plantages n'avait juste rien à voir.
Par exemple sur Amiga je me souviens que souvent quand tu chargeais des disquettes tu avais des Gurus et l'Amiga était planté.
Ben sur Archie tu auras 'Disk error at ... numéro de piste' et voilà c'est tout, tu cliques 'OK' et le système a toujours la main.


Pour AmigaOS qui avait aussi des routines, oui, je n'en doute pas ; mais bon il doit bien y avoir 'un p'tit qqchose en plus' quand sur Archie ton OS fait 2 Mo et ta doc sur toutes les fonctions système fait 3000 pages ...

[babsimov]

Je ne suis malheureusement pas assez calé concernant le hardware pur et dur du MEMC avec ses tables de translation mémoire logique / mémoire physique, mais de ce que j'ai compris, par tranche d'un certain nombre de kilo octets (4 ko je crois) la mémoire est vérouillable en lecture seule ... Je pense que c'est comme ça que mon RAM Disk était protégé.
J'imagine qu'à chaque fois que j'écrivais dans le RAM Disk via les fonctions de l'OS et bien l'OS déprotégeait la fonction d'écriture et reprotégeait en fin de sauvegarde.
Quand moi je lançais mon prog et crachait tout et bien comme le RAM Disk était verrouillé je ne risquais pas d'écrire sur mon source, mes graphs, etc ...

Je suis pas certain qu'on puisse dire qu'un RAM disk résistant au reset soit une protection mémoire au sens classique du genre pour un OS multitâche ? Mais peut être que je me trompe.
Ce que j'ai compris, c'est que sans une MMU ce n'est pas possible d'avoir de la protection mémoire au niveau d'un OS multitâche (et des logiciels qui tournent en multitâche sous cet OS). C'est pour ça que SUN avait créé sa MMU propriétaire pour ses stations UNIX à base de 68000, parce que sinon pas d'UNIX. Plus tard Motorola sortira sa MMU. A quelle période une MMU a t elle existée pour l'ARM ? A mon avis pas au début en tout cas ?
Pour les Uchronie ici j'avais un peu creuser, à mon niveau, l'histoire des MMU et de la protection mémoire c'est pourquoi j'ai un peu le sentiment que protection mémoire égale MMU, sinon ce n'en ais pas.
L'exemple du RAD: sur AmigaOS 1.3 semble indiquer que cette fonction n'a rien à voir avec de la protection mémoire. En effet l'AmigaOS n'a jamais eu de protection mémoire et ça semble impossible à implémenter sans être totalement incompatible avec les logiciels existants. Note que Carl Sassenrath voulait de la protection mémoire et du ressource tracking pour son OS multitâche, mais comme l'OS était très en retard (longue histoire), l'AmigaOS que nous connaissons n'est pas celui prévu au départ qui se serait appelé CAOS (Commodore Amiga OS). Mais la protection mémoire avait de toute façon été abandonné (pas le ressource tracking), parce qu'il aurait fallu ajouter une MMU à l'Amiga pour celà (façon SUN). 
Désolé, j'ai fait encore long.

Le guru pas un plantage seulement si tu peux récupérer et poursuivre ton travail : ok.

Mais pour l'utilisateur de base, c'était bel et bien un plantage, je te rassure. J'ai fait plus court 

[ArchieForEver]

Je ne suis malheureusement pas assez calé concernant le hardware pur et dur du MEMC avec ses tables de translation mémoire logique / mémoire physique, mais de ce que j'ai compris, par tranche d'un certain nombre de kilo octets (4 ko je crois) la mémoire est vérouillable en lecture seule ... Je pense que c'est comme ça que mon RAM Disk était protégé.
J'imagine qu'à chaque fois que j'écrivais dans le RAM Disk via les fonctions de l'OS et bien l'OS déprotégeait la fonction d'écriture et reprotégeait en fin de sauvegarde.
Quand moi je lançais mon prog et crachait tout et bien comme le RAM Disk était verrouillé je ne risquais pas d'écrire sur mon source, mes graphs, etc ...

Je suis pas certain qu'on puisse dire qu'un RAM disk résistant au reset soit une protection mémoire au sens classique du genre pour un OS multitâche ? Mais peut être que je me trompe.
Ce que j'ai compris, c'est que sans une MMU ce n'est pas possible d'avoir de la protection mémoire au niveau d'un OS multitâche (et des logiciels qui tournent en multitâche sous cet OS). C'est pour ça que SUN avait créé sa MMU propriétaire pour ses stations UNIX à base de 68000, parce que sinon pas d'UNIX. Plus tard Motorola sortira sa MMU. A quelle période une MMU a t elle existée pour l'ARM ? A mon avis pas au début en tout cas ?
Pour les Uchronie ici j'avais un peu creuser, à mon niveau, l'histoire des MMU et de la protection mémoire c'est pourquoi j'ai un peu le sentiment que protection mémoire égale MMU, sinon ce n'en ais pas.
L'exemple du RAD: sur AmigaOS 1.3 semble indiquer que cette fonction n'a rien à voir avec de la protection mémoire. En effet l'AmigaOS n'a jamais eu de protection mémoire et ça semble impossible à implémenter sans être totalement incompatible avec les logiciels existants. Note que Carl Sassenrath voulait de la protection mémoire et du ressource tracking pour son OS multitâche, mais comme l'OS était très en retard (longue histoire), l'AmigaOS que nous connaissons n'est pas celui prévu au départ qui se serait appelé CAOS (Commodore Amiga OS). Mais la protection mémoire avait de toute façon été abandonné (pas le ressource tracking), parce qu'il aurait fallu ajouter une MMU à l'Amiga pour celà (façon SUN). 
Désolé, j'ai fait encore long.

Le guru pas un plantage seulement si tu peux récupérer et poursuivre ton travail : ok.

Mais pour l'utilisateur de base, c'était bel et bien un plantage, je te rassure. J'ai fait plus court 

Je dirais qu'une vraie MMU complète, moderne, c'est à partir de la série ARM600, donc les RISC PC.

Mais c'est peu clair pour les 1ers ARM.
Si tu regardes ce tableau, l'ARM250 est donné comme ayant une MMU avec le MEMC1A intégré, et pas les ARM d'avant ; hors l'ARM250 c'est un tout-en-un de l'ARM2 d'avant avec les autres chips ARM ... dont ce MEMC1A (que ce tableau classe donc comme étant une MMU, du coup depuis le départ les ARMs avaient des MMUs )
https://fr.qwe.wiki/wiki/List_of_ARM_microarchitectures
A nouveau je ne suis pas spécialiste du sujet.
Je sais qu'Acorn voulait un OS multitâche pré emptif avancé, et faute de temps il n'est jamais arrivé, on a eu Arthur puis RISC OS.
On peut penser que le MEMC1A de l'Archimedes a été pensé initialement pour un OS plus ambitieux que RISC OS.

Je rappellerai quand même qu'Acorn a développé son UNIX sur Archimedes : RISC iX.
Je n'en sais malheureusement pas grand'chose, mais sur stardot ça les excite vâchement ( les machine UNIX d'Acorn, le R140, puis le R260, n'étaient pas données ).
http://www.computinghistory.org.uk/det/3639/Acorn-R140/
http://www.computinghistory.org.uk/det/4475/Acorn-R260/


Me concernant, j'étais juste toujours très heureux en tant que codeur de ne jamais perdre ce qui était dans le RAM disk, ça me suffisait bien.
La programmation système ne m'a jamais intéressé, et que l'OS soit en interne beau ou pas, je m'en foutais : j'aimais sa convivialité et sa quasi absence de plantages ( que ce soit une surcouche du MOS d'Acorn, ou bien un truc à base d'UNIX de la mort qui tue me laissait bien indifférent, je n'avais aucune envie de programmer en environnement fenêtré )

[babsimov]

Le guru pas un plantage seulement si tu peux récupérer et poursuivre ton travail : ok.
Crasher en mode debug, ça reste toujours crasher.

Oui oui, je te l'ais confirmé. Juste que c'est un mode crash plus évolué qu'ailleurs je crois.

Pour les plantages de l'Archie, on a eu des 'Filecore in use' sur Archie, car les programmeurs n'avaient pas bien pigé certains trucs, mais sinon, je confirme, pour avoir aussi utilisé un Amiga, que le nombre de plantages n'avait juste rien à voir.

Peut être. N'ayant pas utilisé d'Archimedes je ne peux pas comparer. Mais, comme dis, l'Archimedes plantait de temps à autre, comme tout ordinateur. Aucun programmeur n'écrit pas de bug à ma connaissance, personne n'est parfait.

Par exemple sur Amiga je me souviens que souvent quand tu chargeais des disquettes tu avais des Gurus et l'Amiga était planté.

Alors ça, de mémoire c'est un plantage lié en général à un logiciel bootable (souvent un jeu) écrit pour un kickstart différent de celui de ton Amiga (1.3 lancé sur 2.0 par exemple), ou écrit pour un 68000 au lieu de 680x0. Je te parlais de plantage sous AmigaOS (sous workench en sommes), pas au boot de disquette. Parce que ça j'en ai eu plein sous 1200 à l'époque, souvent corrigé par la early startup (qui permet de paramétrer le cache du 68020, le type de chipset AGA/ECS OCS).   

Ben sur Archie tu auras 'Disk error at ... numéro de piste' et voilà c'est tout, tu cliques 'OK' et le système a toujours la main.

Ca tu l'auras sous une forme différente sous Workbench avec une boite de dialogue quand ta disquette est déféctueuse et là aussi le workbench te rend la main après OK.

Pour AmigaOS qui avait aussi des routines, oui, je n'en doute pas ; mais bon il doit bien y avoir 'un p'tit qqchsoe en plus' quand sur Archie ton OS fait 2 Mo ...

Le kickstart 1.x pesait dans les 256 ko de mémoire et la disquette workench qui contenait la GUI et quelques autres choses dans les 800ko, soit environ 1 MO pour l'AmigaOS 1.x complet.

Le Kickstart 3.x pèse 512 ko et l'Amiga OS 3.0 (prévu pour disque dur) tient sur 5 disquette de 880 ko, soit un total d'environ 5 mo.

Je pense qu'on était dans une taille d'OS plus ou moins similaire. Il me semble que les logiciels écrit pour les processeurs RISC sont plus gros que ceux écrit pour du CISC ? 
Bien sur, j'ai cru comprendre que la ROM de l'Archimedes contenait des choses en plus que l'OS, ça peut aussi expliquer les 2 MO ?

[ArchieForEver]

L'ARM n'est pas un exemple de processeurs RISC 'pur et dur' du coup dire que pour 2 progs équivalents ur Archie ça prendra bcp + de place c'est très aventureux.
Un type sur eab avait ouvert une file de discussion pour vanter le côté compact du code du 68000, notamment par rapport à l'ARM, et quand sur des exemples types il s'est trouvé que sur ARM on ne prenait pas plus de 5% de mémoire supplémentaire, il a cessé d'alimenter la file de discussion.
Le code de l'ARM a de sacrées capacités à être compact avec les instructions conditionnelles, ses 3 opérandes, et les shifts.
Faudrait que je te retrouve le lien.

Dans RISC OS, tu as aussi le BASIC, un éditeur léger (!Edit) et les applis !Paint et !Draw mais on ne peut pas dire qu'elles vont être bien gourmandes, puisqu'elles utilisent les fonctions de l'OS.

Amiga OS 3.0 ce n'est pas pour les Amiga AGA ça ? Du coup forcément il faut des routines en plus pour gérer les nouveaux modes graphiques
( comme RISC OS à partir de 3.50, qui augmente encore en taille, pour les RISC PCs )

[babsimov]

Je ne suis malheureusement pas assez calé concernant le hardware pur et dur du MEMC avec ses tables de translation mémoire logique / mémoire physique, mais de ce que j'ai compris, par tranche d'un certain nombre de kilo octets (4 ko je crois) la mémoire est vérouillable en lecture seule ... Je pense que c'est comme ça que mon RAM Disk était protégé.
J'imagine qu'à chaque fois que j'écrivais dans le RAM Disk via les fonctions de l'OS et bien l'OS déprotégeait la fonction d'écriture et reprotégeait en fin de sauvegarde.
Quand moi je lançais mon prog et crachait tout et bien comme le RAM Disk était verrouillé je ne risquais pas d'écrire sur mon source, mes graphs, etc ...

Je suis pas certain qu'on puisse dire qu'un RAM disk résistant au reset soit une protection mémoire au sens classique du genre pour un OS multitâche ? Mais peut être que je me trompe.
Ce que j'ai compris, c'est que sans une MMU ce n'est pas possible d'avoir de la protection mémoire au niveau d'un OS multitâche (et des logiciels qui tournent en multitâche sous cet OS). C'est pour ça que SUN avait créé sa MMU propriétaire pour ses stations UNIX à base de 68000, parce que sinon pas d'UNIX. Plus tard Motorola sortira sa MMU. A quelle période une MMU a t elle existée pour l'ARM ? A mon avis pas au début en tout cas ?
Pour les Uchronie ici j'avais un peu creuser, à mon niveau, l'histoire des MMU et de la protection mémoire c'est pourquoi j'ai un peu le sentiment que protection mémoire égale MMU, sinon ce n'en ais pas.
L'exemple du RAD: sur AmigaOS 1.3 semble indiquer que cette fonction n'a rien à voir avec de la protection mémoire. En effet l'AmigaOS n'a jamais eu de protection mémoire et ça semble impossible à implémenter sans être totalement incompatible avec les logiciels existants. Note que Carl Sassenrath voulait de la protection mémoire et du ressource tracking pour son OS multitâche, mais comme l'OS était très en retard (longue histoire), l'AmigaOS que nous connaissons n'est pas celui prévu au départ qui se serait appelé CAOS (Commodore Amiga OS). Mais la protection mémoire avait de toute façon été abandonné (pas le ressource tracking), parce qu'il aurait fallu ajouter une MMU à l'Amiga pour celà (façon SUN). 
Désolé, j'ai fait encore long.

Le guru pas un plantage seulement si tu peux récupérer et poursuivre ton travail : ok.

Mais pour l'utilisateur de base, c'était bel et bien un plantage, je te rassure. J'ai fait plus court 

Je dirais qu'une vraie MMU complète, moderne, c'est à partir de la série ARM600, donc les RISC PC.

Mais c'est peu clair pour les 1ers ARM.
Si tu regardes ce tableau, l'ARM250 est donné comme ayant une MMU avec le MEMC1A intégré, et pas les ARM d'avant ; hors l'ARM250 c'est un tout-en-un de l'ARM2 d'avant avec les autres chips ARM ... dont ce MEMC1A (que ce tableau classe donc comme étant une MMU, du coup depuis le départ les ARMs avaient des MMUs )
https://fr.qwe.wiki/wiki/List_of_ARM_microarchitectures
A nouveau je ne suis pas spécialiste du sujet.
Je sais qu'Acorn voulait un OS multitâche pré emptif avancé, et faute de temps il n'est jamais arrivé, on a eu Arthur puis RISC OS.
On peut penser que le MEMC1A de l'Archimedes a été pensé initialement pour un OS plus ambitieux que RISC OS.

Merci pour ces infos. A l'époque tout le monde voulait un OS multitâche préemptif, mais peu l'avait en standard. On ne peut enlever ça à l'Amiga. Ca veut pas dire que RISC-OS n'avait pas plein de qualité, je suis convaincu qu'il en avait, sinon j'aurais pas été tenté d'acheter un RISC-PC plutôt qu'un PC.

Je rappellerai quand même qu'Acorn a développé son UNIX sur Archimedes : RISC iX.
Je n'en sais malheureusement pas grand'chose, mais sur stardot ça les excite vâchement ( la machine UNIX d'Acorn, le R240, n'était pas donnée ).

Dans le débat il avait été évoqué qu'il avait existé un UNIX sur Amiga 500 (donc sans MMU). Il s'appelait MINIX
http://obligement.free.fr/articles/minix15.php
En lisant l'article, il n'utilise par les MMU des cartes 68020/030 de l'époque, ce qui semble indiquer que c'est un dérivé d'UNIX mais sans la protection mémoire. D'ailleurs ils disent qu'il n'a rien à voir que l'UNIX de Commodore qui lui était un portage complet du UNIX qui était la norme de l'époque (avec protection mémoire par MMU) :
https://en.wikipedia.org/wiki/Amiga_Unix
Il est possible que le RISC iX soit un genre de dérivé d'UNIX comme MINIX, mais sans protection mémoire.

Mais, à lire le wiki de RISC iX je ne sais que penser sur ce point.
https://en.wikipedia.org/wiki/RISC_iX
En effet, ils disent qu'il gère la mémoire virtuel. Hors, dans mes lectures sur les MMU, je crois me souvenir que la gestion de la mémoire virtuelle dans un OS était une des fonctions d'une MMU (en complément de la protection mémoire). Ca tendrait à montrer qu'Acorn avait trouvé un moyen d'avoir un genre de MMU assez tôt pour l'ARM. Mais, ça dépasse mes compétences pour aller plus loin sur ce point.


EDIT : en lisant les liens que tu avais donné, il n'y pas de doute, l'ARM2v2a (ARM250) avait une MMU, donc le UNIX d'ACORN était alors complet 
https://fr.qwe.wiki/wiki/List_of_ARM_microarchitectures
Par contre je doute que RISC-OS ait eut cette fonction ajoutée à l'époque, parce qu'ajouter la protection mémoire à un OS qui ne l'avait pas dès l'origine rends les anciens logiciels incompatible et je doute qu'Acorn ait voulu prendre le risque de se priver de sa logithèque existante à l'époque pour ajouter une fonction non vitale sur un OS non préemptif il me semble. En tout cas, ça ne semble pas être une tâche facile à faire. Atari l'avait tenté avec le Multi TOS et il semble que niveau compatibilité c'était pas au top.

Me concernant, j'étais juste toujours très heureux en tant que codeur de ne jamais perdre ce qui était dans le RAM disk, ça me suffisait bien.

Je suis pas programmeur, mais le RAD: m'a servit également comme simple utilisateur. Mais probablement pas de la même façon.

La programmation système ne m'a jamais intéressé, et que l'OS soit en interne beau ou pas, je m'en foutais : j'aimais sa convivialité et sa quasi absence de plantages ( que ce soit une surcouche du MOS d'Acorn, ou bien un truc à base d'UNIX de la mort qui tue me laissait bien indifférent, je n'avais aucune envie de programmer en environnement fenêtré )

Je n'étais nullement un expert (je ne le suis toujours pas). Mais, chaque fois que j'apprenais à mieux connaitre l'AmigaOS, je le trouvais vraiment bien pensé et élégant quand je le comparais à ce que je connaissais à l'époque (MSDOS/Windows, GEOS (bien que j'appréciais beaucoup GEOS sur PC), dans une moindre mesure MAC-OS). En tant qu'utilisateur c'était un vrai plaisir d'avoir un OS comme celui là à disposition chez moi. Je n'ai pu utiliser UNIX avec une GUI sur station SUN que vers 92, mais je me suis quasiment sentit tout de suite chez moi, parce que j'avais eu un UNIX du pauvre chez moi depuis déjà 4 ans.
Certainement que l'Archimedes et son OS avaient des qualités. Microsoft n'y a pas pompé des idées pour rien (comme il l'a fait sur l'Amiga d'ailleurs). Le principal étant que l'utilisateur soit satisfait de sa machine et manifestement nous le sommes tous les deux de la notre 

[babsimov]

L'ARM n'est pas un exemple de processeurs RISC 'pur et dur' du coup dire que pour 2 progs équivalents ur Archie ça prendra bcp + de place c'est très aventureux.
Un type sur eab avait ouvert une file de discussion pour vanter le côté compact du code du 68000, notamment par rapport à l'ARM, et quand sur des exemples types il s'est trouvé que sur ARM on ne prenait pas plus de 5% de mémoire supplémentaire, il a cessé d'alimenter la file de discussion.
Le code de l'ARM a de sacrées capacités à être compact avec les instructions conditionnelles, ses 3 opérandes, et les shifts.
Faudrait que je te retrouve le lien.

J'avais toujours lu qu'un programme RISC est plus gros que l'équivalent en CISC. Je suppose en effet qu'il doit y avoir des raccourcis faciles qui ont pu être fait avec cette affirmation et qu'avec de l'optimisation, ici ou là, il est tout à fait possible que l'inverse soit vrai. 
Si on veut pinailler 5 % de plus c'est toujours 5 % de plus   Non je taquine juste   
Je ne doute pas que l'ARM comme processeur ait des qualités, sinon il n'aurait pas fait la carrière qu'il a fait.

Dans RISC OS, tu as aussi le BASIC, un éditeur léger (!Edit) et les applis !Paint et !Draw mais on ne peut pas dire qu'elles vont être bien gourmandes, puisqu'elles utilisent les fonctions de l'OS.

Ca prend forcément une partie de la ROM malgré tout, sinon ils n'aurait pas mis 2 MO s'ils avaient pu tout caser dans moins (ça devait avoir un coût de mettre 2MO de ROM à l'époque). Mais je ne nie pas qu'il y avait ce qu'il fallait comme routine dans la ROM. Je te remercie pour le détail du contenu de la ROM.

Amiga OS 3.0 ce n'est pas pour les Amiga AGA ça ? Du coup forcément il faut des routines en plus pour gérer les nouveaux modes graphiques

Oui, c'est pour l'AGA. Mais en fait le 3.0 n'apporte au final pas tant que ça par rapport au 2.x qui lui tenait sur 4 disquettes je crois. En réalité le 2.x aurait du s'appeler le 1.4 (2.0 était une désignation plus commerciale qu'autre chose, tout comme le 3.0 qui aurait pu s'appeler 1.5). Je m'explique le 1.4 qui était une réécriture complète de l'AmigaOS avec une refonte et l'ajout de plein de chose aurait du être prêt en 1988 (mais pas d'argent, pas de direction... retard). Il a apporté plein de choses en particulier pour les pro (langage script ARexx issu de REXX d'IBM, et d'autres choses :
http://obligement.free.fr/articles/workbench20.php
Mais en réalité il aurait du intégrer ce qui sera inclus dans le 3.0 (localisation), car cette fonction était déjà décrite dans les articles sur le 1.4 à l'époque soit au moins 4 ans avant le 3.0. Mais là aussi pas d'argent donc la locale.library a été reporté à la version 3.0 de l'OS au lieu d'être finalisée pour le 2.0 (1.4). 
Le 3.0 a apporté en plus les datatypes et la gestion de l'AGA et je crois qu'il ajoutait une gestion plus intégré de POSTSCRIPT.
Mais quoi qu'il en soit, je suis passé du 1.3 directement au 3.0 (sans connaitre le 2.0) et ce fut presque une redécouverte.
Désolé d'avoir fait long avec encore des détails.

( comme RISC OS à partir de 3.50, qui augmente encore en taille, pour les RISC PCs )

Evolution normale de tout OS en effet.

[ArchieForEver]

Oui, tous les RISC ne sortent pas du code de même taille, de même pour tous les CISC ( par exemple le code du 68000 sera + compact qu'un code x86 ) et l'ARM se place plutôt bien par rapport à ses concurrents ( comme dit + haut, grâce à la conditionnalité possible de toutes les instructions, du fonctionnement avec 3 opérandes, et du shift possible sur la dernière opérande )
Evidemment il se placera encore mieux quand la version Thumb apparaît ( mais si ma mémoire ne me joue pas des tours, en mode Thumb l'ARM ne manipulue plus des mots 32 bits mais des mots 16 bits. Ca ne gênait pas pour l'usage des CPU ARM Thumb, notamment pour l'industrie, où l'idée est d'économiser sur la taille de la ROM contenant le code. Pour contrôler une machine à laver on n'a pas besoin de 32 bits :-) ).

Pour savoir dans quelle mesure RISC OS ( dès le départ ou au fil du temps ) a utilisé les capacités de MMU offertes par le contrôleur mémoire MEMC ( et leurs évolutions au fil du temps ) tu pourrais poser la question sur le forum de stardot, riscos.fr ou bien risc os open.
Les experts sont là, notamment sur risc os open puisqu'eux développent toujours RISC OS.
https://www.riscosopen.org/content/

Je pense comme tu le suggères que si ok le MEMC de l'Archimedes peut être vu comme une MMU, ses capacités doivent être rudimentaires, et même si ensuite les ARM ont évolué et offert des MMUs de + en + abouties, et bien Acorn avec son RISC OS conçu pour la 1ère mouture de MMU a dû se trouver coincé, et très limité dans les possibilités de modifier le coeur de l'OS, pour cause, comme tu le dis, de compatibilité à maintenir.

[ArchieForEver]

les ATARI MEGA ST, TT et AMIGA 1200 etaient has been face à cette machine.

Pas le falcon ??, Sortir un micro sans parler du prix ne sert à rien, tu avais quoi pour le prix de l'archimedes ??
Parce que les archis hormis l'évolution du CPU, étaient en 93 avec le même hardware qu'en 87 et plus chers que les A1200/falcon,et avec un CPU @8mhz .

contre 5MIPS pour un Archimedes de base

Déjà c'est 4 mips,mais bon c'est un vrai CPU 32 bits lui !!

Non, pour les modèles à 8 Mhz, c'est
4 MIPS pour les tous 1ers Archies qui ont le 1er contrôleur mémoire, le MEMC
puis c'est 4,5 MIPS pour ceux qui ont le contrôleur mémoire MEMC1A.

Le MEMC1A est pour sûr mis en standard dans tous les Archimedes lorsque le BBCA3000 sort en 1989, et il est en fait dispo dès que les cartes upgrade CPU ARM3 sortent, car il faut avoir un MEMC1A dans sa machine pour faire tourner l'ARM3.

Tous les 1ers Archimedes ( séries 300 et séries 400 ), avec le MEMC, peuvent recevoir un MEMC1A simplement en retirant le MEMC de son support et en insérant à la place le MEMC1A, et en changeant 2 GALs, qui sont également sur supports.
( Tous les composants ARM sont montés sur support dans les modèles séries 300 et 400, et pas mal d'autres aussi ).

[ArchieForEver]

Présentation de l'Archimedes en 1987, explication de ce qu'est la technologie RISC, par Roger Wilson ( qui deviendra Sophie Wilson ), une des très grosses têtes d'Acorn :

On a même droit à une présentation de la carte mère, et ça devient technique, avec tout le process de fabrication de la carte mère ( en Angleterre, la fabrication, pas en Chine )
Tout ça sur la BBC en 1987.
Ce n'est pas en France qu'on aurait ça ( en France c'est sale la technique et la fabrication, montrer des soudures, une pompe à dessouder, des cartes mères : beurk !  )

[ArchieForEver]

Oui dont en gros l'Archimedes coutait 1000FF de plus que l'Amiga 1200

C'est pas enorme comme écart

Si on met l'A3010 à 2Mo, c'est bcp plus cher .

Ahhh ? Beaucoup ?
De mémoire c'était 50 livres sterling supplémentaires en Angleterre, donc environ 500 francs.
Est-ce que 500 francs c'est vraiment 'bcp plus cher' pour avoir 2 Mo ?
Le système RISC OS 3.11 en ROM de 2 Mo qui fait qu'on a une machine super complète, qui boote en moins de 2 secondes, ça,
il faudrait peut-être le valoriser, non, côté Archimedes ? Ca vaut combien dans la balance ? 1, 500 ou 1000 francs ?
Et le lecteur de disquettes haute densité sur ces modèles, ça vaut aussi peut-être qqchose, non ?
Combien ? 10 centimes, 1 euro, 500 ou 1000 ?
Le fait d'avoir désormais 1,6 Mo sur disquettes sous RISC OS, et de pouvoir lire ( et écrire ) les disquettes 1,44 Mo au format PC, on le valorise comment ?
Le lecteur de disquettes de l'Amiga du 1200 reste double densité : ça coûte combien d'en avoir un en haute densité pour cette machine ?
Un peu plus cher, bcp plus cher, ou bien c'est du domaine du rêve car ça n'existe tout simplement pas ?


Les résolutions graphiques VGA et SVGA, toujours 'flicker free' depuis l'origine sur Archimedes, ça vaut combien ça, en 256 couleurs ?
Il sait afficher 800 x 600 en 256 couleurs, le A1200 ? Ou bien 1152 x 896 en monochrome ?

Les 8 canaux hardware du chip son de l'Archie, ça vaut combien ?
Cette fois-ci il n'y a pas le filtre qui étouffait le rendu sur les machines A300, A400 et BBCA3000.
Ca vaut combien, avec 7 positions stéréo possible par canal ?
C'est le même chip son que les 1ers Archies, mais bon, voilà : 8 canaux, tout de même.
61 kHz maxi quand on utilise 4 canaux ; 41 kHz maxi quand on utilise les 8.
Bien sympa pour écouter des modules Fasttrekker ou bien même des S3M avec le lecteur Matrix Tracker.
Ca vaut combien sur Amiga une carte pour avoir 8 canaux ?
Paula est toujours en 4 canaux avec 3 positions stéréo, il faut une carte accélératrice hors de prix à l'époque
sur le A1200 pour faire du mixage de + de 4 canaux.

Le fait que le A3010 soit overclockable hyper facilement, ce qui n'est pas le cas de l'A1200,
ça vaut combien ?
Hyper facilement et pour pas cher.
La RAM et le CPU supporte sans aucun plantage l'overclocking à 16 Mhz, CPU et bus mémoire.
Matériel nécessaire : un oscillateur de fréquence + élevé, 2 fils à souder (de mémoire ) et peut-être une résistance à rajouter.
Vous en connaissez bcp des bécanes à l'époque qui gagnent 33% de puissance ( CPU et bus mémoire ) pour moins que 50 balles ?
Aujourd'hui, avec des RAMs à 50 ns on peut overclocker à 24 Mhz, et même pas besoin de ventilateur, l'ARM250 chauffe à peine.
Combien ça vaut, ce potentiel de booster la machine pour si peu cher ?

Le BBC BASIC d'Acorn, livré en standard avec l'Archimedes, dans la ROM, ça vaut combien ?
Incomparablement meilleur et + rapide ( le BASIC le + rapide du monde sur une machine à moins de 10 000 francs H.T., à sa sortie en 1987,
dixit tous les magasines qui ont testé l'Archimedes à sa sortie) que le BASIC Crosoft livré par C= avec l'Amiga, ça vaut combien ?
Avec son assembleur intégré ( et désassembleur, et des fonctions de débugging avec breakpooints etc ... ) ça vaut combien ?
On ne va pas le valoriser dans le prix soit disant 'cher' de l'Archimedes ?
Les applis comme !Draw, livrée en standard avec la machine, un 'petit' soft qui fait du dessin vectoriel, ça vaut tripette, peut-être ?
L'émulateur 6502 qui permet de faire tourner les softs bien écrits des BBC 8 bits, ça aussi, ça vaut zéro ?
C= livrait-il en standard avec l'Amiga un émulateur C64 ou C128 ? Ben non.

J'arrête là.
Le A3010 et le A1200 sont des machines tellement dissemblables que la simple comparaison sur la base du prix, ça reste très limité.

[TotOOntHeMooN]

Vidéo intéressante. Par contre, au final on voit des démo de trucs qui rament... C'est une tradition ? 

[ArchieForEver]

Vidéo intéressante. Par contre, au final on voit des démo de trucs qui rament... C'est une tradition ? 

Si c'est du BASIC non compilé ( les compilateurs BASIC arrivent dès l'année suivante ), genre programmes qui pourraient être faits par des enfants dans les écoles, au moins c'est honnête.

Tu as ça pour te consoler si tu veux, niveau vitesse :






et pour ce dernier, le YTeur utilise un moniteur VGA, il aurait mieux fallu avoir un moniteur RGB / une télé classique ( ou un multisync ), car sortir un signal VGA ( 720 x 400 en 70 Hz si j'en crois l'affichage on screen ) consomme nettement plus de bande passante mémoire que pour un signal basse résolution classique 320x256 50 Hz

[babsimov]

Oui, tous les RISC ne sortent pas du code de même taille, de même pour tous les CISC ( par exemple le code du 68000 sera + compact qu'un code x86 ) et l'ARM se place plutôt bien par rapport à ses concurrents ( comme dit + haut, grâce à la conditionnalité possible de toutes les instructions, du fonctionnement avec 3 opérandes, et du shift possible sur la dernière opérande )
Evidemment il se placera encore mieux quand la version Thumb apparaît ( mais si ma mémoire ne me joue pas des tours, en mode Thumb l'ARM ne manipulue plus des mots 32 bits mais des mots 16 bits. Ca ne gênait pas pour l'usage des CPU ARM Thumb, notamment pour l'industrie, où l'idée est d'économiser sur la taille de la ROM contenant le code. Pour contrôler une machine à laver on n'a pas besoin de 32 bits :-) ).

Ca devient un peu trop technique pour moi, le mode thumb je sais même pas ce que c'est. Mais, je pense qu'on est d'accord sur le fait que RISC et CISC avaient chacun différent représentant et que chacun d'eux avaient des qualités et des défauts. 

Pour savoir dans quelle mesure RISC OS ( dès le départ ou au fil du temps ) a utilisé les capacités de MMU offertes par le contrôleur mémoire MEMC ( et leurs évolutions au fil du temps ) tu pourrais poser la question sur le forum de stardot, riscos.fr ou bien risc os open.
Les experts sont là, notamment sur risc os open puisqu'eux développent toujours RISC OS.
https://www.riscosopen.org/content/

Je pense ne pas être assez calé pour me lancer dans une discussion aussi technique avec des experts. D'ailleurs, je n'ai plus de doute sur le fait qu'il y ait eu une MMU sur l'ARM 250, c'est écrit. Comme il y a eu un UNIX dessus, je pense qu'il y avait tout le nécessaire à l'intérieur. Autrement je vois pas trop l'intérêt d'ajouter une MMU qui n'aurait pas ce qu'il faut pour UNIX.

Je pense comme tu le suggères que si ok le MEMC de l'Archimedes peut être vu comme une MMU, ses capacités doivent être rudimentaires, et même si ensuite les ARM ont évolué et offert des MMUs de + en + abouties, et bien Acorn avec son RISC OS conçu pour la 1ère mouture de MMU a dû se trouver coincé, et très limité dans les possibilités de modifier le coeur de l'OS, pour cause, comme tu le dis, de compatibilité à maintenir.

De ce que je comprend le MENC intégré dans l'ARM 250 a tout d'une MMU. Mais pour conserver la compatibilité RISC-OS n'a probablement pas pu intégrer la protection mémoire.

ArchieForEver

Oui dont en gros l'Archimedes coutait 1000FF de plus que l'Amiga 1200

C'est pas enorme comme écart

Si on met l'A3010 à 2Mo, c'est bcp plus cher .

Ahhh ? Beaucoup ?
De mémoire c'était 50 livres sterling supplémentaires en Angleterre, donc environ 500 francs.
Est-ce que 500 francs c'est vraiment 'bcp plus cher' pour avoir 2 Mo ?

Oui, mais 500 frs en plus de quel tarif pour la machine complète de la gamme du dessous ? D'ailleurs 500 frs de plus pour un modèle avec 2MO, ça me parait peu malgré tout, tu es certain de tes chiffres ?

Le système RISC OS 3.11 en ROM de 2 Mo qui fait qu'on a une machine super complète, qui boote en moins de 2 secondes, ça,
il faudrait peut-être le valoriser, non, côté Archimedes ? Ca vaut combien dans la balance ? 1, 500 ou 1000 francs ?

Le boot sur ROM tu l'as aussi sur ST et MAC (et sur Amiga n'en déplaise à certains, c'est juste que la GUI n'est pas intégrée). Le MAC coûtait très cher en rapport de sa puissance. Le ST était très abordable (ce qui fera son succès initiale). Alors valoriser le choix des concepteurs de l'Archimedes pour sous entendre que ça équivaut à faire baisser virtuellement son prix de 1500 à 1000 frs, c'est à mon avis hasardeux. Toutefois, je reconnais qu'avoir ce qu'il y avait dans cette ROM est un plus que que l'utilisateur devait y trouver un certain confort au déballage de la machine. Reste à voir si à l'usage le !Paint et le !Draw seront utilisé majoritairement plutôt que d'autres logiciels similaires en disquette qui aurait eu des fonctions plus avancée. Car une ROM ça ne se met pas à jour (en tout cas pas par monsieur tout le monde).

Et le lecteur de disquettes haute densité sur ces modèles, ça vaut aussi peut-être qqchose, non ?
Combien ? 10 centimes, 1 euro, 500 ou 1000 ?
Le fait d'avoir désormais 1,6 Mo sur disquettes sous RISC OS, et de pouvoir lire ( et écrire ) les disquettes 1,44 Mo au format PC, on le valorise comment ?

Oui, c'est bien en effet qu'il y ait eu ça en standard sur ce modèle. Lire les disquette PC, le ST le faisait aussi (et l'Amiga avec CrossDos aussi)

Le lecteur de disquettes de l'Amiga du 1200 reste double densité : ça coûte combien d'en avoir un en haute densité pour cette machine ?
Un peu plus cher, bcp plus cher, ou bien c'est du domaine du rêve car ça n'existe tout simplement pas ?

Oui ça existait le lecteur HD sur Amiga (dès le 3000 et sur le 4000). Pour le 1200 il fallait en acheter un externe. Dans les fait, comme ce n'était pas standard sur le 1200, le format de disquette HD n'était pas utilisé par les éditeurs.
Ce lecteur HD était en fait un lecteur bidouillé et non standard parce que l'AGA incluait Paula qui n'avait pas la puissance pour gérer un lecteur HD standard qu'on trouvait sur PC. Commodore n'avait pas mis l'argent pour faire évoluer Paula et c'est bien dommage.

Les résolutions graphiques VGA et SVGA, toujours 'flicker free' depuis l'origine sur Archimedes, ça vaut combien ça, en 256 couleurs ?
Ces modes graphiques que le A1200 est absolument incapables de produire ?

Mode productivity 640x512 256 couleurs sur AGA 31 khz (flicke free) en standard. Le 800x600 était entrelacé si je me souviens bien. Bon par contre en 256 couleurs les deux modes ramaient dans mon souvenir. Là encore, parce que Commodore a créé l'AGA à la va vite avec pas de vrai budget pour le faire comme il fallait.

Les 8 canaux hardware du chip son de l'Archie, ça vaut combien ?
Cette fois-ci il n'y a pas le filtre qui étouffait le rendu sur les machines A300, A400 et BBCA3000.
Ca vaut combien, avec 7 positions stéréo possible par canal.
C'est le même chip son que les 1ers Archies, mais bon, voilà : 8 canaux, tout de même.
Bien sympa pour écouter des modules Fasttrekker ou bien même des S3M avec le lecteur Matrix Tracker.
Ca vaut combien sur Amiga une carte pour avoir 8 canaux ?
Paula est toujours en 4 canaux avec 3 positions stéréo.

Oui, mais on a vu dans un précédent débat que les 8 canaux de l'Archimedes n'ont pas autant de souplesse que les 4 canaux de Paula. D'ailleurs Paula peut sortir 2 voies 14 bits 0% processeurs. Une chose qu'on ignorait à l'époque, ça on le valorise comment ?
Les 8 canaux sur Archimedes si je me souviens bien ce n'est pas 0% processeur ?
Bien sur, on peux pas nier que 8 canaux sur le papier c'est mieux que 4 et que l'AGA aurait bien mérité d'avoir 8 canaux 16 bit.

J'arrête là.
Le A3010 et le A1200 sont des machines tellement dissemblables que la simple comparaison sur la base du prix, ça reste très limité.

En Angleterre malgré tous les points que tu avances (et qui sont tout à l'honneur de l'Archimedes), l'Amiga et le ST se vendaient davantage que l'Archimedes si je me souviens bien de ce que j'ai lu ici ou là au fil du temps. Ca montre bien que la fiche technique aussi reluisante qu'elle soit ne fait pas tout. Acorn, même sur son marché de prédilection n'a pas su écraser Atari ou Commodore et détenir la plus grosse part de marché. Parce que justement, niveau logiciel, je pense que le rapport était largement en faveur des Amiga et ST à l'époque. Si Acorn avait sérieusement visé en plus le marché international, là les choses auraient pu être différentes. C'est la principale erreur d'Acorn à mon avis, avoir cantonné l'Archimedes à l'Angleterre et ne pas avoir réellement visé le grand public. Ce qui fait qu'encore de nos jours tu as le sentiment que l'Archimedes est injustement reconnu. Si c'est le cas, c'est en grand partie à cause de la politique d'Acorn.

Quand à l'Amiga quoi que tu en penses, c'était un très belle machine, son OS était novateur et élégant. Bien que l'AGA soit le principal défaut du 1200 (et du 4000), cette génération ne déméritait pas. Si Commodore avait mieux géré l'évolution technologique de l'Amiga dès le départ, cette gamme existerait encore je pense. On pourrait dire la même chose pour l'Archimedes, bien que c'était moins un problème d'évolution technologique pour lui, que de politique marketing discutable de la part d'Acorn.

En tout cas Atari, Commodore et Acorn ont toutes les trois fait des erreurs, toutes différentes, mais qui ont conduit à la disparition de leur plateforme propriétaire. Dans une uchronie des décisions différentes ici ou là auraient très bien pu permettre à ces plateformes de perdurer jusqu'à nos jours. Le paysage informatique n'en serait que plus intéressant, car il y aurait vraiment des choix alternatifs et par la force des choses des innovations pour se démarquer du concurrent.

[ArchieForEver]

Oui le ST et l'Amiga lisaient les disquettes PC, mais soit c'était seulement les 720 ko, soit ( je crois, mais détrompe moi là dessus si je me plante ) c'était hyper lent dans le cas de l'Amiga 1200, avec une solution où le lecteur tournait à la moitié de sa vitesse.
C'est si dur que ça pour toi Babsimov de déclarer que oui, avoir un lecteur haute densité sur le A3010, c'est mieux que d'avoir un lecteur basse densité sur Amiga 1200 ?
Ca va t'arracher les tripes de le reconnaître ?
Et de reconnaître que ça a un coût car un lecteur HD coûte plus cher qu'un lecteur DD, donc quand on parle d'un A3010 'plus cher' qu'un A1200, il faudrait peut-être prendre en compte la présence d'un lecteur de disquettes HD sur A3010, absent sur le A1200 où ce n'est qu'un DD ?

Pour le temps CPU pris par un Archie pour jouer 8 canaux, ben oui ça prenait autour de 20% du temps CPU, certes.
La machine est conçue comme ça.
Sur une machine de base à 8 Mhz et ses 4,5 MIPS c'est clair tu le sens passer ; mais sur une machine à 12 Mhz, bcp moins.
Je reconnais tout à fait que le système DMA son de l'Amiga est bien plus efficace que celui de l'Archie, et de surcroît l'amplificateur opérationnel de l'Amiga, et la sélection en software du filtre sur l'Amiga, c'est bien mieux que la solution retenue par Acorn, avec son filtre bien trop fort sur les 1ers Archimedes, et l'amplificateur opérationnel qui aurait pu être bien meilleur.
C'est moi qui ai eu l'idée de remplacer l'amplificateur opérationnel de qualité standard par un de qualité audiophile de Burr-Brown, et bien ça vaut le coût.

Pour l'Amiga qui peut sortir 2 voies 14 bits, c'est bien, mais l'Archie fait mieux.
La même technique sur Archie c'est 2 voies stéréo 15 bits, et sinon 16 bits en mono.
C'est Steve Harrison, l'auteur de l'excellent QTM qui a développé ça, ça s'appelle VIDCBlaster,
https://stardot.org.uk/forums/viewtopic.php?f=29&t=10874
( topic intéressant qui évoque la reproduction du son sur l'Archimedes, et ça apporte un éclairage intéressant par rapport à ce qui avait été dit sur ce forum il y a quelques années )

[babsimov]

Oui le ST et l'Amiga lisaient les disquettes PC, mais soit c'était seulement les 720 ko, soit ( je crois, mais détrompe moi la dessus si je me plante ) c'était hyper lent dans le cas de l'Amiga, avec un trick où le lecteur tournait à la moitié de sa vitesse.

Oui c'est du 720 ko sur ST et Amiga. Mais ce nétait pas plus lent.

EDIT : sur Falcon je me demande si c'était pas un lecteur HD en standard d'ailleurs ?

Le lecteur HD sur Amiga j'en avais pas. Mais, de mes lectures c'était effectivement une bidouille qui ralentissait le moteur par 2 pour pouvoir avoir de la HD. Ca semble logique que les accès soit plus lent dans ce cas (ça n'excuse pas Commodore pour autant du recours à cette bidouille). 
La taille des disquettes Amiga HD était de 1,96 Mo à comparer au 1.44 standard du PC. Je dis pas qu'on aurait pas préféré que Paula ait été amélioré comme il se devait et avoir un lecteur HD standard dans tous les modèles cependant. 
La question était 500 frs de plus par rapport à quel prix de base ? Car si déjà le modèle de la gamme précédent était nettement plus cher que ne l'était un Amiga ou ST, forcément que le modèle avec lecteur HD était encore moins à la portée de toutes les bourses. Comme dit, en Angleterre l'Archimedes est resté 3ème derrière Atari et Amiga si je me souviens de ce que j'ai lu. Il y avait surement un peu du tarif et beaucoup de la logithèque moins étendue.

Pour le temps CPU pris par un Archie pour jouer 8 canaux, ben oui ça prenait autour de 17% du temps CPU, certes.
La machine est conçue comme ça.
Sur une machine de base à 8 Mhz et ses 4,5 MIPS c'est clair tu le sens passer ; mais sur une machine à 12 Mhz, bcp moins.

Qu'on le tourne comme on veuille, ça montre bien que malgré tout la conception de Paula était mieux que celle de la partie sonore de l'Archimedes puisque 0 % de processeur. Les 8 voies on pouvait aussi les avoir sur Paula, mais ça prenait un peu du processeur (je sais pas combien en pourcentage).

Pour l'Amiga qui peut sortir 2 voies 14 bits, je crois que c'est du mono.
La même technique sur Archie c'est 2 voies stéréo, et sinon 15 bits en mono.
C'est Steve Harrison, l'auteur de l'excellent QTM qui a développé ça, ça s'appelle VIDCBlaster, et là évidemment je ne retrouve pas le lien.

Non, je crois bien que c'est stéréo, puisque paula à 2 fois 2 voies stéréo.

Si sur Archimèdes en partant de 8 voies avec la même technique (je doute que ce soit la même puisque je crois qu'il y a le copper dans la bidouille 14 bits sur Amiga et que l'Archimedes n'a pas de copper), bref si en partant de 8 voies tu n'a au final que 2 voies avec la bidouille, c'est bien que la partie audio de l'Amiga est mieux conçue. Sinon si celle de l'Archimedes était au niveau de celle de l'Amiga tu aurais du avoir 4 voies et non 2. De plus je suppose que cette bidouille là consomme bien davantage que les 17 % de processeur des 8 voies, là ou sur Amiga les 2 voies c'est toujours 0% de processeur. Ce n'est pas pour rien que la Gravis Ultrasound s'est inspiré de Paula sur PC pour avoir 16 à 32 voies 0 % processeur en 16 bit.
Tu vas me dire que c'est 15 bit, mais la question n'est pas vraiment là. De ce que je comprends des débats qui avaient eu lieu sur la partie son de l'Archimedes, pour tirer partit au maximum du composant sonore qui l'équipe, le processeur doit y mettre du sien, là ou sur Amiga c'est transparent pour lui. Et ça, c'était très moderne pour l'époque c'est à mon avis indéniable. Tout comme le concept du blitter et du copper qui déchargeaient le processeur de toute la partie affichage.

[ArchieForEver]

je modifiais mon texte initial quand tu postais, tu peux relire maintenant.

Je parle de 2 voies stéréo car oui il faut bien 2 voies pour être en stéréo ... faut comprendre que tu lis un 'stream', ça n'a rien avoir avec la lecture d'un mod 4 ou 8 canaux.
Tu pêches au niveau compréhension technique, là.

L'usage du copper sur Amiga c'est pour gérer la fréquence de sortie de Paula, ou bien pour mixer le 'stream'.
Sur Archimedes pas de copper : on se sert des interruptions classiques, et comme l'ARM est, par sa conception même, un CPU qui répond aux interruptions et en sort très vite (bien mieux qu'un 68000) et bien ça se passe très bien.
Je le répète c'était le souhait d'Acorn de ne pas baser leur architecture sur un système avec plein de DMA, nécessitant un chip dédié complexe comme l'AGNUS, mais créer une architecture qui répond très vite aux interruptions, et maximise l'usage de la bande passante des mémoires standard de l'époque.
L'anti démarche Amiga, en quelque sorte.
Suffit d'écouter les interviews de Sophie Wilson et Steve Furber qui sont sur YT, c'est répété, expliqué, martelé de très nombreuses fois (genre ' on a créé l'ARM car les autres CPUs étaient incapables de faire ça, et nous c'est ce qu'on voulait avoir ' )
En mode FIRQ ( de mémoire ) l'ARM 'switche' les registres R8 à R14 du mode USER et 'apparaissent' les nouveaux registres R8_FIRQ à R14_FIRQ.
Du coup si tu n'as pas besoin de + de 7 registres pour ton code sous interruption, tu n'as pas besoin de sauvegarder des registres en entrée du code FIRQ, ni de recharger tes registres USER quand tu sors de ton interruption FIRQ : c'est le processeur qui 'switche' les banques de registres des registres FIRQ vers les registres USER.
C'est pour ça que l'ARM a 27 registres, et 16 sont toujours utilisables simultanément, quel que soit le mode ( USER, IRQ, FIRQ )
Et là mon compte n'est pas bon car 16+7 ça fait 23 pas 27, va falloir que je corrige + tard.

[babsimov]

je modifiais mon texte initial quand tu postais, tu peux relire maintenant.

Je parle de 2 voies stéréo car oui il faut bien 2 voies pour être en stéréo ... faut comprendre que tu lis un 'stream', ça n'a rien avoir avec la lecture d'un mod 4 ou 8 canaux.
Tu pêches au niveau compréhension technique, là.

Peut être que je manque de connaissance technique effectivement. Je laisse donc ceux qui ont plus de connaissance technique te répondre éventuellement ou me corriger si nécessaire.

L'usage du copper sur Amiga c'est pour gérer la fréquence de sortie de Paula.
Sur Archimedes pas de copper on se sert des interruptions classiques, et comme l'ARM est, par volonté de design avec son MEMC, un CPU qui répond aux interruptions et en sort très vite (bien mieux qu'un 68000) et bien ça se passe très bien.

Peut être, là aussi on dépasse me compétences techniques.

Je le répète c'était le souhait d'Acorn de ne pas baser leur architecture sur un système avec plein de DMA, nécessitant un chip dédié complexe, mais créer une architecture qui répond très vite aux interruptions, et maximise l'usage de la bande passante des mémoires standard de l'époque.
L'anti démarche Amiga, en quelque sorte.

Je pense que c'était le seule moyen pour Acorn d'avoir un ordinateur avec un processeur RISC à un tarif raisonnable pour les acheteurs. Comme tu dis c'était le choix des ingénieurs Acorn. Je ne pense pas qu'ils se soient dit "on va faire que l'anti Amiga", mais plutôt qu'ils ont cherché le meilleur compromis performance prix. 
Ils ont privilégié ce qui se faisait partout, un processeur central qui fait tout. Avoir des copros avec des DMA et en plus un RISC puissant aurait, je pense, été bien trop cher au final pour le marché grand public. 
EDIT : d'aileurs Acorn n'avait peut être pas les moyens à l'époque de concevoir un processeur RISC de zéro et des copros dans le style Amiga en même temps. Il se sont concentré sur le processeur et je pense que c'était la décision la plus cohérente pour Acorn.
De mon point de vue, je préfère la vision Amiga avec des copros et les DMA, ça me semblait bien plus moderne et élégant que le processeur qui fait tout qu'on trouvait partout ailleurs. Et de nos jours, c'est ce qu'il y a partout, ce qui tend à montrer que le concept de l'Amiga était celui d'avenir.
EDIT : Chez Amiga ils ont fait le choix inverse, prendre un processeur sur étagère et concevoir un chipset autour pour en tirer les meilleures performances possibles avec la technologie de l'époque. Ils n'avaient de toute façon pas les moyens de faire les deux, ils ont déjà eu bien du mal à financer le chipset de zéro.

[ArchieForEver]

je modifiais mon texte initial quand tu postais, tu peux relire maintenant.

Je parle de 2 voies stéréo car oui il faut bien 2 voies pour être en stéréo ... faut comprendre que tu lis un 'stream', ça n'a rien avoir avec la lecture d'un mod 4 ou 8 canaux.
Tu pêches au niveau compréhension technique, là.

Peut être que je manque de connaissance technique effectivement. Je laisse donc ceux qui ont plus de connaissance technique te répondre éventuellement ou me corriger si nécessaire.

L'usage du copper sur Amiga c'est pour gérer la fréquence de sortie de Paula.
Sur Archimedes pas de copper on se sert des interruptions classiques, et comme l'ARM est, par volonté de design avec son MEMC, un CPU qui répond aux interruptions et en sort très vite (bien mieux qu'un 68000) et bien ça se passe très bien.

Peut être, là aussi on dépasse me compétences techniques.

Je le répète c'était le souhait d'Acorn de ne pas baser leur architecture sur un système avec plein de DMA, nécessitant un chip dédié complexe, mais créer une architecture qui répond très vite aux interruptions, et maximise l'usage de la bande passante des mémoires standard de l'époque.
L'anti démarche Amiga, en quelque sorte.

Je pense que c'était le seule moyen pour Acorn d'avoir un ordinateur avec un processeur RISC à un tarif raisonnable pour les acheteurs. Comme tu dis c'était le choix de ingénieurs Acorn. Je ne pense pas qu'ils se soient dit "on va faire que l'anti Amiga", mais plutôt qu'ils ont cherché le meilleur compromis performance prix. 
Ils ont privilégié ce qui se faisait partout, un processeur central qui fait tout. Avoir des copros avec des DMA et en plus un RISC puissant aurait, je pense, été bien trop cher au final pour le marché grand public. 
De mon point de vue, je préfère la vision Amiga avec des copros et les DMA, ça me semblait bien plus moderne et élégant que le processeur qui fait tout qu'on trouvait partout ailleurs. Et de nos jours, c'est ce qu'il y a partout, ce qui temps à montrer que le concept de l'Amiga était celui d'avenir.

Là encore je faisais des ajouts pour compléments d'infos quand tu postais ;-)
Je n'ai pas dit qu'ils ont sciemment voulu faire de l'anti Amiga ( qu'ils ne connaissaient pas : la création de l'ARM a débuté en 1983, et le 1er chip l'ARM1 est sorti en 1985 ) : ils ne voulaient pas avoir à créer un chip genre AGNUS de l'Amiga ( qui est une sacrée prouesse technique quand on regarde l'époque et les performances, bien sûr je le reconnais ).
Et non, Babsimov, ils n'ont pas 'privilégié ce qui se faisait partout' car à l'époque il n'y a AUCUN CPU qui comme l'ARM, maximise l'usage de la bande passante, et sait répondre aux interruptions aussi vite qu'un ARM : c'est pour ça qu'ils ont décidé de créer leur propre CPU, ils voulaient ces caractéristiques dans le CPU de la future gamme d'Acorn.
Ils ont testé les autres CPUs de l'époque, y compris des RISC, et aucun ne les a impressionnés, car ça faisait des système trop lents sans l'ajout d'un chip type AGNUS que je pense, ni ils ne voulaient développer, ni même ils en avaient les moyens financiers.
Je pense que développer Agnus a coûté + cher que ce que ça a coûté chez Acorn de développer tout le chipset ARM.

[babsimov]

je modifiais mon texte initial quand tu postais, tu peux relire maintenant.

Je parle de 2 voies stéréo car oui il faut bien 2 voies pour être en stéréo ... faut comprendre que tu lis un 'stream', ça n'a rien avoir avec la lecture d'un mod 4 ou 8 canaux.
Tu pêches au niveau compréhension technique, là.

Peut être que je manque de connaissance technique effectivement. Je laisse donc ceux qui ont plus de connaissance technique te répondre éventuellement ou me corriger si nécessaire.

L'usage du copper sur Amiga c'est pour gérer la fréquence de sortie de Paula.
Sur Archimedes pas de copper on se sert des interruptions classiques, et comme l'ARM est, par volonté de design avec son MEMC, un CPU qui répond aux interruptions et en sort très vite (bien mieux qu'un 68000) et bien ça se passe très bien.

Peut être, là aussi on dépasse me compétences techniques.

Je le répète c'était le souhait d'Acorn de ne pas baser leur architecture sur un système avec plein de DMA, nécessitant un chip dédié complexe, mais créer une architecture qui répond très vite aux interruptions, et maximise l'usage de la bande passante des mémoires standard de l'époque.
L'anti démarche Amiga, en quelque sorte.

Je pense que c'était le seule moyen pour Acorn d'avoir un ordinateur avec un processeur RISC à un tarif raisonnable pour les acheteurs. Comme tu dis c'était le choix de ingénieurs Acorn. Je ne pense pas qu'ils se soient dit "on va faire que l'anti Amiga", mais plutôt qu'ils ont cherché le meilleur compromis performance prix. 
Ils ont privilégié ce qui se faisait partout, un processeur central qui fait tout. Avoir des copros avec des DMA et en plus un RISC puissant aurait, je pense, été bien trop cher au final pour le marché grand public. 
De mon point de vue, je préfère la vision Amiga avec des copros et les DMA, ça me semblait bien plus moderne et élégant que le processeur qui fait tout qu'on trouvait partout ailleurs. Et de nos jours, c'est ce qu'il y a partout, ce qui temps à montrer que le concept de l'Amiga était celui d'avenir.

Je n'ai pas dit qu'ils ont sciemment voulu faire de l'anti Amiga : ils ne voulaient pas avoir à créer un chip genre AGNUS de l'Amiga.

Oui, c'est ce que j'ai écrit (déduit) dans mes edit pendant que tu répondais.

Et non, Babsimov, ils n'ont pas 'privilégié ce qui se faisait partout' car à l'époque il n'y a AUCUN CPU qui comme l'ARM, maximise l'usage de la bande passante, et sait répondre aux interruptions aussi vite qu'un ARM : c'est pour ça qu'ils ont décidé de le créer.

Ce que je veux dire c'est qu'il ont fait l'architecture classique un processeur central qui fait tout, comme sur PC/MAC/ST. 

Ils ont testé les autres CPUs de l'époque, y compris des RISC, et aucun ne les a impressionné.

Et personne ne dit qu'il n'ont pas produit un très bon processeur RISC. Toute la presse de l'époque l'a salué et crois bien qu'en lisant le test de l'Archimedes dans TILT j'avais été impressionné par ce qui était décrit. 
Mais, ça n'a été en vente nul part en France et la gamme est resté quasi inconnue du grand public en dehors de l'Angleterre. Et même la bas c'était un marché de niche (c'était le Thomson anglais, à la différence qu'Acorn avait de bon ordinateurs). Et ce dernier point est TOTALEMENT la faute d'Acorn et de sa politique commerciale. Ils n'ont pas vraiment eu d'ambition pour leur plateforme à l'international ce qui a conduit à la disparition de l'Archimedes comme plateforme et Acorn comme constructeur. Car, je doute que les concepteurs de l'ARM aient envisagé à sa conception que sa vocation serait d'être un processeur sous licence et non le processeur d'une gamme d'ordinateur sous la marque Acorn pour les décennies à venir. La licence ARM est à mon avis une conséquence du fait qu'Acorn n'a pas su démocratiser la plateforme RISC-OS et a finalement du l'abandonner.

ArchieForEver





Là encore je faisais des ajouts pour compléments d'infos quand tu postais ;-)
Je n'ai pas dit qu'ils ont sciemment voulu faire de l'anti Amiga ( qu'ils ne connaissaient pas : la création de l'ARM a débuté en 1983, et le 1er chip l'ARM1 est sorti en 1985 ) : ils ne voulaient pas avoir à créer un chip genre AGNUS de l'Amiga ( qui est une sacrée prouesse technique quand on regarde l'époque et les performances, bien sûr je le reconnais ).

C'était bien mon propos, chacun à travaillé de son côté et choisit ce qui lui paraissait la meilleure option du moment. De toute façon, financer un nouveau processeur et un chipset en même n'était surement pas à la porté ni d'Amiga (Hi Toro au départ) ou d'Acorn. Chez Amiga Jay Miner avait plus l'habitude des chipset et il voulait depuis sa sortie travailler autour du 68000. Chez Acorn de ce que j'ai compris ils ont fait le choix assez tôt de concevoir en interne leur propre processeur, parce qu'ils ont vu que le 65816 (ou une évolution du 6502) était conçu par une toute petite équipe et qu'il se sont dit qu'ils pouvaient eux concevoir un processeur qui serait à leur gout plutôt que d'en acheter sur étagère. Tant mieux qu'ils aient fait ce choix, car l'ARM a de nombreuses qualités semble t il, sinon l'industrie de l'aurait pas adopté aussi massivement.

[ArchieForEver]

Suis d'accord.
Sans l'arrivée de tout ce qui est 'portable' l'ARM n'aurait sûrement pas eu le développement qu'il a connu.
Cependant, même sans ça, vu qu'il a très peu de transistors, il aurait eu sa place comme 'super micro contrôleur' en concurrence avec les autres, car qui dit 'peu de transistors' dit 'pas cher à produire'.

[babsimov]

Suis d'accord.
Sans l'arrivée de tout ce qui est 'portable' l'ARM n'aurait sûrement pas eu le développement qu'il a connu.
Cependant, même sans ça, vu qu'il a très peu de transistors, il aurait eu sa place comme 'super micro contrôleur' en concurrence avec les autres, car qui dit 'peu de transistors' dit 'pas cher à produire'.

Tout ce qui est informatique nomade ne pouvait de toute façon que très difficilement être envisagé à l'époque, hormis comme une science fiction plus ou moins lointaine. Acorn a su habilement saisir l'opportunité de reconversion pour son ARM.

[Invité]

Tout ce qui est informatique nomade ne pouvait de toute façon que très difficilement être envisagé à l'époque, hormis comme une science fiction plus ou moins lointaine. Acorn a su habilement saisir l'opportunité de reconversion pour son ARM.

Moi je dirais plutôt qu'ACORN récolte le fruit de son travail, en fait on peut dire que leurs CPU ont toujours été taillés pour cela, c'est juste que le "portable/mobile" comme on le connait aujourd'hui a mis pas mal de temps à exploser à cause surtout des batteries,car les ARM ont toujours été un choix logique et quasiment depuis le début .