K7 nouveau format - testeurs demandés !

Hello,
Je bosse sur un outil appelé TAP2F16 pour ".TAP to Fast *1.6 speed". L'outil produit un WAV à 44kHz WAV qui, vous l'aurez deviné, chargera un programme environ 1,6 fois plus vite que les cassettes de l'époque. En gros un programme qui mettait 5 minutes à charger ne mettra plus que 3 minutes.

Mais pourquoi, vu que TAP2CD réalise déjà des chargements beaucoup plus rapides ?
Eh bien, TAP2F16 a l'avantage de se charger sur n'importe quel Oric, sans loader particulier, et sans modification de ROM. Donc il devrait fonctionner aussi bien sur Atmos et Oric-1, et peu-être (sans garantie à 100% cependant) charger certains programmes qui étaient incompatibles avec TAP2CD (Lone Raider par exemple).

Mais je n'ai pu pour l'instant faire de tests que sur un Atmos (ROM 1.1). Est-ce que de bonnes âmes pourraient faire un test de chargement sur un Oric-1 réel ? J'ai mis un ZIP du WAV de Lone Raider sur Defence-Force.
Bien sûr, vous pouvez aussi vous amuser à tester sur Atmos pour confirmer si cela fonctionne ou pas. Comme je joue vraiment avec les limites des routines de décodage de la ROM, tout test est bienvenu.

Merci d'avance

salut
J'ai testé sur mon Atmos et Oric 1
ça fonctionne pas : l'oric reste sur 'searching...'

Pour charger les jeux j'utilise un ancien iPod (2e génération, gros et tout blanc avec un disque dur) sur lequel je copie les fichiers WAV avec le volume à 70%
Tous mes jeux passent bien comme ça sauf peut-être un ou deux (j'ai eu des problèmes avec Mission Delta).
J'ai testé ton fichier tel quel et aussi en le convertissant an AIFF (pour faire plaisir à l'ipod) ou en variant le volume sonore . Mais rien n'a fonctionné pour moi.

patrick

Merci pour tes tests !
Mmmmh, c'est mauvais signe, soit tous les Oric ne réagissent pas pareil, soit il faut un player audio de qualité parfaite (et isolé: chez moi j'ai dû couper le Wifi pour ne plus avoir d'erreurs).

En revanche, reconvertir le fichier est un gros risque, chaque sample est vraiment calculé limite-limite

Je pourrai tester plusieurs machines le WE prochain en principe, ça orientera un peu sur la raison du problème. Encore merci

Hello,
Bon, j'ai fait un test sur Oric-1: succès
Chargement sans pb de Lone Raider, et de Zorgons Revenge.

Je vais préparer une release.
Froggy, il est probable que le matériel ou logiciel utilisé n'ait pas été assez précis dans ce cas particulier - ça arrive ! As-tu déjà fait des tests avec TAP2CD ?

oui. tous mes jeux sont comme ça : wav sur ipod. Tous fonctionnent (sauf Mission Delta) sur l'oric 1 et l'atmos.
Donc le câble est bon aussi.

froggy a écrit:oui. tous mes jeux sont comme ça : wav sur ipod. Tous fonctionnent (sauf Mission Delta) sur l'oric 1 et l'atmos.
Donc le câble est bon aussi.

Ok, mais je ne suis pas sûr d'avoir compris: le WAV est issu de TAP2CD ou TAP2WAV ?
Je demande car TAP2WAV c'est la routine "standard", donc robuste, alors que TAP2CD est une routine hyper-rapide et donc hyper-sensible.

Si TAP2CD marche bien avec ton matériel, alors TAP2F16 joue sans doute trop avec les limites et se retrouve trop rapide pour certains Oric.

Symoon: tu peux expliquer en quoi ton idée consiste?

Godzil a écrit:Symoon: tu peux expliquer en quoi ton idée consiste?

J'ai regardé la routine de décodage de la ROM, et j'ai réduit au maximum, dans le signal, la durée des sinusoïdes pour faire un "1" ou un "0".
Le signal standard code un 0 sur environ 624µs et un 1 sur 416µs. La ROM standard de l'Oric mesure cette durée et tape au milieu: "si c'est plus long que 512µs, c'est un 0; si c'est plus petit c'est un 1".
J'ai donc réduit dans le signal la taille du 0 de 624µs à (je ne sais plus exactement) une valeur proche de 520µs; quant au 1, il n'y a pas de minimum ! Les seules limites sont le hardware et la durée de décodage. J'ai donc mesuré la durée mini qui faisait réagir mon Atmos, qui s'est fixée à environ 69µs.
Mais c'est peut-être trop court pour tout le parc de machines ?
TAP2CD lui fixe le minimum à 92µs (mais comme il travaille en 22kHz, il ne pouvait pas faire 69µs )

Il faudrait faire des tests en masse sur différentes machines ptet; j'ai testé avec succès sur 3 machines ici.

Je me doutais que c'était une idee similaire, mais ce n'est pas con du tout

Je serait peut être un peu plus conservateur sur la longueur du 1, jai peur que certains patchs sur l'entrée cassette joue sur c'est timing (l'âge dès condensateur à cet endroit peu aussi avoir une influence) mais bravo pour l'idée!

Godzil a écrit:Je me doutais que c'était une idee similaire, mais ce n'est pas con du tout

Je serait peut être un peu plus conservateur sur la longueur du 1, jai peur que certains patchs sur l'entrée cassette joue sur c'est timing (l'âge dès condensateur à cet endroit peu aussi avoir une influence) mais bravo pour l'idée!

Je vais ptet ajouter un paramètre "old machine" qui ferait passer le 1 à 92µs ? Ou penses-tu qu'il faille encore plus ?
En + qui sait, ça permettra peut-être à Trouble In Store de se charger (routines spéciales, qui ne passent pas avec 69µs )

L'idée étant de conserver l'optimal pour les chanceux qui ont des machines en bon état, mais de permettre aussi aux autres d'accélérer un peu...
EDIT: ceci dit, la qualité du player influe aussi. J'ai dû couper le WIFI sur mon PC sinon ça ne marchait pas !

Est ce normal que le fichier ne charge pas non plus dans Oricutron ?

froggy a écrit:Est ce normal que le fichier ne charge pas non plus dans Oricutron ?

Je ne connais pas trop Oricutron, mais je dirais qu'il n'a aucune chance de marcher sur emulateurs ! En tout cas Euphoric, certain que non.
C'est vraiment de l'optimisation maximale pour machine réelle.

Symoon: je dirait qu'un paramètre pour le régler ne serait pas une mauvaise idée

Je pense que ta valeur est bonne mais certains Oric de pars leur âge peuvent avoir quelques soucis, je vais regarder sur le schéma ce qui pourrais être la valeur du "pire" pour ne pas perdre une transition

J'ai dit une bêtise !
Je suis pour un "1" sur 115µs: un calcul théorique (j'ai compté les cycles des instructions) m'a montré que je devais m'en sortir avec des "0" à environ 531 microsecondes (au lieu de 624 en standard), et des "1" à 115 microsecondes (au lieu de 416).

Le 69µs étant en revanche le minimum pour que l'Atmos réagisse avec une boucle qui ne fait qu'attendre un signal en entrée et en mesurer la longueur - donc le minimum "hard".

Donc avec cet outil, je suis déjà bien au-dessus des 69µs; je ne sais pas si tu me rejoindras das l'analyse Godzil mais du coup je penche plus pour un pb de qualité de lecture du signal (ou des perturbations ?) concernant les soucis de Froggy.
Bon j'ajoute quand même le switch "old machine" (138µs au lieu de 115).

EDIT: c'est curieux, j'ai testé avec 138µs et l'Oric n'aime pas du tout, j'ai plein d'erreurs alors que ça passe avec 115µs. Là je ne comprends pas
EDIT2: pb résolu, j'avais un déséquilibre sur le centrage de la sinusoide entre les 0 et les 1, mince c'est sensible ! J'ai donc aussi un peu rallongé les 0 et ça marche nickel.

Symoon a écrit:J'ai dit une bêtise !
Je suis pour un "1" sur 115µs: un calcul théorique (j'ai compté les cycles des instructions) m'a montré que je devais m'en sortir avec des "0" à environ 531 microsecondes (au lieu de 624 en standard), et des "1" à 115 microsecondes (au lieu de 416).

Le 69µs étant en revanche le minimum pour que l'Atmos réagisse avec une boucle qui ne fait qu'attendre un signal en entrée et en mesurer la longueur - donc le minimum "hard".

Donc avec cet outil, je suis déjà bien au-dessus des 69µs; je ne sais pas si tu me rejoindras das l'analyse Godzil mais du coup je penche plus pour un pb de qualité de lecture du signal (ou des perturbations ?) concernant les soucis de Froggy.
Bon j'ajoute quand même le switch "old machine" (138µs au lieu de 115).

EDIT: c'est curieux, j'ai testé avec 138µs et l'Oric n'aime pas du tout, j'ai plein d'erreurs alors que ça passe avec 115µs. Là je ne comprends pas
EDIT2: pb résolu, j'avais un déséquilibre sur le centrage de la sinusoide entre les 0 et les 1, mince c'est sensible ! J'ai donc aussi un peu rallongé les 0 et ça marche nickel.

Hehe

Bon j'ai regardé, c'est purement théorique, mais apriori meme avec les capa en mode "je suis vraiment pourrie" ca devrait marcher avec 60 a 100us sur tous les Orics. Si certains oric sont suceptible, ca ne viens pas des capas. Il faudrait regarder la tete des signaux sur une machine ou ca foire et determiner si c'est un des ampli op qui ne suit pas, ce qui est possible, il me semble qu'il ne sot pas tous du meme fabricant donc il peux y avoir des variations

Merci Godzil pour les infos.
Voilà, je pense avoir fini l'outil, vous le trouverez avec les autres Tapetools, plus précisément ici:
TAP2F16

Retours d'expérience bienvenus

J'ai modifié l'outil pour qu'il soit plus fiable, j'avais un peu forcé sur le signal.
C'est à jour en téléchargement.

Simon: en plus de ton codage adaptatif, tu devrais regarder du coté du codage de huffman, l'arbre peux etre généré a la volée avec ton outil de transfert, et faire partit des octet chargé par le chargeur rapide. L'avantage du codage de huffman c'est qu'au travers de l'utilisation d'une centaine d'octet en mémoire (l'arbre en lui meme) la décompression est très rapide (parcour d'arbre avec chaque bit lu, et une fois arrivé sur une feuille on sais quel est le caractère et on repart de la racine)

Je voulais faire une démo (je peux toujours) mais la motivation n'était pas la quand j'ai commencé donc elle attends toujours d'etre codé

Je pense que ca couplé avec un codage adaptatif tel que celui que tu as fait pour limiter le nombre de 0/1 pourrais permettre un bon taux de compression et de chargement, peux etre au point de dépasser tap2cd

Attention, j'étais sur 2 choses à la fois:
- le projet F16 (ce thread) où il n'y a aucun ajout, aucune routine, juste une forme de signal optimal pour les routines standard de la ROM
- et effectivement une tentative d'aller très vite, avec un résultat visible dans la vidéo, hélas trop aléatoire d'une machine à l'autre (voire même sur la même machine tant qu'elle n'a pas chauffé, sisi).

Je note l'idée, sachant que l'essentiel pour aller vite est la vitesse de décompression: pour être optimal l'Oric doit lire le signal et écrire qqchse en mémoire en moins de 50µs environ (valeur au doigt mouillé)

Mais avant de pousser plus loin, le truc étant instable, je vais d'abord chercher à fiabiliser et voir ce qui peut être compatible d'une machine à l'autre en terme de signal optimal. Ca va prendre du temps (tests pénibles), et hélas je suis de retour au boulot et le temps et l'énergie vont me manquer à nouveau

Symoon a écrit:Attention, j'étais sur 2 choses à la fois:
- le projet F16 (ce thread) où il n'y a aucun ajout, aucune routine, juste une forme de signal optimal pour les routines standard de la ROM
- et effectivement une tentative d'aller très vite, avec un résultat visible dans la vidéo, hélas trop aléatoire d'une machine à l'autre (voire même sur la même machine tant qu'elle n'a pas chauffé, sisi).

Je note l'idée, sachant que l'essentiel pour aller vite est la vitesse de décompression: pour être optimal l'Oric doit lire le signal et écrire qqchse en mémoire en moins de 50µs environ (valeur au doigt mouillé)

Mais avant de pousser plus loin, le truc étant instable, je vais d'abord chercher à fiabiliser et voir ce qui peut être compatible d'une machine à l'autre en terme de signal optimal. Ca va prendre du temps (tests pénibles), et hélas je suis de retour au boulot et le temps et l'énergie vont me manquer à nouveau

Oui je sais que ce sont deux projet séparé, mais il n'y a qu'un seul thread ici
Bon courage en tout cas Et je pense que quand il s'agit de l'Oric, quelque soit le projet, la patience est de mise, donc t'inquiète pas Tu as deja fait un enorme boulot, et en plus présenté des prototypes, c'est bien plus la pluspart d'entre nous, moi y compris..

Merci !
Ok je l'admets, mes titres de thread sont vaseux
Mais y'en a bien un autre
http://forums.oric.org/t343-toujours-plus-vite#4712