Pour rappel, HRC compresse un écran HIRES en RLE, et en fait un fichier .TAP qui s'auto-décompresse une fois chargé, en n'utilisant que 40 octets de mémoire + 4 octets en page 0.

La compression RLE codée ici est assez efficace car elle sait automatiquement détecter si l'octet rencontré est à afficher, ou est un compteur de répétition. Ainsi, pas besoin de stocker d'octet de répétition à "zéro" après chaque octet à afficher sans répétition.

Fonctionne sur ROM 1.1, et sur ROM 1.0 uniquement à partir d'une disquette (en raison du bug d'affichage des routines K7 1.0 en HIRES).

Nouvelle version de TAP2F16 (v1.2) disponible:

https://sourceforge.net/projects/euphorictools/files/Tape%20tools/Tap2F16/

Pour rappel, TAP2F16 permet de générer un fichier WAV à partir d'un fichier TAP, qui se charge sur n'importe quel Oric, sans routine spéciale, mais plus rapidement à condition qu'il soit lu par un lecteur numérique.

La v1.2 permet de choisir le nombre de bits de stop avec l'option -bX, où X est une valeur allant de 2 à 9. Par défaut, TAP2F16 reste à 3 bits de stop, comme la version précédente.
La nouvelle option permet:
- de charger des programmes qui ne fonctionnaient pas avec TAP2F16 1.1, en augmentant le nombre de bits de stop (cas de Trouble In Store, qui se charge finalement avec 9 bits de stop). On perd certes en temps de chargement, mais cela reste bien plus rapide que le signal standard.
- de réduire à 2 le nombre de bits de stop, et donc de gagner un peu de temps, pour les .TAP qui ne rencontrent aucune difficulté avec les 3 bits de stop habituels.

J'ai remarqué un petit "bug" dans OricHir. Rien de méchant a priori: les écrans sont sauvegardés avec une adresse de fin en BF40 au lieu de BF3F.

Mais là où ça se complique, c'est que ça semble se croiser avec un bug de la ROM 1.0.

Testez la chose suivante sur ROM 1.0:
- charger un écran HIRES se terminant en BF40
- taper en mode direct les instructions suivantes: CURSET99,99,1:I=1:CIRCLEI,1

Et là on obtient un ILLEGAL QUANTITY ERROR.
Si on repasse en mode TEXT après, on obtient ensuite des messages d'erreur "aléatoires", du genre OUT OF MEMORY ERROR.

Rien de tout ça ne semble arriver avec un fichier se terminant en BF3F ! Et sur ROM 1.1, tout va bien quel que soit le fichier.

Donc attention aux fichiers issus de OricHir si vous envisagez de les utiliser sur Oric-1, il faut raccourcir l'adresse de fin d'un octet. A priori, tout va bien dans ce cas (chance ?)
Je soupçonne les routines de chargement cassette, l'Oric à Nu page 276 indique divers bugs et je ne vois pas d'autre différence entre le test qui plante et ceux qui fonctionnent. 

P'tite question à ceux qui postent régulièrement des captures d'écran d'Oric : comment procédez-vous ? Vous faites ça sous Windows ? Avec Oricutron ? Vous devez faire de la "bidouille" ou il y a une fonction cachée ?

Merci d'avance de vos réponses.

@+

damien.

Antoine

Pour faire suite (9 ans après 😋 ) aux articles de Dominique dans le Mag sur le format des cassettes protégées par les routines spéciales Cobra Soft (Ceo-Mag 283 et suivants), voici un petit utilitaire qui permet de décoder le signal WAV à la place de WAV2TAP.

Il faut donc utiliser Wavclean (après la version 1.2 sinon ça ne marchera pas), puis Cobr2tap. Le TAP en résultant aura  conservé toutes les protections de Cobra Soft, à part les fameux octets tantôt en vitesse lente, tantôt en vitesse rapide.

Et voilà ;-)

PS: attention, toutes les cassettes Cobra Soft ne sont pas protégées par ces routines spéciales. Donc à n'essayer que si Wav2tap a donné plein d'erreurs !

Ce n'est pas la première fois que j'ai un message d'erreur... il semble que le site mythique oric.free.fr qui relayait des utilitaires et euphoric ne soit plus en ligne. Quelqu'un a des news rassurantes ?