Depuis l’avènement des fichiers WAV, l’Oric a connu plusieurs nouveaux modes de chargement cassette accélérés: TAP2CD, F16, … En voici un petit nouveau, dont la gestation m’aura bien occupé !

Je vous présente Novalight, qui se veut le mode de chargement cassette Oric le plus rapide à ce jour de février 2019. Son nom a été choisi en hommage à deux regrettés disparus. Twilighte tout d’abord, qui a programmé tant d’outils, jeux et démos pour Oric, en essayant souvent de garder ses jeux Oric compatibles avec le format cassette. Paul Woakes ensuite, un non-Oricien disparu en 2017. Il a été le co-fondateur de la société de jeux vidéo Novagen, auteur de l’excellente série Mercenary, et créateur de NovaLoad sur Commodore 64… NovaLoad étant précisément un mode de chargement cassette rapide, très répandu à l’époque !

Tout est parti au début sur une idée de compresser le signal cassette au niveau des bits (plutôt qu’au niveau des octets). Après des simulations sur 5 ou 6 façons de faire, il est apparu que la plus régulièrement efficace est celle… Qu’utilisait déjà TAP2CD de Fabrice ! Novalight doit donc son épine dorsale à TAP2CD: il lui emprunte cette “compression”, ainsi qu’un principe de fonctionnement par interruptions, indispensable pour analyser suffisamment finement la durée des sinusoïdes du signal audio. J’aurais presque pu l’appeler “TAP2CD2” ! Côté outil PC, Novalight est un dérivé direct (mais bien modifié) des outils existants comme TAP2WAV.

Fabrice a apporté, comme toujours, un soutien régulier; il est fort probable que sans son aide le projet n’aurait pas vu le jour. Il me faut remercier également les Oriciens sur les forums Oric.org et Defence-Force.com, qui ont pris de leur temps pour tester diverses beta-versions et donner des conseils.

Quelles différences entre TAP2CD, F16 et Novalight ?

Commençons à situer entre eux les chargements “turbo” existants. On pourrait les hiérarchiser ainsi:

– F16: le plus lent des trois, il a l’avantage d’accélérer les chargements pour tous les Oric (Oric-1 et Atmos), et ne nécessite aucun loader ! C’est en fait une optimisation du signal audio pour les routines existantes en ROM.

– TAP2CD: très, très rapide, TAP2CD nécessite une ROM 1.1. Il utilise un loader et sera très fiable à partir du moment où votre liaison audio est de bonne qualité

– Novalight: reprend les principes de TAP2CD, mais en les poussant aux limites quasi-maximum et en ajoutant une compatibilité ROM 1.0. Il sera donc plus rapide que TAP2CD, mais au détriment de la fiabilité: il faut une connexion audio et un player de WAV d’excellente qualité (Audacity ?), et certains Oric au hardware un peu fatigué, malgré tout, ne seront pas compatibles. A noter que Novalight gagne un peu de temps sur le chargement de son loader… En utilisant le format F16 puis en se chargeant en partie lui-même au format Novalight 😉

Novalight va se loger en page 1, sous la pile, et laisse assez peu de place à cette dernière: 54 octets. Attention à l’utilisation dans un programme donc, éviter de faire trop d’appels à des sous-programmes !

Comparatif des vitesses Loader + Programme

	slow	Fast standard	F16	TAP2CD	Novalight
Zorgon  (37K)	?	4min 26s	2min 38s	31s	15s
Xenon-1 (37K)	28min	4min 15s	2min 31s	32s	12s
Acheron’s Rage (43K)	32min	5min 12s	3min 12s	40s	12s
Oricium (46K)	?	5min 31s	3min 27s	48s	18s
Voilier (Hires – 8K)	6min	56s	34s	8s	3s
Cercle (Hires – 8K)	?	1min 03s	42s	11s	2s
Ecran TEXT (1K)	?	10s	6.5s	5s	1.5s

En détail, les modifications et ajouts par rapport à TAP2CD

– les périodes de base servant à encoder 2 bits dans le signal (fichier WAV), sont passées de 4, 6, 8, 10 samples, à 3, 4, 5 et 6 samples. Cela a sans doute été le travail le plus difficile: bien souvent ces durées raccourcies n’étaient pas correctement reconnues par les Oric, dont certains prenaient l’une pour l’autre. Il a fallu tester toutes formes de sinusoïdes pour voir laquelle permettait au mieux à un maximum d’Oric de distinguer correctement ces quatre durées. Au final quelques Oric avec un VIA fatigué n’arriveront jamais à décoder correctement ce signal. C’est LA limite de Novalight, TAP2CD sera plus fiable à ce niveau.

– des statistiques ont été effectuées et ont montré que dans les programmes Oric, on utilise environ 60% de bits à 0, et 40% de bits à 1. La période la plus courte a donc été utilisée en priorité pour encoder “00”, alors que dans TAP2CD elle servait pour “11”. Le gain ne sera pas systématique, il s’agit vraiment d’une statistique…

– une compression RLE a été ajoutée: si un octet est répété plusieurs fois à la suite, il n’est encodé qu’une seule fois, et sera suivi par le nombre de répétitions. Dans le signal, un octet répété N fois se traduit donc par cet octet, suivi de (N-1) sinusoïdes de 3 samples, puis une dernière sinusoïde de 4 samples qui marque la dernière répétition (et leur fin donc).

– création de dictionnaires: avant de créer le signal, le fichier TAP est analysé et on repère les octets non répétés (échappant à la compression RLE donc), qui occupent la plus grande place dans le signal. Les 14 octets avec le plus grand nombre d’occurrences sont placés dans deux tableaux de 7 octets chacun, chargés en page 2 avec l’en-tête du programme. Les octets de chaque dictionnaire bénéficieront d’un encodage particulier, plus rapide qu’un octet normal: une seule sinusoïde de 3 à 9 samples.

– les bits de stop ont été supprimés, l’Oric travaille pendant le bit de start. Et ce bit de start devient porteur d’information: s’il dure 5 samples, ce qui suit est un octet normal. 6 ou 7 samples, c’est un octet à chercher dans un des deux dictionnaires. Enfin 8 samples: ce qui suit est une répétition d’octet (RLE). Pourquoi pas moins de 5 samples ? Parce que c’est pendant cette durée que l’Oric assemble les bits et met en mémoire l’octet précédent. Il faut quand même lui laisser ces 115 microsecondes pour cela; on pourrait donc dire que les bits de stop ne sont pas vraiment supprimés, mais regroupés avec le bit de start 😉

ROM 1.0: l’horrible bug d’affichage du Loading en HIRES n’affectera plus les écrans que vous chargerez !

Si on arrivait à faire en sorte que l’Oric travaille plus vite, on pourrait raccourcir ce bit de stop. Mais le code a été tordu dans tous les sens pour minimiser les sauts et autres “pertes de temps”. Au final quand défilent les bits, l’Oric doit, dans toutes les situations, travailler en moins de 69µs (3 samples, période la plus courte pour encoder “00”) pour être certain de ne pas rater une information; et en fin d’octet, pour assembler en plus l’octet et le placer en mémoire, travailler donc en moins de 115µs.

– pour son loader, Novalight utilise le format F16 plutôt que le format standard, ce qui fait gagner environ 1 seconde. Ensuite il inverse la valeur des bits, pour encoder des 1 (plus courts) à la place des 0 (plus nombreux); gain environ 10% de temps. Enfin le loader Novalight est découpé en morceaux: un “noyau” chargé en vitesse F16, qui peut charger le reste de son code à la vitesse Novalight sans compression, sous forme de banques. Chaque banque contient le code nécessaire au moment voulu (compression, fin de programme, etc.).

– Ce système de banques permet de gagner de l’espace mémoire, suffisamment pour permettre de rendre Novalight compatible Oric-1 et Atmos

– En bonus, le chargement des écrans Hires n’est plus abîmé sur Oric-1 par l’affichage de “Loading” au beau milieu du dessin. Le CLOAD de la ROM va commencer par afficher ce bug, mais il sera effacé par l’écran chargé, lequel ne sera ensuite plus altéré à la fin du chargement.

Mise au point

La mise au point de Novalight s’est étalée sur plusieurs années, non sans difficultés. Le principe est le suivant: quand une sinusoïde se présente, le VIA (6522) détecte un signal (front montant), et envoie une interruption à l’Oric. Lors du front montant suivant, l’Oric calcule le temps écoulé entre ces deux sinusoïdes. Cette durée est comparée à des seuils (des bornes, donc) qui lui permettent de déterminer si la sinusoïde valait 3, 4, 5 samples (etc.). Problème : la valeur de cette durée, mesurée par l’Oric, diffère légèrement d’une machine à l’autre. Et donc les seuils à utiliser pour l’encadrer diffèrent aussi un peu selon chaque Oric.

Ainsi le programme, s’il veut tourner sur tous les Oric, devrait soit gérer ces variations (autocalibration: test sur la machine et adaptation des seuils), soit utiliser des valeurs qui seront communes à tous les Oric et Atmos. La calibration nécessitant trop de temps d’exécution et de place dans le programme, il a fallu étudier le cas d’un maximum de machines pour tenter de déterminer des seuils moyens, communs à tous. J’ai pu tester régulièrement Novalight sur 3 à 10 machines, plus l’aide ponctuelle de testeurs sur les forums Oric ou par email, sur 4 ou 5 autres machines. Sur les 10 régulières, seule une machine est récalcitrante, il faut dire qu’elle ne doit pas être en forme: même avec des seuils personnalisés, elle n’est pas capable de distinguer à chaque coup entre 3 et 4 samples. Deux autres machines nécessitent un volume sonore minimal pour fonctionner, les autres un volume maximal. Comme d’habitude donc, le volume semble être un paramètre essentiel et aléatoire d’une machine à l’autre !

La difficile recherche des seuils communs à plusieurs Oric et aux émulateurs, en fonction des formes d’ondes.

Compatibilité ROM 1.0

Initialement, Novalight ne fonctionne que sur ROM 1.1, avec un loader de 218 octets. Impossible de faire l’équivalent sur ROM 1.0, programmée de façon moins modulaire que la ROM 1.1. Il aurait fallu reproduire de longs morceaux de la ROM, ce qui aurait pris trop d’octets.

L’idée est donc venue petit à petit: créer un “noyau” Novalight, permettant, sur toute ROM, de charger à vitesse accélérée mais sans toutes les options (compression et dictionnaires absents); puis des “banques” (de 40 à 60 octets) chargeant des morceaux de code à exécuter ensuite. Au final Novalight utilise un noyau chargé en 2 parties, et 4 banques. La place ainsi gagnée a permis d’écrire du code compatible Oric-1 et Atmos !

L’avantage “bonus” est que le loader initial est plus court, donc plus rapide à charger. Les banques se chargeant à vitesse “Novalight réduite” sont beaucoup plus rapides à charger. Au final, le loader se charge en moins de 0,7 seconde. Le revers de la médaille est pour les programmes en plusieurs parties: il faut recharger le loader à chaque fois, car les banques écrasent le code initial.

Le fichier WAV sera donc construit avec une succession de programmes à charger:

Loader (vitesse standard ou F16): initialisations du VIA, des interruptions, et chargement de la suite du loader

Suite du loader contenant les instructions de chargement des banques  (vitesse Novalight “lente”)

En-tête du programme (vitesse Novalight “lente”)

Banque 2 (vitesse Novalight “lente”): affichage Loading etc., et chargement de la suite

Banque 3 (vitesse Novalight “lente”): chargement de la compression RLE et des dictionnaires Novalight

Programme (vitesse Novalight maximale)

Banque 4 (vitesse Novalight “lente”): réinitialisation du VIA, des interruptions, lancement du programme chargé

Afin de garder un peu de  flexibilité, une option existe dans Novalight pour utiliser l’ancien loader: ROM 1.1 uniquement, mais il n’est pas utile de le recharger à chaque fois. Cela peut être utile, par exemple, pour faire des slide-shows ou des animations.

La surprise Oric

Les tests ont été l’occasion d’avoir une petite surprise.

C’était presque ça ! Try again…

Pour être très rapide, une des idées de Novalight est que l’Oric doit rester synchronisé avec le signal audio du début à la fin. Le signal audio numérique se déroulant à vitesse parfaitement constante, il “suffit” que l’Oric travaille assez vite pour lire les informations et les traiter avant de lire l’information suivante… Il se trouve que sur un Atmos particulier, j’avais des erreurs, d’abord prises pour des erreurs de calibration des seuils. Mais rien n’y faisait… La conclusion a fini par s’imposer: le traitement du dictionnaire était un peu long, et passait sur certains Atmos, mais pas sur celui-ci quand il était appelé plus de 3 fois de suite ! Il était donc exécuté plus lentement, trop lentement ! Et déphasait doucement le signal audio et l’Atmos, qui finissait par perdre une information. Autrement dit, et ça a été ma surprise: tous les Oric ne travaillent pas exactement à la même vitesse !

En réduisant un peu la durée de traitement du dictionnaire, tout est rentré dans l’ordre… Comprendre le problème aura pris plusieurs jours !

La surprise PC

Autre surprise sur laquelle je me suis arraché les cheveux… Le PC (sous Windows XP), au bout d’un certain temps de fonctionnement, ne semble plus générer un signal audio aussi propre qu’après le boot ! Un de mes Oric en prend ombrage et ne charge plus les programmes, alors que tout va bien sur les autres…

En cas de doute, appliquez la règle universelle: rebootez l’ordi qui lit le WAV !

Utilisation

En ligne de commande : Novalight [ -option1 ] [ -option2 ] <.TAP ficher en entrée> <.WAV fichier en sortie>

Il existe bien entendu des options:

-s  ‘standard speed’: utiliser la vitesse standard au lieu de la vitesse F16 pour le loader (plus lent, mais certains Oric supporteraient mal la vitesse F16 ?)

-o  ‘old loader’: utiliser l’ancien loader ROM 1.1-seulement au lieu du nouveau compatible 1.0/1.1. L’ancien a un avantage: il peut être chargé une seule fois, puis appelé plusieurs fois par un CALL#100, tant qu’il reste intact bien sûr. Vous pourrez ainsi charger plusieurs programmes ou écrans sauvés au format Novalight sans loader. Mais adieu la ROM 1.0 donc.

-n  ‘no loader’: génère les WAV Novalight sans y ajouter de loader. Il vous faudra charger un ‘old loader’ d’abord puis utiliser CALL#100 pour charger chaque WAV ainsi constitué. ROM 1.1 seulement.

-p  ‘long pause’: génère un silence de plusieurs secondes après chaque programme sur le WAV. Raison ? Les programmes ERE Informatique, par exemple, nécessitent du temps pour dessiner l’écran de chargement; c’est dommage si le WAV démarre avant que l’Oric ait fini son dessin…

Novalight affichera, pour chaque programme converti, le dictionnaire utilisé pour la compression, ainsi que des statistiques de compression. Vous verrez que certains programmes y sont peu propices, alors qu’un écran HIRES presque vide sera quasi-totalement compressé, et donc très, très rapide à charger.

 

Où trouver Novalight

Vous devriez trouver Novalight sur la disquette du magazine à télécharger. Y sont inclus des sources; C pour le programme MS-DOS, et assembleur pour le loader Oric. Attention toutefois, ce n’est pas normalisé et je n’ai rien nettoyé, ne soyez pas surpris… Mon assembleur est autodidacte et donc plein d’astuces rédactionnelles perso, et je vois surtout ces fichiers comme des brouillons desquels il aurait été dommage d’effacer certaines idées. Le C néanmoins, devrait compiler comme il faut !

Un petit fichier mp3 est aussi là pour l’anecdote: quand une idée arrivait subitement, je m’enregistrais pour ne pas l’oublier, tout en espérant l’exposer clairement pour qu’à la réécoute, elle reste compréhensible ! J’ignore si ça peut être rigolo à écouter, ou si ce sera totalement pénible, à vous de me dire si vous en avez le courage 😉

Il est aussi possible de récupérer Novalight avec les autres outils cassette de Fabrice:

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

Zorgons Revenge à la moulinette Novalight: un seul programme, moyennement compressé.

N’oubliez pas les impératifs:

– liaison audio au top, et aucune perturbation audio pendant la lecture (téléphone sans fil, sons sur l’ordi qui joue le WAV, Wifi ?, …)

– ne surtout pas modifier le WAV ou le convertir dans un autre format: chaque sample compte

– lecteur de WAV à 44kHz, au top (la moindre approximation, et c’est l’échec)

– il reste la possibilité que votre Oric ne soit pas compatible

Snif, la fin !

J’espère que vous pourrez profiter de Novalight sur vos Oric-1 et vos Atmos. C’est pour moi la fin d’un long projet passionnant, de plusieurs années, à créer des outils pour faire des mesures, des statistiques, à réfléchir à la compression, à réduire la taille du code, à l’accélérer, à échanger avec les Oriciens, … Et j’espère qu’un jour quelqu’un fera mieux – plus rapide ou plus fiable, voire les deux !

Tests de signal sur l’Atmos de Chema, début 2018.

Merci pour leur aide, tests et conseil, à…

Fabrice, FredV60, Musepat, Kenneth, Dom50, Voyageur, Oric1-Atmos, Froggy, Godzil, DrPsy, ISS, Chema, Dbug, NekoNoNiaow.

Annexe 1: séquence de chargement du loader Novalight dans la pile, puis du programme.

Annexe 2: Format du WAV, et séquence de chargement du loader Novalight, puis du programme.

Codage WAV	Contenu loader normal
3000 samples	Silence d’intro, au cas où un player “mange” le début du signal. 0,07s.
F16	30 octets de synchro (surtout pour la même raison que le silence qui précède)
F16	header et nom de programme = au nom du programme dans le .TAP
100*3 samples	Gap: bits de stop pour laisser le temps à l’Oric de travailler
F16	$13E-14A – 13 octets: code pour inverser les bits des octets qui suivent
F16, bits inversés	$14B-$1BD – Common Area 1 et décodage de base Novalight (sans dictionnaire ni compression RLE) 115 octets, inverser les bits permet de gagner 10% de temps (les 0 étant encodés plus lentement que les 1 en F16) Détail: $14E-$14F: saut pour exécuter la “Common Area 1” $150-$15C: interruption de lecture du signal $15D-$18F: décodage d’un octet Novalight “normal” (non compressé RLE, et hors dictionnaire) $190-$1C0: “Common Area 1”: initialisation du VIA, mise en place de l’interruption Novalight, chargement de la “Common Area 0”
500 samples	Silence pour séparer les programmes (purement visuel). 0,0115 secondes. Réduire cette durée affecte la compatibilité Euphoric.
100*3 samples	Synchro Novalight
Novaligth “basique” (sans compression RLE ni dictionnaire), octets inversés	$100-$14C – Common Area 0 77 octets, du dernier au premier (permet au code de chargement d’être plus compact). A noter: écrase la partie précédente $141-$14F, devenue inutile. Détail: $100-$117: chargement du header (et du dictionnaire) du programme à charger $118-$120: chargement et exécution de la “Common Area 2” (affichage du Loading, gestion du Hires et du bug de la ROM 1.0) $121-$128: chargement de la “Common Area 3” (gestion de la compression RLE et du dictionnaire Novalight) $129-13A: chargement du program principal, 100% Novalight $13B-$145: chargement et exécution de la “Common Area 4” (restauration des interruptions et du VIA, lancement du programme chargé) $146-$14F: sous-programme de chargement des “Common Area”
30*3 samples	Petit gap
Novaligth “basique”	30 octets de synchro ($16)
Novaligth “basique”, octets inversés	$292-$2BF – En-tête du programme + dictionnaire 46 octets, du dernier au premier (permet au code de chargement d’être plus compact). Contient les infos du programme à charger (header classique) + les dictionnaires de 14 octets les plus répétés dans le programme (pour la compression)
Novaligth “basique”, octets inversés	$18D-$1BA – Common Area 2 46 octets, du dernier au premier (permet au code de chargement d’être plus compact). Détail: Affichage du Loading, gestion du Hires et du bug de la ROM 1.0: si l’écran est en Hires, on n’affiche pas le Loading, et on évite ainsi une ligne avec des points blancs.
100*3 samples	Synchro Novalight
Novaligth “basique”, octets inversés	$18D-$1C9 – Common Area 3 61 octets, du dernier au premier (permet au code de chargement d’être plus compact). Détail: $190-$1BB: décodage d’un octet du dictionnaire $1BC-$1CD: décodage d’octets compressés RLE
Novalight	Programme à charger (fichier TAP), à vitesse maxi ! (avec compression RLE et dictionnaire).
2*9 samples	Marqueur de fin de programme
100*3 samples	Synchro Novalight
Novaligth “basique”, octets inversés	$18D-$1C4 – Common Area 4 56 octets, du dernier au premier (permet au code de chargement d’être plus compact). Détail: Restauration des interruptions et du VIA, lancement du programme chargé.
2*3 samples	Pour terminer la synchro Novalight
15000 samples	Silence de fin, au cas où un player “mange” la fin du signal.