Logicielsmoto.com

Pour que Pulko comprenne bien : il faut oublier les interruptions sur Thomson. Elles sont toutes reliees en hard (vecteur en ROM) sur des routines qui depensent un nombre hallucinant de cycles avant de donner la main a l'utilisateur. C'est totalement prohibitif pour faire des trucs performants.

Par comparaison, quand on a porté OS9 (http://os9.forler.ch), on a viré toute la ROM et on l'a remplacée par le noyau OS9 qui fait un usage bien plus efficace des interruptions. On a vraiment été épaté par la puissance qu'on a libérée lors de cet exercice.


On en a deja parle, mais c'est exactement ce qu'il serait necessaire de faire avec l'interface synthese vocale, dont je rappelle que c'est avant tout un synthetiseur tout court.

Fool

Oui, l'interface synthèse vocale est aussi dans mes cartons... mais sur mo5 c'est ça ou le lecteur de disquettes (ou la rs232)... à moins que je fasse un truc pour brancher plusieurs extensions.

Pour la génération du son, effectivement les interruptions posent problème. Il n'y a aucun moyen de détourner ça ? Tout reste en dur dans la rom, pas le moindre passage par la table SWI ou autres machins en zero-page ?

D'autre part, je ne pense pas me lancer dans du sample à 44KHz tout de suite. Par exemple sur CPC le record actuel est de 18KHz (musique d'intro d'Orion Prime). Il faut ruser un peu avec les samples utilisés (filtrage de fréquences) mais les résultats sont tout à fait satisfaisants. On est habituellement à 15 voire 8KHz. A 8KHz on peut déjà générer un signal beeper à la main avec, a mon avis, un résultat correct (pour faire bip).

Les sidvoices réalisées sur CPC et sur ZX spectrum (démos déjà citées plus haut) ont d'autres problèmes à contourner : sur CPC l'accès à la puce AY se fait à travers le PPI (équivalent du PIA) et demande de nombreux cycles CPU pour mettre à jour un registre, ce qui fait qu'il reste assez rapidement peu de temps pour le reste. Sur spectrum, le temps d'exécution des instructions n'est pas constant (il est ralenti par les accès mémoire de la puce vidéo pendant l'affichage de l'écran), ce qui rend beaucoup plus difficile la réalisation d'une note qui sonne juste. tout ceci, rapellons le, sans timer ni interruptions programmables. Je pense que c'est également possible sur thomson, même si ça signifie qu'il faudra mettre moins de choses qui bougent à l'écran...

En ce qui concerne l'idée de court-circuiter le port cassette; ça ne me pose pasde problème. Le même genre de chose est utilisé sur Oric, ou le signal VBL de balayage de l'écran est renvoyé sur le port cassette afin de disposer d'une interruption de synchronisation permettant de faire des démos propres et bien synchronisées. ça ne dénature pas trop la machine, je pense

Pour brancher plusieurs interfaces sur MO5, il y a le Megabus, produit commercial, c'est pas un souci. on en trouve de temps en temps sur ebay.

T'es un teigneux c'est bien, mais cherches pas : voici le debut du code de la routine en ROM pour l'IRQ sur MO5 :



Total : 31 cycles pour sauter a ton code sans compter le basculement de contexte qui prendre 19 cycles a l'aller et 15 cycles au retour. Au final 65 cycles de gaspillés avant de pouvoir executer le moindre truc intéressant.

Le plus efficace reste la TSG de notre cher BC109
(c'était bien de lui?), et c'est bien plus fun.

PS : dans mes bras mon ami, enfin quelqu'un qui s'interesse au MO5 et pas au TO8D

Fool

C'est sur c'est con que ça passe par le firmware à chaque fois et que les IRQ fassent un empilement/dépilement de la pile à chaque fois... mais après une VBL pommé lors de l'interruption c'est pas non plus ce qu'il y a de plus mortel, ça dépend ce qu'on y fait...

La routine d'IRQ des autres Thomson est la même ? (à l'adresse de JMP prêt bien entendu qui est 0x6064 je suppose...)

Concernant les autres interruptions, enfin surtout les FIRQ, elles sont utilisé par quoi sur les différents Thomson ?

Concernant les samples, en plus sur CPC on à l'énorme problème d'avoir du 4-bits non linéaire... Enfin non linéaire si c'était symétrique ça irait, mais ça l'ai pas

Pour le graphisme, le problème est effectivement je pense l'absence de graphiste directement sur la machine, les contraintes de palettes sont vachement moins importante que sur Spectrum, 2 couleurs par bloc de 8x1 contre 8x8... Et quand je vois ce qu'il font sur Spectrum...
(Tient d'ailleur puko, grafx2 gére les contraintes spectrum ? ça doit pouvoir s'ajouter facilement non ?)

Sinon, y a t'il moyen de modifié la palette en cours d'image ou c'est latché et synchronisé ?
De même que le switch d'écran affiché sur les Thomsons supportant 4 pages écrans différentes sont synchronisé à quel momement ?)

Pareil! (EDIT: dans le sens ou ça part en Rom avant d'aller sur la routine perso. Le code Rom étant différent quant à lui)
Sur To9, on doit se taper la Rom avant le saut final sur ta routine perso.


Par le crayon optique.


Sur Mo5 ou To7(/70) non. Y a pas de palette.
Sur les autres, oui. Via quelques bidouilles, on peut mixer plusieurs modes d'écran et changer les palettes à la volée.
Par contre, c'est un peu plus sioux de faire du code compatible multi TO.

Le multibuffering n'est valable que sur To8 ou To9+. N'étant pas spécialiste de ces bécanes, je suppose qu'ils font le switch au retour du spot.
D'ailleurs, est-ce possible de le faire en cours de balayage?

Sinon, si t'es calé en hard et que tu as une astuce pour déverrouiller les vecteurs d'interruptions de la Rom, je prends!

Nota: il n'y a pas d'interrupt VBL. Le test de la VBL se fait avec du polling actif sur les regs d'affichage.


Pas sur Il faudrait checker avec DCMOTO... Ok non pas du tout. Pour TO9 je trouve en $FFF8-$FFF9 un vecteur qui pointe en $FC13 lequel contient:

Ce qui se rapproche le plus du code de fool (provenant d'un MO5) est peut-être (si j'ai bien analysé cela comme étant la gestion du clignotement curseur) à l'adress $FC32 qu'on atteint avec quelque cycles en plus depuis $FC13:


Crayon optique. Quand la led du crayon optique est activée, alors une FIRQ est générée et le 6809e va vite lire les compteurs ecrans et les placer dans un buffer qui sera traité plus tard lors de l'appel aux routines moniteurs pour récupérer les coord X/Y du spot à partir de la valeur des compteurs ecrans.

sam.

Le switch de mode d'écran coute quasiment pas (1 octet à placer). La modif de palette si hélas (3 octets par couleurs). On ne peut guère que changer 1 couleur pendant le retour de ligne (2 quand on est super optimisé à ce qu'il parait, mais préhisto n'a jamais révélé son secret à quiconque, enfin je crois )

sam.

Ok, donc le temps d'IRQ est différent...

Sur MO5NR et MO6 sur le schéma y a bien un fils nommé INT 50Hz qui sort du compteur de ligne pour arrivé sur l'entré de commande d'interruption du PIA, donc qui peut déclencher une IRQ du CPU. Elle est pas synchro sur la VBL ? Elle est déclancher à quel moment ?

Logiquement le MO6 et le MO5NR devraient aussi disposer du multi-buffering, puisqu'ils ont le meme gate-array que le TO8/TO9+ ...

Debloquer les interruptions est impossible sans modifier la ROM. On pourrait imaginer de produire une ROM modifiee mais qui reste compatible au niveau fonctionnalite, mais personnellement, je trouve cela idiot : personne va aller patcher hard son MO5 pour faire tourner une demo. De toute maniere c'est pas l'esprit : autant ajouter 1 Go de RAM un chip son et un coprocesseur graphique d'emblee on gagnera du temps ...

La FIRQ n'est cablee que sur le crayon optique effectivement. Tous les peripheriques utilise l'IRQ ... quand elle est cablee, ce qui n'est pas toujours le cas. La FIRQ est dispo sur le bus d'extension toutefois.

Mais le retour de VBL est testable par polling, ce n'est pas un souci et c'est generalement tres efficace comme l'ont prouve plusieurs programmes et demos. Je connais certaines personnes qui irait meme jusqu'a dire qu'utiliser les interruptions pour la synchro c'est pour les paresseux

Il n'y a pas d'autre interruption utilisable sur Thomson. La NMI est redirigee en ROM vers un RTI et inutilisee sur le bus d'extension, les interruptions logicielles sont inoperantes as well (SWI2, SWI3 -> RTI) et le SWI est utilisé sur MO pour les appels au moniteur.

il reste le reset si le coeur t'en dit ... mais bon il est aussi cable en ROM, evidemment.

Fool

La quoi ?

sam.

Y va pas arreter avec son obsession de la vbl ...

comme son nom l'indique, elle pete a 50 Hz et elle sert pour afficher le curseur. elle declenche l'IRQ a 65 balles de tout a l'heure. et sur Thomson, 65 balles ca fait cher la synchro VBL. Y'en a qui ont essayé, z'ont eu des problèmes. Mais on t'empêche pas cela dit ...

Fool

La Théorie de la Synchronisation Généralisée, ou l'art d'écrire du code parfaitement synchronisé sans utiliser d'interruption. Ce dont on discute en ce moment quoi.

Je me souviens avoir lu ca dans un Science&Vie Micro qui consacrait un article au Forum Thomson il y a une quinzaine d'année.

Fool

Non, je suis d'accord, modifié le hard et utilisé des extensions ne présente aucun intérêt pour la démo, on à la même philosophie sur CPC. Les extensions sont uniquement pour permettre des facilités de développement (utilitaire dans un émulateur de ROM (extension la plus courante), interface RS232 pour le transfère de snapshot, disquette et... lecture de musique sur l'AY depuis un SoundTracker sur PC ! (tout neuf))

Sur CPC le test VBL ce fait aussi par polling... mais généralement après une interruption... (on a 6 interruption par écrans, si on les modifie pas la dernière à lieu juste après le début de la VBL, puis après attente de la fin de la VBL (on a une interruption toutes les 52 HBL (valeur de compteur fixe), mais on peux forcer une remise à 0 du compteur (donc on peux compter 52 HBL à partir d'un moment donné)

Après des démos utilise des routines à temps fixe foncièrement synchrone (DTC, From Scratch)

Je crois qu'il n'y a pas eu autant de papotte sur ce forum depuis des années. Faudrait presque ouvrir un bar ...

Fool

C'est pas pour une démo (et encore moins pour de la musique)