La fréquence du CPU ne fait pas tout malheureusement.

(exemple, la SNES, le CPU tourne entre 1.5 et 3Mhz, ça ne la rend pas facile a émuler pour autant.)
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Moi aussi je commence a faire joujou avec le toolchain sur Emu (j'ai pas de NSpire).

Points de vue performances, on est très proche (+ freq CPU, + 4xRAM) que la GP32.
Donc potentiellement on pourrais faire tourner les mêmes émus de la GP32 sur NSpire :
- voici la liste http://dl.openhandhelds.org/cgi-bin/gp32.cgi?0,0,0,0,5

SNes, NGPC, WonderSwan Color PCE, GBA, Mame....
La GP32 a un hard dédié pour les graphismes ce qui n'est pas le cas la...
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
A mon avis à 100 MHz déjà Game Boy Color ça va être assez tendu pour le faire bien (sans frameskip, avec les rasters).
Pour la Mega Drive ça doit être faisable sans raster et sans son (et sans Z80), mais pas mal de jeux risquent d'être moches et certains pas se lancer. Plus, ce serait +/- du miracle mais pas impossible ^^
Pour la SNES ce n'est pas vraiment réaliste.
avatarHighway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741
Godzil : La gp32 n'avais pas de hard dédié au jeu. Elle avait juste un ARM 920T. Et rien d'autre.
non Godzil, la gp32 est nue, un arm qui tourne généralement de 16mhz à 166mhz, 8mo de ram, un écran 320*240 16b, des bouton et un port smc.

Concrètement le contrôleur gère derrière du dma, possède un mmu, et fait 3/4 conneries qui ne servent à rien, utilisé seulement par mr spiv pour des proof of concept.

Brunni, la gbc fonctionnais parfaitement avec le son et sans frameskip sur les 133mhz de la gp, plus généralement je jouais sans son à 33mhz (avec un stretch simple qui bouffais pas trop et un frameskip de 1 ou 2)
Je viens de chercher les specs du CPU, il est clairement bien supérieur à celui de la GP32 (en plus du fait de pouvoir monter plus haut en freq).
Il y a 4x plus de RAM de dispo (voir combien le system en squoitte pour lui), et d'après mon souvenir, le BUS de la GP32 était assez bas < Nspire.

C'est vraiment super, ca laisse de belle perspectives pour l'avenir.
je sais pas si avoir une console de ouf en classe laisse présager de bonnes choses pour l'avenir cheeky
r043v (./35) :
Brunni, la gbc fonctionnais parfaitement avec le son et sans frameskip sur les 133mhz de la gp, plus généralement je jouais sans son à 33mhz (avec un stretch simple qui bouffais pas trop et un frameskip de 1 ou 2)

133 c'est déjà plus simple, mais il faut quand même le faire bien ^^
Pour une émulation correcte sans assistace matérielle, je dirais qu'il faudrait au moins 50~66 MHz. Mais à ce niveau c'est de la belle optimisation (typiquement au-dessus de mes compétences -- et de ma patience accessoirement grin).
avatarHighway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741
tout dépend de ce que tu appelles "correcte" à 33mhz je jouais surtout à mario1, tennis color et les zelda, et c'était parfaitement jouable

après pourquoi recommencer du début alors que sur gp tout est déjà fait ?
ta "juste" à refaire les entrées sorties et vérifier quelques bouts de code spécifiques

je viens de regarder le source de fgb que j'avais inclus dans mon firmware, le fichier C principal spécifique à la gp fait 17ko et à coté il y à 85ko de code divers pour la gp (menu graphique selection de rom/récupération de fichiers/zlib, lecture zip/lecture son/...)

et même pas de fichiers asm ^^
Screen
240x320, 16 grayshades LCD screen.
l'écran est tourné de 90° la aussi ?
Le CPU est un OMAP1 c'est certain (donc MMU non standard) par contre la ref exact est incertaines, il me semble que c'est proche d'un OMAP85x (sans les IPs GSM)

Il doit etre assez simple, vu qu'on a le controle sur l'OS de regarder les registres des devices autour de l'OMAP pour voir si il correspond plus a un OMAP85x ou un de la branche des OMAP1710 (de mémoire de mes discutions, c'était plutot dans les 85x qu'il faut chercher)

omap850: http://www.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12000&contentId=4679

omap1710: http://www.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=11991&contentId=4670
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
y'a pas des registres style CPUID qu'on peut dumper pour avoir la réponse?
Il y a des identifiant oui en effet
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
Ces registres ont déjà été dumpés, voir des topics un peu plus anciens des sections Nspire de yAronet smile
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
r043v (./39) :
le fichier C principal spécifique à la gp fait 17ko

aaaaaaaaargh couic2
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
C'est peu, pourtant grin
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Oh, je me doute bien qu'il y a pire dans certains softs, oui, je me demande juste comment on fait pour s'y retrouver...
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Non, vraiment 17Ko c'est pas grand chose.
Vérifie ton code source, je suis sûr que tu en as plein dans ces environs.
Surtout si tu commentes un minimum, ça monte rapidement.
ma version, allégée au max http://www.mirari.fr/gEfI
version originale de rlyeh http://www.mirari.fr/HVRk
L'OS des Nspire bouffe beaucoup de RAM, car il est déchiffré puis décompressé en RAM. L'embonpoint de l'OS augmente au fil des versions: avec 3.1.0.392, sur Clickpad / Touchpad, il faut compter plus de 11 MB rien que pour l'OS.

Même potentiellement plus puissante, la Nspire reste beaucoup moins programmable, et programmée, que la GP32. Le fait est que depuis deux ans que l'exécution de code arbitraire a été démontrée pour la première fois, la plate-forme Nspire n'intéresse pas grand monde: il y a toujours peu de programmes en code natif, pas de distro Linux, pas de programmation C++ full-featured, pas de librairie graphique sérieuse, le chargement dynamique de code est en beta, etc.
Davantage de développeurs motivés ferait le plus grand bien à la plate-forme Nspire... mais voilà, bien qu'on ne manque pas d'idées (voir ce topic, ou si on remonte dans le temps, des topics comme http://www.unitedti.org/forum/index.php?showtopic=9384 - mai 2010...), on manque de temps libre, tous autant que nous sommes wink

Finalement, on aurait peut-être dû passer du temps sur un Ndless pour l'OS 3.0.1.1753, grâce à l'exécution de code arbitraire rapidement connue. Même si ça n'était pas utilisable pour l'OS 3.0.2.1791. Mais comme toujours, le revers de la médaille de la publication d'une faille est sa correction rapide.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
Le problème vient aussi probablement de l'absence de développeurs dans la nouvelle génération... Perso, à l'époque des ti68k, je ne pouvais pas compter sur un grand frère pour développer à ma place...
avatarWebmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca
Tout à fait smile
Les "jeunes" programment sur d'autres plate-formes plus puissantes et plus accessibles (quand ils programment - il y a une désaffection certaine pour les métiers scientifiques en général, il est vrai que ça paie moins que d'autres métiers), et les "vieux" que nous sommes n'ont plus vraiment le temps...

Pour ne rien arranger, le plus probable est que la prochaine version de l'OS Nspire, qui sortira vraisemblablement dans quelques semaines, verrouille tout encore une fois sad
On pourra se réjouir profondément si ce n'est pas le cas, mais il ne serait pas raisonnable de supposer, et de laisser les gens supposer, le contraire...
Les utilisateurs ne comptent pas pour TI; ceux qui comptent pour le business model de TI sont les comités de réglementation des examens, et les profs.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.
les premiers définissants quels produits seront autorisés, les seconds conseillant leurs étudiants sur le modèle à choisir...
avatarWebmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca
J'ai commencé une petite lib (rien d'extraordinaire).
/* * Double buffer management. */ // Init the double buffering managements. extern void InitScreen(unsigned short screenWidth, unsigned short screenHeight, unsigned char screenDepth); // Init the double buffering for TI-Nspire CX. extern void InitScreenNspireCX(); // Swap the screens. extern void SwapScreen(void); /* * Clear screen management. */ // Clear screen with a color. extern void ClearScreenWithColor(unsigned short int color); // Clear screen in black. extern void ClearScreenBlack(void); // Clear screen in white. extern void ClearScreenWhite(void); /* * Drawing functions. */ // Set a pixel with a color. extern void SetPixel(int x, int y, unsigned short int color); // Get a pixel color. extern void GetPixel(int x, int y, unsigned short int color); // Draw a line with a specific color (Bresenham's line algorithm). extern void DrawLine(int x0, int y0, int x1, int y1, unsigned short int color); // Draw a rect. extern void DrawRect(int x, int y, int width, int height, unsigned short int color); // Draw a filled rect. extern void DrawRectFill(int x, int y, int width, int height, unsigned short int color); // Draw a circle. extern void DrawCircle(int x, int y, int r, unsigned short int color); // Draw a sprite. extern void DrawSprite(int x, int y, int sizeX, int sizeY);


Hier j'ai fini le draw sprite (unsecure, pas de blit, ni de clip)
Ducoup le "Plop from inside" est dispo sur la CX.

boo_cx_screen.PNG
Meme si l'OS NSpire bouffe 11 Mo, la RAM dispo est toujours supérieur au 8Mb de la GP32.
La RAM ne fait pas tout
avatarProud to be CAKE©®™
The cake is a lie! - Love your weighted companion cube

->986-Studio's Wonder Project!<-
yN a cassé ma signature :o
vous pouvez peut-être taper dans les millions de fonction de blit de la gp, tourné de 90° aussi trioui

après la gp c'est du 8b ou du 16b en 5.5.5.1
Sympa iceman, par contre ça te dirait pas une lib tournée façon SDL, plutôt que de proposer des primitives ?
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Je te ferai la même suggestion que pour nRGBlib: utiliser les types de stdint.h, plutôt que "char", "short" et "int" smile
Suivant ce qu'on cherche à remplacer, ils sont plus courts ("unsigned short int" -> "uint16_t") ou plus longs (char -> uint8_t) à écrire, mais plus précis.
Aussi, ta fonction GetPixel me paraît curieuse (copier-coller ?), je penserais plutôt à "uint16_t GetPixel(int x, int y);" smile
(ou même en utilisant typedef uint16_t Color; pour masquer le type)

Un truc qui n'a à ma connaissance pas vraiment été essayé, c'est de piloter en 16 bpp l'horrible écran des Clickpad & Touchpad. On sait qu'il supporte 8 bpp, nDOOM l'utilise ainsi. Mais il y a des chances qu'on ne puisse quand même pas, par ce biais, utiliser les mêmes graphismes sur CX / CM et sur Clickpad / Touchpad.

Pour info, j'ai fait des routines de tile (sprite aligné) 8x8 en 4 bpp, et j'ai commencé une routine de sprite 8x8 smile
Bien sûr, en essayant de tirer parti du retour d'expérience d'ExtGraph, ce qui veut dire: utilisation de macros dans le code ASM !!

La conversion R5G6B5 -> G4 coûte cher. Aucune lib performante ne peut chercher à gérer les modes 4 bpp et 16 bpp avec les mêmes fonctions; mais d'un autre côté, séparer les jeux de fonctions et de sprite veut dire que les possesseurs de Clickpad / Touchpad vont vite se trouver ostracisés, à cause de l'écran à pleurer, et du boulot supplémentaire que nécessite l'utilisation de deux jeux de graphismes.
Et en effet, nous sommes plusieurs à avoir suggéré SDL.
avatarMembre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.