La conquête des coprocesseurs DSP
Posté le 22/09/2020 10:42
Contexte, le DSP intégré et les DSP du SPU
Récemment, j'ai redécouvert avec l'aide de
Yatis que le SH7305, le microprocesseur qu'on trouve dans les calculatrices SH4 (y compris les Graph mono récentes et la Graph 90+E) possède un module de traitement de son (SPU) avec
deux DSP.
Pour information, un DSP est un coprocesseur dédié au traitement du signal. C'est une sorte de processeur qui travaille en parallèle du processeur central et possède un jeu d'instructions permettant de traiter rapidement des signaux. C'est donc particulièrement adapté au traitement du son. Leur existence est très intéressante car on peut dans une certaine mesure les détourner pour faire d'autres tâches intensives. Mon plan par exemple c'est de faire des shaders 2D avec.
Il y a une poignée de ressources parlant de DSP (
[1],
[2],
[3]), mais en fait la plupart concernent un DSP intégré au processeur central, documenté dans la section 6 du
manuel du SH4-AL DSP (le processeur qu'on a et qu'on appelle communément « SH4 »). Ce DSP est intéressant mais il ne tourne pas en parallèle du processeur central : pour l'utiliser, on insère des instructions DSP dans le code et dans ce cas le processeur ne fait rien quand le DSP travaille. De plus, son jeu d'instructions est difficile à détourner dans des buts graphico-ludiques (il n'a par exemple qu'une seule multiplication 16x16→32, ce qui est boiteux au possible).
Par contre le DSP intégré a deux zones de RAM appelées XRAM et YRAM de 8k chacune, qui sont foudroyantes en vitesse parce que situées près du bus processeur. Pour vous donner une idée, les memcpy() et memset() optimisé de gint tournent à 10 Mo/s et 30 Mo/s environ pour la RAM normale. Avec le DSP, on peut monter aisément à 300 Mo/s voire 450 Mo/s si on s'y prend bien. Le potentiel est très élevé pour les calculs intensifs, avec la limite que 16k c'est très peu.
Les deux DSP de l'unité de traitement de son (SPU) sont différents. Ils ont une mémoire de travail beaucoup plus grande (vaguement connue
[4]), avec chacun 170k de XRAM, au moins 30k de YRAM (pas clair encore), et 160k de RAM supplémentaire pour stocker du code. Puisque la mémoire pour le code est différence de la mémoire où on stocke le programme central, ces DSP calculent vraiment
en parallèle à la façon d'un processeur multi-coeurs. Le hic, c'est qu'il n'y a pas de documentation. Il faut donc rétro-analyser tout ce dont on dispose pour récupérer le fonctionnement de 0. C'est là que ça se complique...
Le modèle 24-bits et la RAM à trous
Dans la doc du SH7305, il y a une seule page expliquant les fonctionnalités principales du SPU, c'est en quelque sorte le teaser de Renesas envers ses potentiels clients ; tout le détail n'est fourni qu'aux clients qui utilisent le processeur pour de vrai. Mais la doc explique déjà que le DSP manipule des mots de 24 bits, qu'on peut imaginer sont des valeurs en point fixe pour représenter des échantillons de signal. C'est différent du DSP intégré donc d'emblée on sait que le jeu d'instructions sera différent.
Ce qui est un peu casse-pieds, c'est que la XRAM et la YRAM sont à trous pour faciliter le travail du DSP. Vous voyez, un signal est souvent vu comme un tableau d'échantillons géant. Le problème c'est qu'avec des valeurs de 24 bits (trois octets), atteindre le n-ème échantillon demande de calculer n*3, ce qui prend du temps en électronique. Les processeurs ont depuis longtemps pris l'habitude d'utiliser des types de données à 1, 2, 4 ou 8 octets (des puissances de 2) parce que multiplier par des puissances de 2 est immédiat en électronique (il suffit de déplacer les fils et d'ajouter des 0). Ici, le DSP fait un truc encore plus fourbe : il place un mot de 24 bits (3 octets) tous les 4 octets, en ignorant un octet sur 4. Le premier mot couvre les adresses 0, 1, et 2 ; le second couvre les adresses 4, 5 et 6 ; le troisième, les 8, 9 et 10 ; et ainsi de suite.
Comme les adresses 3, 7, 11 etc sont inutilisées, le constructeur a trouvé malin de ne pas réellement y mettre de mémoire. Du coup la XRAM et la YRAM sont hyper fragmentées, avec un trou tous les quatre octets. Impossible donc d'y stocker un simple int puisqu'il n'y a pas 4 octets de mémoire d'affilée. Il faudra donc être malin pour faire marcher ça. Par contre, le RGB888 ça passera crème pourvu qu'on arrive à calculer avec efficacement.
Qu'y a-t-il à faire et où va-t-on ?
Actuellement je désassemble le programme de Renesas qui émule le SH7305 (d'ailleurs utilisé dans les émulateurs de Casio) pour déterminer quels sont les registres périphériques des DSP, comment les initialiser, les utiliser, et j'espère trouver le jeu d'instructions. Il y a pas mal de choses à comprendre :
• Liste des registres périphériques : fait
• Allumage et initialisation : en bonne voie
• Transfert de données via DMA intégré : en bonne voie
• Fonctionnement de la RAM et des bus : ?
• Jeu d'instructions : ???
• Horloge : ?
Ce sera un bon début pour cette fois.
Citer : Posté le 22/09/2020 11:49 | #
This is very intriguing, especially the 2D shader part!
Citer : Posté le 22/09/2020 11:56 | #
Sha-chan nous a déjà, fais le coup du module wifi, tu nous auras pas comme ça
Plus sérieusement, c'est follement exitant
Citer : Posté le 22/09/2020 13:28 | #
Je vais essayer d'apporter un peu de ce que je sais pour compléter.
En gros, la partie SPU est hiérarchisé en 4 modules :
* SPU2 - celui qui gère et ordonnance les autres modules
* SPU2DP0 - Le DSP0
* SPU2DP1 - Le DSP1
* SPU2RAM - Les différentes zones de RAM que le SPU offre.
En désassemblant le bootcode de Casio, je suis tombé sur un petit bout de driver utilisé uniquement lors d'un redémarrage a froid et qui semble initialiser le SPU et le FSI pour une raison obscure (je pense que c'est utilisé pour déboguer la machine de l'extérieur car il me semble que H-UDI est impliqué dans la manœuvre de Casio). En tout cas j'ai pu réussir à accéder aux différentes RAMs. Reste à savoir en quoi le module SPU2 peut influer sur les zones de RAMs (car il a certains de ses registres qui sont en lien avec le module SPU2RAM).
J'ai aussi documenté le module CPG qui permet globalement de gérer la fréquence des différents bus / clock et je tiens à signaler qu'il y a registre pour le SPU justement. En sois, il me reste encore à documenter le module BSC pour être sur mais il me semble que l'horloge du module peut être modifiée uniquement ici.
Après ce qui est sympa c'est que les deux DSP sont probablement construit en miroir ce qu'il signifie qu'une fois qu'on en a documenté un, l'autre est identique (ou presque). Donc en sois, il n’y a pas tant de chose à RE pour avoir quelque chose de fonctionnel. Le truc qui est long c'est qu'on est dans le noir total pour avancer (car Casio ne l'utilise pas ou peu) et qu'on est obligé d'y aller en tâtonnant. Mais j'ai bon espoir pour la documentation du module.
Je pense qu'il y a effectivement pas mal à jouer en détournant le SPU de son but premier (pour aider à certaines actions graphiques par exemple). Il faudra en parler à Ninestars pour son moteur 3D, parce qu'il a probablement beaucoup à gagner avec ce module.
Citer : Posté le 22/09/2020 20:42 | #
J'ai rien compris mais je sens qu'il y a un truc lourd qui se prépare (notamment lorsqu'on lit "shader") :3
Bientôt un gint 3.0 ?
Citer : Posté le 25/09/2020 13:34 | #
Ha ha je ne suis pas surpris que ce soit les applications qui donnent le plus l'eau à la bouche. Attention cela dit, je n'ai pas encore d'informations quantitatives sur la puissance de calcul que ça offrirait, c'est surtout des estimations par expérience de Yatis à moi à manipuler la matériel et mes propres observations sur les capacités de la Graph 90.
Le point le plus subtil c'est le jeu d'instructions, avec deux questions cruciales : (1) Peut-on rétro-analyser le jeu d'instructions ? et (2) Peut-on détourner efficacement le jeu d'instructions ?. Dans le cas du moteur 3D de Ninestars, s'il n'y a pas au moins une multiplication décente c'est vraiment pas gagné d'avance. (Par contre il peut mettre tous ses buffers dans les RAM DSP et gagner 15% de perfs en plus.
Les règles de versionnage sémantique réservent les montées de versions majeures aux modifications incompatibles d'API ou de fonctionnement. En tant qu'extension, l'ajout du DSP ne serait qu'une nouvelle version 2.x.
Yatis a pas mal couvert la partie horloge, merci !
Je continue de désassembler comme je peux et de tester les perfs. Le RE est assez imprévisible donc il n'y a jamais de garantie qu'on va réussir à progresser sur la compréhension des mécanismes. Je vous tiens au courant.
Là j'ai commencé à m'occuper du DMA, je désassemble ce que je trouve comme code pour comprendre les différents champs de CHCR et le fonctionnement des buffers de communication inter-DSP.
Citer : Posté le 25/09/2020 14:15 | #
Pour rétro-analyser le jeu d'instructions, je ne sais pas si tu connais ce site, mais il y a une catégorie dédiée au DSP. Si les instructions sont les mêmes suivant les différentes familles de processeurs, ça peut être un début de piste.
Citer : Posté le 25/09/2020 14:38 | #
Non, c'est juste un dump de la documentation du SH4AL-DSP. Ça ne concerne que le DSP intégré ; les autres ont définitivement un jeu d'instructions différent.
Citer : Posté le 29/09/2020 14:39 | # |
Fichier joint
Un bout de conversation avec Kbd2, qui contient des informations intéressantes ; pour pas que ça se perde
Ajouté le 03/10/2020 à 18:43 :
J'ai pas mal progressé sur la question, ayant réussi à comprendre la logique majeure du DMA et déterminé la plupart des interruptions. Pour l'instant je ne sais pas encore comment programmer le DMA dans les détails, mais ça s'approche. Je crois que le DMA est complètement cassé aussi à cause de quelques bugs, mais je confirmerai avec les tests si besoin.
Comme l'émulation du DMA utilise beaucoup le mécanisme d'allocation de mémoire de l'émulateur, j'ai dû toucher à ça aussi.
J'ai également joué avec les interruptions et je pense avoir obtenu la liste exhaustive des signaux d'interruptions, par un ID interne mais aussi par les registres IMR et IPR. Il y a définitivement des choses passionnantes à sortir !
Pour l'instant, aucune trace de l'émulation du DSP en tant que processeur. Si ça se trouve il est pas émulé ; c'est encore trop tôt pour conclure mais je garde cette (triste) possibilité en tête.
Citer : Posté le 03/10/2020 21:43 | # |
Fichier joint
J'en profite pour donnée mes notes sur l'INTC (fichier joint). C'est toujours en cours de RE mais il me semble avoir trouvé le contrôle des interruptions venant des deux DSP(?) (IMRx et IPRx). Si tu arrives à me devancer dans la recherche de cette partie (ce qui sera forcément le cas vu le peu de temps que j'ai devant moi) tiens-moi au courant.
Citer : Posté le 07/10/2020 11:32 | #
Effectivement ce que tu as trouvé pour les DSP est correct (je l'ai redécouvert indépendamment). Dans l'émulateur les interruptions sont identifiées par des entiers de 8 bits. J'ai listé tous ces IDs internes pour lesquels une priorité peut être calculée (il y a une fonction qui renvoie ça), et aussi tous ceux pour lesquels la fonction qui active les interruptions est appelée. Mon but serait de partir de ça et ensuite de nommer tous les signaux qu'on a testé et vérifiés sur la calculatrice pour pas se retrouver avec des modules multimédias du SH7724 qui n'existent en fait pas.
J'ai préparé ça et intégré les infos dans ton fichier joint, merci ! Je publierai ça bientôt. J'ai les IPR et IMR pour presque tout avec juste un problème relatif à l'ADC à voir.
Citer : Posté le 07/10/2020 11:47 | #
Mes travaux sur l'ADC m'ont amené à penser qu'il y a plusieurs moyens de déclencher une mesure : via le DMA et/ou via un des TMU. Seulement, je n'ai réussi à trouver comment configurer l'ADC pour tester mes hypothèses. Mais je pense que ça pourrait t'aider dans tes recherches car il doit y avoir de la redirection d'interruptions possiblement émulée quelque part.
En tout cas, bravo pour tes découvertes, j'essaie de te rejoindre le plus vite possible dans la documentation du MPU
Citer : Posté le 08/10/2020 20:22 | #
Alright, j'ai presque fini de décortiquer le DMA. Il ne me reste qu'une poignée de paramètres à étudier, ensuite je pousserai mon début de doc sur la bible ! Stay tuned.
Si tout cela s'avère correct sur la calculatrice, ce que j'ai découvert complète ce que Yatis sait déjà et permettra de :
• Démarrer le SPU et ses DSP (ça Yatis sait faire).
• Accéder à la PRAM, la XRAM et la YRAM de chaque processeur (ça Yatis y arrive mes les tailles des zones sont louches).
• Utiliser le DMA pour copier efficacement des données entre la RAM normale et la XRAM/YRAM/PRAM de chaque DSP.
• Et quelques détails avancés de DMA, conversion de l'endianness, différentes tailles d'accès, etc.
Tout cela donnerait déjà beaucoup de mémoire rapide supplémentaire et serait un joli boost pour les add-ins ! Notamment pour remplacer la deuxième moitié de RAM (88040000:256k) qui était libre jusqu'à la Graph 35+E II mais plus depuis, utilisée notamment par C.Basic, CasioPython et FxGnuBoy.
C'est pas révolutionnaire mais ce sera une partie indispensable de tout usage optimal d'un DSP. Le tout après c'est que le DSP soit émulé dans la DLL sinon on ne peut rien faire avec. Si par chance le DSP est émulé, je pense qu'il y aura beaucoup à en tirer car il est apparemment conçu spécifiquement pour décoder de l'audio, la doc citant AAC et MP3. MP3 utilise des transformées trigo et de Fourier donc il doit définitivement y avoir du calcul en point fixe ou flottant disponible. Le DSP peut aussi recevoir des interruptions et contrôler le DMA sans l'aide du CPU donc il doit y avoir au moins des registres internes de 32 bits et des fonctions logiques/arithmétiques décentes. On croise les doigts !
Ajouté le 09/10/2020 à 11:16 :
Upload time! o/
Voici la version préliminaire de la doc d'après ce que j'ai tiré de l'émuateur. J'ai pas encore testé sur calto donc je ne vous conseille pas de le faire sauf si vous voulez faire du RE à proprement parler. Ce sera implémenté assez vite sur la branche dev de gint avec une API propre si vous voulez tester dans vos programmes.
Autre bonne nouvelle, le DMA intégré aux DSPs du SPU a un mode de transfert qui lit et écrit dans la XRAM et la YRAM en sautant les trous. Ça veut dire qu'on peut au moins archiver et récupérer des données quelconques dans ces zones de façon efficace sans s'embêter à gérer les trous. Ce qui est extrêmement pratique si vous avez des données lourdes mais que vous pouvez implémenter une politique de swap efficace !
Voici les pages que j'ai poussées sur la bible :
• SPU: DSP Reset
• SPU: DSP Interrupts
• SPU: DSP DMA channels (le plus complet !)
• INTC: Interrupt sources, comme discuté avec Yatis
Ajouté le 10/10/2020 à 17:58 :
J'ai fait d'autres découvertes aujourd'hui, et... je crois que j'aurai bientôt fini le module SPU. C'est surprenant à dire parce que je ne pensais pas qu'il était possible d'isoler proprement un module dans une aussi grosse DLL et de le désassembler de fond en comble.
Actuellement j'ai un grand bloc de code, entièrement désassemblé et bien compris dans l'ensemble, qui commence par la routine d'initialisation du SPU et se termine par le code d'écriture dans la RAM spécifique du SPU, qui est coincé entre du code du MSIOF1 (rien à voir) et du FSI (rien à voir non plus dans un certaine mesure).
Le plus gros, c'est-à-dire l'existence et l'utilisation de coprocesseurs DSP, reste à établir. Pour l'instant je n'ai pas vraiment de certitudes ; ils peuvent être émulés ailleurs, ne pas être émulés, ou ne pas exister. Pour l'instant on a probablement la RAM en plus, le temps que j'arrive à faire marcher ça proprement dans gint (avec quelques indices de Yatis), ce sera déjà bien.
Notez que je n'ai pas non plus vu la moindre trace de l'émulation du bon vieux processeur SH4 donc clairement je n'ai pas tout vu.
Ajouté le 12/10/2020 à 21:14 :
Update rapide après pas mal de discussion avec Yatis. Deux mauvaises nouvelles essentiellement :
• Les DSP du SPU ne sont probablement pas émulés voire pas présents sur la calculatrice.
• La PRAM et la XRAM est probablement partagée entre les deux DSP, ce qui réduit la quantité de RAM supplémentaire à ~450k.
Bon tout ça reste pas dégueu. Je vais refaire un tour sur le DSP intégré pour voir si on peut l'abuser d'une façon ou d'une autre.
Ajouté le 21/10/2020 à 11:03 :
Time for a summary of the discoveries so far (in English since it's an important one x3).
Available SPU memory:
• PRAM0: 160 kiB, 4-byte access only, continuous
• XRAM0: 224 kiB, 4-byte access only, every 4th byte is not writable (total memory: 168 kiB)
• YRAM0: 64 kiB, 4-byte access only, every 4th byte is not writable (total memory: 48 kiB)
• YRAM1: 64 kiB, 4-byte access only, every 4th byte is not writable (total memory: 48 kiB)
Total memory: 424 kiB, 62% with holes
Non-existence or non-availability of the SPU DSPs:
The SPU normally comes with two DSPs, DSP0 and DSP1, but there is no trace of any emulation code and no documentation so even if they exist we don't know how to use them.
Availability of the SH-4AL integrated DSP:
Our CPU, the SH4-AL, comes with an integrated DSP that has a limited but usable instruction set along with two memory regions called XRAM and YRAM of 8k each. This is our fastest processing unit because of high data/memory parallelism and a decent lead for computation-intensive tasks and color manipulation.
SPU memory sharing mechanisms:
All the SPU memory can be accessed from the CPU and the integrated DSP. Parts of PRAM0 and XRAM0 (which belong to DSP0) can be shared with DSP1 (in two regions called PRAM1 and XRAM1) with a bank mechanism, but we mostly don't care because we don't have these DSPs and we can already access all of the memory from PRAM0 and XRAM0.
SPU DMA for fast access to SPU memory: (still under testing)
The SPU comes with some DMA channels that allow fast access to PRAM0, XRAM0, YRAM0 and YRAM1. In particular, these channels have a "compacting mode" that store or retrieve continuous data to and from XRAM0, YRAM0 and YRAM1 by skipping the holes, which would make for a very efficient storage method.
Ajouté le 23/10/2020 à 23:11 :
Voici le fonctionnement détaillé du partage de mémoire SPU entre les deux DSP.
Il y a 5 pages de PRAM et 7 pages de XRAM, toutes de 32 kiB adressables (32 kiB de données par pages de PRAM, 24 kiB de données par page de XRAM). Ces pages peuvent être attribuées soit à DSP0, soit à DSP1.
Le registre PBANKC0 possède 5 bits représentant le statut de chaque page de PRAM pour DSP0. Avoir le bit n à 1 indique que la page n est accessible depuis DSP0, c'est-à-dire depuis PRAM0 (fe200000). Avoir le bit à 0 indique que la page n'est pas accessible. PRAM0 est toujours continu, donc si seules les pages 0 et 2 sont actives pour DSP0, alors fe200000 pointera vers la page 0, fe208000 pointera vers la page 2, et toue le reste à partir de fe210000 pointera dans le vide.
Il en va de même pour PBANKC1 vis-à-vis du DSP1. Les pages sont exclusives et on ne peut pas y accéder depuis les deux DSP en même temps ; si le bit d'une page est à 1 à la fois dans PBANKC0 et PBANKC1, alors la page est attribuée à DSP0 et invisible depuis DSP1.
La XRAM fonctionne pareil au détail près qu'il y a 7 pages et pas 5. Les registres PBANKC0, PBANKC1, XBANKC0 et XBANKC1 ont tous 24 bits en lecture-écriture mais seuls les 5 (PRAM) ou 7 (XRAM) premiers ont un effet.
La YRAM est privée, et contient 64 kiB de mémoire adressable pour chaque DSP (48 kiB de données, pour un total de 96 kiB).
Ajouté le 24/10/2020 à 00:15 :
J'ai mis à jour la documentation du SPU sur la bible avec ces informations. Encore un grand pas sur la documentation et le test de toutes ces choses !
Je n'attends plus de nouvelle fonctionnalité sur le SPU désormais, donc je planifie uniquement de documenter proprement ce que j'ai trouvé, et de bien tester ce qu'on peut sortir de performant sur les transferts de données, le DMA, et le DSP intégré du SH4-AL.
Citer : Posté le 11/11/2021 22:56 | #
Hi,
Apologies for the English but this seems to be the only active place for low-level discussion. I am interested in researching undocumented HW and was wondering if the register names discussed (DSPCORERST etc) are official, I can only find them referenced here with no source to be found, are they from the renesas emulator you mentioned?
Citer : Posté le 12/11/2021 11:18 | #
Hi! Nice to see people interested in the low-level stuff
Yes, they're from the emulator. But SimLo often did not explain how he got the information, so I believe no one on Planète Casio knew until I re-discovered it last year... I got them by reverse-engineering data tables from CPU73050.dll.
Anyway yes they're official, and you can find my slightly-more-detailed reference here.
Note that as far as the SPU2 DSPs are concerned we don't know whether they exist on the SH7305 and we don't know the instruction set, which apparently is not emulated. So doing anything with them would be quite hard.
Citer : Posté le 12/11/2021 12:06 | #
Super intéressant, ça peut donner l'opportunité de créer des shaders et du post processing du rendu.
J'ai déjà mis en place un post processing de l'image dans Windmill qui permet d'accentuer les contours des objets.
Mais ça prend des perfs car à la fin du rendu avec le CPU.
Très prometteur mais ça risque de complexifier pas mal la mise en oeuvre
D'ailleurs c'est qui ce SimLo ? Tout le monde en parle depuis des années et qu'il a tout trouvé, j'ai l'impression que c'est une sorte de prophète...
Citer : Posté le 12/11/2021 12:12 | #
En soi, c'est un peu moins joli que ça. C'est parce que d'un côté les DSPs du SPU n'existent probablement pas (ou sont inutilisables), et d'un autre le DSP intégré n'est pas aussi puissant que je l'espérais, ou plus précisément le CPU est plus puissant que je ne l'imaginais, ce qui limite l'intérêt du DSP.
Mais j'ai quand même un moteur de rendu expérimental capable de faire des trucs pétés avec la mémoire on-chip et les optimisations que je connais en assembleur ; il y a des détails ici. Sur la Graph mono ce serait plus facile parce que la mémoire est bien moins un problème.
Simon Lothar, un membre de la communauté allemande qu'on trouvait sur Omnimaga et Casiopeia à une époque. (Ce n'est pas son vrai nom.) Il a fait beaucoup de reverse-engineering avant tout le monde, et en particulier il a décortiqué l'OS, le protocole de communication (Protocole 7, celui de FA-124), beaucoup beaucoup de syscalls, le fx-9860G SDK... en plus de ça il a proprement documenté ce qu'il faisait, ce qui a fait de son travail une référence.
Edit : Il n'était pas tout seul (Andréas Bertheussen était dans les premiers PDF de fxReverse par exemple), mais c'est surtout lui qui ressort.
Aujourd'hui beaucoup de choses ont changé et personne n'a trop remis les infos au goût du jour, donc tout n'est plus valide ; heureusement l'OS n'évolue pas vite donc la majorité l'est encore. Le type de reverse-engineering qu'on fait sur Planète Casio (MPU, matériel, tout ce qui contourne l'OS) ne touche pas tout à fait aux mêmes objets. Tout le travail de SimLo reste donc plutôt unique et régulièrement utilisé.
En bref, c'est une grande figure du reverse-engineering sur la plateforme
Citer : Posté le 12/11/2021 15:20 | #
Note that as far as the SPU2 DSPs are concerned we don't know whether they exist on the SH7305 and we don't know the instruction set, which apparently is not emulated. So doing anything with them would be quite hard.
Considering that the SPU is present I hope that the DSPs do exist since they seem to be a sunblock of it.
I think the best course of action for the DSPs is to try and obtain the FW off of a SH-Mobile3 feature phone and reverse engineer that (a brief list of them is here , I am currently researching to see if any have published updates). There are also Samsung phones using the newer SPUV with somewhat more easily obtained firmware, might try that first since I have it on hand but will have to see if the instruction set is the same.
Either way once the FW is obtained reversing the instructions set from it will take a while, especially if it's variable length or something.
. I got them by reverse-engineering data tables from CPU73050.dll
I shall have a look at that, is it included with the Casio emulator package?
On another note, there are a bunch of other HW blocks mentioned in the HW manual, (2D engine, VPU etc), is it known if these are present?
Citer : Posté le 12/11/2021 15:59 | #
That'd be pretty cool! If the phones use the DSPs at least.
Yes. Yatis and I have a shared Ghidra project with some useful annotations, plus some tooling to show lists and properties of registers and pins; it's not very polished but you could start here if you want.
No. They're not emulated and there are no traces in actual hardware. All of these are SH7724 stuff, the kind of multimedia modules designed for phones and car GPS and other advanced systems, which is the main thing not present in the SH7305. That's why I'm slightly wary of comparing with SH-Mobile platforms, I'm not very confident that the knowledge would apply.
Citer : Posté le 13/11/2021 23:55 | # |
Fichier joint
As a brief update I managed to get the SPUV FW from a samsung device and have been looking through that, instructions in this 32 bits long and searching up some repeated byte patterns online leads me to this part so there's a chance it's an already documented architecture.
But before I look too far into the SPUV FW I need to verify that it is indeed the same architecture as the SPU2's DSP (if it exists) so I have started writing a test program for running code on it. Am I correct that PRAM can only be written to via SPUDMA? My attempt at writing it normally without DMA resulted in strange behaviour:
* Before SPU power on: Most of PRAM is 0 however every third byte is 0xFF.
* After SPU reset: Same however every second byte is 0x1.
* Also I can't have more than two calls to store_pram, a third will always result in my calculator freezing, this is probably a memory leak or something and not related to PRAM.
I have attached my test program below if it is useful for anyone (rename to main.cpp)
Citer : Posté le 14/11/2021 09:21 | #
Great work, thanks! The ARTIC chip seems to match as far as memory layout and access sizes go, which is already pretty good. The instruction set of the DSP itself is not documented though, only these 8-bit commands that are defined at the chip level.
What kind of device did you use exactly? "SPUV" doesn't bring up anything suggestive in search results. Also what type of firmware did you dump? Was it the OS/kernel, libraries?
Your assumption is, fortunately, incorrect. You can absolutely write to PRAM (and XRAM/YRAM) with the CPU, you just need to use a 4-aligned address and you can only perform 4-byte accesses. Please see this document first.
I don't think the CPU will crash by initializing the DSP with an invalid program so your crash is probably a "trivial" bug. Note that we don't have full C++ support because it's kind of complicated. If possible I'd first externalize the lambdas as functions and only use C features, because all this code on the stack is an added "risk" (in terms of possible bugs lying around).
Oh before I forget the interrupt vector for DSP is 0xce0, not 0xcc1. The increment is 0x20. Any priority is fine. Also if you don't clear interrupt request flags in your handlers you'll likely freeze at the first interrupt.