Prog compatible - Page 1

http://leonard.oxg.free.fr/articles/multi_atari/multi_atari.html explique comment rendre une démo compatible

Ca partait d'un bon sentiment, mais il y a des choses qui me font tout de meme bondir quand on veut faire du code propre. On est en 2004, il y a des choses qu'il ne faut pas montrer aux enfants quand meme:

- Section 4: Taper dans les registres hardware quand on a des fonctions systèmes.
C'est assez facile d'appeler le xbios avec le bon numéro de mode vidéo pour avoir un 320x200 sur rgb ou 320x240 sur vga. Et puis du 50Hz en vga, beurk. Surtout si le possesseur de la machine a changé l'horloge qui va au VIDEL, grillage de moniteur possible.

- Section 5: Les caches ça sert à rien, faut les couper.
Quand on achète une machine rapide (Mega STE, TT ou CT60 maintenant), c'est pas pour la rabaisser au niveau d'un ST. Si on peut détecter le CPU qu'on utilise avec le cookie _CPU, c'est facile d'avoir des routines qui marchent avec chaque CPU, et pas besoin de code généré sur TT ou CT60 (surtout avec de la Fast-RAM).

- Section 6: Accès direct au FDC.
Ya des fonctions XBIOS pour accéder aux pistes d'un lecteur de disquette (bon c'est vrai que ça marchera pas en overscan). En plus les routines du XBIOS se débrouilleront avec les caches du CPU, donc double avantage.

Le haut parleur interne du Falcon: tous ceux que je connais l'ont débranché.

- Section 7: Les timers du MFP
Et si je vous disais que là aussi, ya des fonctions du XBIOS pour ça, vous me croyez ?

- Section 8: movep sur 68060
Rien à redire cette fois, à éviter donc (ou utiliser une autre routine, comme pour éviter de désactiver les caches).

Si je parle des fonctions du XBIOS, c'est parce qu'elles sont accessibles quand on boote une disquette. Et si ça vous embete de faire un boot sector customisé pour votre disquette, vous pouvez lancer votre démo du dossier AUTO.

Et j'en profite pour dire que j'avais justement fait des programmes pour montrer comment utiliser le hardware Atari en passant par les différentes API systèmes (et le hardware si pas d'API système disponible). Si vous avez des idées de programmes d'exemple à faire, contactez-moi:
http://membres.lycos.fr/pmandin/index.php?page=perso-utils#cleancode

Merci de ces précisions Patrice, et bienvenue sur le forum dev atari

merci

moi de toute façon je fais que des modifs hard...

... et il s'en vante l'animal !

Arf oui, c'est vrai que MOVEP n'existe pas sur 68060 Je me demandais pourquoi SSAVCALL plantait sauvagement sur ma CT60 quand j'utilisait MOVEP pour remplir mes tableau GEM. Et moi qui croyais à tord que c'était les caches qui étaient en cause Arf... Remarque Patrice, Motorola à bien jarté les instructions CALLM et RTM du 68030 alors qu'ils venaient de les mettres dans le 68020. Et putain, quel bonheur que ces instructions ! Enfin, allez comprendre des fois ce qui motive les gars de chez Motorola :/

Kochise

- Section 5: Les caches ça sert à rien, faut les couper. Quand on achète une machine rapide (Mega STE, TT ou CT60 maintenant), c'est pas pour la rabaisser au niveau d'un ST. Si on peut détecter le CPU qu'on utilise avec le cookie _CPU, c'est facile d'avoir des routines qui marchent avec chaque CPU, et pas besoin de code généré sur TT ou CT60 (surtout avec de la Fast-RAM).

D'accord ave toi, couper les caches du 060 c'est comme rouler avec un moteur de 2CV dans une Ferrari, bof
D'un autre côté, si la démo est prévu pour un ST et tourne déjà la VBL, on peut comprendre l'intérêt de couper les caches et de pas s'embetter avec...
Sauf si biensûr si on fait une version + de la démo (genre planar 8 bits).

Le haut parleur interne du Falcon: tous ceux que je connais l'ont débranché.

Le mien je l'ai retiré quelques jours après avoir acheté le Falcon
(un vrai boulet quand on lance, entre autre, des jeux ST)
Et de toute façon quand on a un Falcon c'est pas pour sortir du son sur ce genre de cochonnerie !

- Section 8: movep sur 68060 Rien à redire cette fois, à éviter donc (ou utiliser une autre routine, comme pour éviter de désactiver les caches).

C'est le talon d'achille du 060, purée que c'est lent et aucun moyen d'y remédier pour les softs qui ne sont plus supporter... :/

Kochise :
Arf oui, c'est vrai que MOVEP n'existe pas sur 68060 Je me demandais pourquoi SSAVCALL plantait sauvagement sur ma CT60 quand j'utilisait MOVEP pour remplir mes tableau GEM. Et moi qui croyais à tord que c'était les caches qui étaient en cause Arf... Remarque Patrice, Motorola à bien jarté les instructions CALLM et RTM du 68030 alors qu'ils venaient de les mettres dans le 68020. Et putain, quel bonheur que ces instructions ! Enfin, allez comprendre des fois ce qui motive les gars de chez Motorola :/

Kochise

Donc le movep n'existe plus sur le 68060, bon a savoir j'ai une ou deux routines d'effacement qui l'utilise et je crois bien dans ma routine d'init Falcon !!! ARRRGGHHHH !!!

Je vais la modifié de ce pas, sinon Poong tournera pas CT60


GT Turbo

Bah ça tourne car elle est émulée, mais je te dit pas comment ça plomb les perfs !

Pourtant, MOVEP, c'est pas ce qu'il existe de plus dur à émuler :/ Genre :

movep.l    D0,(A0)

Equivalent à :

moveq.w  #0,D1
ror.l         #8,D0
move.b    D0,D1
move.w    D1,(A0)+
ror.l         #8,D0
move.b    D0,D1
move.w    D1,(A0)+
ror.l         #8,D0
move.b    D0,D1
move.w    D1,(A0)+
ror.l         #8,D0
move.b    D0,D1
move.w    D1,(A0)+
subq.l      #8,A0

Quelque chose dans le genre, mais sans toucher à D1 Tsss, remarque, SANE sur PowerPC, c'est du même acquabit ! Accablant...

Kochise

Bah le problème c'est pas vraiment de savoir si c'est simple à émuler mais le nombre de cycles que ça va prendre.
Imagine dans ton exemple 15 instructions pour en émuler une seule, compte le nb de cyles au total, ça refroidit vite

Bwaaa, au 060, et avec un cache (Pollux ne me contredira pas), ça devrais le faire Et puis franchement, MOVEP, c'est pas une instruction qu'on utilise si souvent que ça (hmmm, quoique...)

Kochise

ça devrait mais au final ça le fait pas du tout, test une démo qui utilise des movep, tu vas avoir un choque

J'ai déjà eu le 'choque' avec mon SSAVCALL sur CT60 :/ Question compatibilité inter 680x0, on repassera... J'ai gouté !

Kochise

pmandin :
[Snip]

Salut patrice, bienvenue sur le forum

Kochise :
Pourtant, MOVEP, c'est pas ce qu'il existe de plus dur à émuler :/ Genre :

movep.l    D0,(A0)

Equivalent à :

moveq.w  #0,D1
ror.l         #8,D0
move.b    D0,D1
move.w    D1,(A0)+
ror.l         #8,D0
move.b    D0,D1
move.w    D1,(A0)+
ror.l         #8,D0
move.b    D0,D1
move.w    D1,(A0)+
ror.l         #8,D0
move.b    D0,D1
move.w    D1,(A0)+
subq.l      #8,A0

Quelque chose dans le genre, mais sans toucher à D1 Tsss, remarque, SANE sur PowerPC, c'est du même acquabit ! Accablant...

Et quelque chose comme ça, ce serait pas plus simple ?

rol.l   #8,d0
move.b	d0,(a0)
rol.l   #8,d0
move.b	d0,2(a0)
rol.l   #8,d0
move.b	d0,4(a0)
rol.l   #8,d0
move.b	d0,6(a0)

pmandin :
Et quelque chose comme ça, ce serait pas plus simple ?

rol.l   #8,d0
move.b	d0,(a0)
rol.l   #8,d0
move.b	d0,2(a0)
rol.l   #8,d0
move.b	d0,4(a0)
rol.l   #8,d0
move.b	d0,6(a0)

Non, puisque c'est sur octet impair. Or les Motorola n'aiment pas les accès aux octets impairs ! Ton exemple aurait du être :

rol.l   #8,d0
move.b	d0,1(a0)
rol.l   #8,d0
move.b	d0,3(a0)
rol.l   #8,d0
move.b	d0,5(a0)
rol.l   #8,d0
move.b	d0,7(a0)

En effet, #12345678 devient en mémoire (A0) = 0012 0034 0056 0078. En fait ça devrait être réellement (A0) = xx12 xx34 xx56 xx78, où 'xx' sont les octets non modifiés. Je ne devrait même pas initialiser D0 à 0 :/

Kochise

Le problème des accès aux addresses impaires est valable pour les word & long.

pas de problème en .b quoi !

Mais... mais ouiiiii (Kochise se tape la tête sur le clavier : ç'h à)y ... "hjyu_) ... tyhy_ç) ... h_)aé"hjç) !

Comme je bosse essentiellement en word ou long, ben j'oublie :/ Le 68030 accepte sans broncher les accès sur des adresses impaires en faisant en fait deux accès sur la largeur de la donnée. Donc ça ralenti, d'où ma sale manie de forcer toutes mes routines sur adresse paire, d'où ma première routine... Parce que le 060 n'échappe pas à la règle :/

Kochise

Kochise
:

pmandin :
Et quelque chose comme ça, ce serait pas plus simple ?

rol.l   #8,d0
move.b	d0,(a0)
rol.l   #8,d0
move.b	d0,2(a0)
rol.l   #8,d0
move.b	d0,4(a0)
rol.l   #8,d0
move.b	d0,6(a0)

Non, puisque c'est sur octet impair. Or les Motorola n'aiment pas les accès aux octets impairs ! Ton exemple aurait du être :

rol.l   #8,d0
move.b	d0,1(a0)
rol.l   #8,d0
move.b	d0,3(a0)
rol.l   #8,d0
move.b	d0,5(a0)
rol.l   #8,d0
move.b	d0,7(a0)

En effet, #12345678 devient en mémoire (A0) = 0012 0034 0056 0078. En fait ça devrait être réellement (A0) = xx12 xx34 xx56 xx78, où 'xx' sont les octets non modifiés. Je ne devrait même pas initialiser D0 à 0 :/

Kochise

Les deux exemples sont valables, en acces .B on peut acceder aux adresses paires comme impaires. Et le movep accede aussi bien aux adresses paires qu'impaires !!

GT Turbo