Logicielsmoto.com

Il doit aussi être possible d'utiliser le lecteur K7 standard mais en jouant sur le nombre de salves de cycles à 6.3 et 4.5khz (de mémoire). La ROM Prédéfinie ces valeurs pour faire 900bauds exactement, mais si ca se trouve, la moitié de ces valeurs serait utilisable doublant la vitesse de chargement. Le hic c'est que si le nombre de salves est trop courte, la détection HARD des bits à 0 ou 1 devient moins bonne. Dans ce cas il faudrait prévoir un codage des bits avec un code correcteur d'erreur autorisant 1 ou deux bits faux.

Dans tout les cas il faudrait expérimenter pour voir ce que cela donne, par contre exit les émulateurs car aucun n’émule exactement le lecteur K7 (sauf peut-être MESS, mais c'est même pas sur).

L'idée n'est pas mauvaise, mais le gain est faible comparé au lecteur du MO5 qui a une bonne tenue en frequence jusqu'a 12-13 KHz et dont la seule fonctionnalité est de detecter les transitions et non les salves de frequences.

Toutefois, dans le mode "puriste", l'idee meriterait d'etre etudiee

Sinon, on peut se retourner sur le lecteur de disquette de premiere generation, c'est aussi un gadget qui meriterait de peter la limite des 80 Ko par disquette, ainsi que sa lenteur.

Pouf, ca en fait des trucs rigolos a essayer, y'a-t-il un thomsoniste dans la salle ?

Ah ça les idées, c'est pas comme le pétrole, on en a plein et ça coûte pas cher.Par contre c'est ici que le bât blesse... snif

Avec le LEP MO5, on peut sans difficulté lire et écrire des cassettes à 2400 bauds (comme le MO6). Il suffit de copier les fonctions d'I/O cassette de la ROM vers la RAM et de modifier les temporisations. On peut le faire aussi avec un LEP MO5 sur TO7 en utilisant ces mêmes fonctions. Je n'ai pas réussi à aller plus vite avec des cassettes, par contre en liaison directe PC --> entrée cassette Thomson on peut facilement doubler encore la vitesse. C'est probablement possible aussi avec un lecteur de CD, mais je n'ai pas encore fait l'expérience au delà de la vitesse standard. A 1200 baud la fiabilité est excellente, on doit donc pouvoir assez facilement aller 3 ou 4 fois plus vite.

il me semble que du temps où il y avait encore des développements pour thomson chez les éditeurs certains de ces éditeurs avaient déjà exploité la possibilité de relire les K7 TO sur MO et inversement pour faciliter les portages de softs.
Je pense l'avoir lu dans un numéro de TEO(phile), peut être à propos d'infogrames mais je ne m'en souviens plus exactement...

_________________
http://www.alternative-system.com

Exomizer est en effet la référence en ce moment sur plusieurs machines et en particulier l'Amstrad CPC que je connait assez bien

Je l'avais compilé en C (il y a un bout de code C fourni avec, en plus du code 6502) avec c6809, mais l'assembleur généré était assez moche pour décider que c'était mieux de le faire à la main.

En ce qui concerne le chargement sur cassette, il y a OTLA sur Spectrum qui atteint les 13000bps, mais pas sur une vraie cassette... Là aussi il va falloir traduire le code en 6809
http://code.google.com/p/otla/

On peut faire mieux sur Sinclair, mais pas sur vraie cassette (mais ca marche avec un lecteur de CD), la demo Rezurrection (http://www.youtube.com/watch?v=ztkQMjdPtuQ sur Sinclair ZX-81 charge les donnees a environ 28000 bits/s.

Mais attention a la confusion des genres : les lecteurs Thomson sont numeriques, alors que les autres machines de l'epoque travaillaient directement avec les signaux analogiques de la bande.

Avec la ligne cassette sur thomson et un PC en liaison directe (port serie ou parallele), on peut monter a 115200 bits/s, ca n'a pas grand interet, c'est un signal TTL.

Tout le probleme est de determiner les limites en frequences et la latence des lecteurs. Pour appliquer l'idee de Sam, la doc cofadel du mk90-90 fournit une partie de la reponse grace aux schemas et aux captures d'oscilloscope. On voit clairement sur ceux-ci qu'en reduisant le nombre de periodes a 6.3 et 4.7 KHz, on va augmenter la cadence mais on attenue aussi la sortie des detecteurs d'enveloppe. Il faut determiner quelle est la limite pour que le comparateur reste sensible aux sorties des detecteurs.

Sur MO5 c'est un peu different. Tout le barda a ete remplace par un simple filtre ecreteur dont la sortie est directement mise en forme. La limite depend de la sensibilite de la partie filtre.

Pour contourner le defaut de sensibilité sur les frequences elevees, deux techniques additionnelles sur MO5 viennent a l'esprit:

1. enregistrer des sinus plutot que des ondes carrees (je me mets dans un contexte creation d'une image depuis un PC), car les carres induisent des harmoniques et un feedback indesirables sur les transitions, et les sinus seront tout aussi bien detectes par le lecteur -> augmentation de la qualite de l'enregistrement

2. baisser la frequence des transitions, ce qui semble aller a l'encontre de notre but, mais en fait non : tous les codes modernes sur disque dur sont bases sur ce principe et je pense que les codages les plus simples comme MFM ou (2,7) RLL (http://en.wikipedia.org/wiki/Run_Length_Limited) auraient un role a jouer pour nous. Probleme : on risque de pas reussir a ecrire un code assembleur assez rapide pour les decoder.

ps. pour ceux qui n'auraient pas plante un oscilloscope sur une carte mere de PC recemment, ca fait bien 10 ans que les signaux ne sont plus carres sur les bus.

Pour le décodage, il serait peut être possible de coder 2 bits à la fois comme le fait OTLA, ou même peut être 4. ça implique de reconnaître 4 ou 16 "symboles" différents au lieu de 2 (le 0 et le 1); mais ça évite beaucoup d'opérations fastidieuses pour reconstruire des octets.

En ce qui concerne le traitement des signaux sur d'autres machines, l'écrétage n'est pas fait dans le magnétophone, mais en général il est fait dans l'ordinateur, ce qui revient au même à peu de choses près.

Je ne suis pas d'accord

Premierement l'etage de mise en forme sur Thomson est bien mieux fichu que sur la plupart des autres machines de l'epoque : plusieurs ampli-op avec filtres vs. une resistance et un condo relie a une patte TTL sur Sinclair par exemple.

Deuxiemement, le fait que la conversion se fasse au plus pres de la tete de lecture/enreg, permet d'eviter tous les soucis lies a la qualite du cable entre la machine et le lecteur externe.

Troisiemement, pas besoin de se faire *bip* avec le bouton du volume et le niveau d'enregistrement est toujours maximal, mais sans saturation.

Et pour avoir personnellement bricole de l'Apple II, du Sinclair, du Tandy et de l'Alice, oups, j'ai senti la difference.

Cela etant dit, j'ai toujours trouve que l'approche sur TO7 etait mauvaise, tout simplement parce qu'un simple souci avec la vitesse de defilement de la bande rend celle-ci illisible, ce qui n'est pas le cas sur MO (ou disons, beaucoup moins).

Il me semble que sur mon lecteur K7 de TO, il y a une petite vis pour régler justement la vitesse de défilement de la bande. Mais de toute façon comme le moniteur génère des signaux carrés (en sortie direct depuis le TIMER), on peut compter sur la présence de nombreuses harmoniques impaires très fortes pour compenser l'inexactitude de la vitesse (les signaux carrés ne décroissent pas très vite en fréquence: l’harmonique n (impair) a une intensité 1/n).

Sinon c'est vrai que la présence de deux détecteurs hardware est un choix théoriquement bon (je sens que les ingénieurs ont pris le pied sur ce principe), mais pratiquement mauvais:

- pas possible de bidouiller
- plus cher à fabriquer
- impossibilité de remplacement par un magneto standard

En effet... je comparais plutot le MO5 avec le CPC 464 dont le lecteur de cassettes est interne et donc assez fiable. Je n'ai pas regardé s'il y avait un système un peu poussé de remise en forme du signal dedans, tiens... J'vais vérifier

Pour ceux que ca intéresse, j'ai fait un plugin pour l'outil XnView permettant de visualiser les fichiers thomson MAP directement sur PC. Les formats 40 colonnes, bitmap 4, bitmap 16 et 80 colonnes sont supportés. Pour l'installation il suffit de mettre le fichier XThomsonMap.usr de l'archive XThomsonMap.zip dans le dossier Plugins de XnView (le source est inclus dans le ZIP pour les curieux).

Pour le moment seule la lecture est possible, mais il doit être possible d'étendre le plugin pour qu'il convertisse n'importe quelle image PC au format MAP. Affaire à suivre...

Attention le lien est un lien cjoint. Il ne dure pas très longtemps , si quelqu'un sait comment ajouter le zip ici, merci de m'indiquer la procédure.

Edit du 9 Janv. 2013: correction des couleurs pour le mode BM4 suite au bug trouvé par W_oo_d.

Edit du 5 sept. 2014: Attachement du plugin à ce message pour ne plus le perdre parce que c-joint a fait du ménage.

Vous avez tous certainement entendu parler de Skyrim. C'est vrai que les images en millions de couleurs nécessitant une carte graphique de dernière génération font baver. Je me suis posé la question de voir ce que ca donnerait sur MO6/TO8/9/9+ et leurs moyens graphiques limités. Et bien la surprise est que les images rendent vraiment bien sur nos machines! J'ai fait un petit ZIP avec 2 diskettes à utiliser en simultané qui présente un slideshow d'images récupérées sur le réseau.

Pour se mettre en appétit, voici ce qu'on peut obtenir sur nos petits thomson dans le format 40colonnes 16couls.



Le moins qu'on puisse dire, c'est que les contraintes de proximités ne sont pas vraiment un soucis quand on a une bonne palette. Le circuit palette est vraiment un truc super, et je doute que les autres ordis de l'époque (CPC, oric, ...) puissent fournir des images aussi belles (les mêmes images en palette fixe to7 donnent un rendu beaucoup moins joli).

Hum.. et dire qu'à l'époque je trouvais les capture écrans de Geste d'Artillac magnifiques... je n'ose imaginer l'ambiance qu'on pourrait créer avec un tel jeu remis au gout du jour avec des images à couper le souffle telles que celles présentées ici.

Sam.

Impressionnant pour des images Thomson Reste plus qu'à écrire le scénario et le moteur du jeu
Puis-je ajouter la disquette aux autres démos d'images, à la page Programmes du site dcmoto ?

Euh, il y a une face B sur tes disquettes ?
Car ton programme essaie d'y accéder et fait une "I/O Error in 460" s'il n'y en a pas

(j'ai testé avec le HxC floppy emulator, donc le problème est peut être de mon côté...)