Format de fichier LEP

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.

Modérateurs : Carl, Papy.G, fneck

Répondre
Patrick
Messages : 917
Enregistré le : 16 mai 2009 09:30
Localisation : Clermont-Ferrand

Format de fichier LEP

Message par Patrick » 11 avr. 2019 16:51

SDLEP Reader, la création de Daniel, et ses dérivés, reposent sur l'utilisation des fichiers au format LEP.
Je m'intéresse au sujet et je pense qu'il serait utile de définir un format structuré de ce type de fichier pour répondre à différents besoins.
Voici les points auxquels j'ai déjà pensé :
  • une signature, sur 4 octets, par exemple LEPF, pour identifier le fichier,
  • une période variable, 50 µs par défaut mais 16 pour les fichiers Sharp MZ par exemple (période),
  • une possibilité de combiner deux fichier LEP en un seul pour les fichiers Mattel Aquarius par exemple (blocs),
  • les machines compatibles (marque, famille, modèle),
  • une indication de la commande à exécuter pour démarrer la lecture (méthode).
J'ai déjà commencé à travailler sur une structure de fichier dont je vous donne le pseudo code.

Code : Tout sélectionner

/*
 * LEP.h
 *
 *  Created on: 8 avr. 2019
 *      Author: Patrick
 */

#ifndef LEP_H
#define LEP_H

#include <stdint.h>

#define LEP_DEFAULT 0

// Header
typedef struct lep_header {
	uint32_t magic;
	uint32_t version;
	// Computers
	uint8_t brand;
	uint8_t family;
	uint32_t compatibily;
	// Loading
	uint8_t period; // µs
	uint8_t method;
	uint32_t duration; // ms
	// Block
	uint8_t blocks;
} lep_header;

// Block
typedef struct lep_block {
	uint32_t size; // Up to 4 GB
	uint32_t duration;
} lep_block;

// Magic
#define LEP_MAGIC 'LEPF'

// Version
#define LEP_VERSION_MAJOR 1
#define LEP_VERSION_MINOR 0
#define LEP_VERSION_REVISION 0

#define LEP_VERSION ((LEP_VERSION_MAJOR << 16) | (LEP_VERSION_MINOR << 8) | LEP_VERSION_REVISION)

// Period
#define LEP_PERIOD 50

// Method
#define LEP_RUN 0 // RUN "
#define LEP_LOADM 1 // LOADM
#define LEP_LOADMR 2 // LOADM"",,R

// Brand
#define LEP_ACORN 1
#define LEP_AMSTRAD 2
#define LEP_ATARI 3
#define LEP_COMMODORE 4
#define LEP_DRAGON 5
#define LEP_EXELVISION 6
#define LEP_JUPITER 7
#define LEP_MATRA 8
#define LEP_MATTEL 9
#define LEP_MICRONIQUE 10
#define LEP_ORIC 11
#define LEP_PHILIPS 12
#define LEP_SHARP 13
#define LEP_SINCLAIR 14
#define LEP_TANDY 15
#define LEP_THOMSON 16

// Family
// 0 LEP_DEFAULT
// 1..127 brand
// 128..255 multi brands families
#define LEP_MSX 128
#define LEP_MSX2 129
#define LEP_MSX2PLUS 130

// Amstrad
#define LEP_CPC464 (1 << 0)
#define LEP_CPC664 (1 << 1)
#define LEP_CPC6128 (1 << 2)
#define LEP_464PLUS (1 << 3)
#define LEP_6128PLUS (1 << 4)

// Thomson
#define LEP_MO 1
#define LEP_TO 2

// MO
#define LEP_MO5 (1 << 0)
#define LEP_MO6 (1 << 1)

// TO
#define LEP_TO7 (1 << 0)
#define LEP_TO7_16K (1 << 1)
#define LEP_TO770 (1 << 2)
#define LEP_TO770_64K (1 << 3)
#define LEP_TO8 (1 << 4)
#define LEP_TO8_256K (1 << 5)
#define LEP_TO8D (1 << 6)
#define LEP_TO8D_256K (1 << 7)
#define LEP_TO9 (1 << 8)
#define LEP_TO9_64K (1 << 9)
#define LEP_TO9PLUS (1 << 10)

#endif /* LEP_H */
Un fichier serait donc composé d'un en-tête, d'un bloc et des données brutes du fichier existant.

Pour le Mattel Aquarius, le fichier serait composé d'un en-tête, d'un premier bloc, des données brutes du premier fichier, du second bloc et enfin des données brutes du second fichier.
La lecture après un bloc d'un fichier s'arrête automatiquement et doit être relancée pour le bloc suivant, sur l'ordinateur comme sur le lecteur LEP.

J'ai essayer de donner des exemples de marques, de familles et de modèles pour illustrer. Ce n'est bien sûr pas complet, je pense à la famille MO. Par contre, j'ai intégré les variations avec extension de mémoire, car cela peut conditionner la compatibilité d'un modèle avec un programme. Je ne suis pas certain que c'est la bonne manière de traiter ces données.

Je pense que générer des fichiers structurés à partir de fichiers existants sera simple. La modification des lecteurs également. Pour ma part je travaille sur un lecteur basé sur une carte Nucleo STM32. Pour l'instant, ces caractéristiques sont :
  • pas de contrainte de fragmentation sur les fichiers,
  • pas de limitation du nombre de fichiers,
  • lecture du fichier en tâche de fond,
  • génération du signal par compteur et interruption,
  • gestion de la commande du moteur par interruption,
  • interface graphique.
J'ai testé les deux premiers points sur une carte Uno. Par contre, pour l'implémentation d'une interface graphique évoluée, le Uno est insuffisant et le STM32 est idéal.

Voici un aperçu de l'interface de l'application :
Image

Daniel, Carl, Hlide, Falkor, vous qui avez beaucoup travaillé sur le sujet, et tous les autres, n'hésitez pas à manifester votre opinion sur le sujet et vos remarques.
Patrick

hlide
Messages : 927
Enregistré le : 29 nov. 2017 10:23

Re: Format de fichier LEP

Message par hlide » 11 avr. 2019 18:03

Quelques observations pour commencer :

1) Concernant mon projet spécifique aux SHARP MZ, j'ai trois formats : Binaire (MZF, MZT, M12, etc.), LEP (à 16 ou 50 µs) ou WAV (n'importe quelle fréquence mais mono 8-bit). Dans les faits, je n'utilise plus LEP. Il n'y avait vraiment que moi pour l'utiliser initialement jusqu'à ce que je parvienne à exploiter les fichiers WAV sous Arduino. Deux personnes ont reproduit mon projet et s'en servent pour lire des fichiers WAV ou MZF. Il y a des fortes chances que je laisse tomber ce format puisqu'un Arduino est parfaitement capable de lire les binaire et les WAV qui sont des formats très usités pour cette série d'ordinosaures. Les binaires sont très courts en taille (octet disk == octet mémoire) et génère un signal très propre. Les fichiers WAV sont les plus gros (2 x 9 x n octets == octet mémoire) mais ils permettent les mêmes variations de baud que le LEP sans le soucis de la résolution 16 ou 50 µs.

2) De souvenir, Daniel avait crée le format LEP pour qui ne contienne aucune spécificité. Il serait peut-être plus juste de parler d'un conteneur pouvant contenir du LEP (contenu qui ne change pas par rapport au LEP d'origine) avec des méta-données - mais alors il faudrait une extension de fichier autre que LEP. Par ailleurs, il serait plus opportun de mettre cet entête en pied si tu veux qu'un lecteur SDLEP d'origine soit capable de lire ce fichier. Le programme sera chargé et exécuté avant que le lecteur commence à débiter des inepties à cause de ce pied.

3) La lecture séquentiel de plusieurs blocs est quelque chose qui peut exister aussi avec les SHARP MZ. Le MZ arrête le moteur puis reprend : avec un fichier WAV, c'est gérable car il se met en pause quand le moteur s'arrête et qu'il reste des octets à lire. La lecture du reste du fichier WAV reprend donc avec la mise en route du moteur. Cependant cette commande du moteur ne doit pas être disponible sur toutes les machines, mais je suppose que ce devrait être le cas du Mattel, non ? ce qui est possible avec WAV l'est donc avec LEP.

4) l'interface graphique : je ne vois pas la difficulté avec Arduino. Du moment que tu gères les signaux via le PWM et l'interruption, l'IHM et la gestion de lecture/écriture en double tampon en tâche de fond via loop() n'est pas impossible. Tu dois probablement utilisé un Discovery avec écran LCD qui n'est pas dans le même ordre de prix qu'un SDLEP-READER TFT et si c'est pour juste gérer du LEP, ça me semble sur-dimensionné. Certes en terme de mémoire et de puissance, ce doit être confortable.

5) Le projet est-il open source ? peut-on y jeter un coup d’œil ?

EDIT: Ah non, c'est bien bien un Nucleo avec TFT shield sur la connectique Arduino. Bon c'est probablement moins cher que je ne le pensais initialement.

Patrick
Messages : 917
Enregistré le : 16 mai 2009 09:30
Localisation : Clermont-Ferrand

Re: Format de fichier LEP

Message par Patrick » 11 avr. 2019 20:23

Bonsoir hlide,

Merci pour ton message.
Je vais répondre à certains points :
  1. En ce qui concerne les formats, tout est possible. TZXDuino fonctionne très bien également, avec des fichiers d'une taille bien plus faibles : TZX, TAP, CAS... Les fichiers WAV ne posent pas de problème non plus. Il serait même possible de traiter les fichiers K7 des émulateurs de Daniel.
  2. Daniel précisera mais il a peut-être été dépassé par sa création et la rapidité à laquelle elle a été adoptée. Je ne retranche rien à ce que j'ai énoncé, un en-tête permet de résoudre les problèmes posés. Cela permet de préparer la lecture des données. Il n'est pas compliqué de vérifier la présence d'un en-tête et en son absence de retourner au début du fichier et de débuter la lecture effective.
  3. Il n'y a pas de commande de moteur pour l'Aquarius. Carl a séparé les fichiers en deux parties, lues l'une après l'autre (cf. ce message).
  4. La librairie que j'utilise pour l'interface, LittlevGL, est très riche en fonctionnalités et nécessite de la RAM. Avec un Arduino, c'est tout simplement impossible. Pour paraphraser Doc Brown, tant qu'à utiliser une interface, autant qu'elle ait de la gueule ! Pour la lecture du fichier, j'ai écrit le code sur Uno.
  5. Je pense mettre en place un dépôt Github.
J'utilise une carte Nucleo-F429ZI à 20 € et un shield TFT classique. Avec le core STM32 et Sloeber, le plugin Eclipse, il est même possible de faire du debug pas à pas. Par rapport à l'IDE Arduino et un Uno, c'est le jour et la nuit.
Patrick

Daniel
Messages : 11653
Enregistré le : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: Format de fichier LEP

Message par Daniel » 11 avr. 2019 20:26

Au départ du projet je ne pensais qu'aux ordinateurs Thomson. Avec l'Arduino je ne savais pas lire assez vite un fichier .wav (comme l'a fait hlide plus tard), c'est pourquoi j'ai créé le format .lep. Ce n'est qu'un format compressé pour des signaux rectangulaires, qui a l'avantage d'être très petit et bien adapté à la décompression par l'Arduino. L'unité de temps a été choisie pour le MO5 et le TO7, mais peut évidemment être modifiée pour s'adapter à d'autres machines.

Plus tard nous avons découvert, en particulier avec les expériences de Carl, la possibilité d'utiliser SDLEP-READER pour d'autres ordinateurs. Le format .lep n'a pas été conçu pour eux, et le système SDLEP est bien entendu perfectible pour répondre aux cas particuliers, comme l'ont montré les différentes adaptations de hlide et d'autres.

Bien entendu j'encourage tous ceux qui veulent perfectionner le système, mais je n'y participerai pas directement : je n'ai pratiquement que des Thomson et j'ai beaucoup trop d'autres projets en cours.
Daniel
L'obstacle augmente mon ardeur.

Patrick
Messages : 917
Enregistré le : 16 mai 2009 09:30
Localisation : Clermont-Ferrand

Re: Format de fichier LEP

Message par Patrick » 06 mai 2019 16:55

Ce message présente l'état d'avancement du projet.

J'ai finalisé l'application sur la carte Nucleo-F429ZI et réalisé un câble d'interface avec le kit que je mentionne ici. Le résultat est acceptable bien qu'un peu court :
Image

Une fois les câblages nécessaires effectués, cela m'a permis de tester l'ensemble.
Voici une photographie de la lecture en cours d'Eliminator :
Image

Lecture en cours de Sorcery :
Image

Et enfin, Sorcery en fonctionnement :
Image

Sur l'écran TFT, le témoin moteur et la barre de progression donnent des indications sur la lecture.
La carte Nucleo fonction en 3,3 V mais les E/S sont tolérantes au 5 V ce qui est appréciable. Dans l'autre sens, le MO5 semble accepter un niveau TTL haut à 3,3 V.
Par contre, Pulsar II a refusé de se charger. La lecture semble se dérouler correctement, mais à la fin, l'ordinateur reste bloqué sur l'écran de chargement. Il me faut tester plus de fichiers et éventuellement passer sur Aquarius pour tester le traitement du multi-blocs.

Par ailleurs, j'ai débuté le développement d'une application pour gérer les fichiers LEP :
Image

Les fonctionnalités de l'applications sont :
  • reconnaissance automatique des types de fichiers,
  • conversion de fichier LEP brut en fichier LEP, avec fusion éventuelle de fichiers (cf. la capture d'écran),
  • conversion de fichier WAV en fichier LEP,
  • conversion de fichier K7 en fichier LEP (uniquement VG5000),
  • glisser-déposer des fichiers à traiter, traitement par lot...
L'application est développée sous Lazarus, testée sous Windows.

En ce qui concerne, la structure des fichiers LEP, je n'ai pas beaucoup progressé.
J'ai uniquement tenté de recenser les marques des ordinateurs susceptibles d'utiliser des cassettes. J'hésite encore sur la manière de traiter le cas des MSX.

Code : Tout sélectionner

// Brand
#define LEP_ACORN 1
#define LEP_AMSTRAD 2
#define LEP_APOLLO_7 3
#define LEP_APPLE 4
#define LEP_APPLIED_TECHNOLOGIES 5
#define LEP_ATARI 6
#define LEP_CAMPUTERS 7
#define LEP_CANON 8
#define LEP_COMMODORE 9
#define LEP_DRAGON 10
#define LEP_ENTERPRISE 11
#define LEP_EPSON 12
#define LEP_EXELVISION 13
#define LEP_EXIDY 14
#define LEP_GRUNDY 15
#define LEP_HANIMEX 16
#define LEP_INDATA 17
#define LEP_JUPITER_CANTAB 18
#define LEP_KYOCERA 19
#define LEP_MATRA 20
#define LEP_MATSUSHITA 21
#define LEP_MATTEL_ELECTRONICS 22
#define LEP_MEMOTECH 23
#define LEP_MICRONIQUE 24
#define LEP_MSX 41
#define LEP_NEC 25
#define LEP_OLIVETTI 26
#define LEP_ORIC 27
#define LEP_PHILIPS 28
#define LEP_PROTEUS_INTERNATIONAL 29
#define LEP_SANYO 30
#define LEP_SEGA 31
#define LEP_SHARP 32
#define LEP_SINCLAIR 33
#define LEP_SMT 34
#define LEP_SORD 35
#define LEP_SPECTRAVIDEO 36
#define LEP_TANDY 37
#define LEP_TEXAS_INSTRUMENTS 38
#define LEP_THOMSON 39
#define LEP_VIDEO_TECHNOLOGY 40
Merci de me signaler d'éventuels oublis. Une fois celle liste finalisée, j'ajouterai au cas par cas les familles/gammes et les modèles/configuration.
Patrick

Répondre