Oric Atmos problème de sortie vidéo

[ZodiacFR]

Bonjour à tous!


Ce WE je suis tombé sur les vieux Orics appartenant à mon père: un Oric 1 et un Oric Atmos du début des années 80.
Les deux sont en bon état de conservation mais l'Oric 1 ne semble malheureusement plus booter.
L'Atmos en revanche boote sans problèmes, et ses deux sorties vidéo fonctionnent.

Cependant il semble y avoir une erreur de buffer vidéo car l'invite de commande est composée des mauvais caractères (le "$" remplace " " par exemple)
En tapant au clavier on se rend compte que certaines touches (pas toutes) sont incorrectement représentées à l'écran.
Cela me semble être un problème purement vidéo car la commande "EXPLODE" fonctionne correctement, mais je vois affiché "E\TLOD" sur l'écran

Aucune des microchip ne surchauffe anormalement après plus de 15 minutes sous tension, pas de gonflement sur les condos ni aucune corrosion, et toutes les soudures que j'ai vu étaient en bon état.

Mes recherches sur les chips HCS 10017 (en charge de la vidéo de par sa position il me semble) et HN613128P n'ont rien donné de probant, et j'aimerai beaucoup pouvoir restaurer ce petit bout d'histoire qui ne manquerait pas de rappeller quelques bons souvenirs à mon paternel.

Merci d'avance

[kenneth]

Bienvenue sur le site.
A mon avis, l ula a du mal a lire la mémoire pour l assignation des caracteres. Si une instruction fonctionne c est que la cpu et la ram sont ok. Tu devrais essayer de prelever le hcs10017 de l'oric1 qui ne marche pas, et le mettre dans l'atmos a la place de l'autre, ca devrait aller mieux, sur l'ula defectueux, verifie qu il n y a pas une patte repliée.

[retroric]

Kenneth, je n'ai pas tes  connaissances hardware, mais je me permets une autre hypothèse

Ne pourrait-ce pas être plutôt un pb sur le VIA ou sur le PSG ?

Le fait que le son fonctionne ne prouve pas que les ports A et B du PSG fonctionnent bien...

Et pour le VIA, je ne me rappelle plus, mais je crois que pour le son seul le port A est sollicité, alors que pour la scrutation du clavier je suis sûr que les 2 ports A et B sont utilisés...

Et pour l'ULA, s'il arrive à lire la mémoire, je ne vois pas pourquoi il aurait du mal à lire uniquement certaines zones mémoire ?

Pour moi, le fait que "certaines touches (pas toutes) sont incorrectement représentées à l'écran" semble plutôt lié à la scrutation des touches clavier (donc VIA et PSG) que lié à l'ULA...

PS - par contre du coup pas trop possible de tester le VIA par simple échange vu qu'il est soudé... Pour le PSG, je me souviens plus s'il est sur support ou pas ?

[retroric]

CORRECTION - j'avais mal lu le début de la question, avec la précision que l'invite de commandes est mal affichée... Du coup ce n'est donc pas a priori un pb de scrutation clavier, désolé, l'hypothèse de Kenneth apparait donc  plus plausible (ceci dit, il y a peut-être aussi un pb de scrutation clavier qui se greffe là-dessus )

PS - Je viens de comprendre (enfin je crois ) l’hypothèse de la patte repliée (ou cassée ?) qui pourrait expliquer des pbs à lire juste qq zones mémoire, s'il s'agit d'une patte du bus d'adresses...

[retroric]

Bon,

Je crois que j'ai un début d'explication !

Quand on regarde la 2nde photo d'écran, on reconnaît assez facilement que le prompt "Ready" semble 'déformé' en "Veed}", et que l'espace semble déformé en '$'.

Si on regarde de plus près les codes ASCII associés en binaire:

'R' = $52 = 01010010
'V' = $56 = 01010110  (code binaire identique, excepté bit 2 à 1)

'a' = $61 = 01100001
'e' = $65 = 01100101 (code binaire identique, excepté bit 2 à 1)

'd' = $64 = 01100100 (bit 2 à 1)

'y' = $79 = 001111011
'}' = $7D = 001111101 (code binaire identique, excepté bit 2 à 1)

'_' = $20 = 01111011  [caractère espace]
'$' = $24 = 00100100 (code binaire identique, excepté bit 2 à 1)


BREF... On voit que lors de l'affichage des caractères, le bit 2 semble forcé à 1... ce qui explique l'affichage déformé de "Ready" en "Veed}" (seules les lettres 'e' et 'd' ne sont pas déformées car dans leur code ASCII le bit 2 est déjà à 1) et de l'espace...

Reste à savoir quel est le circuit défectueux en cause, mais ce n'est en tous cas pas une ligne d'adresse comme j'avais écrit plus haut qui est fautive...

NB: ceci étant, je n'ai pas l’impression que mon explication fonctionne pour "EXPLODE" déformé en "E\TLOD", je n'ai pas vérifié les combinaisons binaires car déjà je ne comprends pas pourquoi le "E" final n'est pas affiché ??!!

[ZodiacFR]

Merci à tous pour ces réponses si rapides, StackOverflow m'avait habitué à bien pire

laurentd75 je pense bien que tu as identifié le problème! je n'avais pas pensé à regarder les correspondances en binaire c'est bien joué

L'Oric utilise t'il toujours le code "_" pour un espace?
En effet le code " " vaut 00100000, contrairement au "_" qui vaut 0101111, ce qui renforcerait l'hypothese du 2nd bit inversé vu que "$" = 00100100.

Je n'ai pas l'Atmos sous la main mais je testerai ce we si cette hypothèse se verifie avec tout les caractères (et si le deuxième bit est toujours à 1 ou est inversé).

Il reste cependant à identifier le composant ou la soudure defectueuse, savez vous laquelle des puces est en charge de la vidéo?
La HCS10017 est malheureusement soudée sur l'Atmos, contrairement à l'Oric 1, ce qui m'empêche de tester tout cela facilement en les échangeant

[retroric]

L'Oric utilise t'il toujours le code "_" pour un espace?
En effet le code " " vaut 00100000, contrairement au "_" qui vaut 0101111, ce qui renforcerait l'hypothese du 2nd bit inversé vu que "$" = 00100100.

Excuse-moi, je t'ai induit en erreur, en fait j'ai utilisé le caractère de soulignement (qui n'existe pas sur Oric d'ailleurs, ou plutôt qui correspond au caractère '£') pour représenter l'espace d'une façon plus "visible" !!!

Donc on parle bien d'espace (" ") qui vaut 00100000, et qui, avec le bit 2 forcé à 1 devient "$" = 00100100. Note bien que je dis "forcé à 1" et non pas "inversé", ce n'est pas la même chose (c'est d'ailleurs pour ça que le "e" de "Ready" n'est pas déformé, car dans le code binaire du 'e' le bit 2 est déjà à 1. S'il y avait inversion, le caractère 'e' serait lui aussi déformé..)

[retroric]

PS - je ne suis toujours pas convaincu que ce soit l'ULA le fautif... Ca pourrait tout simplement être l'une des RAM qui correspond à la mémoire écran ($$BB80 à $BFE0 pour le mode TEXT), donc vers le haut de la mémoire.

Il serait intéressant de voir ce qui se passe en mode HIRES, vu que la mémoire écran s'étend alors de $A000 à $BFE0. Tu pourrais lancer qq commandes CURSET, DRAW et CIRCLE pour voir si les tracés sont "déformés" ou pas...

EDIT: je me dis qu'au passage eb HIRES, au lieu d'un écran noir tu devrais même peut-être voir des lignes verticales blanches espacées de 6 pixels, si toute la partie de la mémoire vidéo est affectée...

[kenneth]

Je pensais a un truc...
L'Oric teste la mémoire au départ en alternant les bits d'ou tout ces "U". Si la mémoire etait defectueuse, l'Oric ne démarrerai pas comme si de rien n'était...

[retroric]

Kenneth, la question est de savoir si l'Oric procède réellement à un contrôle programmatique, ou s'il s'agit juste d'un contrôle "visuel"...  Mais ce que tu me dis me rappelle qq chose que je crois avoir lu dans l'Oric à nu, je vais essayer de vérifier l'info...

[kenneth]

Kenneth, la question est de savoir si l'Oric procède réellement à un contrôle programmatique, ou s'il s'agit juste d'un contrôle "visuel"...  Mais ce que tu me dis me rappelle qq chose que je crois avoir lu dans l'Oric à nu, je vais essayer de vérifier l'info...

J ai trouvé
Page 371: Routine de test de mémoire.
Page 365: Routine de décision d'afficher "MEMORY ERROR".
Je salue, casque bien bas, le travail d'écriture de Fabrice Broche pour son ouvrage "L'Oric à Nu".

[retroric]

@Kenneth, nos messages se sont croisés, tu as posté alors que j'étais en train d'éditer mon précédent message

J'ai également trouvé la routine de test mémoire, mais tu es allé plus loin que moi en trouvant la routine qui affiche un message d'erreur (je n'avais pas trouvé la routine exploitant le flag "erreur mémoire" en $260...)... Sauf qu'à première vue, ça ne vaut que pour l'Oric 1 ?! Je ne vois nulle part d'affichage 'MEMORY ERROR' pour les routines appelées lors du reset système pour l'Atmos ???

Je salue, casque bien bas, le travail d'écriture de Fabrice Broche pour son ouvrage "L'Oric à Nu".

+1, ça a été mon bouquin de chevet du moment où je l'ai acheté, et 32 ans plus tard, c'est redevenu ma bible ! ... et j'en prends soin comme de la prunelle de mes yeux, je fias attention en tournant les pages, j'ai renforcé les coins avec du scotch, et pour l'instant, la reliure tient encore bon, mais je fais vraiment très attention...

[retroric]

Autre détail que je ne m'explique pas: l'écran devrait être remplis de '$', mais on voit clairement à chaque ligne 2 caractères 'blancs' (espaces? attributs?), dont la position est décalée d'une ligne à l'autre. On pourrait supposer qu'il s'agit d’attributs dans les colonnes 0 et 1, mais dans ce cas-là ça veut dire qu'il y a un décalage de l'affichage, bref tout ça est vraiment très bizarre...

... Et enncore autre chose, qu'il faudrait que je vérifie au niveau des codes binaires, mais il semble bien que la séquence de caractères "GETW" en blanc sur fond noir pourrait correspondre à "CAPS" de la ligne de statut, mais là aussi ça apparaît complètement décalé...

[kenneth]

Autre détail que je ne m'explique pas: l'écran devrait être remplis de '$', mais on voit clairement à chaque ligne 2 caractères 'blancs' (espaces? attributs?), dont la position est décalée d'une ligne à l'autre. On pourrait supposer qu'il s'agit d’attributs dans les colonnes 0 et 1, mais dans ce cas-là ça veut dire qu'il y a un décalage de l'affichage, bref tout ça est vraiment très bizarre...

... Et enncore autre chose, qu'il faudrait que je vérifie au niveau des codes binaires, mais il semble bien que la séquence de caractères "GETW" en blanc sur fond noir pourrait correspondre à "CAPS" de la ligne de statut, mais là aussi ça apparaît complètement décalé...

C'est ce je soupçonne: L'Oric au niveau cpu/memoire fonctionne bien (il faudrait charger un jeu bien gras, je suis sur que ça passe ), par contre, dans l'architecture de l'ula, il y a un bug: le pointeur écran et le pointeur de fonte des caractères se mélangent les pinceaux: affichage du mauvais contenu par rapport a la table ascii et nauvais positionnement du début de ligne. Le problème se situe dans le module situé juste avant le module de conversion en rgb. En gros, l ula fait bien son travail coté "mémoire" même si les apparences sont trompeuses, par contre coté "video" il y a une porte qui a grillé. Quel dommage que l'ula soit soudé directement, cela rend l'opération perilleuse, surtout si je me suis planté...

[retroric]

Oui, à la réflexion, on se rapproche de plus en plus de ton hypothèse initiale, l'ULA...

J'ai en effet noté un autre symptôme: on voit clairement une répétition de texte sur les photos d'écran, tout apparaît 2 fois (visible plus oarticulièrement sur la 2nde photo d'écran):
- l'intitulé (texte déformé) "ORIC EXTENDED BASIC V1.0" (bizarrement pour la première occurence il manque le ".0" de "1.0").
- le prompt (texte déformé) "Ready"
- la commande (texte déformé) EXPLODE

Et pour mon hypothèse du "bit 2 forcé à 1", on peut l'expliquer d'une autre façon, très précisément par un décalage de 4 octets dans la table de caractères (ex: "CAPS" qui devient "GETW")... ce qui expliquerait qu'il n'y ait pas d'affichage du message "MEMORY ERROR", puisque la mémoire est OK, c'est juste l'ULA qui déconne avec des décalages bizarres lors d'accès à la mémoire...

EDIT: pour l'hypothèse sur le décalage, pas si sûr que ça en fait, car cela n'explique pas pourquoi le "E" et le "D" de "EXPLODE", ou le "e" et le "d" de "Ready" ne sont pas modifiés...

[ZodiacFR]

Merci pour cette analyse détaillée du coup l'erreur ne vient pas de la RAM vu qu'il n'affiche pas de MEMORY_ERROR c'est bien ça? Et du coup ce serait l'ULA (la HCS 10017)

Je n'arrive pas a trouver de documentation sur le mode HIRES, il permet de dessiner?
Auriez vous un scan de manuel Oric sous la main que je puisse creuser tout ça et essayer?

Les ULA de l'Oric 1 et Atmos sont elles compatibles? Sur l'Oric 1 elle est en berceau si je ne dis pas de bétises

[retroric]

Hello,

Tu peux trouver l'essentiel des bouquins sur Oric scannés sur le site de Defence Force dans la rubrique  Pages Oric > Bibliothèque.

Les ouvrages sont classés par catégorie, tu trouveras le manuel de l'Atmos en version française et anglaise dans la catégorie MANUALS.

Il y a un chapitre dédié aux instructions graphiques, et aussi un autre chapitre qui liste les commandes du BASIC par ordre alphabétique.

Bonne lecture !

PS - je crois que je me suis peut-être un peu trompé dans mon hypothèse de "lignes verticales" au passage en HIRES ceci dit, car la mémoire est organisée en octets qui représentent des groupes de 6 pixels de large, mais pour que les pixels soient affichés je crois qu'il faut que le bit n°6 soit positionné (c'est géré par les commandes graphiques) et je ne sais plus si c'est initialisé comme ça dès le passage en HIRES, il faudrait que je vérifie.

Mais en tous cas, dès que tu feras qq tracés avec DRAW ou CIRCLE, normalement tu devrais avoir des "artefacts", des pixels en plus du tracé qui apparaissent...

____

EDIT: j'ai vérifié, la mémoire vidéo HIRES est bien initialisée avec la valeur #40 (%01000000, bit n° 6 positionné), donc normalement si l'ULA déconne on aura aussi le bit n°2 positionné, donc si tu tapes juste "HIRES" au démarrage tu devrais te retrouver en théorie avec un écran avec des lignes verticales espacées de 6 pixels.

[kenneth]

Les architectures de l'Oric1 et celle de l'Atmos sont identiques donc les ULAs sont identiques.

[Contenu sponsorisé]