Placez ici vos trucs et astuces, étalez sans retenue votre savoir-faire et votre science qui va nous permettre de redonner une apparence neuve et fonctionnelle à nos bouzes.
hlide a écrit : ↑12 juin 2020 19:31
Même au delà de X3 ! 48Ko en 18s. Je vois que tu as pris de l'avance sur moi, j'ai aussi un lecteur en panne et je tergiversais là-dessus puis je suis parti sur d'autres projets (dont un FLASH de 512 Ko qui remplace la ROM d'origine pour stocker des programmes que je peux charger en un temps éclair). Il faudra que je reprenne le projet mz-sd²cmt.
Je suis évidemment bloqué sur X2 .. mais pourriez-vous me passer la version de mzf2wav qui génère directement le lep?
avec MZFWAVGUI créer des centaines de wav en une seule étape est un jeu ... mais les convertir un par un avec DCLEP est un tourment!
Alors ça ne va pas pas être possible malheureusement car j'ai oublié un détail : je parle de mon projet mz-sd²cmt qui a démarré à partir du SDLEP-READER pour devenir son propre projet avec des différences aussi bien du côté hardware que software où je lève pas mal de limitations qui n'avaient pas lieu pour un MZ-700 seul (je lis directement du MZF comme du WAV). Et du coup on sort du cadre de ce topic. Autant te dire que mettre le logiciel du mz-sd²cmt à la place ne fonctionnera pas à plus d'un titre. J'ai besoin de me connecter à 4 signaux (READ, WRITE, MOTOR et SENSE). SDLEP-READER n'en fait au plus que deux (READ, MOTOR). Je ne gère pas le TFT. J'utilise un MEGA et non un UNO. Et j'en passe. Par contre, je gère plus de périphériques : OLED, LCD 16x2 avec 5 boutons, rotateur infini, touches tactiles, télécommande IR, etc. Mais là encore on sort du topic.
Dernière modification par hlide le 12 juin 2020 20:04, modifié 1 fois.
Ah le mzf2wav... faut que je retrouve ça... j'ai fait un mzf2lep mais il n'est plus compatible : le LEP que je génère est en unité de 16 µs alors que le LEP que sdel-reader utilise c'est de l'unité 50 µs. Une fois de plus, désolé. Personnellement, le MZF et le WAV me suffisent; j'ai gardé le LEP (= L16) et L50 par rétro-compatibilité mais quand on a un SD de 64 Go, les WAV suffisent. Pourquoi LEP à 16 µs ? parce que je ne peux pas aller plus loin que X2 avec du LEP à 50 µs.
Merci hlide, en fait, l'option de lire directement les fichiers mzf est beaucoup plus intéressante.
Peut-être qu'un jour je trouverai le temps d'adapter les versions de ton mz-sd au tft, comme je l'ai déjà fait pour le zxduino et, auparavant, avec SDLep.
En attendant, une option pour convertir plusieurs fichiers à la fois avec SDLEP aurait été utile ... qui sait si l'auteur ne fournit pas!
Si tu comptes passer au mz-sd²cmt, n'hésite pas je t'aiderais (encore qu'avec un NANO c'est chaud) et l'option TFT m'aiderait aussi. Note que je peux accéder à des sous-répertoires et pas seulement aux fichiers dans la racine. Il y a foule d'améliorations je pense : j'ai fais un outils qui compresse la taille d'un MZF (mz7c) assez drastiquement et donc réduit substantiellement le temps de lecture. J'ai fait l'expérience d'une transformation d'un binaire de 60 Ko que je peux charger en 3 minutes au lieu des 12 minutes. Par contre, il faudra passer par les fils dédiés.
aotta a écrit : ↑12 juin 2020 21:07
En attendant, une option pour convertir plusieurs fichiers à la fois avec SDLEP aurait été utile ... qui sait si l'auteur ne fournit pas!
Créez un nouveau fil dans le forum pour la demande, et j'étudierais ça : compresser le MZF puis le transformer en LEP.
Dernière modification par hlide le 12 juin 2020 22:14, modifié 1 fois.
hlide a écrit : ↑12 juin 2020 21:58
Si tu comptes passer au mz-sd²cmt, n'hésite pas je t'aiderais (encore qu'avec un NANO c'est chaud) et l'option TFT m'aiderait aussi. Note que je peux accéder à des sous-répertoires et pas seulement aux fichiers dans la racine. Il y a foule d'améliorations je pense : j'ai fais un outils qui compresse la taille d'un MZF (mz7c) assez drastiquement et donc réduit substantiellement le temps de lecture. J'ai fait l'expérience d'une transformation d'un binaire de 60 Ko que je peux charger en 3 minutes au lieu des 12 minutes. Par contre, il faudra passer par les fils dédiés.
Le portage sur un Arduino UNO peut être impossible en raison de la mémoire limitée disponible, largement utilisée par les bibliothèques pour TFT ... mais nous pourrons penser à l'Arduino Mega (je viens d'acheter un écran TFT pour le Mega à 8 euros!).
Si je décide d'essayer le travail, je vous contacterai pour de l'aide ... mais pour le moment nous allons hors sujet!
Dans tous les cas, une version de SDLEP-TFT sur MEGA avec prise en charge de FAT32, des sous-répertoires, etc., pourrait être un bon pas en avant!
aotta a écrit : ↑12 juin 2020 21:07
En attendant, une option pour convertir plusieurs fichiers à la fois avec SDLEP aurait été utile ... qui sait si l'auteur ne fournit pas!
Vous pouvez essayer la version 20200613 de dclep. Si elle fonctionne bien je la mettrai à disposition sur le site dcmoto.
Merci Daniel, juste ce que je voulais!
Fonctionne bien pour les 254 premiers fichiers, les suivants les jettent avec "erreur d'ouverture du fichier .wav, conversion abandonnée sur erreur."
Il y a une variable declarèe octet?
aotta a écrit : ↑13 juin 2020 12:04
Fonctionne bien pour les 254 premiers fichiers, les suivants les jettent avec "erreur d'ouverture du fichier .wav, conversion abandonnée sur erreur."
C'est certainement une erreur de programmation. Je vais corriger.
@hlide: Pour SDLEP-TFT il faut regarder le programme .ino. Il y a peut-être une limite mais il est facile de la modifier.
Dernière modification par Daniel le 13 juin 2020 12:38, modifié 1 fois.
hlide a écrit : ↑13 juin 2020 12:24
A l'origine le SDLEP-READER ne pouvait adresser que 128 fichiers (via le piano à 7 bit). J'ignore si cette limitation a été levée pour le SDLEP-TFT.
SDlep-tft n'a pas de limites sur le nombre de fichiers, mais un répertoire fat16 le fait, et cela dépend de la longueur du nom de fichier. J'ai réussi à télécharger environ 200 fichiers dans la root de ma SDcard, et cela fonctionne.
Bien sûr, la navigation n'est pas facile, et si vous appuyez trop sur un "en avant", vous devez recommencer!
aotta a écrit : ↑12 juin 2020 22:12
Le portage sur un Arduino UNO peut être impossible en raison de la mémoire limitée disponible, largement utilisée par les bibliothèques pour TFT ...
Question technique, ton UNO il est branché à quoi sur ton MZ-700 ? sur la prise externe READ ? ou sur le connecteur TAPE interne ? d'où il tire son alimentation ? utilises-tu uniquement READ ? ou MOTOR (REMOTE) aussi ? que fais-tu de SENSE ? etc.
Le nombre de fichiers est limité par la taille de l'unité d'allocation, car on ne traite que le première unité d'allocation du répertoire principal.
On peut l'augmenter en spécifiant une plus grande unité d'allocation au formatage.
On peut aussi utiliser des noms courts, ils occuperont moins de place et on pourra en mettre plus.
hlide a écrit : ↑13 juin 2020 12:40
Question technique, ton UNO il est branché à quoi sur ton MZ-700 ? sur la prise externe READ ? ou sur le connecteur TAPE interne ? d'où il tire son alimentation ? utilises-tu uniquement READ ? ou MOTOR (REMOTE) aussi ? que fais-tu de SENSE ? etc.
Suite à vos tentatives, j'ai connecté l'UNO à la prise interne:
UNO ----> MZ-700 (P-12 connector)
GND ----> GND+SENSE (9+5)
VIN ----> 5V (6)
RX0(Motor) ----> Motor (4)
TX0(Data) ----> Read(8)
Ca fonctionne, mais sans le messagge "press play"
Dernière modification par aotta le 13 juin 2020 12:54, modifié 3 fois.
