Decidement les ST vont etre farci a la SDCARD cette annee, en tout cas c'est encore un super projet bravo
Une production est elle envisageable ?
Bonjour et merci pour ces realisation, cela fait vraiment envie, a quand un STE portable lol !
Jc- Le 01/07/2007 à 19:48 C'est génial , trés trés bon boulot
précision:
pas d'écriture sur disquette pour l'instant le soft n'est pas encore terminé.
les routines d'ecritures sur la sd card sont terminées et utilisées pour sauvegarder la config sur la sd card.
ce qui n'est pas encore fait c'est le décodage du flux mfm en provenance du st ,mais ca viendra d'ici la fin de l'année.
le logiciel embraqué dans le microcontroleur est flashable de facon autonome depuis la sdcard.
les mises jour suivront.
Me laisserai tenter aussi.
Oui et tu n'es pas le seul même si le Satan Disk est là.
J'essaye de me renseigner pour le PASTI(s).
J'ai déjà interrogé l'auteur a ce sujet il y a 6 mois / 1 ans:
Le problème du format pasti est qu'il est orienté émulation contrôleur WD1772 et non pas contenu comme le format IPF.
En gros un fichier un pasti contient les données des secteurs lu lors du dump mais également tout un tas d'informations concernant les timings des secteurs: à quel moment a t'il été lu et en combien de temps, la présence éventuelle de "weak bit" , etc.
Pour l'émulation hardware du floppy il faut générer à partir de ces timings les différents secteurs avec les bitrates correspondants.
Les bitrates utilisés sont bien sur pas du tout standard et varie constamment sur une piste protégée de façon plus ou moins fine.
Sur amiga (format IPF) on voit souvent des rampes avec une augmentation (ou diminution) progressive du temps entre chaque bit MFM.
Je ne me souviens plus de la finesse du truc mais je crois que c'est assez précis.
Ceci dit d'après ce que j'ai pu lire sur Atari forum l'auteur (ijor) va bientôt publier les specs de son format...
Bonjour,
merci Shadow272, toutes les infos sont les biens venues.
jeff : en effet j'ai édité le fichier les synchro et idfield sont inclus,mais pas mal de données reste sans signification pour moi.
quand au timing bitrate variable, pas evident a intégré.(mais pas infaisable....)
en attendant la publication d'ijor sur le forum atari
ca te dirais de faire un nouveau format de fichier incluant les synchros,id field , crc etc ,directement en bit mfm avec une compression
de type RLE (genre msa en un peu plus scioux), histoire de nous epargner le fichier de 4 mo.
Pour le format de fichier bas niveau, c'est déjà au programme en fait ;-). Concernant la compression il faut faire attention à ne pas se mettre des bâtons dans les roues pour l’émulation hardware : il faut prévoir les changements de têtes/ pistes de façon aléatoire. En RLE ça peu poser des problèmes car tu devras te resynchroniser dans le flux compressé à chaque changement de tête ou piste. A voir …
Tiens au fait comment travaille t’on émulo ? Séquentiellement (chargement secteur -> encodage MFM -> sérialisation MFM) ou en parallèle (chargement + encodage en simultané de la sérialisation) ?
Tout simple apres selection, le fichier image est decompressé dans un fichier temporaire sur la sdcard, ce fichier temporaire
presente les secteurs les uns derrieres les autres.
apres je lis en direct avec un offset depenedant du track demander , l'encodage MFM et les calcul de crc se font à la volée en temps réel.
de cette facon la (dé) compression ne pose aucun probléme.
ok, la "sérialisation" MFM (ou plutôt la sortie effective du signal MFM vers le ST), est donc réalisées qu'après avoir encodé le secteur.
Crois tu que tu pourrais tenir un flux mfm constant si tu n'encodais pas le flux MFM en lisant simplement le prochain "paquet" mfm sur la sdcard pendant que tu sérialises le précédent ?
en effet je lit le secteur sur la sdcard puis je l'encode MFM et le serialise ,
en supprimant l'étape endodage mfm et donc en lisant directement les données encodées mfm sur la sdcard cela me simplifierais la tache , le debit peut etre tenue sans problème et etre variable de surcroit.
)
