TEO 1.8.2

[fneck]

Si vous voulez que j'héberge un fichier sur le site, c'est tout à fait réalisable, il suffit de me le faire parvenir.

[gilles]

je vais l'héberger chez moi en attendant de le mettre proprement sur sourceforge.

ici:
http://www.precise-data.fr/temp/teo-1.8 ... x86_64.rpm

[Jeff_HxC2001]

@jeff:
il s'agit ici de gérer le sous ensemble nécessaire à l'émulation thomson. C'est vrai qu'il est souvent préférable de passer par une librairie mais dans ce cas précis (et au moment où le dev a été lancé), cela collait assez mail à la structure du code de l'émulateur et au but recherché.

Dommage ...

Le format HFE évolue sans préavis, et les anciennes versions pourrait devenir incompatibles avec les nouveaux firmware. (migration possible via le soft HxC.)
Le format HFE est conçu pour la version PIC du HxC Floppy Emulator et n'a pas la vocation d'un format d'archivage.

Si le but est de récupérer le flux MFM, la lib permet de faire cela et pas seulement avec le format HFE

Vous pourrez, si vous le voulez, m'envoyer vos disquettes HFE copiées avec CC90HFE par mail afin, selon l'expression consacrée, d'en faire profiter la communauté. Elles seront alors publiées dans la rubrique Logiciels sur le site LogicielsMoto.

Voila ce que je crains... Utilisation d'un format très spécifique a une famille d'émulo HxC pour de l'archivage...

[gilles]

Je comprend tes objections par rapport au projet HxC mais après avoir pesé le pour et le contre cela restait tout de même la solution la plus cohérente.
Dans les arguments pour il fallait trouver un format riche en information mais pas excessif en taille et en complexité de traitement (ce qui élimine les formats exotiques comme le format stream du kryoflux (qui n'est pas un format adapté à l'écriture)). L'autre gros argument pour est de passer de l'émulation au matériel réél simplement par copie de fichiers sur la carte SD. Enfin il était exclu de réinventer encore un nouveau format spécifique.
Dans les arguments contre il y a l'évolutivité non maîtrisable du format mais qui est contrebalancée par la base matérielle déjà installée (une modification de firmware qui rendrait inutilisable les fichiers des utilisateurs serait une très mauvaise chose). L'utilisation d'une librairie n'apporte pas de réelle solution à ce problème.
Et il faut bien comprendre le but de la chose, il s'agit de contenir les formats thomson dans des format image adaptés (c'est à dire adaptés à la préservation de certaines techniques de protection par formatage spécial). Ce n'est probablement pas transposable à toutes les plateformes.

[Jeff_HxC2001]

Dans les arguments contre il y a l'évolutivité non maîtrisable du format mais qui est contrebalancée par la base matérielle déjà installée (une modification de firmware qui rendrait inutilisable les fichiers des utilisateurs serait une très mauvaise chose).

Et bien croyez moi que nous n'allons pas hésiter une seule seconde : Le format HFE a déjà évolué plusieurs fois et évoluera encore.
Pas question de gérer directement dans le PIC toutes les versions passées... Il y a un soft pour faire la transposition.
Ne pas oublier ceci : Le header de ces fichiers est: "HXCPICFE" et l'extension HFE signifie HxC Floppy Emulator. Le format est spécifique à la version pic du HxC et évolue avec le firmware.
Encore une fois il ne s'agit pas d'un format d'archivage mais un format adapté au mieux pour fonctionner avec le matériel du HxC version PIC actuel.

L'autre gros argument pour est de passer de l'émulation au matériel réél simplement par copie de fichiers sur la carte SD.

J'ai le sentiment qu'il va y avoir de grosses déceptions sur ce point à l'avenir... Et c'est bien là que le problème se pose de mon coté...

Enfin il était exclu de réinventer encore un nouveau format spécifique.

C'est un format hyper spécifique

[Daniel]

La mise en garde de Jeff me semble très judicieuse.

J'y ajoute un argument personnel :
Les formats spéciaux utilisés pour la protection des disquettes Thomson sont en nombre très limité, on peut les compter sur les doigts d'une seule main. Le format HFE les prend en compte, c'est vrai, mais il a pour objectif de traiter tous les formats possibles (des milliers et peut-être plus). Pour Thomson on pouvait faire beaucoup, beaucoup plus simple. SAP était une très mauvaise idée : utiliser un format crypté pour coder le contenu d'une disquette empêche son exploration avec un éditeur hexadécimal. HFE pour TEO n'est pas mieux, c'est chercher à faire compliqué quand on peut faire simple. C'est un peu dommage, car par ailleurs TEO a bien progressé sous l'impulsion de Prehisto, en particulier pour l'émulation du contrôleur de disquette du TO8. L'émulation des imprimantes est également excellente, mais je ne sais pas si elle est très utilisée par le grand public. Il faudrait faire des sondages...

[Jeff_HxC2001]

L'idée d'utiliser un format "low level", c'est à dire au niveau encodage MFM, n'est pas forcement une mauvaise idée. Cela permet théoriquement de supporter l'ensemble des formats possibles. Mais évidement il faut que l’émulation implémente l'ensemble des sous fonctions FDC pour avoir un "bon retour sur investissement".
Le problème ici est juste le choix d'un format (HFE) qui ne devrait pas être vu comme un format d'archivage. Il ne s'agit pas d'un problème technique mais "d'environnement".

[gilles]

@jeff: oui mais rien d'autre n'existe qui soit ouvert, simple et déjà outillé. Manipuler des images kryoflux de dizaines de méga sans support de l'écriture n'a pas de sens dans le contexte thomson. A la rigueur il existe quelques format exotique d'images mais les outils sont vieux et généralement sous msdos uniquement (ou amiga).
Alors oui cela limite l'usage des images sur le matériel HxC a certaines versions du firmware uniquement mais en soi cela n'est pas un vrai problème. Dans la pratique c'est souvent le cas des projets généralistes où les évolutions vont à l'encontre des plateformes moins courantes et testées moins souvent.
Un format propriétaire n'est pas nécessairement un mauvais format, les problématiques d'émulation soft et hard vont présenter de nombreuses similitudes. Ce format est donc devenu le support de l'amélioration de l'émulation du contrôleur de disquette. Le jour où un format générique similaire émergera les fonctions de lecture/écriture de et vers ce format seront ajoutées.

@daniel: l'argument était valable de la même façon en 1998 pour le format SAP, il s'agissait du travail personnel d'Alexandre Pukal dans le but d'archiver les disquette thomson, ce format permettait d'être porteur d'informations de protection utiles à l'émulation et à la préservation des images originales sans avoir besoin de les pirater. Ce format est toutefois obsolète car l'outillage permettant de créer les vraies images avec information de protection a disparu.

[Daniel]

Dans le format SAP, il y a une bonne chose et une mauvaise. Vous avez abandonné la bonne (l'indication des protections) et gardé la mauvaise (le cryptage). Il eut été plus judicieux de faire l'inverse.

Il serait encore mieux d'avoir une image de disquette "physique" permettant une émulation sans astuce pour déjouer les protections. L'idée de Jeff (niveau encodage MFM) est à retenir. Les utilitaires Thomson écrits par les membres de l'ASCI pour traiter les disquettes protégées utilisent cette méthode (voir en particulier les programmes de dump de disquettes et le copieur CC++). C'est probablement la meilleure solution : simple et efficace.

[gilles]

Dans le format SAP, il y a une bonne chose et une mauvaise. Vous avez abandonné la bonne (l'indication des protections) et gardé la mauvaise (le cryptage). Il eut été plus judicieux de faire l'inverse.

L'historique n'est pas aussi simple que cela. La protection n'a jamais été abandonnée de TEO elle existe encore mais les outils de transfert sont toujours resté la propriété exclusive d'Alexandre, c'est son savoir-faire, seule la partie générique a été reprise dans sap2.
Le cryptage (qui n'est qu'un crc relativement simple) ne peut pas être abandonné pour des raisons de compatibilité avec l'existant et par respect pour les utilisateurs. Pour les autres émulateurs et outils de transformation open source il y a une librairie.

Il serait encore mieux d'avoir une image de disquette "physique" permettant une émulation sans astuce pour déjouer les protections. L'idée de Jeff (niveau encodage MFM) est à retenir. Les utilitaires Thomson écrits par les membres de l'ASCI pour traiter les disquettes protégées utilisent cette méthode (voir en particulier les programmes de dump de disquettes et le copieur CC++). C'est probablement la meilleure solution : simple et efficace.

C'est précisément l'idée qui nous a amené à utiliser ce format pour la nouvelle version de teo, par ailleurs j'en avais déjà parlé à Jeff en MP il y a quelques mois. Donc oui c'est une bonne idée et nous l'avons déjà mise en oeuvre. Après il s'agissait de trouver un format pour contenir ces données brutes, or le format actuellement le plus adapté est bien le format de travail de l'émulateur HxC et ce pour plusieurs raisons. D'une part c'est pratiquement le seul de ce type, et d'autre part il est outillé et fiabilisé, ce qui permet de ne pas avoir à avancer sur plusieurs fronts à la fois.

[Zaxxon]

Bonjour à tous,

@Gilles :merci pour les utilisateurs de fedora.

Je rebondis sur Teo en lui même (je ne parlerais pas des disquettes, etant plus un thomsoniste à k7 à la base), j'ai remarqué quelques problèmes d'affichages mineurs.

Sur Titus classiques 1 par exemple, j'ai remarqué que la boule du pacman clignote, j'ai vérifié sur un vrai TO7/70, je n'ai pas ce problème. je l'ai remarqué sur d'autres jeux également.

Par ailleurs, il y une fonctionnalité qui pourrait être sympathique, un mode plein écran. Dans ce cas un filtre de type 2xsai pourrait être envisageable. j'ai un code source qui fait le job entre deux surfaces sdl, ça devrait être portable à gtk.

Sinon l'émulateur fonctionne de manière nickel.

Bonne journée.

[gilles]

bonjour,
effectivement cela clignote un peu. Pour voir si c'est normal ou pas il faudrait brancher le vrai TO sur un écran à très faible rémanence, sur un écran de l'époque le défaut sera gommé par les caractéristiques de l'affichage.
Il est également possible que le défaut soit un artefact de l'émulation (prise en compte de la position du balayage pendant les mise à jour graphiques).
Le mode plein écran serait effectivement utile dans certains cas.