Inscription : 20 Août 2007, 18:21 Message(s) : 4997
DjPoke a écrit :
Merci hERMOL. J'ai finalement pris mon courage à deux mains, démonté le 6128+, débranché la nappe du lecteur de disquette ainsi que son alim. Heureusement, le HxC est donc reconnu en ùa.
Inscription : 28 Août 2008, 23:41 Message(s) : 258
Citer :
NTFS ? Format Spécifique ? Pourquoi faire ? l’émulateur supporte les SD/SDHC. Le format standard sur ces cartes c’est la FAT32….
Ce n'est pas vrai. Tu peux avoir d'autres formats. Mais tu n'as pas saisi l'objet de ma remarque qui n'est pas de disserter sur les formats possibles d'une carte mémoire (car si on achète une sdcard pour cet usage, on la formate avec le système connu par la carte, ce qui est logique et sans discussion)
Je dis simplement qu'obliger chaque machine hôte à s'adapter à la structure des données de stockage connue par l'émulateur n'est pas une bonne solution à long terme. Il serait plus logique de laisser la gestion et connaissance de la structure des fichiers à l'émulateur en normalisant cette gestion car ce qui ne changera pas c'est bien le drive émulé alors que le format des données stockées dépendra toujours de la techno utilisée par l'émulateur. Si par exemple dans 5 ans on a des cartes mémoire de 1 to et que tu veux gérer une partition NTFS pour y mettre 10 go de disques amiga, 10 go de disques atari, ... , et que toi ou un autre crée une version de l'émulateur supportant cette carte, ses partitions, ..., ça va impliquer que tous les softwares existants ne fonctionneront plus, et qu'il faudra que tout le monde se paluche la gestion des partitions, du ntfs, ect...
Avec des variables 32 bits partout... ca va donner sur le z80a...
Citer :
Cette arborescence il faut la générer… et donc faire le travail dans le PIC… rappel des specs du PIC18F4620 : 64Ko de FLASH (quasi plein…) 4Ko de RAM… Je pense que c’est largement plus facile sur CPC De plus la FAT est un système de fichier ultra simple … Proche de cette fameuse liste…
Ce n'est pas ce que j'ai dit. La liste serait générée sur PC et pas par le PIC. Et l'émulateur n'aurait pas grand chose à faire justement car il sait déjà gérer le (ou les formats) qu'il connait.
Citer :
Facile c’est toujours le même : FAT32 & HXCSDFE.CFG
Pour l'instant. J'ai exprimé ce que je pensais sur la pérennité des formats et principes de stockage. Etablir une passerelle "logique" évite à chaque machine d'être esclave du système utilisé par un émulateur X ou Y avec une carte A ou B C'est d'ailleurs un moyen d'imaginer un émulateur multi carte all-in-one ou même avec une prise USB en prime pour accepter une carte mémoire USB ou une connection PC. Ca éviterait d'écrire un soft qui connait la "même chose" que l'émulateur en ligne de l'autre côté.
NTFS ? Format Spécifique ? Pourquoi faire ? l’émulateur supporte les SD/SDHC. Le format standard sur ces cartes c’est la FAT32….
Ce n'est pas vrai. Tu peux avoir d'autres formats. Mais tu n'as pas saisi l'objet de ma remarque qui n'est pas de disserter sur les formats possibles d'une carte mémoire (car si on achète une sdcard pour cet usage, on la formate avec le système connu par la carte, ce qui est logique et sans discussion)
Oui tu peux, mais d'après la SD Card Association, C'est FAT32 sur SDHC...
Longshot a écrit :
Je dis simplement qu'obliger chaque machine hôte à s'adapter à la structure des données de stockage connue par l'émulateur n'est pas une bonne solution à
long terme. Il serait plus logique de laisser la gestion et connaissance de la structure des fichiers à l'émulateur en normalisant cette gestion car ce qui ne changera
pas c'est bien le drive émulé alors que le format des données stockées dépendra toujours de la techno utilisée par l'émulateur. Si par exemple dans 5 ans on a des cartes mémoire de 1 to et que tu veux gérer une partition NTFS pour y mettre 10 go de disques amiga, 10 go de disques
atari, ... , et que toi ou un autre crée une version de l'émulateur supportant cette carte, ses partitions, ..., ça va impliquer que tous les softwares
existants ne fonctionneront plus, et qu'il faudra que tout le monde se paluche la gestion des partitions, du ntfs, ect...
Oui mais dans 5 ans les choses auront bien changées... et le fameux "standard" que tu proposes sera aussi devenu obsolète. De nouvelles fonctionnalités rendront caduc le format ce qui forcera de toute façon une évolution du soft. Croire qu'il n'y aura aucun changement est une utopie.
Avec des variables 32 bits partout... ca va donner sur le z80a...
Ouhai et tu crois que ça donne quoi dans un PIC18F ?
Longshot a écrit :
Citer :
Cette arborescence il faut la générer… et donc faire le travail dans le PIC… rappel des specs du PIC18F4620 : 64Ko de FLASH (quasi plein…) 4Ko de RAM… Je pense que c’est largement plus facile sur CPC De plus la FAT est un système de fichier ultra simple … Proche de cette fameuse liste…
Ce n'est pas ce que j'ai dit. La liste serait générée sur PC et pas par le PIC. Et l'émulateur n'aurait pas grand chose à faire justement car il sait déjà gérer le (ou les formats) qu'il connait.
Par le PC ? Le problème est qu'il faut se détacher le plus possible du PC... En plus ça risque d'être bien lourd a gérer : Par exemple pour supprimer une image, la plupart du temps l'utilisateur supprime simplement l'image sur la SD, sans forcement remettre à jour cette fameuse liste... L'autre solution serait de faire un format de fichier contenant un ensemble d'images ainsi que la liste, ou encore un "système de fichier" spécifique pour l'émulateur (cad sans FAT). Et la le problème est réglé (et c'est hyper simple à faire). L'utilisateur est ainsi forcé de passer par le soft pour ajouter/supprimer des images, il n'y a plus de risque d'erreur. Mais je doute que cela soit bien apprécié... Déjà la conversion en HFE passe moyennement...
Longshot a écrit :
Citer :
Facile c’est toujours le même : FAT32 & HXCSDFE.CFG
Pour l'instant. J'ai exprimé ce que je pensais sur la pérennité des formats et principes de stockage. Etablir une passerelle "logique" évite à chaque machine d'être esclave du système utilisé par un émulateur X ou Y avec une carte A ou B C'est d'ailleurs un moyen d'imaginer un émulateur multi carte all-in-one ou même avec une prise USB en prime pour accepter une carte mémoire USB ou une
connection PC. Ca éviterait d'écrire un soft qui connait la "même chose" que l'émulateur en ligne de l'autre côté.
Bref, ce que j'en dis...
L'idée c'est surtout résoudre l'équation "Facilité d'utilisation" et "Difficulté de réalisation/technique". Pour être adopté le premier paramètre passe en premier.
Tant que les sources sont disponibles et le format hfe ouvert, il sera toujours facile de faire un outil simple d'utilisation quel que soit l'OS utilisé. La preuve, en deux heures, grâce à la disponibilité des sources, je me suis bricolé une version qui m'est bien utile sous Ubuntu. (Le temps de comprendre qu'il fallait compiler en 32 bits, entre autres...)
Pour ce qui est de la facilité d'utilisation, je vais regarder comment intégrer ça au browser de Gnome. Peut-être serait-il possible de faire pareil sous Windows, en ajoutant un menu contextuel du genre "dump to SD as hfe". Là, au moins, on ne pourrait pas faire plus simple...
Par ailleurs, Jeff, est-ce que le format du fichier de configuration de l'émulateur est décrit quelque part ? Je voudrais juste réduire un peu la vitesse de défilement. Et je n'ai pas forcément le courage de chercher dans les sources où c'est fait. C'est à quel offset, et sous quelle forme, ce paramètre ?
Suite au commentaire de l'ami Longshot, je rejoins l'ami Jeff (et vous, on est tous amis ici ) dire que le format FAT32 est voué à l'obsolescence c'est aussi valable pour tous les autres devices utilisant les SDCard : consoles portables, cadre photo numérique, appareil photo... ca reste quand même pas mal standard, tellement standard même que je pense qu'on est bon avec ca pour au moins un bon 15 ans (sauf si tout le monde se converti à l'iPad entre temps, mais c'est une autre histoire ) Enfin (et faut pas l'oublier), entre RIEN et ce projet malgré tout amateur et parti de rien, c'est qd même une très bonne nouvelle pour la scène CPC en général. Puis Jeff semble malgré tout à l'écoute avec une volonté d'apporter un certain support, c'est très positif.
Inscription : 28 Août 2008, 23:41 Message(s) : 258
Citer :
Oui mais dans 5 ans les choses auront bien changées... et le fameux "standard" que tu proposes sera aussi devenu obsolète. De nouvelles fonctionnalités rendront caduc le format ce qui forcera de toute façon une évolution du soft. Croire qu'il n'y aura aucun changement est une utopie.
Ce n'est pas vrai non plus. Il y a une différence entre standardiser les échanges de données sur un format "non évolutif" (le drive et la structure des anciens fichiers) et le format des données gérées par un système "externe". C'est un peu comme si tu disais que le standard DSK évoluera encore beaucoup. Cette normalisation permet à tous les émulateurs cpc de gérer le même format. Et quand bien même il évolue, il reste rétro compatible! J'ai l'impression de devoir faire un débat sur l'utilité d'OSI.
Un émulateur électronique peut évoluer. D'autres que toi travaillent sur ce type de projet (je pense à ram7 par exemple qui avance sur un prototype pour lire le contenu d'un clef usb). La méthode d'accès aux fichiers est donc radicalement différente! Si tout le monde normalise de la même manière le fait de récupérer une arbo, c'est une chose qui n'évoluera pas bcp. Et le même programme fonctionnera pour tous les émulateurs.
Les principes de stockage "moderne" évoluent. D'ailleurs quid du partitionnement dont j'ai causé 2 fois... Pour la parenthèse , j'enfonce un peu plus le clou, mais ce n'est pas FAT mais exFAT qui est "préconisé" par sdcard.org, ce qui souligne encore une fois que tout évolue, et pas si lentement. Rien n'empêche quelqu'un de faire son émulateur avec un format propriétaire pour des raisons techniques par exemple (ou justement pour mieux gérer une liste pré-calculée) (un p'tit exemple WBFS... ca vous parle )
Citer :
Par le PC ? Le problème est qu'il faut se détacher le plus possible du PC...
J'imagine que les DSK et les HFE qui en résultent, c'est pas de la génération spontanée sur la carte...
Citer :
L'autre solution serait de faire un format de fichier contenant un ensemble d'images ainsi que la liste, ou encore un "système de fichier" spécifique pour l'émulateur (cad sans FAT). Et la le problème est réglé (et c'est hyper simple à faire). L'utilisateur est ainsi forcé de passer par le soft pour ajouter/supprimer des images, il n'y a plus de risque d'erreur. Mais je doute que cela soit bien apprécié... Déjà la conversion en HFE passe moyennement...
Pourquoi pas. Puisque de toute manière il faut obligatoirement convertir les fichiers qui, sinon occupent beaucoup plus de places, je ne vois pas le problème. C'est pas comme si tu t'adressais à la ménagère qui veut sortir un fichier de son appareil photo!
Citer :
L'idée c'est surtout résoudre l'équation "Facilité d'utilisation" et "Difficulté de réalisation/technique". Pour être adopté le premier paramètre passe en premier.
A ce moment là, gère des DSK! Et l'équation c'est pas que "facilité d'utilisation" vs "difficulté technique". tu oublies "maintenabilité", "interopérabilité", "pérennité" Et la le résultat n'est pas le même...
Oui mais dans 5 ans les choses auront bien changées... et le fameux "standard" que tu proposes sera aussi devenu obsolète. De nouvelles fonctionnalités rendront caduc le format ce qui forcera de toute façon une évolution du soft. Croire qu'il n'y aura aucun changement est une utopie.
Ce n'est pas vrai non plus. Il y a une différence entre standardiser les échanges de données sur un format "non évolutif" (le drive et la structure des anciens fichiers) et le format des données gérées par un système "externe". C'est un peu comme si tu disais que le standard DSK évoluera encore beaucoup. Cette normalisation permet à tous les émulateurs cpc de gérer le même format. Et quand bien même il évolue, il reste rétro compatible! J'ai l'impression de devoir faire un débat sur l'utilité d'OSI.
En parlant des dsk, Il existe 2 versions ("standard" et "extended") qui certes se ressemblent mais ne sont en aucun cas retro compatible. A un moment il s’est fait sentir le besoin de faire évoluer le format et cela à impliquer des modifications logiciels. Merci pour l’exemple
Longshot a écrit :
Un émulateur électronique peut évoluer. D'autres que toi travaillent sur ce type de projet (je pense à ram7 par exemple qui avance sur un prototype pour lire le contenu d'un clef usb). La méthode d'accès aux fichiers est donc radicalement différente! Si tout le monde normalise de la même manière le fait de récupérer une arbo, c'est une chose qui n'évoluera pas bcp. Et le même programme fonctionnera pour tous les émulateurs.
Franchement j'y crois peu : le fait définir un protocole ne va en aucun cas le faire adopter par les autres. Et dans ce domaine (les petits devices style emulo floppy) encore plus. En ce moment c'est plutôt la mode du je réinvente la roue...
Longshot a écrit :
Les principes de stockage "moderne" évoluent. D'ailleurs quid du partitionnement dont j'ai causé 2 fois... Pour la parenthèse , j'enfonce un peu plus le clou, mais ce n'est pas FAT mais exFAT qui est "préconisé" par sdcard.org, ce qui souligne encore une fois que tout évolue, et pas si lentement. Rien n'empêche quelqu'un de faire son émulateur avec un format propriétaire pour des raisons techniques par exemple (ou justement pour mieux gérer une liste pré-calculée) (un p'tit exemple WBFS... ca vous parle )
Remarque : exFAT c'est préconiser pour les SDXC et non pas pour les SDHC....
Longshot a écrit :
Citer :
Par le PC ? Le problème est qu'il faut se détacher le plus possible du PC...
J'imagine que les DSK et les HFE qui en résultent, c'est pas de la génération spontanée sur la carte...
Oui d'ou ma remarque par rapport à ce retour d'expérience.
Longshot a écrit :
Citer :
L'autre solution serait de faire un format de fichier contenant un ensemble d'images ainsi que la liste, ou encore un "système de fichier" spécifique pour l'émulateur (cad sans FAT). Et la le problème est réglé (et c'est hyper simple à faire). L'utilisateur est ainsi forcé de passer par le soft pour ajouter/supprimer des images, il n'y a plus de risque d'erreur. Mais je doute que cela soit bien apprécié... Déjà la conversion en HFE passe moyennement...
Pourquoi pas. Puisque de toute manière il faut obligatoirement convertir les fichiers qui, sinon occupent beaucoup plus de places, je ne vois pas le problème. C'est pas comme si tu t'adressais à la ménagère qui veut sortir un fichier de son appareil photo!
Oui mais en faisant cela tu oublies quelque chose : La notion d'image disparaît puisque tu n'as plus qu'un gros fichier de 1Go. Impossible de supprimer/copier/stocker les "images" de manière standard justement c'est à dire avec un explorateur classique : Tu seras obligé de passer par un logiciel spécialisé pour cela... Un comble pour du standard
Pour le SD HxC Floppy Emulator par exemple beaucoup de gens utilisent le soft Windows pour la conversion de leurs images à la réception de l'emulo, ensuite ils ne l'utilisent plus et manipulent uniquement les hfe comme des dsk. En passant par ce système tu supprimes cette possibilité, et là ça va poser un problème.
Concernant la ménagère, il n'y pas que des informaticiens qui achètent ce genre de chose (et heureusement...). Regardes notamment du coté des musiciens.
Longshot a écrit :
Citer :
L'idée c'est surtout résoudre l'équation "Facilité d'utilisation" et "Difficulté de réalisation/technique". Pour être adopté le premier paramètre passe en premier.
A ce moment là, gère des DSK! Et l'équation c'est pas que "facilité d'utilisation" vs "difficulté technique". tu oublies "maintenabilité", "interopérabilité", "pérennité" Et la le résultat n'est pas le même...
[/quote]
Le DSK et tous les autres format supporté dans le PIC ? A non ça ce n'est pas possible Monsieur (rappel : http://hxc2001.free.fr/floppy_drive_emu ... SSUPPORTED ) J'ai du trancher de ce coté entre "facilité d'utilisation" vs "difficulté technique" Ce format permet surtout un support d'un nombre très important de cible avec un petit uC (là ça touche au prix).
"maintenabilité", "interopérabilité", "pérennité" ça le consommateur s'en fout un peu. Ce qu'il cherche avant tout c'est quelque chose qui fonctionne avec le minimum d'effort (prix & utilisation). Et effectivement le résultat ne sera pas le même ça c'est clair... (voir les remarques ci-dessus) De plus je ne tiens pas à m'enfermer dans un <<standard>> qui ne fera que poser des problèmes lors des évolutions softs/hardware (notamment en terme de ressource pour le gérer) et qui sera de toute façon obsolète à la prochaine version de hardware pour tout un tas de raisons. Les couches je les rajoutes quand il peut y avoir un intérêt. Pour ce cas je ne suis toujours pas convaincu.
Inscription : 28 Août 2008, 23:41 Message(s) : 258
Citer :
En parlant des dsk, Il existe 2 versions ("standard" et "extended") qui certes se ressemblent mais ne sont en aucun cas retro compatible. A un moment il s’est fait sentir le besoin de faire évoluer le format et cela à impliquer des modifications logiciels. Merci pour l’exemple
De rien.. tu ne fais que confirmer ce que j'ai écrit. Si on n'a que deux formats DSKs qui ne sont pas compatibles c'est très peu, surtout au vu des évolutions du format, puisque la seconde mouture a été faite justement dans l'idée d'en faire un standard évolutif et rétro compatible. Ca prouve qu'un format standardisé peut ensuite être utilisé par des dizaines d'émulateurs toutes plateformes confondues et prendre en compte de plus en plus de choses (notamment certaines protections)
Citer :
Franchement j'y crois peu : le fait définir un protocole ne va en aucun cas le faire adopter par les autres.
C'est faux. DSK, YM, AYC, PT3... la liste est longue! (j'oubliais HFE)
Citer :
En ce moment c'est plutôt la mode du je réinvente la roue...
C'est plutôt l'idée que donne ce système non normalisé que tu indiques vouloir mettre en place et qui implique que chaque programme sur chaque plateforme connaisse ton émulateur dans telle version...et pas celui d'un autre. Rien qu'accéder à la piste 255 pour faire des choses particulières avec l'émulateur pourrait être standardisé (d'ailleurs je ne sais toujours pas comment le no de secteur est filé à l'émulateur)
Citer :
Et dans ce domaine (les petits devices style emulo floppy) encore plus.
Il n'y aurait pas tant de monde et projets sur le sujet si ça n'avait pas son importance.
Citer :
Remarque : exFAT c'est préconiser pour les SDXC et non pas pour les SDHC....
C'est vrai. Mais SDXC est bien à SDHC ce que SDHC est à SD. Une évolution technique. Avec des drivers, donc, qui seront capables de gérer du FAT16, FAT32, ....et ex-FAT...
Citer :
J'imagine que les DSK et les HFE qui en résultent, c'est pas de la génération spontanée sur la carte...
Citer :
Oui d'ou ma remarque par rapport à ce retour d'expérience.
Justement, cette réponse n'a pas de sens. Il faut obligatoirement un système informatique pour créer et écrire les HFE sur la carte.
Citer :
beaucoup de gens utilisent le soft Windows pour la conversion de leurs images à la réception de l'emulo, ensuite ils ne l'utilisent plus et manipulent uniquement les hfe comme des dsk. En passant par ce système tu supprimes cette possibilité, et là ça va poser un problème.
Ils continueront à utiliser Windows, Linux, ... pour copier les fichiers sur une carte mémoire! Que ça pose problème est loin d'être une évidence! D'abord car un format HFE occupe nettement plus de place qu'un DSK Quid des émulateurs Cpc désormais capables de lire des DSK Zippés... Ensuite les transferts HFE <> DSK seront toujours d'actualité Qu'un soft soit dédié à ces échanges sur une plateforme évoluée n'est pas si contraignant.
Citer :
Oui mais en faisant cela tu oublies quelque chose : La notion d'image disparaît puisque tu n'as plus qu'un gros fichier de 1Go.
Certes... Tu l'as dit toi-même, c'est plus simple à faire. Et sans doute plus rapide à traiter.
Citer :
Tu seras obligé de passer par un logiciel spécialisé pour cela... Un comble pour du standard
Ce qui n'est pas standard, c'est la façon dont tu as décidé d'organiser tes données dans la carte géré par la version de ton émulateur (c'est bien toi qui a parlé des gens qui réinventent la roue) Vu qu'il faut mettre des HFE dessus, tu as toi-même posé la contrainte originelle. Que des gens manipulent des HFE ou pas, ils seront toujours obligé de passer par une machine contenant des DSK Parceque justement la navigation pose un prb au niveau des machines HOTES, c'est là qu'il faut standardiser!
Citer :
Impossible de supprimer/copier/stocker les "images" de manière standard justement c'est à dire avec un explorateur classique :
Contrainte négligeable.
Citer :
Regardes notamment du coté des musiciens.
Ceux qui utilisent ce genre de système savent parfaitement ce qu'est une application ou un fichier! D'autant plus qu'ils ont du préalablement faire des conversions hfe!
Citer :
Le DSK et tous les autres format supporté dans le PIC ? A non ça ce n'est pas possible Monsieur
Et personne ne te le reproche. Car il était plus simple, plus optimisé de faire un système propriétaire pour ton émulateur, et tu l'as fait.
Citer :
"maintenabilité", "interopérabilité", "pérennité" ça le consommateur s'en fout un peu.
Ben voyons. Ca signifie en gros qu'à la moindre évolution, faut tout recompiler et débogger partout (maintenabilité), relivrer des versions pour tout le monde, avoir un soft différent pour chaque émulateur qui veut gérer une liste de sélection (interopérabilité), et risquer de se retrouver avec un système qui ne marche plus dès qu'un nouvel émulateur sort (pérénité)... En tant que consommateur, ça a une incidence.
Quant à la "difficulté d'utilisation", je trouve plus "facile d'utilisation" d'avoir un soft qui gère l'import/export des données sur un système propriétaire (conversion hfe en prime à partir de n'importe quel format) que de dire à quelqu'un d'utiliser un outil pour convertir ses fichiers, les stocker, et ensuite les transférer.
D'ailleurs pour avoir aussi la version USB via PC, c'est bien ainsi que ça fonctionne, mais je ne t'apprends rien. Je préfèrerais grandement avoir UN seul soft sur CPC qui marche avec les deux émulateurs. Ce qui serait parfaitement faisable. Par exemple que le CPC via l'interface normalisée accède à un dossier d'images.
Citer :
De plus je ne tiens pas à m'enfermer dans un <<standard>> qui ne fera que poser des problèmes lors des évolutions softs/hardware (notamment en terme de ressource pour le gérer) et qui sera de toute façon obsolète à la prochaine version de hardware pour tout un tas de raisons.
C'est faux. On parle d'une normalisation d'échanges par rapport au DRIVE émulé avec un format rétrocompatible et évolutif. Ce qui va évoluer, c'est bien le HARD/SOFT de stockage sur la carte. Et ça c'est loin d'être rétrocompatible. (quid des partitions que tu éludes à chaque post)
Bref, j'ai exprimé mon avis. Tu ne démordras pas du tien et étant donné que c'est toi qui a créé cet émulateur tu fais ce qui bon te semble. Un software spécifique à ton émulateur sur CPC, ATARI, ... va exister et il ne sera compatible avec rien d'autre. Je reste convaincu que c'est une erreur conceptuelle
Dans un autre sens, Longshot, Jeff avait probablement ses contraintes et ne pouvait se permettre de supporter "nativement" les MSA, ADF, DSK, .. je comprends la nécessité de convertir les images disques au format natif.
Jeff, question bête, une fois qu'on a un HFE entre les mains, peut-on le convertir de nouveau en DSK ? (tu peux me répondre RTFM! et ce sera très correct )
Jeff, question bête, une fois qu'on a un HFE entre les mains, peut-on le convertir de nouveau en DSK ? (tu peux me répondre RTFM! et ce sera très correct )
Oui bien sur : l'HFE est pris comme toutes les images et peut être converti en DSK.
Un software spécifique à ton émulateur sur CPC, ATARI, ... va exister et il ne sera compatible avec rien d'autre. Je reste convaincu que c'est une erreur conceptuelle
Avec quoi veux tu que se soit compatible ? Les autres émulateurs utilisent soit des LCD, soit une connexion filaire avec la vidéo pour l'affichage et je doute que d'autre utilise cette voie assez contraignante.
Longshot a écrit :
Citer :
J'imagine que les DSK et les HFE qui en résultent, c'est pas de la génération spontanée sur la carte...
Citer :
Oui d'ou ma remarque par rapport à ce retour d'expérience.
Justement, cette réponse n'a pas de sens. Il faut obligatoirement un système informatique pour créer et écrire les HFE sur la carte.
Oui mais ce système peut être la machine hôte Il y a une version native pour Amiga sur le net.
Longshot a écrit :
Citer :
Oui mais en faisant cela tu oublies quelque chose : La notion d'image disparaît puisque tu n'as plus qu'un gros fichier de 1Go.
Certes... Tu l'as dit toi-même, c'est plus simple à faire. Et sans doute plus rapide à traiter.
Oui mais contraignant à l'utilisation.
Longshot a écrit :
Citer :
Tu seras obligé de passer par un logiciel spécialisé pour cela... Un comble pour du standard
Ce qui n'est pas standard, c'est la façon dont tu as décidé d'organiser tes données dans la carte géré par la version de ton émulateur (c'est bien toi qui a parlé des gens qui réinventent la roue) Vu qu'il faut mettre des HFE dessus, tu as toi-même posé la contrainte originelle. Que des gens manipulent des HFE ou pas, ils seront toujours obligé de passer par une machine contenant des DSK Parceque justement la navigation pose un prb au niveau des machines HOTES, c'est là qu'il faut standardiser!
Je ne vois pas ou la navigation pose problème?
Longshot a écrit :
Citer :
Impossible de supprimer/copier/stocker les "images" de manière standard justement c'est à dire avec un explorateur classique :
Contrainte négligeable.
ça c'est toi qui le dit! Tous le monde n'est pas forcement de cet avis.
Longshot a écrit :
Citer :
"maintenabilité", "interopérabilité", "pérennité" ça le consommateur s'en fout un peu.
Ben voyons. Ca signifie en gros qu'à la moindre évolution, faut tout recompiler et débogger partout (maintenabilité), relivrer des versions pour tout le monde, avoir un soft différent pour chaque émulateur qui veut gérer une liste de sélection (interopérabilité), et risquer de se retrouver avec un système qui ne marche plus dès qu'un nouvel émulateur sort (pérénité)... En tant que consommateur, ça a une incidence.
Penses tu réellement que les gens réfléchissent à ça ?
Longshot a écrit :
Quant à la "difficulté d'utilisation", je trouve plus "facile d'utilisation" d'avoir un soft qui gère l'import/export des données sur un système propriétaire (conversion hfe en prime à partir de n'importe quel format) que de dire à quelqu'un d'utiliser un outil pour convertir ses fichiers, les stocker, et ensuite les transférer.
En fait je ne vois pas bien la différence entre les deux...
Longshot a écrit :
D'ailleurs pour avoir aussi la version USB via PC, c'est bien ainsi que ça fonctionne, mais je ne t'apprends rien. Je préfèrerais grandement avoir UN seul soft sur CPC qui marche avec les deux émulateurs. Ce qui serait parfaitement faisable. Par exemple que le CPC via l'interface normalisée accède à un dossier d'images.
Bah par exemple avec la version USB c'est pas possible: pas de support en écriture -> communication unidirectionnelle.
Longshot a écrit :
Citer :
De plus je ne tiens pas à m'enfermer dans un <<standard>> qui ne fera que poser des problèmes lors des évolutions softs/hardware (notamment en terme de ressource pour le gérer) et qui sera de toute façon obsolète à la prochaine version de hardware pour tout un tas de raisons.
C'est faux. On parle d'une normalisation d'échanges par rapport au DRIVE émulé avec un format rétrocompatible et évolutif. Ce qui va évoluer, c'est bien le HARD/SOFT de stockage sur la carte. Et ça c'est loin d'être rétrocompatible. (quid des partitions que tu éludes à chaque post)
Pour les partitions ExFat dans 5/10ans (le temps que le format soit ouvert) -> Mise à jour matériel (le support des SDXC demande un gros proc ou un FPGA) & soft (s'il y a encore du monde sur CPC , et que les emulos floppy ont encore un sens)
Inscription : 28 Août 2008, 23:41 Message(s) : 258
Citer :
Oui mais ce système peut être la machine hôte Il y a une version native pour Amiga sur le net.
Rien n'empêche de normaliser également un système permettant via l'émulateur d'écrire sur la sdcard (ou une clef mémoire usb par exemple) sans qu'il soit nécessaire de développer un système contraignant sur la machine hôte connaissant fat16, ex-fat, ntfs ou tout autre format géré par le créateur de l'émulateur.
Citer :
Avec quoi veux tu que se soit compatible ? Les autres émulateurs utilisent soit des LCD, soit une connexion filaire avec la vidéo pour l'affichage et je doute que d'autre utilise cette voie assez contraignante.
Avec tous les autres émulateurs. Tu n'es ni le premier ni le dernier à plancher sur ce sujet. Qu'ils soient LCD, avec affichage vidéo, ou filaire, le prb est le même. Un seul soft qui fonctionne avec tous les émulateurs pour faire la même chose, à savoir ici récupérer les noms de fichiers gérés par l'émulateur sans avoir à connaitre la manière dont le gus qui a fait l'émulateur a décidé de stocker ses fichiers.
Pour le reste, je me suis déjà exprimé. Je vais donc éviter de troller davantage
Avec quoi veux tu que se soit compatible ? Les autres émulateurs utilisent soit des LCD, soit une connexion filaire avec la vidéo pour l'affichage et je doute que d'autre utilise cette voie assez contraignante.
Avec tous les autres émulateurs. Tu n'es ni le premier ni le dernier à plancher sur ce sujet. Qu'ils soient LCD, avec affichage vidéo, ou filaire, le prb est le même. Un seul soft qui fonctionne avec tous les émulateurs pour faire la même chose, à savoir ici récupérer les noms de fichiers gérés par l'émulateur sans avoir à connaitre la manière dont le gus qui a fait l'émulateur a décidé de stocker ses fichiers.
Pour le reste, je me suis déjà exprimé. Je vais donc éviter de troller davantage
Ah? première nouvelle ! Quel autre émulateur dialogue via l'interface floppy pour la sélection d'image? A ma connaissance aucun. Tous ceux que j'ai vu sont complètement autonomes dans le sens il n'y a pas d'interaction logiciel entre l'hôte et l'émulateur. La sélection se fait toujours par des moyens détournés : Afficheur LCD + bouton de sélections (Amiga Floppy Emulator, SIO2SD,etc), Affichage sur l'écran avec un "Hack" de dérivation des signaux videos (sdiskemul, TFE, UFE...), voir dérivation des signaux claviers pour remplacer les boutons de l'émulateur (UFE). Pour les émulateurs commerciaux c'est encore plus cheap avec simplement 2 boutons +/- et un afficheur numérique a led.
Je suis curieux de savoir qui travaille sur ce système.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 5 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum