Logicielsmoto.com

Salut !

Je me bricole quelques outils de cross dev en ce moment. J'ai essayé de faire un outil de conversion d'images à partir de fichiers PNG.
J'essaie de générer un fichier chargeable avec un LOADM. Donc j'ai un en-tête du genre :


Cependant, j'obtiens une erreur 70 après avoir chargé un quart de mon écran forme. Qu'est-ce que j'ai raté ? Une limite de taille des blocs ?

Y'a un autre format utilisé pour enregistrer des images ? J'ai entendu parler de loadp mais ça existe sur MO5 ?

Je proposerais plutôt :

00 00 01 A7 C0 00
00 20 00 00 00
(données forme)
00 00 01 A7 C0 01
00 20 00 00 00
(données couleur)

$A7CB, il vaut peut-être mieux ne pas y toucher...


Si le DOS existe (pour le Basic), le LOADP existe aussi. Donc pas en Basic 1.0.

Cela dit, le décodage est facile. Ici par exemple on trouve le code pour TO7 par un certain defusr (ce nom me dit quelque chose ). Il est facilement adaptable pour MO5.

Bon j'ai corrigé le A7C0 (je sais pas ce qui m'a pris)

Le probleme reste le meme, je n'arrive pas a charger plus d'un quart de l'ecran et ensuite c'est erreur 70.
D'autres idées là dessus ?

Pour le format MAP, je ne pense pas l'utiliser, il y a des méthodes de compression bien plus efficaces

L'erreur 70 est provoquée par une anomalie dans la structure de la disquette. Comment l'as-tu créée ? Le problème se produit avec le matériel réel ou avec un émulateur ? Si oui lequel, et avec quel format d'image de disquette ?

Oui. Pourquoi $2000 ? 8000 en décimal, ça fait $1F40 en hexadécimal, pas $2000. Ou les données que tu as insérées font effectivement 8000 octets et ton compteur de données est faux, ou tu as effectivement 8192 octets de données et des données importantes pour le système pourraient être écrasées.

Qui plus est, dans le reset du MO5, j'ai :

... ce qui implique que l'état des autres bits de $A7C0 ont leur importance. Il n'est peut-être pas conseillé d'initialiser aussi brutalement $A7C0 comme tu le fais dans ton binaire, surtout que ce registre contrôle aussi l'écriture (b6) et la lecture cassette (b7). Si toutefois tu charges le programme à partir de ce périphérique.

Oui, j'avais mis 0x2000, ce n'est pas un problème, la zone mémoire après l'écran est inutilisée (et mes données font la bonne taille).

J'ai corrigé ça mais le problème reste le même...

La disquette a été créée avec sapfs, puis convertie en fichier fd avec mon outil saptofd (qui doit être quelque part sur ce forum). Le problème vient peut être de là. Je fais mes tests avec dcmo5 pour le moment.

En ce qui concerne A7C0, en effet c'est pas forcément très propre, mais j'utilise une disquette donc ça ne devrait pas coincer ?
Dans le doute je vais essayer sans ce bloc là de juste charger les données...

Pas toujours. Sur TO8, par exemple, elle est utilisée. Juste histoire de prendre de bonnes habitudes. Et en plus, ça réduit la taille des données





Ca se pourrait. Auquel cas Daniel serait le premier à avoir cerné le problème. Ceci dit, CC90 sait aussi faire le genre de conversion que tu souhaites


Non, ça ne devrait pas. Mais je suggère alors d'utiliser $51 et $50 plutôt que $01 et $00. Sait-on jamais.

Bon alors, je me suis replongé un peu dans ce problème aujourd'hui et j'ai fait différents essais.

D'abord, j'ai vérifié avec sapfs -u et comparé avec un dump en hexa de mon fichier .fd converti : pas d'erreur de ce côté là, la conversion en fd est conforme au fichier sap.

Ensuite, j'ai enlevé le passage en mémoire forme/couleur et je n'ai gardé que la partie forme pour le moment (ça sera au moins ça qui marche...)

Le résultat est que je n'arrive pas à charger un fichier plus gros que 2039 octets (en-tête de blocs compris). Pourquoi 2039, j'en sais rien... Si c'était sapfs je pense que quelqu'un d'autre s'en serait apperçu... à moins que mon compilateur C soit foireux à ce point...

J'ai essayé de changer mon en-tête pour charger en 0x0F00 au lieu de 0000, le résultat est le même...

Bon, il ne me reste plus qu'à vérifier le code source de sapfs et espérer y trouver un bug. Mais cette taille de 2039 octets me surprend tout de même... 2048 pourquoi pas, mais là...

Une idée ?

2048 - 2039 = 9, mince j'ai pondu un oeuf!
Sinon j'ai pas plus intelligent à l'esprit (ouais ca vole pas haut). Ah non pas tant que ca. J'ai comme une idée... Execute en basic sur MO5: et regarde le contenu du fichier binaire. Tu pourras probablement t'en inspirer.

Mh, ça n'a pas l'air de marcher dans DCMO5 ça... disquette toujours protégée en écriture peut être ? Bon je rebranche le MO5 pour tester...

J'ai regardé le fichier fd généré par sapfs à la loupe, y'a un truc bizarre...
J'ai donc un fichier avec 8000 octets de données (mémoire forme), + 5 octets d'en tête et 5 octets pour le marqueur de fin, soit 8010 octets au total. On devrait donc avoir 4 blocs de 2048 octets alloués, le 4ème avec 'C8' dans la FAT pour indiquer que tous ses secteurs sont remplis. Mais en fait il y a 5 blocs alloués, le dernier n'étant visiblement pas utilisé (rempli de E5). L'avant dernier par contre est rempli jusqu'au bout, la fin du fichier y est copiée deux fois... (il devrait rester 182 octets 'E5' si mes comptes sont bons ?)

Oui, n'oublie pas de selectionner l'option "ouverture en écriture". Tu dois avoir un zoli (W) en bas à coté du nom du fichier FD.


Le nombre d'octets utilisés dans le dernier bloc est stocké en offset 14-15 de l'entrée du fichier sur la piste 20 de la diskette (juste après le type de fichier).

Ah oui ça marche mieux en désactivant la protection en écriture.

Du coup j'ai trouvé le problème... sapfs fait des images disque en 80 pistes et met mes fichiers en commençant sur le dernier bloc de la piste 40. Le MO5 s'attend à ne toruver que 40 pistes et donc impossible de lire au delà du premier bloc du fichier...

bon il me reste plus qu'à bricoler sapfs pour ajouter un mode 40 pistes alors. Mais on verra ça demain

Pour éviter ce genre de problème, je remplacerai probablement le contrôleur CD90-640 par le CD90-351 dans la prochaine version de dcmo5.
Une remarque en passant : la version disponible sur le site dcmo5 date de décembre 2007. J'ai des versions plus récentes, mais je n'ai pas eu le temps de les finaliser. Une nouvelle version en 2011 ne serait pas du luxe. Elle intègrerait les dernières améliorations de mes autres émulateurs SDL, et toutes les corrections de bugs faites dans dcmoto. J'ai aussi le projet d'étendre la version SDL à toutes les machines Thomson, et d'améliorer la compatibilité avec Mac OS. Reste à trouver le temps...

Ben ça m'intéresse ça
Si tu as besoin d'aide je peut trouver un peu de temps, par exemple pour tester les dernières versions

... avant que je ne commence à modifier dcmo5 moi même