Hey, vous saviez qu'il y a un registre de l'AICA qui permet de changer la fréquence de l'arm7 ?
On peut théoriquement le monter à 128MHz... Mais bon j'imagine qu'à cette fréquence ça fait longtemps qu'il a crâmé !

EDIT: Du coup y'a peut-être moyen d'y faire tourner Helix...
https://datatype.helixcommunity.org/Mp3dec.html

--Message edité par titemoo le 2009-09-25 21:16:30--

Le prpblème avec Hélix, c'est qu'il utilise des instructions ARM non supportées par l'ARM7. Du coup, il faut les émuler et ça bouffe encore plus de ressources.
L'upgrade de la fréquence de l'ARM7, je ne sais pas si ça fonctionne. J'ai lu quelques trucs là-dessus, mais rien de probant. Il faudrait faire le  test.
Si c'est prévu, je ne vois pas pourquoi ça surchaufferait au point de tout casser, mais il faut demander aux spécialistes (Semicolo :-) ).
128 au lieu de combien, déjà? (il me semble que c'est 27, mais ça me parait soudain minuscule).

L'arm7 de l'AICA tourne à 25MHz... Ça fait une sacrée différence !

Par "instructions non supportées par l'arm7" je suppose que tu veux parler des instructions en mode thumb... Le seul avantage de ce mode (à ma connaissance) est le gain de place en mémoire vive, causé par une densité accrue du code (instructions 16 bits au lieu de 32 bits). Selon wikipedia : "Most of these 16-bit-wide Thumb instructions are directly mapped to normal ARM instructions". Il "suffit" donc de réécrire en assembleur ARM standard les parties écrites en Thumb, et ça devrait marcher sans trop perdre en perfs...

En attendant, si on peut obtenir un lecteur mp3 qui décode des mp3 à 48kHz jusqu'à 320Kbps, ça serait tout simplement énorme.

--Message edité par titemoo le 2009-09-26 18:07:46--

Tu essaies encore de m'embrouiller :-)
Mais maintenant que tu maitrises l'AICA, si tu arrives à compiler Helix, je te tire mon chapeau!

Mince, je croyais t'avoir suffisamment motivé pour que tu t'en charges

Ben j'ai essayé pendant un bon moment et vu le temps que ça prenait, je me suis dit qu'il vallait mieux que je me recentre sur la partie "jeu" de mon jeu.
Pour rappel, si je suis tapé un driver AICA qui gère les S3M, c'était simplement au départ pour intégrer du son dans mon jeu de voitures :-)
Pour en revenir aux instructions non gérées, ce sont bien des instructions ARM, pour faire des opérations 64 bits si ma mémoire est bonne. Il faut regarder un peu plus haut dans ce topic.
Dans lecode d'Helix, certaines fonctions sont codées sous forme de macro direct en assembleur et il nous manque certains des mnémoniques utilisés sur notre version de l'ARM.
Bref, avant toute chose, il faudrait faire des tests avec cette cadence d'horloge.

Je viens de jeter un coup d'œil aux docs de l'arm7di et de l'arm7tdmi. Et c'est assez décevant…

En effet, l'arm7tdmi prend au maximum 6 cycles pour effectuer une opération 32b * 32b => 64b.
Concernant l'arm7di (celui de la DC si j'en crois les dires de Semicolo), celui-ci prend au maximum 17 cycles pour effectuer une opération 32b * 32b => 32b, et ne possède pas d'instructions 64 bits selon la doc officielle.

Évidemment, il faut compter l'ensemble des cycles nécessaires à l'arm7di pour effectuer une multiplication sur 64 bits…

En utilisant l'algorithme suivant, avec A,B les deux mots de 32 bits à multiplier, l(X) les 16 bits de poids faible de X et h(X) les 16 bits de poids fort de X, Rl et Rh les deux registres 32 bits de destination :

Citation :

tmp1 = l(A) * h(B) tmp2 = h(A) * l(B) Rl = l(A) * l(B) + l(tmp1) + l(tmp2) Rh = carry + h(A) * h(B) + h(tmp1) + h(tmp2)

On effectue selon cet algorithme (qui n'est sans doute pas le meilleur, c'est le seul qui me soit venu à l'esprit) 4 multiplications de 32 bits : on se retrouve avec un maximum de 4 * 17 = 68 cycles, rien qu'en comptant les multiplications. À cela il faut ajouter les additions ainsi que les shifts. En gros on avoisine les 100 cycles utilisés pour un mull sur l'arm7di, contre 6 sur l'arm7tdmi…

Donc c'est un peu cheap pour décoder des mp3s…  

--Message edité par titemoo le 2009-10-15 13:43:07--

Surtout a 25 MHz :-)

Bon ma toolchain ARM pose problème, j'ai une corruption de la pile et donc l'ARM plante aléatoirement.

Ce qui m'énerve c'est que je n'arrive pas à m'en débarrasser, j'ai testé avec 3 versions différentes de GCC et rien ne marche

Tu as essayé avec la version toute prête du CD de L@Cible?

Non, je n'ai pas encore testé. Cependant là j'ai une toolchain ARM avec gcc 4.4.0, et j'arrive à compiler le driver de KOS sans problèmes. Cependant, j'ai encore quelques soucis : http://pastebin.com/f4c69616
Concrètement, le SH-4 reçoit une chaîne vide pour le 1er message envoyé (1er appel à la fonction send()) mais affiche "cd" lors du 2e appel.

J'ai enfin des CDs vierges, je vais tester le pack de L@Cible

C'est bon ça marche !!

Citation :

KallistiOS ##version##: mercredi 23 septembre 2009, 20:51:54 (UTC+0200)  paul@cerebro:/home/paul/dev/dreamcast/kos thd: pre-emption enabled, HZ=100 16:57:53 8C02290E WARN  ARM Halted: BRANCH to invalid address FFFFFFE8 at 00000004 maple: active drivers:    Dreameye (Camera): Camera    Sound Input Peripheral: Microphone    PuruPuru (Vibration) Pack: JumpPack    VMU Driver: Clock, LCD, MemoryCard    Mouse Driver: Mouse    Keyboard Driver: Keyboard    Controller Driver: Controller  DMA Buffer at ac096080 vid_set_mode: 640x480IL NTSC fs_romdisk: mounting image at 0x8c04bbb4 at /rd dc-load console support enabled maple: attached devices:  A0: Dreamcast Controller          (01000000: Controller) Welcome to the AICA Player! Disactivating the SPU... Opening the driver... Driver loaded. Reactivating SPU... Waiting for SPU to be initialized... SPU successfully started. SPU: 1 kilomètre à pied SPU: ça use, ça use SPU: 1 kilomètre à pied SPU: ça use les souliers SPU: 2 kilomètres à pied SPU: ça use, ça use SPU: 2 kilomètres à pied SPU: ça use les souliers ...

J'avais remplacé "-Wl" par "-Wall" dans le Makefile comme un con…
Maintenant que j'ai un truc fonctionnel, les choses sérieuses vont pouvoir commencer !!

--Message edité par titemoo le 2009-11-08 17:01:19--

Eh ben en voilà, une bonne nouvelle!
Bravo, tu vas pouvoir tester le code que tu avais fait sur PC?
Pas de plantage avec la division par 3?

Salut !

Non pour l'instant mon projet est en stand-by, le temps que je me fasse la main sur l'ARM7.

Par contre, ce dernier me pose aussi problème pour toutes les divisions et les modulos (avec optimisation, il utilise des shifts pour les puissances de 2 je suppose).
Chose étrange, lxdream fait bien les divisions, donc c'est à priori pas un problème de compilation. Je vais regarder ça plus en profondeur.

Bref prochaine étape, c'est de faire marcher la division, comme ça j'aurai un printf() qui marchera aussi avec les entiers.

J'ai déjà un petit bout de code en assembleur qui calcule le nombre de cycles exécutés par l'ARM pendant une seconde. Je n'arrive pas encore à utiliser le registre permettant de modifier la fréquence du proco, mais je sais déjà qu'il exécute environ 2781000 cycles (à 1000 cycles près) soit environ… 2,78 MHz.

--Message edité par titemoo le 2009-11-10 17:00:15--

J'ai réglé le problème de la division par 3.
En fait, il faut compiler ta toolchain ARM en passant l'option "--with-arch=armv4" au ./configure.

Ensuite, plus de problème de division

--Message edité par titemoo le 2009-11-10 16:46:43--

Ah c'était ça? Voilà élucidé le mystère de la division maudite!

Si ça t'intéresse, j'ai réussi à implémenter la fonction printf() sur le SPU (utilisable avec les %), en utilisant une interruption : le SH-4 n'a pas besoin de vérifier périodiquement si un nouveau message est dans le buffer, il reçoit une interruption IRQ lorsque c'est le cas.

Il me reste plus qu'à trouver comment activer une interruption sur l'arm7 depuis le SH-4…

--Message edité par titemoo le 2010-03-22 23:05:04--

Cool, ça!
Pour les interruptions, il faut peut-être jeter un oeil au pilote streamig de KOS, il utilise probablement un truc dans le genre pour le streaming audio.

Non, le pilote de de KOS fait du polling pour le streaming… Aucune interruption n'est utilisée.

Aujourd'hui est un grand jour, je viens de réussir à envoyer une interruption FIQ à l'arm7 depuis le SH-4

Prochaine étape, je crée une petite lib permettant d'envoyer une interruption munie d'un code, qui lance automatiquement la fonction que l'utilisateur aura assignée à ce code sur l'autre processeur, et ce sur chacun des deux processeurs

Si tu as jeté un œil à mon code, tu as vu que la partie AICA tourne avec un polling qui me sert à lire plusieurs musiques en parallèle, donc je crois que je vais conserver ce système. Par contre, dans l'autre sens, il manque clairement un système d'interruption, pour ne pas avoir à lire les messages en provenance de l'ARM à la main.
Pour résumer, carrément cool, quand est-ce qu'on récupère ça? :-)