Bonne lecture !!!
j'explique : quand on capture l'instruction movem.l (a0)+,d0-d7 sur le bus il y a le code opération (movem.l sur 16bits) puis les valeurs de d0 a d7
a raison de 16 bits par cycle , je capture les données de d0 a d7(qui arrivent en "rafales")
en gros un transfert "normal" géré par le 68k c'est :
movem.l (a0)+,d0-d7 1er instruction
movem.l d0-d7,(a1)+ 2eme instruction
avec a0 sur une zone mémoire du st (ram)
et a1 sur le pour cartouche (si on pouvait écrire dessus)
dans le mode rafale seule la première instruction est nécessaire,
movem.l (a0)+,d0-d7 1er instruction
ce qui permet de doubler les vitesses de transferts !
une autre astuce permet de limiter les cycles de gestion entre chaque movem.l
pour ce qui est des accélérations
j'ai identifié 3 méthodes
-1 on déroute les exceptions du GEM/BIOS etc et en gros on donne le travail a faire au µchip
les exceptions pointes sur des routines (en $FFFA0000) qui utilise au max le µchip
sachant que les plus longues des opérations arithmétiques durent au maxi 2 cycles du 68K (division et multiplication)
on peut aussi émuler un super 68882... avec des shifts en interleave etc
le gain est minime, la compatibilité est maximum.
-2 on implémente des fonctions complexe pré-calcul de sprite, tracé de ligne et routine 3D
il faut utiliser le pré calcul, la structure de la cartouche s'y prête particulièrement
l'utilisation soit par trap #5 par exemple ou directement sous programme 68k
-3 beaucoup plus difficile a mettre en œuvre :
le µchip a en gros 48Ko de ram interne accès super rapide , 1 mo de ram externe et 4Go sur la sdcard a 10/20 Mbit/s
en gros il y a de l'espace mémoire a plus quoi savoir en faire !!!
le ST donne les fonts les objets 2D et 3D le µchip précalcul et stock
puis après le st transmet un scénario pour faire construire une image par le micro controleur
le scénario est mis a jour à chaque vbl.
l'image de 32 Ko est dispo en $FFFB0000 le 68K la recopie en ram video
bon ok c'est pas demain l'avant veille que ce seras fait,
surtout que je suis nul en 3D et en développement sur ST
de plus je pense que la demande d’émulation d'un hdd et floppy rapide est beaucoup plus forte d'une part
et d'autre part peut de développeur seront intéressés part les accélérations...
parfois il faut être réaliste,
le seul moyen d'avoir un vrai projet plus ou moins universel dans le petit monde de l'Atari c'est qu'il soit collaboratif
et la, j'ai vraiment du mal a rallier du monde...
et bien sur de faible cout !
pour ce qui est du circuit imprimé je dois le refaire, afin d'en facilité son câblage.
Fichier joint : 
, souder un tqfp de 100 pins avec un pas de 0.5mm en série n'est plus dans mes compétences autant pour un proto je le fait
