Hello,
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.
@Symoon : Merci beaucoup. Gràce à toi, je viens de remporter 2 victoires sur moi-même 🙂
1. J'ai trouvé le bug, l'ai résolu dans le C# source
2. J'ai recompilé et mis à jour la version corrigée dans le dossier CEOTOOLS https://github.com/club-europe-oric/DEVKIT_CEO. L'exécutable est facile à reconnaitre, il est daté.
Et j'ai mis le GIT original à jour. J'espère que je n'ai pas fait de betise
Si seulement je pouvais être aussi efficace pour d'autres sujets de ma todolist
@didier_v cool merci, quelle rapidité ! Je découvre de nouvelles fonctions par la même occasion.
Un outil qui fait gagner beaucoup de temps dans le design d'écran Hires.
Allez, au cas où tu t'ennuierais (ho ho ho), deux autres petites choses:
1- Bug pas gênant mais sans doute un peu plus compliqué: il me semble que les valeurs d'octet comprises entre 32 et 63 (en décimal) doivent afficher des pixels, mais que OricHir ne le fait pas. De même entre 160 et 191: on voit les 6 pixels en inverse, alors que normalement les 6 pixels affichables doivent être allumés ou non selon leur valeur.
Bon, ce n'est pas gênant à partir du moment où on le sait et où on n'a pas à faire des trucs complexes avec "je veux les mêmes pixels allumés mais avec ou sans le bit 6".
2- Bug: le nom de sauvegarde est limité à "moins de 16 caractères", donc 15 alors que 16 caractères sont acceptés par l'Oric ! (et même plus mais on ne va pas chipoter 😀 ).
En outre, à la sauvegarde, si on choisit un fichier de type .TAP, le "nom de chargement" (celui qui apparaît au LOADING) contient obligatoirement ".TAP", et ça c'est relou 😉 Parce que comme c'est déjà limité à 15 caractères, en fait on n'a plus que 11 caractères de dispo pour nommer son fichier sinon on déclenche le message "trop long" ! Ce serait bien de ne prendre que le nom avant extension pour le "nom de chargement".
Voilà voilà, je te laisse tranquille maintenant 😉 Merci encore pour le correctif.
