J'attendrai de voir le résultat sur Youtube.
Ce sera pour la prochaine fois, et peut etre en vrai le 14 janvier. On aura plus le temps de voir tout ce que christian et jérome ont fait comme évolution sur la carte orix
J'ai pas eu le temps de regarder les enregistrements. J'espere que cela va aller. On a du faire une coupure au milieu des présentations car l'heure était dépassée.
Soit le compte google pour les assos permet de faire des meet + long, soit on passera sur teams la prochaine fois.
On n'a pas pensé à aborder le sujet des drives qui ne fonctionnent plus, zut.
14 janvier meet physique ?
Un lieu est défini ?
Oups, j'ai loupé la visu du 9 décembre à laquelle je souhaitais participer... dommage. 😔
Voilà, la vidéo est uploadée sur Youtube, en cours de vérification par le grand google.
Elle sera publique ce mardi à 19h. Le lien fuitera sur les réseaux sociaux et notre belle page facebook toute neuve à liker.
En ligne 🙂
A voir, commenter, liker, vous abonner et aussi liker la nouvelle page facebook du CEO (l'autre a perdu son histoire)
Merci pour la vidéo! 😎
Présentement, "Vidéo non disponible
Je viens de voir la vidéo et pour ceux qui se demandent pourquoi le jeu de caractères semi graphique est différent entre l'Oric-1 et l'Atmos, l'explication est la suivante.
Ce jeu de caractères n'est pas figé dans la rom comme le jeu standard mais calculé au démarrage de l'Oric.
La routine utilisée est la même pour les deux machines donc ce n'est pas un problème de décalage de bits qui serait fait une fois de plus ou de moins dans une rom et pas dans l'autre.
Le code "ASCII" du caractère est découpé en trois groupes de deux bits et à chaque groupe correspond un motif qui sera répété sur deux ou trois lignes
Code ASCII en binaire: x x c c b b a a
Caractère à l'écran:
A A A A A A B B B B C C C C C C
Où A A est le motif corespndant aux bits a a du code ASCII, idem pour B B et C C.
Les deux bits les plus à gauches ne sont pas utilisés dans le calcul.
Ce calcul est fait de la même manière dans les deux roms mais le motif correspondant à chaque valeur de bits est différent:
Oric-1 Atmos 00 . .| . . . . . . (#00) . .| . . . . . . (#00) 01 * *| * * . . . . (#F0) . .| * * * . . . (#38) 10 . .| . . * * * * (#0F) . .| . . . * * * (#07) 11 * *| * * * * * * (#FF) . .| * * * * * * (#3F)
En première colonne les quatres valeurs possibles pour deux bits, ensuite le motif correspondant pour l'Oric-1 et l'Atmos.
Un '.' représente un 0 et un '*' représente un 1, entre parenthèses la valeur de l'octet dans la table utilisée par la routine.
J'ai séparé les deux bits les plus à gauche car ils ne sont pas affichés à l'écran parce que on n'a qu'une matrice de 6x8 et non de 8x8 à l'écran.
On voit bien que les motifs de l'Oric-1 sont corrects si la matrice fait 8 bits de large, ce qui était vrai sur un bon nombre de machines mais pas pour l'Oric/Atmos.
Et on voit bien le déséquilibre observé sur l'Oric-1 par rapport à l'Atmos.
La rom de l'Atmos a donc été corrigée pour prendre en compte la spécificité de l'ULA et de son mode d'affichage.
À noter que seuls les caractères 0 à 63 sont initialisés par cette routine (jeu de caractères situé entre #B900 et #BAFF inclus, il reste donc potentiellement 16 autres caractères à définir avant d'arriver au début de l'écran TEXT en #BB80)
@assinie : Merci beaucoup pour ton détail technique précis et clair. Abordé durant l'échange mais très approximativement. Avec ton accord, j'ajoute ton explication claire et précise à l'article du mag.
En fait, pour l ORIC-1 ils ont oublié de recompacter les caractères LORES1 "8x8" prévu pour d'autres machines en "6x8" pour l'Oric. C'est ballot. 🤣
