[THOMSON] ARDDRIVE

Cette catégorie traite de développements récents pour nos vieilles machines, applications, jeux ou démos... Amis programmeurs, c'est ici que vous pourrez enfin devenir célèbres!

Modérateurs : Papy.G, fneck, Carl

__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [THOMSON] ARDDRIVE

Message par __sam__ »

@Totor: Le pb du hard fait en soft est le fait qu'on maitrise mal le timing. En asm coté 6809 on peut calculer les affaires avec grande précision, mais en C coté arduino ca n'est plus pareil: il n'y a pas de support pour maitriser les délais d'attentes de l'ordre de la µs. Ici le soft doit tourner en temps-réel dur, et c'est pas facile à mettre au point. Il y eu pas mal d'essais/erreurs pour synchroniser la lecture d'octet coté thomson avec l'envoi coté arduino, mais ca a fini par marcher, et démontré que c'est pas souple du tout.

Le truc à comprendre est que pour avoir le max de débit entre le thomson et l'arduino on ne peut pas utiliser de protocole avec accusé de réception pour chaque octet: c'est trop lent. En fait il faut que émetteur (code C arduino) marche de concert avec le récepteur (ASM 6809) pendant un certain temps (une "trame" de plusieurs octets) et qu'ensuite on resynchronise les deux avec un accusé de réception.

Question RAM, il est possible qu'un gros buffer aide à maîtriser les aléas de réponse de la carte SD. Cependant les fichiers VIDEO sont lourds. Si je prends le cas de SDAnim7, on lit à 120ko/sec, donc une chanson de 3min occupe déjà 21Mo. Je te dis pas pour un starwars de 2h au complet (j'ai ca!). Je pense pas qu'il y ait beaucoup de mini processeur avec autant de ram.

En fait la solution n'est pas tellement dans le buffer coté arduino, mais plutôt du coté TO. Le protocole d'échange de données est conçu pour que durant la réception d'un secteur de 512 octets, le TO fasse provision de quelques échantillons audio supplémentaires qui seront joués le temps que la carte SD passe au secteur suivant. Cela avait été découvert lors des premières tentatives de streaming purement audio. (Comme quoi les étapes intermédiaires où l'on apprend des chose servent toujours.)

Au fait pourquoi juste quelques échantillons audio en réserve et pas vidéo? Ben parce que c'est plus petit (je sais plus, ca doit faire dans les 8ko/sec) que la vidéo qui elle marche en flux tendu (112ko/sec). En plus la vidéo est bien plus tolérante que l'audio ou une petite irrégularité répétitive s'entends tout de suite.

C'est un truc qui a aussi été vu dans les débuts de la TNT si vous avez remarqués. Au tout début, un parasite perturbait simultanément la vidéo et l'audio et on entendait un glitch insupportable rendant l'expérience TNT mauvaise. Après ils ont fait en sorte que le flux audio soit moins perturbé, et curieusement alors que les parasites sont toujours là, et bien moins de monde se plaint de mauvaise qualité de réception. Et oui: on s’accommode mieux des glitchs vidéo que audio en fin de compte.
Dernière modification par __sam__ le 01 nov. 2019 18:14, modifié 1 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [THOMSON] ARDDRIVE

Message par Daniel »

totor a écrit : 01 nov. 2019 18:01 Donc ma question est : quelles instructions 6809E utilises tu pour ces 250 000 octets/seconde que je puisse comparer avec le mode Raspberry PI et pourquoi tu arrives à 250 000 octets/seconde avec un Arduino et qu'il ne serait pas possible de le faire avec un RPI ?
J'ai mis à jour mon post précédent. C'est :
LDA <$BF lecture octet (4 cycles, 250000 octets par seconde)
Le signal demandant le transfert est envoyé par hard (0 cycle), comme dans SDDRIVE.

Evidemment il faut faire quelque chose avec l'octet lu, par exemple un STA, donc en réalité on ne transfère que 125000 octets par seconde.
Daniel
L'obstacle augmente mon ardeur.
totor
Messages : 204
Inscription : 09 oct. 2019 22:41

Re: [THOMSON] ARDDRIVE

Message par totor »

Ici le soft doit tourner en temps-réel dur, et c'est pas facile à mettre au point. Il y eu pas mal d'essais/erreurs pour synchroniser la lecture d'octet coté thomson avec l'envoi coté arduino, mais ca a fini par marcher, et démontré que c'est pas souple du tout.
D'où l'intérêt d'avoir un RPI qui tourne un millier de fois plus vite que le Thomson et pas un simple à Arduino seulement 16 fois plus rapide.

C'est pareil avec un émulateur : si vous tournez sur un PC AT 16Mhz vous aurez plus de mal à avoir un jeu émulé avec TEO qui tourne parfaitement que si vous êtes sur un PC 1 Ghz.
totor
Messages : 204
Inscription : 09 oct. 2019 22:41

Re: [THOMSON] ARDDRIVE

Message par totor »

LDA <$BF lecture octet (4 cycles, 250000 octets par seconde)
Le signal demandant le transfert est envoyé par hard (0 cycle), comme dans SDDRIVE.
Donc on est bien d'accord qu'on pourrait faire la même chose avec un RPI qui enverrait les données sur $E7BF/$A7BF ?
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [THOMSON] ARDDRIVE

Message par Daniel »

Bien sûr que c'est possible. Personne n'a jamais dit que ce n'était pas possible.
Le problème est d'une part le coût, d'autre part le côté marteau pilon pour écraser une mouche.

Arduino Pro Mini 5V = 1,79 €
https://www.ebay.fr/itm/Pro-Mini-Atmega ... 2727071155

Le Raspberry Pi je ne sais pas, mais je suis sûr qu'il n'est pas moins cher.
Daniel
L'obstacle augmente mon ardeur.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [THOMSON] ARDDRIVE

Message par __sam__ »

@Totor: Il faut que le PI envoit les données sitôt que le 6809 le demande, et pas plus tard, sinon le 6809 ne lira que du bruit sur le bus.

La latence sur interruption de l'ARM est-elle suffisante ? Surtout que c'est pas juste la latence matérielle qui compte, mais les N couches logicielles dont le noyau linux qui n'est pas conçu pour le temps-réel dur. Après on peut choisir de ne pas faire d'interruptions et faire du pooling.. mais quid du multitâche linux (ou de l'interruption du driver SD) qui peut interrompre le pooling au mauvais moment et faire louper une donnée? Je ne trouve pas cette plateforme simple pour répondre à des contraintes temps-réel dur. Au moins avec l'arduino c'est du "bare metal" sans noyau multitâche qui complique tout. Enfin je crois.

A moins que tu veux faire du RPi "tout nu" sans OS qui ne fait tourner que le soft de service de carte SD? Oui là c'est possible, mais c'est quand même dommage d'utiliser un ARM bien péchu juste pour ca.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
totor
Messages : 204
Inscription : 09 oct. 2019 22:41

Re: [THOMSON] ARDDRIVE

Message par totor »

Arduino Pro Mini 5V = 1,79 €
Je ne dis pas le contraire, le RPI c'est 30€.

Juste que c'est une fois pour toutes et qu'il suffit de trois câbles différents.

-un connecteur GPIO vers port extension Thomson
-un connecteur GPIO vers port manette jeu Thomson
-Un connecteur GPIO vers por LEP Thomson

Une fois qu'on a ça il n'y a plus de matériel à acheter et on peut créer les projets que l'on veut puisque le reste est du soft.

C'était juste ça que je disais : avoir un système unique et universel plutôt qu'à chaque fois un nouveau projet.

Ensuite il suffit de voir celui qui a acheté SDDRIVE (25 euros) + SDMOTO + SDMO5 + SDLEP + SDANIM7 etc... en aura pour beaucoup plus que l'achat du RPI et des trois câbles.

C'est tout ce que je dis :) Et bien entendu je dis ça parce que moi je ne connais pas la fabrication hard alors que je connais le soft.

Donc c'est juste que les projets hard de Daniel doivent être utilisés tels quels mais que si Daniel faisait une carte universelle alors n'importe qui connaissant le soft (comme moi) pourrait faire ses propres projets à partir de cette carte.

Et moi je pense au RPI parce qu'on peut le programmer facilement en C (que je connais).
totor
Messages : 204
Inscription : 09 oct. 2019 22:41

Re: [THOMSON] ARDDRIVE

Message par totor »

A moins que tu veux faire du RPi "tout nu" sans OS qui ne fait tourner que le soft de service de carte SD? Oui là c'est possible, mais c'est quand même dommage d'utiliser un ARM bien péchu juste pour ca.
Non moi je voudrais bien utiliser le RPI avec OS. Simplement le soft Thomson serait lancé avec une priorité très haute et le contenu de la carte SD serait pré-chargé en mémoire.
Mais si seul le RPI sans OS est possible, ce n'est pas un problème d'avoir une carte SD à insérer dans le RPI. On boot sur la version Thomson quand on veut utiliser l'interface Thomson et puis on remet une autre carte SD si on veut l'OS.

Comme par exemple le retrogame RetroPie qui boot sur sa propre carte SD.

En fait je n'invente rien, c'est la même chose que ce qui se fait sur les liens que j'ai donné : C64, Atari ST et Amiga.

Et si eux (qui fournissent leurs sources et dont on peut s'inspirer) ont réussi à régler ce problème de latence alors que l'Atari et l'Amiga tournent quand même beaucoup plus vite qu'un Thomson, je ne comprends pas pourquoi tu m'expliques que c'est problématique alors qu'ils ont réussi à le faire?

ils écrivent bien "Pi1541 is a real-time, cycle exact, Commodore 1541 disk drive emulator that can run on a Raspberry Pi 3B, 3B+ or 3A+. Commodore 1581 emulation supported since V1.13!"

D'ailleurs tu as peut être raison, pour le Pi1541, emulateur de Disk C64 c'est bien un soft qui boot sur sa propre carte SD, donc ça doit être la voie que les autres ont choisis pusqu'ils ont leur propre kernel.img
The latest binaries for setting up an SD card can be downloaded here.
If have already set up an SD card and are just looking for the latest kernel.img then you can get it here.
Moi ça ne me dérange pas d'insérer une carte SD spécifique dans le RPI quand je l'utilise avec le Thomson. Ca prend 5 secondes à faire.

les sources du Pi1541:

https://github.com/pi1541/Pi1541

et la partie qui gère les I/O sur GPIO :

https://github.com/pi1541/Pi1541/blob/m ... /rpi-i2c.c

https://github.com/pi1541/Pi1541/blob/m ... rpi-gpio.c
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [THOMSON] ARDDRIVE

Message par __sam__ »

Si je ne me trompe pas, le lecteur de diskette C64 (1541) marche sur un port IEEE série et pas sur le bus CPU directement. Les débits et la vitesse de réponse ne sont pas les mêmes.

Si j'en crois https://en.wikipedia.org/wiki/Commodore ... sfer_speed, les fastloaders donnent au max 2.5ko/sec alors que sur le bus thomson on vise max 250ko/sec. Il faut donc pouvoir réagir 100x plus vite que sur le port série du C64. C'est pas impossible, mais c'est pas certain non plus étant donné que le PI1541 ne marche pas avec un PI1 (700Mhz) qui n'est que 2 fois plus lent que le PI3 (1.4Ghz). Il faut tester ce que ca donne en vrai.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
totor
Messages : 204
Inscription : 09 oct. 2019 22:41

Re: [THOMSON] ARDDRIVE

Message par totor »

Il faut donc pouvoir réagir 100x plus vite que sur le port série du C64.
D'accord alors qu'en est il concernant le projet Amiga ? D'ailleurs lui aussi boot directement sur une carte SD.
This is a very simple and finally very cheap (5-10 eur) project: a very common chip (74LS06), a couple of resistors and diodes, a protoboard. This interface doesn't require any change to the Amiga, you have only to remove the internal floppy and put the interface and the Raspberry PI in place.
le schéma électronique :

http://1.bp.blogspot.com/-kmvg77lAQ-o/U ... ematic.png

et la page complète:

http://amigadrive.blogspot.com/2013/11/ ... loppy.html
Avatar de l’utilisateur
Papy.G
Modérateur
Messages : 3047
Inscription : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: [THOMSON] ARDDRIVE

Message par Papy.G »

Le problème de ta solution matérielle, c'est que certains processeurs peuvent attendre la confirmation que les infos soient présentes sur le bus (le Z80, il me semble, merci de me corriger si je dis une connerie), mais pas tous, et le temps que ton interruption prenne la main, et mette les infos sur le bus, bien des processeurs, malgré leur extrême lenteur, auront déjà pris le bruit du bus pour argent comptant. Après, avec un peu d'avance, les données peuvent être déjà là quand le Thomson les demande, ça doit être faisable avec le surcroît de vitesse du Rπ. Ce n'était pas la philosophie de Daniel, qui, initialement, voulait faire tous ses projets avec des composants contemporains des Thomson, mais en mettant un Arduino, il avait déjà croqué la pomme…

Daniel> On me dira que les conseilleurs ne sont pas les payeurs, mais vu mon habileté à réaliser et le matériel que j'ai bousillé ces dernières années, je me contente plus facilement de faire des suggestions, merci de ne pas t'en offusquer.

L'idée est-elle absolument de faire prendre en charge le format du support par l'extension, ou pas obligatoirement?
Si l'ordi peut prendre en charge le format, est-ce qu'un couple de registres à décalage piloté par une horloge de l'ordi, éventuellement multipliée, avec une suspension de l'horloge au bout de huit, relâchée sur commande de l'ordinateur, ou quand l'opération de lecture est achevée, avec, pour gagner du temps, écriture de huit bits du bus d'adresses sur le registre en sortie, quand les huit bits du bus d'entrée sont lues.
totor a écrit : 31 oct. 2019 20:07-une interface COM Internet logicielle : créer un chat texte entre deux Thomson au travers d'internet et BBS Minitel comme à l'époque en utilisant le logiciel Thomson Communication, le lien téléphone étant remplacé par internet
Pourquoi ne pas utiliser le matériel qui existe déjà et reste fonctionnel, les liaisons modems RTC passant pas trop mal par internet de nos jours.

Modération: Aux acteurs du débat récent, de part et d'autre: Tout les lecteurs apprécient le niveau technique et la pertinence de vos interventions, et l'intérêt de vos réalisations, simplement pour le ton employé, considérez que chacun apprécie différemment le degré d'ironie ou d'auto-dérision que vous pouvez mettre dans vos textes, évitez-donc d'en abuser si vous souhaitez que l'ambiance reste cordiale.
Certaines interventions pourraient se voir tronquées des parties insultantes pour assainir ce sujet
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [THOMSON] ARDDRIVE

Message par __sam__ »

totor a écrit : 01 nov. 2019 19:54D'accord alors qu'en est il concernant le projet Amiga ? D'ailleurs lui aussi boot directement sur une carte SD.
J'ai pas les infos exactes, mais au vu de l'extrait en anglais, le pi se fait passer pour un lecteur floppy (comme pour le projet C64). Dans ce cas le taux de transfert est aussi relativement bas.

De mémoire il me semble que mon amiga500 xcopiait une diskette de 880ko entre deux lecteurs en a peu près 1min30 à la louche, soit environ 9ko/sec. C'est plus que le C64, mais nettement moins que ce qu'on vise avec ARDrive.

A noter encore là que cette solution n'est pas non plus branchée sur le bus Zorro connecté au CPU, mais est branché sur le port série d'un CIA, port série qui est conçu pour s'interfacer avec des trucs externes non synchronisés sur la même horloge (contrairement au bus CPU).
Dernière modification par __sam__ le 01 nov. 2019 20:15, modifié 1 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
totor
Messages : 204
Inscription : 09 oct. 2019 22:41

Re: [THOMSON] ARDDRIVE

Message par totor »

Ce n'était pas la philosophie de Daniel, qui, initialement, voulait faire tous ses projets avec des composants contemporains des Thomson, mais en mettant un Arduino, il avait déjà croqué la pomme…
Ah c'est une information dont je ne disposais pas.
En effet si Daniel ne se lance dans des projets qu'avec des composants qui existaient déjà à l'époque de Thomson, ce n'est plus une question d'ordre technique mais philosophique.
Et ça je peux tout à fait le comprendre.

C'est bien ça le problème, Daniel ?
totor
Messages : 204
Inscription : 09 oct. 2019 22:41

Re: [THOMSON] ARDDRIVE

Message par totor »

Concernant le C64 pi 1541 on peut lire ici :

https://retrozonesite.wordpress.com/2018/08/04/pi1541/
the load time is boosted to a mean 10X original speed, so browsing games and Demo’s are now so much more fun since the wait is gone.
Donc on est déjà à 25ko/sec.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [THOMSON] ARDDRIVE

Message par __sam__ »

Alors il y a un truc que je n'ai pas pigé. Ils affirment être cycle-accurate, mais vont 10x plus vite que l'original. Ca colle pas. Par contre cela donne la même vitesse de transfert que l'amiga, ce qui serait cohérent (c'est le même principe pour les deux tout compte fait.)
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Répondre