Fonctionnement hard du LEP sur TO9

[__sam__]

Quand on lit un fichier K7 dans un émulateur on a pas besoin de respecter les delais (pas d'inertie mécanique par exemple). Mais Daniel a aussi un outil avec un automate sans doute similaire pour convertir les K7 en WAV. C'est dans un autre fil (dont j'ai paumé le lien, mais tout récent).

[Daniel]

C'est ce fil de discussion : http://forum.system-cfg.com/viewtopic.php?f=6&t=7706
Le format .lep a été créé spécialement pour permettre de faire des images de cassettes conformes à l'original, avec les séquences de synchronisation et les espaces entre blocs. Et surtout il restitue le signal en sortie du magnétophone. Dans le cas des cassettes TO c'est beaucoup plus pratique pour un émulateur d'avoir le niveau du signal TTL envoyé à l'ordinateur, plutôt que le signal audio enregistré sur la cassette.

[Tomix]

@__sam__
Pas besoin de respecter les délais, oui. Mais si la rom les attend, il faut bien les simuler quand même?
Il me semble qu'E815 décode chaque octet, pause et blocs de synchro compris, et c'est l'algo qui est derrière qui les interprète.
Je me trompe?

[__sam__]

@__sam__
Pas besoin de respecter les délais, oui. Mais si la rom les attend, il faut bien les simuler quand même?

Les roms sont patchées par un opcode illégal par tous les émulateurs sauf MESS. Ce point a été abordé ici

[Tomix]

@__sam__
J'en conviens. Mais le soucis, c'est que c'est E815 qui est patché. Et E815 lit et restitue chaque octet, y compris les octets des séquences de synchro d'un fichier qui font parti du file system de la k7.
L'algo qui appelle E815 doit s'attendre à ce que le file system corresponde au format qu'il connait. Du coup, si un fichier .k7 est compacté de manière à perdre ces séquences, et que l'émulateur patch juste E815, alors l'algo qui est derrière ne doit pas reconnaître ses petits.

Bref, à moins que tu me dises que les séquences manquantes sont interprétées par E815 quand on essaie de lire un octet et que, de ce fait, les données qui les caractérisent sont zapées par cette routine interne pour ne sortir que les autres octets, je pense qu'il faut forcément reconstituer ces données manquantes quand on appelle la routine de la rom.

Je raisonne en pure théorie. Tu auras compris que je ne connais pas vraiment le fonctionnement du LEP sur Thomson. Je débarque et je devrai en connaître beaucoup plus une fois que j'aurai implémenté le truc dans mon émulateur.
En contrepartie, je connais très bien la partie lecteur de disquette, c'est toujours ça.

[__sam__]

Il faut comprenre qu'il y a plusieurs niveaux : physique et logique.

La routine moniteur décode le flux série régulier de la K7 pour en sortir des octets. Chaque octet comporte 3 bits de plus sur le flux que ceux qui sont retournés. Ok ca tu avais vu. Typiquement les octets sont lus par les routines des jeux et du basic par paquet de 128 ou 256 * 11bits, soit tous les 128 ou 256 octets. Puis tous les 128/256 octets lus, le basic recopie le buffer ailleurs en ram avec la commutation de page et tout le bouzin hyper lent (tokenisation si le fichier en basic est au format ASCII). Si pendant ce temps là ton émulateur continue d'envoyer les bits en E7C3, ils sont perdus. Comment ca se passe alors en vrai ? Et bien sur la K7 pendant qu'elle tourne encore entre deux blocs physiques, il n'y a aucun bit pendant un certain temps (le delais en question, permettant au basic de faire ce qu'il a à faire avec le bloc lu. C'est cette pause là qui est manquante dans ton émulateur, et il faut la ré-introduire en devinant la fin de bloc dans le flux d'octets du fichier K7. Les émulateurs qui patchent les rom n'ont pas besoin d'avoir ces délais car la lecture du fichier K7 n'est pas synchronisée sur l'horloge. Les bits ne sont pas lu comme un flux régulier, mais l'octet décodé est lu du fichier K7 sitôt qu'on en a besoin. Si le basic met plus de temps entre la lecture de 2 octets à cause de la recopie du buffer en RAM, cela ne change rien. L'octet décodé ne sera pas perdu puisqu'il n'est pas synchronisé sur l''horloge Bref ca marche tout seul sans se compliquer la vie.

Ensuite au dessus de ces blocs physiques sur la K7 on trouve les blocs logiques du système de fichier thomson avec ses amorces etc. C'est le second niveau de décodage qui est lui réalisé par le basic. Ce niveau là a d'autre notions de blocs et d'autres octets amorces. Mais ca on a pas besoin de s'en occuper dans l'émulateur car ces blocs là ne sont plus synchronisés comme les octets et les blocs physiques.

L'algo qui appelle E815 doit s'attendre à ce que le file system corresponde au format qu'il connait. Du coup, si un fichier .k7 est compacté de manière à perdre ces séquences

La tu parle des en-tête du fichier logique (file-system). Ca ne sont pas eux qui sont manquants dans les fichiers K7. Ce sont les en-tête d'octets et les gaps inter-blocs physiques qui sont manquants dans les fichier K7 (et cela se passe au niveau des bits pas des octets).

Est-ce que tu vois à présent comment cela se déroule et pourquoi quand tu veux émuler les blocs physiques avec les fichier K7 qui ne contiennent que les octets logique, il y a un peu de travail avec un reconstitution des infos manquantes (le gap inter-bloc). C'est là où le format LEP de Daniel est pratique: c'est un enregistrement du niveau physique. Tous les bits à lire sont présents avec les infos de timing permettant d'émuler exactement les variations du bit de E7C3 pour un émulateur au bit près (et à la base pour la machine réelle). Ces fichiers sont bien mieux fichus que le fichiers K7 qui ne marchent bien que si on patche E815.

[Tomix]

@__sam__
C'est tout de suite limpide. Merci sam.

Question bonus: quel thomsoniste a inventé le format .k7?

[Daniel]

Sous toutes réserves, car je n'ai pas de preuves formelles :

- Le premier émulateur Thomson connu, FunzyTO7 de Sylvain Huet, est sorti, je crois, en 1996. Il utilisait le format .k7. On peut donc dire qu'il l'a inventé. Ensuite il y a eu plusieurs émulateurs MO5, dont FunzyMO5, Emul5, MarcelO5. L'un d'eux (ou peut-être plusieurs ?) a donné l'extension .k5 à ses images de cassette, mais en fait c'est le même format que les .k7

- Bien avant Sylvain Huet, mon fils avait développé un émulateur MO5 en 1992, mais ne l'a pas publié sur internet. J'avais écrit les programmes de transfert des cassettes MO5 sur PC par un port parallèle. Nous donnions l'extension .bin à ces images de cassettes. Il s'est avéré, quatre ans plus tard, que c'était le même format que les .k7 et .k5. Mon fils et moi sommes donc aussi les inventeurs du format, mais comme il n'était pas breveté et que Sylvain Huet ne le connaissait pas ça ne remet pas en cause sa paternité.

Les images de cassettes diffusées à l'époque n'étaient pas toutes alignées sur des octets. Elles contenaient bien des données sur 8 bits, mais ces 8 bits n'appartenaient pas forcément au même octet. J'ai écrit, à l'époque, un programme qui translatait les bits pour retrouver l'alignement sur les débuts d'octets.

- Ensuite mes émulateurs dcmo5, dcmo6, dcto7... puis dcmoto ont repris l'extension .k7, aussi bien pour les MO que pour les TO. Quand je les diffuse sur le site dcmoto j'ajoute en fin du nom de fichier le nom de la machine. Par exemple :
- xxxxxx_mo5.k7 est une cassette MO pour MO5. Elle fonctionne peut-être aussi sur MO6
- xxxxxx_mo6.k7 est une cassette MO pour MO6. Elle ne fonctionne pas sur MO5
- xxxxxx_to7.k7 est une cassette TO pour TO7 ou TO7/70. Elle fonctionne peut-être sur TO9, TO8, TO9+
- etc.

[__sam__]

Ca doit venir du 1er émulateur. Peut-être EmuTO7 de Sylvain Huet vers 1995, bref ça vient de polytechnique

[Daniel]

A la réflexion ce n'est pas Sylvain Huet, ni mon fils, ni moi, qui avons inventé le format .k7.
Il est plus juste de dire que Thomson (ou Microsoft ?) ont inventé le format, il a été baptisé .k7 ensuite par les auteurs d'émulateurs.

Dans le format .k7 il n'y a aucun ajout au contenu de la cassette Thomson : ni header, ni descripteur de bloc. Ce ne sont que les octets enregistrés sur la bande magnétique. C'est équivalent au format RAW pour une image de disquette.

[nicolho]

Oui, ça semble l'explication la plus juste : un fichier .k7 contient simplement l'ensemble des octets "encodés" dans la piste audio.

D'ailleurs tout ce qui été dit précédemment avait été abordé ces derniers jours sur le forum, avec notamment les discussions relatives au format .lep (et la manière dont les données contenues dans les cassettes sont réparties dans le temps à la sortie du magnétophone) et ce lien que je redonne 2 jours plus tard car il s'agit de la page "Cassette" de l'Encyclopédie DCMOTO qui raconte à peu près tout ce qu'il y a à savoir sur l'organisation des données sur cassette :
http://dcmoto.free.fr/forum/messages/591147_0.html
Je viens de regarder les premières lignes d'un fichier .k7 à l'aide d'un éditeur hexadécimal et par une simple observation octet par octet, on retrouve précisément ce qui est explicité dans cette référence.
En revanche, j'ai bien apprécié ce petit retour (pré?)historique sur les émulateurs et les thomsonistes de père en fils

[Daniel]

Dans ce cas précis ce n'est pas de père en fils mais de fils en père