SONDAGE PROJET HARDWARE - Page 5

Ben c'est le but oui, sinon tu te retrouves avec un port accessible seulement en lecture ou seulement en écriture. Mais il ne faut pas le faire sur le LSB de l'adresse, mais sur le MSB (sinon c'est chiant pour les transferts 16 bits et d'autres trucs).

en faites le plus simple (quoique a voir)

$fffaxxxx = buffer read sur 64ko

et write = lecture sur
$fffb(data 16) = en faites l'adresse que tu lis sur la 2eme section ($fffb) est constituée de la data pour les 16 bits inférieurs (c'est pas de moi,déjà fait ailleurs)


les signaux rom3 et rom4 permettent de savoir si lecture ou écriture
comme le 68k check une partie pour y jumper cette dernière est forcement en lecture
et doit être cohérente pour contenir du code (codage pair impaire impossible sur cette section)

Voilà, c'est ce que je disais

maintenant les subtilités de codage du 68 k pour moi , ca date de plus 20 ans,
donc je pense que beaucoup sur le forum sont plus qualifier...

par contre je me demande toujours si on peut faire pointer la vidéo sur cette zone mémoire du port cartouche?

quelqu'un pourrais tester ou a déjà fait ?

Zerosquare (./121) :
Ben c'est le but oui, sinon tu te retrouves avec un port accessible seulement en lecture ou seulement en écriture. Mais il ne faut pas le faire sur le LSB de l'adresse, mais sur le MSB (sinon c'est chiant pour les transferts 16 bits et d'autres trucs).

oui, enfin c'était le principe...

après on peut séparer $fa = code boot 68k
et $fb pair lecture / impair écriture

cependant solution possible aussi:

après on peut séparer $fa = code boot 68k + buffer lecture
et $fb écriture

Comme je l'ai expliqué, la solution pair/impair n'est pas bonne. Si tu veux splitter, faut le faire sur les bits supérieurs de l'adresse.

ok

la solution rom3 et 4 est choisie donc section $fa code 68k et buffer lecture
et section $fb buffer écriture sous forme $fb"data" la data étant récupérée sur lds/uds:a1 à a15

c'est plus simple a mettre en œuvre.

du coup t'as qu'une seule adresse d'écriture?

ba non

un seul offset $fb0000

tu ajoute ta data par exemple $1234

donc tu obtient $fb1234

puis par exemple tu exécute tst.w $fb1234 ou move.w $fb1234,d0

le µp reçoit l'adresse $fb1234 sépare le bus d'adresse afin d'isoler la data soit $1234

donc selon la data tu va lire une case mémoire différente sur la section $fb0000

après il est clair qu'il faut savoir quoi faire de cette donnée, le µp est intelligent on peut imaginer un tas de protocole.

ouais voila t'es content avec ton 1234, parce que si tu veux écrire dans une RAM a plusieurs adresses tu fais comment?

rien de plus simple du fixe une adresse de départ puis mode auto-increment, après il faut mettre au point un protocole avec le µp

genre 1er écriture registre qui détermine ce qui suite par exemple:

1er registre = je vais écrire un buffer de 1Mo a emmètre sur le port eth/usb/ ou a ecrire dans un fichier (dans ce cas il faudra passer le nom du fichier)
puis envoie des datas
2eme 1er word de data
...............
1mo de data

et µp repasse en mode: j’attends un registre d'ordre

le but étant d’établir un protocole entre le 68k et le µp afin d'attribuer des taches complexes a effectuer par le µp
qui tourne 20 fois plus vite (au mini)

après la liste des taches est a déterminer...

je dois aussi évaluer ce qui est faisable.

mais le plus gros intérêt c'est de programmer le shifter/gst $ff8201/$ff8203 sur $fa0000.

je connais une autre solution c'est de sortir un cs d'un custom chip ou des zones mémoires ne sont pas utilisées et le r/w mais ça veut dire ouvrir le st/ste et souder 2 fils...

après mure réflexion il y a moyen de faire beaucoup mieux sur le port cartouche,

en capturant le port cartouche avec l'analyseur logique, je m’aperçois qu'on accède
au bus 68K pour sa totalité pour les data et au 16 bits inferieur pour la adresse,
et je vois tout les accès passer sur ce bus... ceux destinés au port cartouche mais aussi les autres
avec les travaux précédemment menés sur la vidéo gst shifter.

ça vous donne de pas de petites idées...

je vais regarder le hard du ste de plus près...





la zone $fff8266 à $fff827f est utilisable en r/w, mais il faut sortir le cs et le r/w
du gst shifter, ca fait 2 fils à l’intérieur du STE a câbler ...
je ne sais pas si les utilisateurs sont près a ouvrir leur STE...

movem.l (a0)+,d0-d7 movem.l d0-d7,(a2)+

De tete la post incrementation ne marche pas sur un des deux movem que tu a listés, car je me souviens que je l'utilisais pour des sprites et tu est obligé de 'rajouter' a la main. Je crois bien que c'est le second movem qui fonctionne pas avec cette adressage mais cela n'est pas bien grave.

Je te contactes en privé pour certaines choses.

GT Post incrementer !!

sundance (./132) :
ba non

un seul offset $fb0000

tu ajoute ta data par exemple $1234

donc tu obtient $fb1234

puis par exemple tu exécute tst.w $fb1234 ou move.w $fb1234,d0

Ca serait pas plutot : tst.l $fb1234 car codé trois octets sur un word mais bon la encore rien que des détails. Mais cela fait penser a quelques petits trucs utilisés dans les demos pour gagner quelque cycles

GT

GT Turbo (./137) :
GT

Tiens, c'est contagieux

Fais gaffe Sundance, si tu utilises les méthodes à GT, tu vas récolter de jolies bombes

Pour les bombes c'est déjà fait...


quand au code suivant :

move.w(a0)+,d0
tst.b (a1,d0.w) ou move.b (a1,d0.w),d1 (on peut récupérer des datas venants du µp dans d1 ouah du full duplex!!!)

attention d0.w peut être impair !!


il permet un transfert en écriture de 16 bits en 3 µs soit un débit théorique de 2 Mo/s
il est clair qu'il faut compter en plus la gestion d'adresse de départ buffer



j'ai trouvé mieux et plus facile...

Bonsoir,

Alors pas de nouvelles propositions?
Pour moi ce qui me plairais bien c'est de l'usb pour pouvoir utiliser un clavier et une souris en usb et un support de stockage ide/sata/sd etc histoire de pouvoir utiliser un de mes atari dans ma grosse borne d'arcade que je suis en train de fabriquer et donc pouvoir rejouer a mes bon vieux atari facilement

Bonsoir,

pour l'usb pas de pb, par contre pour le stockage, le support sdcard est le plus adapté, une liaison spi est facilement gérable,
ide/sata le cout est trop élevé (alimentation externe etc...)

Yop !

Ce qui m'intéresserait:
SDCard pour le support disque
USB pour transférer les données
En option une RTC pour être à l'heure...

Mais rien que les 2 premiers, ce serait top (et surtout rien à souder, PNP) !

SD pour HDD et RTC = UltraSatan (il y a même 2 port SD sur l'UltraSatan) ^^ c'est le pied cette bête la

USB, RTC , etc ... comme çà : http://forum.system-cfg.com/viewtopic.php?f=18&t=2592

C'est sympa, mais t'as déjà fait des drivers USB ? Tu sais à quel point c'est merdique ?

ah oui c'est merdique!!!

c'est pour que je ne ferais pas de driver pour hdd, souris only et encore c'est pas dit que je prenne un fdti avec le bibli qui va bien !!

il y a aussi la possibilité de trouver une démo sur un kit de dev ...

Merci. J'adore tout ce qui est tordu !!!

ca peut etre interressant :

ftp://ftp.efo.ru/pub/ftdichip/

jchn

merci pour l'adresse, très intéressante...

de nada