TI-NESulator - Page 9

héhé optimisation powa
godzil si t'

Optimisation powa

godzil qi t'

grrrrr salte de portable..
bon godzil si t'as besoin d'aide je suis en vacances

Allé quelquers nouvelles (désolé y en a pas eu bcp ses derniers temps)

je suis en train d'ecrire le nouveau core CPU 100% ASM 68000

J'espere que sa a speeder now

(et va falloir que je le débuggue attentivement aussi je sais que sa va bien foirer au début )

Aussi je vais changer la gestion de la mémoire en esperant que sa gagnera en vitesse
et je commence aussi a préparer l'interface utilisateur

Sa va cartonner

ASM 68000

L'ASM est vraiment très rapide, heuresement que j'ai fait PolySnd en ASM.

Aussi je vais changer la gestion de la mémoire en esperant que sa gagnera en vitesse

Tu procéde comment?

pour l'instant un peu bourrin et apres
TRES bourrin

JE dirait plus ou moine de la meme maniere que le malloc que genalib

Ta une table?
Pour faire un allocation ça ce passe comment?

je sais pas trop comment PpHd a fait pour faire "sauter" la limite des 64Ko, mais j'ai mon id et je planche dessus (il faut que je soit sure que sa marche a 100%..) et c'est con il me manque juste qq Ko pour pouvoir utiliser ma méthode "bourin" (les TI ne permettent pas d'allouer reelement 65535 Octets.. meme si la mémoire est "paginée" en bloc de 64Ko)

Demande à pphd ou regarde les sources de pedrom. Je pense qu'il pourras t'aider voir te donner le code.

le pbm c que le code de pedrom ne passe pas par le TIOS et sa serait etonant que l'allocateur qu'il exporte sous PedRom soit une "surcouche" a un allocateur qui fonctionne comme celui du TIOS

J'ai deux méthodes en vus, mais je pense utiliser la plus propre (comme de tte l'allocation ne se ferra qu'au démarrage du programme sa devrait pas poser de pbms de rapidité..)

Bas si ça ce fait au démarrage du prog, oui pas de pb de rapiditée. Mais si pour y accéder... c'est long là faut ce poser des questions.

non sa sera pas long sa c'est sur et sa risque meme de bcp accelerer par rapport a actuellement (pour les accé mémoire)

enfin a voir

La seule méthode propre est d'utiliser 2 blocs et un truc du style:

tst.w %d0
jblt bloc2
jmp 0(%a0,%d0:w)
bloc2:
jmp 0(%a1,%d0:w)

Ton émus et parfaitement réalisable avec un bon fps, d'autant plus contrairement à l'emu de GameBoy tu n'as pas besoin de traduire les instructions, puisque la nintendo fonctionne avec un 68000 identique au TI68K.

La seule méthode propre est d'utiliser 2 blocs et un truc du style:

tst.w %d0

jblt bloc2
jmp 0(%a0,%d0:w)
bloc2: jmp 0(%a1,%d0:w)

J'avoue qyue cette idée avait traversée mon esprit mais je la trouve assez barbare ert peu 'propre'.

C'est beaucoup plus propre que de se hacker un bloc de 64 KO!

geogeo
: Ton émus et parfaitement réalisable avec un bon fps, d'autant plus contrairement à l'emu de GameBoy tu n'as pas besoin de traduire les instructions, puisque la nintendo fonctionne avec un 68000 identique au TI68K.

Non, c'est un 680x, pas un 680x0. C'est totalement différent.

680x

Ah bon.

L'architecture et les instructions sont identique?
68K chez moi c'est 68000, j'ai vu de nombreuse fois ça au sujet de la nintendo.

geogeo
:

680x

Ah bon.
L'architecture et les instructions sont identique?

Kevin Kofler
: C'est totalement différent.

C'est totalement
différent.

lol, aie.

C'est comme si tu me disait que les Game Boy n'était pas équipé du même Z80 que les TI83...

C'est un 6502 (pas un 6809 ou autre) -> Aucun rapport avec motorola (si se n'est que ceux qui on fait le 6502 on bossé a un moment chez motorola.)

Kevin Kofler :
La seule méthode propre est d'utiliser 2 blocs et un truc du style:

tst.w %d0
jblt bloc2
jmp 0(%a0,%d0:w)
bloc2:
jmp 0(%a1,%d0:w)

Hum je suis pas vraiment sur que ton code marche a tout les coups

si je m'abuse tu utilise "bloc 2" que si d0.w = 0x0 (ou l'inverse : tu utilise bloc2 que si d0.w != 0x0)

et pi je peut pas malheureusement me permettre de rajouter des cycles en trop (le test + jmps) en plus la consomation de registre d'un emu de cpu optimisé est assé importante
D'ailleur il faut que je teste l'impact du SMC plutot que d'une instruction "normale"
franchement il faut que j'ai 65535 Ko consécutif sinon se n'est meme pas la peine
et ma méthode est loin d'etre "sale" dans le sens qu'elle ne laissera jamais la TI dans un etat non connu a la sortie.

geogeo
: C'est comme si tu me disait que les Game Boy n'était pas équipé du même Z80 que les TI83...

Mais c'est le cas! Le "GB-Z80" n'est pas un Z80. Il ressemble à un Z80, mais il y a des différences dans le jeu d'instructions.

aucune console Nintendo n'utilise de processeur motorola (sauf ptet si on regarde de loins le PPC de la GameCube est du a l'accord Apple/Motorola/IBM, mais bon faut pousser le bouchon un peu loins la)

Pour infos :

La NES utilise un 6502 customisé (certaines instruction manquantes on incompletes et gestion du son en hard dans le CPU) le 6502 est un CPU 8 Bit

La SNES utilise la version 16Bit du 6502 (qui porte un "nom" barbar genre 65316 ou un truc du genre)

la GameBoy/Coloc/Pocket utilise un Z80 (a priori standard) (8Bits donc)

la Nintendo 64 utilise un CPU de type Mips (arreter moi si je me trompe) et il s'agit d'un véritable CPU 64Bits

La GameCube utilise un PPC spécialement fabriqué pour nintendo (et il s'agit d'un CPU 32Bits ! sisi ! contrairement a se qu'on laisse entendre (génération "128 bits") les 128bits en question ne sont qu'un des registre d'un DSP trainant qq pars sur la carte mere , d'ailleur la PS2 et la Xbox sont ttes les deux des consoles 32bits aussi)

La GameBoy Advance utilise un CPU ARM (32 doncs)


Le 680x dont parlait kk est le non moins connu 6809 (il y en a eu d'autre dans cette série) qui est un proco 8Bit et dont le coeur a été largement reutilisé dans la série des microcontroleurs 68HC11

godzil :
Hum je suis pas vraiment sur que ton code marche a tout les coups
si je m'abuse tu utilise "bloc 2" que si d0.w = 0x0 (ou l'inverse : tu utilise bloc2 que si d0.w != 0x0)

J'utilise le bloc 1 pour d0.w>=0 en signed, c'est-à-dire d0.w<32768 en unsigned, et le bloc 1 pour d0.w<0 en signed, c'est-à-dire d0.w>=32768 en unsigned.

et pi je peut pas malheureusement me permettre de rajouter des cycles en trop (le test + jmps)

Tu te fiches de ma gueule? Ça te fait un tst.w et un blt.s. En tout 12 cycles pour le bloc 1 et 14 cycles pour le bloc 2.

franchement il faut que j'ai 65535 Ko consécutif sinon se n'est meme pas la peine

Bref, tu préfères faire planter nos machines plutôt que de sacrifier 14 cycles? Je n'utiliserai donc certainement pas ton émulateur. (La même chose est valable pour TeZXas et TIGB qui utilisent le même hack, d'ailleurs. J'ai déjà eu assez de plantages avec TeZXas, ça me suffit...)

godzil
: la GameBoy/Coloc/Pocket utilise un Z80 (a priori standard)

Pas du tout, c'est une variante personnalisée du Z80. (Et ça j'en suis sûr contrairement au numéro de modèle du processeur de la NES. )

aucune console Nintendo n'utilise de processeur motorola (sauf ptet si on regarde de loins le PPC de la GameCube est du a l'accord Apple/Motorola/IBM, mais bon faut pousser le bouchon un peu loins la)

Pour infos :

La NES utilise un 6502 customisé (certaines instruction manquantes on incompletes et gestion du son en hard dans le CPU) le 6502 est un CPU 8 Bit

La SNES utilise la version 16Bit du 6502 (qui porte un "nom" barbar genre 65316 ou un truc du genre)

la GameBoy/Coloc/Pocket utilise un Z80 (a priori standard) (8Bits donc)

la Nintendo 64 utilise un CPU de type Mips (arreter moi si je me trompe) et il s'agit d'un véritable CPU 64Bits

La GameCube utilise un PPC spécialement fabriqué pour nintendo (et il s'agit d'un CPU 32Bits ! sisi ! contrairement a se qu'on laisse entendre (génération "128 bits") les 128bits en question ne sont qu'un des registre d'un DSP trainant qq pars sur la carte mere , d'ailleur la PS2 et la Xbox sont ttes les deux des consoles 32bits aussi)

La GameBoy Advance utilise un CPU ARM (32 doncs)

Le 680x dont parlait kk est le non moins connu 6809 (il y en a eu d'autre dans cette série) qui est un proco 8Bit et dont le coeur a été largement reutilisé dans la série des microcontroleurs 68HC11

Merci pour toute ses infos, je suis étonné.

Kevin Kofler
:

godzil :
Hum je suis pas vraiment sur que ton code marche a tout les coups
si je m'abuse tu utilise "bloc 2" que si d0.w = 0x0 (ou l'inverse : tu utilise bloc2 que si d0.w != 0x0)

J'utilise le bloc 1 pour d0.w>=0 en signed, c'est-à-dire d0.w<32768 en unsigned, et le bloc 1 pour d0.w<0 en signed, c'est-à-dire d0.w>=32768 en unsigned.

et pi je peut pas malheureusement me permettre de rajouter des cycles en trop (le test + jmps)

Tu te fiches de ma gueule? Ça te fait un tst.w et un blt.s. En tout 12 cycles pour le bloc 1 et 14 cycles pour le bloc 2.

franchement il faut que j'ai 65535 Ko consécutif sinon se n'est meme pas la peine

Bref, tu préfères faire planter nos machines plutôt que de sacrifier 14 cycles? Je n'utiliserai donc certainement pas ton émulateur. (La même chose est valable pour TeZXas et TIGB qui utilisent le même hack, d'ailleurs. J'ai déjà eu assez de plantages avec TeZXas, ça me suffit...)

il me manque moins d'1Ko pour avoir pleinement un bloc de 65535Ko d'ailleur tu ne sais meme pas quel genre de "hack" je compte faire et Texzas est vieux et a mon avis plus que buggé donc il ne s'agit surement pas d'une référence en la matiere de bonne programmation asm actuellement

le pbm de ta méthode c'est qu'il faudrait l'utiliser pour TOUT le jeux d'instruction du 6502 emulé et pas juste a un seul endroit je prefere largement allourdir un peu le code plutot que de faire des sauts de partout (1 saut = plusieurs cycle de perdu a "rien" faire)

de toute facon je ne te force pas a utiliser mon emulateur, tu est libre de l'utiliser ou non. et de tte cette méthode n'est pas encore mise en place et il faudra qu'elle fasse ses preuves a mes yeux (c pas gagné encore) d'ailleur le pbm de ta méthode par rapport a ton idée est que je n'utilise pas un registre de donnée pour emuler le PC du 6502 mais un registre d'addresse (pour eviter de sacrifier des cycles a calculer des valeurs d'indexà il y en a deja dans tout les sens a faires (les modes d'addressages du 6502 sont assé etrange, et la pile aussi est "bizzare")

la mégadrive utilise un 68k

oui mais l'ému mégadrive, je sais pas porquoi je le vois mal parti

oué

surtout qu'il y a pas qu'un 68000 dans la genesis...