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).
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 */
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.
Voici un aperçu de l'interface de l'application :
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.