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 : 924
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 : 958
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 : 924
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 : 11699
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 : 924
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

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

Re: Format de fichier LEP

Message par Patrick » 01 oct. 2019 21:08

Je m'amuse toujours avec le format LEP.
La lecture fonctionne maintenant correctement sur MO5.
Je n'ai pas encore essayé d'autres plateformes.
J'ai adapté le programme de la version 5.3 à la version 6.0 de LittlevGL, dont je traduis la documentation en français.
Je suis également passé à la version 1.6.1 du core STM32.
J'implémente maintenant l'écriture avant de passer à la version 1.7.0 qui introduit une API HardwareTimer (pour l'instant, je manipule directement les registres matériels).
J'ai corrigé ce soir différents problèmes et l'écriture fonctionne globalement.
J'ai cependant un problème à l'arrêt du moteur : j'arrête immédiatement la prise en compte du signal et je perds un bit ce qui correspond à environ 800 microsecondes.
Je pense que la latence du moteur du LEP est prise en compte par la ROM du MO5. Le MO5 coupe le moteur puis écrit le dernier bit en considérant que la bande tourne encore.
Si les experts du MO5 peuvent me confirmer cela, ce serait pas mal.
Ce que je vais faire c'est que dès que je détecte l'arrêt du moteur, je vais différer de 800 microsecondes l'arrêt du décodage du signal.
Patrick

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

Re: Format de fichier LEP

Message par Patrick » 03 oct. 2019 21:00

L'écriture est fonctionnelle sur MO5 :D
Mon hypothèse précédente était fausse. Le moteur est arrêté après une temporisation de 500 millisecondes après l'émission du dernier bit (voir Sources du moniteur MO5 Cassette). Le problème ne venait donc pas de là.
Comme j'écris un créneau qu'à la détection d'un changement de niveau du signal en sortie du MO5, à l'arrêt du moteur du LEP il faut écrire un créneau supplémentaire qui représente soit un 0 soit le deuxième créneau d'un 1. Ainsi le bit qui me manquait à la lecture est constitué.
Ensuite, il faut toujours mettre le signal en entrée du MO5 à l'état haut pour indiquer la présence du LEP. Je le faisais à l'initialisation du programme, mais au gré des lectures il pouvait rester à l'état bas. Avant tout lecture ou écriture de fichier je positionne ce signal à l'état haut. J'évite ainsi les erreurs 59 et 60 que j'avais après une écriture.
Patrick

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

Re: Format de fichier LEP

Message par Daniel » 04 oct. 2019 10:02

L'utilisation du signal de sortie à l'état haut pour détecter la présence du magnétophone est astucieuse, mais il est vrai que c'est un piège et beaucoup de Thomsonistes se sont déjà fait prendre à un moment ou un autre. Heureusement, avec l'expérience, on finit par comprendre !

Quand on remplace le magnétophone par un système électronique, il est possible d'atteindre des débits nettement plus élevés. Il est tentant de modifier les routines système de lecture cassette pour diminuer les temporisations. Une vitesse dix fois plus rapide rendrait les temps de chargement beaucoup plus supportables. Mais l'utilisateur moyen est-il capable de changer la ROM de son MO5 ? J'en doute un peu, car elle est soudée.
Daniel
L'obstacle augmente mon ardeur.

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

Re: Format de fichier LEP

Message par hlide » 04 oct. 2019 10:28

A supposer que le programme est un mono-bloc, il est possible de faire un loader de petite taille qui lit ensuite avec un protocole plus rapide le vrai programme suivi d'une décompression sur place. La problématique c'est de déterminer à quel endroit placer ce loader pour pouvoir charger le vrai programme sans conflit. C'est ce que je fais avec le mode Turbo (SHARP PWM classique mais avec une vitesse X2, X3 ou X4) ou le mode Ultra-fast (protocole propriétaire sériel qui charge le plus vite possible que lui permettent l'Arduino et le Z80). Pas de ROM. Cependant, ça reste limité aux binaires qui ne chargent pas d'autres blocs par la suite. Et dernièrement, j'ai créé un outils qui permet de générer un MZF compressé (certains jeux arrivent à donner 8 Ko compressé pour 20 Ko réel) qui peut parfaitement être transcrit en WAV. En combinant les deux, on pourrait atteindre des vitesses acceptables.

Par contre, c'est clair que l'idée de pouvoir modifié la ROM pour prendre en compte ces vitesses est très tentant. J'espère avec mon autre projet (MZ-700 ROM/DISK) pouvoir intégrer la possibilité de lire et écrire plus rapidement avec un lecteur virtuel.

Avatar du membre
6502man
Messages : 9419
Enregistré le : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: Format de fichier LEP

Message par 6502man » 07 oct. 2019 17:19

@Patrick: Très intéressant l'idée de faire un outil généraliste pour gérer les fichiers LEP ;)


@Hilde:
... certains jeux arrivent à donner 8 Ko compressé pour 20 Ko réel ...
Tu utilises quel algo de compression ?
Tu as un exemple de binaire de jeux ;)
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.

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

Re: Format de fichier LEP

Message par hlide » 07 oct. 2019 21:23

J'ai mis le source sous GitHub : https://github.com/SHARPENTIERS/mz7.

C'est du ZX7 (Spectrum) à la base. J'embarque le décodeur dans les 128 octets d'entête du MZF qui décompressera le programme sur place. Pour information, cette entête est ce qui précède le bloc de donnée sur la cassette, ce qui veut dire que le fichier MZF peut être traduit en WAV et enregistré sur une cassette pour lire un programme compressé depuis une vraie cassette.

Le principe est simple : l'entête embarque le décompresseur (89 octets) dans le champ commentaire. Une fois l'entête et le bloc de donnée lu, il y a un saut a une toute petite routine qui va sauter dans le code embarqué dans l'entête. Ce code va décompresser le véritable programme SUR PLACE puis le lancer.

L'exemple cité, c'est le jeu TOMAHAWK (que tu retrouveras dans la liste ci-dessous).

Voici des exemples de compression :

Code : Tout sélectionner

>mz7c.exe -f "Y2K.MZT" "Y2KX4.mz7.mzf"
[Old file] size: 32747 (7feb), load: 1200, exec: 1200
[New file] size: 23329 (5b21), load: 36df, exec: 36df
File converted from 32747 to 23308 bytes! (delta 2)
>mz7c.exe -f "PLOP.m12" "PLOP.mz7.mzf"
[Old file] size: 8541 (215d), load: 1200, exec: 1200
[New file] size: 1577 (0629), load: 2d49, exec: 2d49
File converted from 8541 to 1556 bytes! (delta 2)
>mz7c.exe -f "BATTLE GAME.mzf" "BATTLE GAME.mz7.mzf"
[Old file] size: 10805 (2a35), load: 9000, exec: 9000
[New file] size: 4082 (0ff2), load: aa58, exec: aa58
File converted from 10805 to 4061 bytes! (delta 2)
>mz7c.exe -f "CIRCUS STAR.mzf" "CIRCUS STAR.mz7.mzf"
[Old file] size: 10689 (29c1), load: 9000, exec: 9000
[New file] size: 4912 (1330), load: a6a6, exec: a6a6
File converted from 10689 to 4891 bytes! (delta 2)
>mz7c.exe -f "LAND ESCAPE.mzf" "LAND ESCAPE.mz7.mzf"
[Old file] size: 14139 (373b), load: 3137, exec: 3137
[New file] size: 5762 (1682), load: 5205, exec: 5205
File converted from 14139 to 5741 bytes! (delta 3)
>mz7c.exe -f "MAN-HUNT.mzf" "MAN-HUNT.mz7.mzf"
[Old file] size: 2580 (0a14), load: 2000, exec: 2000
[New file] size: 1584 (0630), load: 23f9, exec: 23f9
File converted from 2580 to 1563 bytes! (delta 3)
>mz7c.exe -f "MOVING SEARCHER.mzf" "MOVING SEARCHER.mz7.mzf"
[Old file] size: 8352 (20a0), load: 1200, exec: 1200
[New file] size: 4190 (105e), load: 2257, exec: 2257
File converted from 8352 to 4169 bytes! (delta 3)
>mz7c.exe -f "PAINFUL MAN.mzf" "PAINFUL MAN.mz7.mzf"
[Old file] size: 12050 (2f12), load: 3137, exec: 3137
[New file] size: 5382 (1506), load: 4b58, exec: 4b58
File converted from 12050 to 5361 bytes! (delta 3)
>mz7c.exe -f "ROUND SHOOT.mzf" "ROUND SHOOT.mz7.mzf"
[Old file] size: 16014 (3e8e), load: 3137, exec: 3137
[New file] size: 6121 (17e9), load: 57f1, exec: 57f1
File converted from 16014 to 6100 bytes! (delta 3)
>mz7c.exe -f "SEND-1.mzf" "SEND-1.mz7.mzf"
[Old file] size: 11671 (2d97), load: 3137, exec: 3137
[New file] size: 4659 (1233), load: 4cb0, exec: 4cb0
File converted from 11671 to 4638 bytes! (delta 3)
>mz7c.exe -f "SNAKE&SNAKE EXP1.mzf" "SNAKE&SNAKE EXP1.mz7.mzf"
[Old file] size: 28830 (709e), load: 1200, exec: 1200
[New file] size: 10511 (290f), load: 59a4, exec: 59a4
File converted from 28830 to 10490 bytes! (delta 3)
>mz7c.exe -f "SUPER PUCK-MAN.mzf" "SUPER PUCK-MAN.mz7.mzf"
[Old file] size: 9802 (264a), load: 9000, exec: 9000
[New file] size: 4307 (10d3), load: a58c, exec: a58c
File converted from 9802 to 4286 bytes! (delta 3)
>mz7c.exe -f "TOMAHAWK.mzf" "TOMAHAWK.mz7.mzf"
[Old file] size: 20225 (4f01), load: 1200, exec: 5c00
[New file] size: 8037 (1f65), load: 41b1, exec: 41b1
File converted from 20225 to 8016 bytes! (delta 2)
>mz7c.exe -f "GENOSS.MZT" "GENOSS.mz7.mzf"
[Old file] size: 7432 (1d08), load: a000, exec: a000
[New file] size: 4215 (1077), load: aca6, exec: aca6
File converted from 7432 to 4194 bytes! (delta 2)
>mz7c.exe -f "ZELBUS.MZT" "ZELBUS.mz7.mzf"
[Old file] size: 11008 (2b00), load: 9d00, exec: 9d00
[New file] size: 6144 (1800), load: b015, exec: b015
File converted from 11008 to 6123 bytes! (delta 2)
>mz7c.exe -f "ZELDIS.MZT" "ZELDIS.mz7.mzf"
[Old file] size: 8960 (2300), load: a300, exec: a300
[New file] size: 6137 (17f9), load: ae1c, exec: ae1c
File converted from 8960 to 6116 bytes! (delta 3)
>mz7c.exe -f "ZEPLIS.MZT" "ZEPLIS.mz7.mzf"
[Old file] size: 7776 (1e60), load: 9e00, exec: 9e00
[New file] size: 4652 (122c), load: aa49, exec: aa49
File converted from 7776 to 4631 bytes! (delta 3)
>mz7c.exe -f "SIDEROLL-F-.m12" "SIDEROLL-F-.mz7.mzf"
[Old file] size: 44544 (ae00), load: 1200, exec: 1200
[New file] size: 20588 (506c), load: 6fa9, exec: 6fa9
File converted from 44544 to 20567 bytes! (delta 3)
Je les ai tous lancés avec succès.

Avatar du membre
6502man
Messages : 9419
Enregistré le : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: Format de fichier LEP

Message par 6502man » 07 oct. 2019 22:07

J'ai bien trouvé un "TOMAHAWK.mzf" sur le net mais il fait 46Ko, est ce que tu peut mettre à dispo celui que tu à de 20Ko, je suis curieux de voir ca structure et de tester la compression ?
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.

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

Re: Format de fichier LEP

Message par hlide » 07 oct. 2019 22:28

Je pense que c'est une version pour le MZ-800 que tu as trouvée. Je t'ai MPé pour savoir comment te l'envoyer ma version.

Avatar du membre
6502man
Messages : 9419
Enregistré le : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: Format de fichier LEP

Message par 6502man » 08 oct. 2019 12:07

la compression ZX7 est performant :D

Le système de charger un code pour décompresser du binaire est sympa mais il faut pas avoir du basic sinon ca risque de coincer !
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.

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

Re: Format de fichier LEP

Message par hlide » 08 oct. 2019 15:08

Si tu fais allusion uniquement au MZ-700, c'est mal parti pour faire une rustine effectivement : il y a tellement de BASIC. Et que faisons nous des Forth et des Pascal ? de plus la gestion de lecture/écriture des cassettes est généralement prise en charge directement par ces langages dans leur code au lieu d'utiliser celui de la ROM. Donc, j'avoue n'avoir pas tenter l'expérience.

Répondre