Emulation Hector II HR.MX

[yo_fr]

Au passage : Si quelqu'un c'est déjà penché sur le schéma de Micronique (Hector1/HR+/HRX...)

... bon après pas mal d'essais et de lecture de la rom ainsi que du schéma, j'ai enfin trouvé le fonctionnement ! le signal son de la tête de lecture passe par quelques circuits qui font dans l'ordre :
* Ampli / Trigger : mise au propre du signal,
* bascule D : changement d'état du bit Data K7 à chaque periode (attention au respect de la phase du signal à ce point)
* d'autre part : avec un signal à 16KHz (15,65KHz sur mon HRX) on entre dans le compteur 74393 qui boucle à l'infini,
* On entre les 7 bits de poids faible de ce compteur + le bit d'état de la periode de la cassette en adresse 0x3000
* Dans le programme de lecture bit (ROM) on attend le basculement du bit d'état periode cassette, puis lors du changement d'état de ce bit on récupére le compteur (7bits) on le soustrait à la valeur précédente (ce qui donne donc le temps de la periode en cours),
* Selon le temps mesuré => 0 ou 1 !

Je ne suis pas sur que cette explication serve à quelqu'un d'autre qu'à moi, mais bon... ayant trouvé la réponse ...
Bref la lecture cassette fonctionne à 99% sur MESS pour un Hector ! (reste quelque réglage pour fiabiliser les conversions)

[yves]

bravo !

[Daniel]

C'est très bien d'avoir fait cette étude, qui complète les lacunes de la documentation

Dchector n'émule pas la cassette à ce niveau de détail. Il se contente de détourner la routine de lecture d'un octet pour lire dans le fichier .k7.

C'est toujours le même débat : à quel niveau de détail doit se situer l'émulation
Les deux approches ont des avantages et des inconvénients et je suis incapable de dire quelle est la meilleure. L'idéal est d'avoir les deux solutions, le module de mess est donc un excellent complément à dchector.

[yves]

personellement j'avais essayé d'émuler partie le plus fidèlement possible mais je n'avais pas été aussi tenace que yo_fr, je m'étais également rabattu sur l'alimentation des registres du z80 nécessaires à faire "croire" à la lecture d'un octet

Yves

[yo_fr]

Les deux approches ont des avantages et des inconvénients et je suis incapable de dire quelle est la meilleure.

...Effectivement dans la solution d'émuler entièrement l'électronique, la machine est peut-être "mieux" respectée mais dans ce cas précis le prix à payer est élevé :
* Un fichier de donnée sous dchector fait quelque Ko, un fichier wav fait 10 à 20 Mo !
* Temps de chargement identique à la machine de base (1 à 2 minutes) et ne peut être réduit...
En revanche il n'y a pas besoin de détourner les ROM de la machine : protabilité plus facile sur les autres machines du même moule (toute la famille Micronique-Hector)

En fait ce n'est pas un choix de ma part mais bien une nécessité de part la structure de MESS, ou de ma méconnaissance de l'environnement de MESS...(ce qui est possible )

Bref la question de Daniel est toujours sans réponse...

Pour info j'ai mis en place le sn76477 dans MESS, mais les 1er sons obtenus sont loin d'être convaincant ! je creuse encore, notament sur l'influence des tensions appliquées pin 16, 19 (et 23 capa pour le one-shoot). Je pense que je ré-ouvrirais mon pauvre Hector bientôt pour mesurer ces tensions..A suivre.

[Daniel]

* Temps de chargement identique à la machine de base (1 à 2 minutes) et ne peut être réduit...

Dans certains émulateurs il y a une option permettant d'accélérer la vitesse du processeur pendant la lecture de la cassette. On peut ainsi réduire le temps de chargement à quelques dizaines de secondes. Je ne sais pas si c'est possible dans MESS

Dans dchector le problème est inverse : la lecture de la cassette est trop rapide, et dans certains jeux l'écran de présentation n'est pas affiché assez longtemps pour le voir. C'est pourquoi j'ai ajouté une option pour ralentir la lecture. Mais avec ou sans l'option la vitesse de chargement n'a aucun rapport avec la vitesse réelle.

[yo_fr]

Dans certains émulateurs il y a une option permettant d'accélérer la vitesse du processeur pendant la lecture de la cassette. On peut ainsi réduire le temps de chargement à quelques dizaines de secondes. Je ne sais pas si c'est possible dans MESS

Effectivement, en dopant un peu le processeur et surtout le compteur 74393 de 16KHZ (à 32Khz ou même 64KHz) cela fonctionne !
par contre dans Mess je n'ai pas la possiilité de lire un sample plus rapidement, je dois donc re-sampler l'échantillon x2 ou x4 plus vite. Cela permet donc de passer d'un wav :
* Normal : 9,2Mo -> 1'47
* x2 : 4,6 Mo -> 54s
* x4 : 2,3 Mo ->27s
Double avantage donc (temps de chargement et poids wav)
PS : J'ai pas essayé au dela de *4 => il y a de forte probabilité que cela se passe mal...

[yo_fr]

Question pour les possesseurs (heureux possesseurs!) d'un Hector MX 80c : J'ai mis en place le fonctionnement du MX dans MESS et j'ai voulu contrôler la taille de l'écran avec un programme simple en basic 3X :

Code : Tout sélectionner

5 mode 1
10 wipe
20 for x = 0 to 243 *2
30 for y= 0 to 231
40 plot x,y
50 next y
60 next x

mais il me semble que le basic 3X soit bugée : les points au delà de 256 en X, finissent en IV error. La boucle se traduit donc par :

Code : Tout sélectionner

5 mode 1
10 wipe
20 for x = 0 to 243
30 for y= 0 to 231
40 plot x,y
50 next y
60 next x

Qui de toutes façon ne trace qu'un point sur 2 !
J'ai essayé sur la version preview de Daniel et le bug est le même ! Bref un contrôle que

Code : Tout sélectionner

plot 400, 0 

se termine également par un IV ERROR. sur le vrai MX80c

PS pour Daniel : Je traçais les sorties sur les ports lorsque en essayant une rom du MX j'ai capté un out 41h... J'ai donc pu retrouver l'agencement des rom en partant de celle ci comme base ! Par contre je ne trouve pas sur votre site (ou un autre) les ROM du MX40c...

[Daniel]

Par contre je ne trouve pas sur votre site (ou un autre) les ROM du MX40c...

Fabien me l'a transmise directement par messagerie, mais il est certainement d'accord pour la diffuser, alors je viens de l'ajouter à http://dchector.free.fr/telechargement/ ... or_rom.zip
De mon côté je n'ai pas eu assez de temps pour finaliser la nouvelle version de dchector, ni pour mettre à jour le site avec toutes les nouveautés, mais ça va venir dans les prochaines semaines.

Pour éviter de rechercher, voici la routine de dchector pour traiter les sorties sur les ports. Si je ne me suis pas trompé, la commutation de pages rom est effectuée par les ports 40, 41, 42 pour le MX80 et 40, 41, 44 pour le MX40. J'ignore pourquoi il y a une différence entre les deux machines, mais c'est ce que j'ai constaté.
A noter aussi l'écriture sur les ports 48 et 49 pour changer la resolution du MX80.

Code : Tout sélectionner

void OutZ80(word w, byte c)
{
 //F0= port A
 //F1= port B
 //F2= port C
 //F3= port de commande
 switch(w)
 {
  case 0x40: rombank = rom; break;
  case 0x41: rombank = rom + 0x4000; break;
  case 0x42: rombank = rom + 0x8000; break; //mx80c seulement
  case 0x44: rombank = rom + 0x8000; break; //mx40c seulement
  case 0x48: resolution = 0; break;
  case 0x49: resolution = 1; break;
  case 0xf0: if(ioport[0xf3] == (char)0x8a) Imprimeoctet(c & 0xff); break; //sortie imprimante
  case 0xf3: ioport[0xf3] = c; //registre de commande du 8255
             if(c == 0x04) cartindex = 0;
 }
}

[fneck]

... mais il est certainement d'accord pour la diffuser, alors je viens de l'ajouter

Mais tu as très bien fait

[yo_fr]

... mais il est certainement d'accord pour la diffuser, alors je viens de l'ajouter

Mais tu as très bien fait

Merci ! c'est maintenant dans Mess, soit HR2P, HRX, MX80C et MX40 fonctionnel !

[yo_fr]

La fin du signal de synchronisation est marqué par la séquence de bits 1 0 1 0 1 0

Je suis en train d'écrire la routine K7 => wav et avant de dessasembler des waves, je me posais la question : C'est bien cette séquence qui apres les cycles de synchro se trouve avant les données ? (avant le codage du 1er octet d'un fichier *.K7 ?)

[Daniel]

C'est bien ça : Chaque fichier comporte un signal de synchronisation (bits à 0), suivi de la séquence 1 0 1 0 1 0, suivie des blocs du fichier. La séquence 1 0 1 0 1 0 permet non seulement de détecter le début des données, mais aussi de s'aligner sur une frontière d'octet.

Pour décoder le fichier wav il faut détecter cette séquence, et ensuite lire les octets du fichier. Le fichier lui-même est décomposé en blocs de longueur variable, mais il n'est pas nécessaire de connaître la structure des blocs. La routine en rom de l'hector se charge de l'interpréter.

[yo_fr]

Je suis désolé de revenir à la charge, mais je pense qu’il y a confusion sur le type de machine ayant ce type de start :
Pour les types d’ondes, je pense que chez Micronique il y en ait 3 :
• Synchro
• Zéro
• Un
Dans le livre « Monitrix » (site d’Yves) on y trouve :
Synchro = 1,5ms ; Zéro = 0,4 ms et Un = 0,9 ms
Sur une cassette j’ai mesuré (le jeu commercial FORMULE1)
Synchro = 1,75ms ;
Zéro = 0,61 ms et
Un = 1,13 ms
D’autre part il me semble qu’entre les blocs se trouvent également des signaux de synchro. Ces signaux de synchro, pour moi, doivent permettre de laisser le temps au processeur de réaliser les tâches demandées par le bloc de la TOL. Les différentes fonctions de la TOL sont décrites dans le guide des routines HRX (page 16- site d’Yves) et certaines doivent, à mon avis, prendre un peu de temps par exemple :

BLOC FE : Bloc de remplissage
FE, adresse, longueur, valeur
Ce bloc permettra, à la lecture de la cassette, de remplir une zone mémoire
avec une constante.

En début de cassette FORMULE1 on trouve :
05 00 40 A0 09 FE 01 00 05 DB 5F 02 00 FF…
Soit 2 blocs :
Le premier avec code 05 (non documenté dans le guide des routines ROM) doit surement faire un effacement de l’écran (4000 @ écran BR, 9A0 : taille écran BR)
Le deuxième : avec le code de remplissage (lui défini dans le guide) adresse 1000 (@ code couleur) longueur (BD50 ???) code 02. Puis un bloc de data avec FF.
Pour ces 2 types de blocs il faut surement laisser le processeur réaliser l’opération, qui de toutes façon se font « à la volée » et pas à la fin (au chargement du jeu l’écran s’efface puis les couleurs changent puis un dessin d’accueil apparait puis chargement du programme en lui même).
Lorsque l’on ouvre le fichier wav, avant le FE on trouve quelques ondes à 1,5ms. De même avant le FF.
Au vu de tout cela, je pense qu’il y a donc confusion de machine sur le processus cassette
EDIT 16h41 : J'ai confondu le code prog des bloc de TOL et les octets effectivement écris sur la cassette... les blocs ont la longueur inscrite dans le 1er octet du bloc et il faut donc inserer des synchros entre les blocs pour faire la conversion... ce qui fonctionne !
Je confirme donc mon postulat de départ : il n'y a pas de 1 0 1 0 1 0 inscrits mais bien des synchros puis immédiatement suivi par les données dans des blocs avec des synchros entre les blocs... et la suite décrite plus haut se lit : 05 : 1ere bloc de 5 octets puis 1 bloc de 1 octet puis un autre de 5 octets...

[yves]

salut,

je n'etais pas venu depuis qques temps:

oui il y a 3 types d'ondes: Synchro, zero, un.

Chaque programme est précédé d'environ 4000 à 8000 cycles de synchro. Pour les enregistrements il ne faut pas moins
de 400 cycles de synchro avant le programme.
Chaque bloc de données est suivi de 4 ou 8 cycles de synchro qui est le même pour tout le programme (je n'ai pas réussi à savoir pourquoi 4 OU 8 ) .


Dans les blocs de données:
Le premier octet est la longueur de bloc à lire. Si 00 alors il y a 255 octects à lire.

Et effectivement, pour reprendre ton exemple:
En début de cassette FORMULE1 on trouve :
05 00 40 A0 09 FE 01 00 05 DB 5F 02 00 FF…

Le 05 est la longueur, le bloc à lire est donc FE 09 A0 40 00, puis 00, puis FF 00 02 5F DB, etc....

Yves