[SDMOTO] fusion SDBOOT + demonstration SD
Modérateurs : Papy.G, fneck, Carl
-
- Messages : 7924
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
[SDMOTO] fusion SDBOOT + demonstration SD
Le code source de la partie asm du SDBOOT fourni dans l'archive sdmoto-année-80-20130314_motosd.zip est-il dispo ?
j'aimerais bien faire un giga fichier SD qui se boot comme une D7, mais contient une version modifiée de SDBOOT réutilisant l'adresse du fichier SD stockée en page 0 mais saute au delà des 1280k premiers octets pour trouver le contenu du fichier SD de démonstration.
En gros je souhaite donc fusionner SDBOOT avec un fichier de démo pour en faire un gros fichier SD autonome. Est-ce possible ?
j'aimerais bien faire un giga fichier SD qui se boot comme une D7, mais contient une version modifiée de SDBOOT réutilisant l'adresse du fichier SD stockée en page 0 mais saute au delà des 1280k premiers octets pour trouver le contenu du fichier SD de démonstration.
En gros je souhaite donc fusionner SDBOOT avec un fichier de démo pour en faire un gros fichier SD autonome. Est-ce possible ?
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [SDMOTO] fusion SDBOOT + demonstration SD
Tout est possible
J'ai essayé à peu près toutes les méthodes, et le temps est venu d'en choisir une pour les démos à venir.
1) SDBOOT, lancé à partir de n'importe quel support (cassette, disquette ou carte SD), initialise la carte SD et lance l'exécution d'un loader situé à une adresse physique donnée sur la carte. Peut fonctionner sans contrôleur CS91-280.
C'est la solution utilisée dans les premières démos du site dcmoto. Le programme SDBOOT n'est pas à jour (il contient des versions anciennes des fonctions d'accès à la carte SD). Il faudrait l'actualiser pour les démos à venir, si cette solution est retenue.
2) Un programme indépendant initialise la carte SD et exécute la démo. Le fichier .sd de la démo ne contient que des données.
Peut fonctionner sans contrôleur CS91-280.
Cette solution est intéressante car elle sépare les données du "moteur" de la démo. J'ai fait beaucoup d'essais mais je ne crois pas avoir diffusé les programmes.
3) Même méthode que ci-dessus, mais avec un contrôleur CS91-280. Le programme de démo utilise les fonctions déjà présentes dans le contrôleur pour initialiser la carte et appeler les commandes d'accès aux secteur. Ne fonctionne pas sans contrôleur CS91-280.
Cette solution est utilisée dans les exemples de ce fil de discussion : http://forum.system-cfg.com/viewtopic.php?f=25&t=5448
Les exemples sont donnés pour le MO6, mais doivent fonctionner aussi bien sur TO. Les programmes sont à jour et fonctionnent avec les versions actuelles du contrôleur CS91-280.
Mes hésitations dans le choix d'une méthode tournent autour de deux questions :
- Les démos doivent-elles être indépendantes ou non du contrôleur CS91-280 ?
- Les programmes de démos doivent-ils être indépendants ou non des données ?
L'utilisation des fonctions du contrôleur CS91-280 a deux gros avantages : éviter de dupliquer ces fonctions, et assurer la mise à jour de tous les programmes en cas de nouvelle version de l'EPROM. Et un gros inconvénient : interdire l'utilisation des démos aux utilisateurs de SDMOTO ne disposant pas du contrôleur.
En analysant ce dilemme, on peut trouver une troisième voie qui me semble tenir la route :
- Ne pas recopier dans les démos les fonctions d'initialisation et d'accès à la carte SD
- Utiliser les fonctions du contrôleur CS91-280 s'il est présent
- A défaut de contrôleur, appeler ces mêmes fonctions dans une bibliothèque indépendante chargée en RAM
Les fonctions utilisées sont simples, en fait il n'y en a que trois :
- Initialisation de la carte
- Lancement d'une commande quelconque
- Lecture d'un secteur de 512K dans un buffer
A priori les démos n'écrivent pas sur la carte. Pour le streaming elle lancent la commande "Lecture Multiple" et utilisent en général un programme optimisé de lecture d'un octet (en déroulant la boucle). Elles n'ont donc pas besoin de la troisième fonction. Dans la journée je vais essayer de résumer tous les appels nécessaires pour écrire la démo et je donnerai les sources (à jour) de toutes les fonctions utilisées.
J'ai essayé à peu près toutes les méthodes, et le temps est venu d'en choisir une pour les démos à venir.
1) SDBOOT, lancé à partir de n'importe quel support (cassette, disquette ou carte SD), initialise la carte SD et lance l'exécution d'un loader situé à une adresse physique donnée sur la carte. Peut fonctionner sans contrôleur CS91-280.
C'est la solution utilisée dans les premières démos du site dcmoto. Le programme SDBOOT n'est pas à jour (il contient des versions anciennes des fonctions d'accès à la carte SD). Il faudrait l'actualiser pour les démos à venir, si cette solution est retenue.
2) Un programme indépendant initialise la carte SD et exécute la démo. Le fichier .sd de la démo ne contient que des données.
Peut fonctionner sans contrôleur CS91-280.
Cette solution est intéressante car elle sépare les données du "moteur" de la démo. J'ai fait beaucoup d'essais mais je ne crois pas avoir diffusé les programmes.
3) Même méthode que ci-dessus, mais avec un contrôleur CS91-280. Le programme de démo utilise les fonctions déjà présentes dans le contrôleur pour initialiser la carte et appeler les commandes d'accès aux secteur. Ne fonctionne pas sans contrôleur CS91-280.
Cette solution est utilisée dans les exemples de ce fil de discussion : http://forum.system-cfg.com/viewtopic.php?f=25&t=5448
Les exemples sont donnés pour le MO6, mais doivent fonctionner aussi bien sur TO. Les programmes sont à jour et fonctionnent avec les versions actuelles du contrôleur CS91-280.
Mes hésitations dans le choix d'une méthode tournent autour de deux questions :
- Les démos doivent-elles être indépendantes ou non du contrôleur CS91-280 ?
- Les programmes de démos doivent-ils être indépendants ou non des données ?
L'utilisation des fonctions du contrôleur CS91-280 a deux gros avantages : éviter de dupliquer ces fonctions, et assurer la mise à jour de tous les programmes en cas de nouvelle version de l'EPROM. Et un gros inconvénient : interdire l'utilisation des démos aux utilisateurs de SDMOTO ne disposant pas du contrôleur.
En analysant ce dilemme, on peut trouver une troisième voie qui me semble tenir la route :
- Ne pas recopier dans les démos les fonctions d'initialisation et d'accès à la carte SD
- Utiliser les fonctions du contrôleur CS91-280 s'il est présent
- A défaut de contrôleur, appeler ces mêmes fonctions dans une bibliothèque indépendante chargée en RAM
Les fonctions utilisées sont simples, en fait il n'y en a que trois :
- Initialisation de la carte
- Lancement d'une commande quelconque
- Lecture d'un secteur de 512K dans un buffer
A priori les démos n'écrivent pas sur la carte. Pour le streaming elle lancent la commande "Lecture Multiple" et utilisent en général un programme optimisé de lecture d'un octet (en déroulant la boucle). Elles n'ont donc pas besoin de la troisième fonction. Dans la journée je vais essayer de résumer tous les appels nécessaires pour écrire la démo et je donnerai les sources (à jour) de toutes les fonctions utilisées.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7924
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [SDMOTO] fusion SDBOOT + demonstration SD
Oula ca fait pas mal d'options..
Perso pour CS9-1280, je verrais bien les demos comme une super grosse D7 qui présente à la fois la partie fd/sd standard contenant le prog basic "loader", sauf que le prog basic n'a pas besoin de demander l'adresse du fichier de démo. Il peut savoir que le controler CS9-1280 est présent (marquage en $E000), et directement trouver l'adresse du fichier dans la page 0 du moniteur auquel il ajoutera l'offset constant l'où l'on trouve les données du fichier démo. Sans controlleur CS, le même prog basic peut être autrement saisi à la main (ou depuis K7/D7), et comme il ne trouve pas le controleur CS présent, il demande à l'utilisateur d'entrer l'adresse du fichier de démo.
Je ne sais pas si je suis clair, mais disons en résumé que le lanceur de démo peut retrouver de lui-même l'adresse du fichier de démo en cas de présence du controleur CS9-1280 et éviter la partie fastidieuse de recopie cette adresse pour l'utilisateur.
Après savoir si le lanceur doit utiliser les routines en ROM pour lire le secteur de boot de la démo, j'ai pas trop d'avis.
Perso pour CS9-1280, je verrais bien les demos comme une super grosse D7 qui présente à la fois la partie fd/sd standard contenant le prog basic "loader", sauf que le prog basic n'a pas besoin de demander l'adresse du fichier de démo. Il peut savoir que le controler CS9-1280 est présent (marquage en $E000), et directement trouver l'adresse du fichier dans la page 0 du moniteur auquel il ajoutera l'offset constant l'où l'on trouve les données du fichier démo. Sans controlleur CS, le même prog basic peut être autrement saisi à la main (ou depuis K7/D7), et comme il ne trouve pas le controleur CS présent, il demande à l'utilisateur d'entrer l'adresse du fichier de démo.
Je ne sais pas si je suis clair, mais disons en résumé que le lanceur de démo peut retrouver de lui-même l'adresse du fichier de démo en cas de présence du controleur CS9-1280 et éviter la partie fastidieuse de recopie cette adresse pour l'utilisateur.
Après savoir si le lanceur doit utiliser les routines en ROM pour lire le secteur de boot de la démo, j'ai pas trop d'avis.
Ok. Ca serait effectivement bien d'avoir un truc pour faire fonctionner de façon homogène et autonomes toutes les démos précédentes.Daniel a écrit :Dans la journée je vais essayer de résumer tous les appels nécessaires pour écrire la démo et je donnerai les sources (à jour) de toutes les fonctions utilisées.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [SDMOTO] fusion SDBOOT + demonstration SD
Le document est en cours de préparation, il s'appellera "SDMOTO - Memento pour le développement de programmes de démonstration".
Je crois qu'il sera utile pour tous les développeurs, moi le premier, car j'ai tellement de versions différentes des utilitaires et des démonstrations que je m'y perds un peu. J'ajouterai aussi des documents de référence, en particulier les spécifications officielles des cartes SD avec toutes les commandes. Finalement ça risque d'être un peu long car je veux remettre au propre tous les programmes et les tester avant de les diffuser.
On peut déjà adopter ton idée : une démo est constituée d'une image .sd (contenant quatre faces de disquettes) suivie d'un nombre quelconque de secteurs de données, le tout groupé dans un seul fichier .sd. Je verrai bien tous les programmes de la démonstration au format standard Thomson (.BAS et/ou .BIN) stockés dans les quatre faces de disquette, et uniquement les données dans les secteurs suivants. Le seul point gênant est de rendre obligatoire le contrôleur CS91-280 pour lancer la démo. Mais est-ce réellement un problème ?
Avec le contrôleur CS91-280, l'utilisation est plus facile (il n'y a pas de programme à charger avec une cassette ou une disquette). Et surtout la programmation est simplifiée du fait de la présence dans le contrôleur de presque toutes les fonctions nécessaires. Il n'est pas utile d'initialiser la carte SD, c'est déjà fait.
Les informations connues sont en RAM (adresses $60xx pour TO et $20xx pour MO) :
On lance une commande par la fonction EXCMD
Exemple : Afficher une image monochrome à partir des données
Il y a des variantes, selon les performances attendues. Du plus lent au plus rapide :
- Utiliser la fonction de lecture d'un secteur du contrôleur CS91-280
- Lire les secteurs un par un avec la commande CMD17
- Lire des secteurs multiples avec la commande CMD18 (comme ci-dessus)
- Comme ci-dessus en déroulant la boucle de lecture d'un octet
- Comme ci-dessus en déroulant la boucle de lecture d'un secteur
Je crois qu'il sera utile pour tous les développeurs, moi le premier, car j'ai tellement de versions différentes des utilitaires et des démonstrations que je m'y perds un peu. J'ajouterai aussi des documents de référence, en particulier les spécifications officielles des cartes SD avec toutes les commandes. Finalement ça risque d'être un peu long car je veux remettre au propre tous les programmes et les tester avant de les diffuser.
On peut déjà adopter ton idée : une démo est constituée d'une image .sd (contenant quatre faces de disquettes) suivie d'un nombre quelconque de secteurs de données, le tout groupé dans un seul fichier .sd. Je verrai bien tous les programmes de la démonstration au format standard Thomson (.BAS et/ou .BIN) stockés dans les quatre faces de disquette, et uniquement les données dans les secteurs suivants. Le seul point gênant est de rendre obligatoire le contrôleur CS91-280 pour lancer la démo. Mais est-ce réellement un problème ?
Avec le contrôleur CS91-280, l'utilisation est plus facile (il n'y a pas de programme à charger avec une cassette ou une disquette). Et surtout la programmation est simplifiée du fait de la présence dans le contrôleur de presque toutes les fonctions nécessaires. Il n'est pas utile d'initialiser la carte SD, c'est déjà fait.
Les informations connues sont en RAM (adresses $60xx pour TO et $20xx pour MO) :
Code : Tout sélectionner
SD_LB0 EQU $608E adresse du debut du fichier .sd dans la carte SD
SD_TYP EQU $6092 type de carte SD=0 SDHC=1
Code : Tout sélectionner
* EXCMD Lance une commande pour la carte SD
* Appel par JSR $E028
* - Registre U = adresse des parametres de la commande
* (code commande + 4 octets + checksum + code retour)
* - Registre DP = $A7(MO) ou $E7(TO)
* - Retour registre A (0 = OK, sinon erreur)
* - Les registres ne sont pas preserves (sauf DP)
Code : Tout sélectionner
*------------------------------------------------------
* Initialisation PIA pour SDMOTO
*------------------------------------------------------
LDA #$E7 valeur d'initialisation DP
TFR A,DP initialisation DP
LDA <$CE lecture registre de controle A
ANDA #$FB raz bit 2
STA <$CE selection DDRA
LDB #$60 set bits 5 et 6
STB <$CC bits MOSI et CLOCK en sortie
ORA #$04 set b2
STA <$CE selection PA
*------------------------------------------------------
* Lancement de la commande CMD18
*------------------------------------------------------
* Calculer ici l'adresse physique des donnees
* en fonction de SD_LB0 (adresse physique de l'image de disquette actuellement montee)
* et de SD_TYP (type de carte SD ou SDHC)
* Mettre l'adresse en CMD18+1 sur quatre octets
LDU #CMD18 adresse commande CMD18
JSR $E028 EXCMD = execution commande
*------------------------------------------------------
* Affichage de l'image
*------------------------------------------------------
DISPLAY
LDU #$4000 adresse memoire video
LDY #$0010 nombre de blocs a lire
DISPL1
LBSR RBYTE lecture d'un octet
CMPA #$FE test debut de bloc
BNE DISPL1 attente debut de bloc
LDX #$0200 nombre d'octets a lire
DISPL2
LBSR RBYTE lecture d'un octet
STA ,U+ affichage
LEAX -1,X decrementation compteur
BNE DISPL2 lecture octet suivant
LBSR RBYTE lecture CRC1
LBSR RBYTE lecture CRC2
LEAY -1,Y decrementation compteur
BNE DISPL1 lecture bloc suivant
BRA SUITE suite du programme...
*------------------------------------------------------
* LECTURE D'UN OCTET (SDMOTO) = 28 cycles
* Le registre B n'est pas préservé
* Valeur de l'octet dans le registre A en sortie
* Optimisation du compteur de boucle par Samuel
* Optimisation transfert b7 avec CMPB par Daniel
*------------------------------------------------------
RBYTE
LDA #$FE b0 marqueur fin de boucle (2)
RBYTE1
LDB #$7F Valeur pour test bit 7 (2)
STB <$CC clock high, di high (4)
CMPB <$CC PA b7 (bit lu) -> carry (4)
LDB #$5F clear bit 5 (2)
STB <$CC clock low, di high (4)
ROLA C (bit lu) -> b0 reg A (2)
BCS RBYTE1 suite de la boucle (3)
RTS retour (octet dans A) (5)
*------------------------------------------------------
* FONCTIONS D'ACCES A LA CARTE SD
*------------------------------------------------------
CMD18
FCB $52 read multiple block
FDB $0000 adresse bloc (poids fort)
FDB $0000 adresse bloc (poids faible)
FCB $00 checksum non testee
FCB $00 code retour attendu
CMD12
FCB $4C stop transmission
FDB $0000 dummy parameter
FDB $0000 dummy parameter
FCB $00 checksum non testee
FCB $00 code retour attendu
END
- Utiliser la fonction de lecture d'un secteur du contrôleur CS91-280
- Lire les secteurs un par un avec la commande CMD17
- Lire des secteurs multiples avec la commande CMD18 (comme ci-dessus)
- Comme ci-dessus en déroulant la boucle de lecture d'un octet
- Comme ci-dessus en déroulant la boucle de lecture d'un secteur
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Re: [SDMOTO] fusion SDBOOT + demonstration SD
La première version du document "SDMOTO - Memento pour le développement de programmes de démonstration" est en ligne à cette adresse : http://dcmoto.free.fr/bricolage/sdmoto/demos.html
C'est un premier jet. Il manque certainement des informations, il y a peut-être de petites erreurs ou imprécisions. N'hésitez pas à signaler les anomalies et à faire des suggestions, pour permettre de corriger et compléter cette page et en faire une référence pour les développeurs.
C'est un premier jet. Il manque certainement des informations, il y a peut-être de petites erreurs ou imprécisions. N'hésitez pas à signaler les anomalies et à faire des suggestions, pour permettre de corriger et compléter cette page et en faire une référence pour les développeurs.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Re: [SDMOTO] fusion SDBOOT + demonstration SD
Merci Daniel, pour cette documentation très détaillée et qui seras certainement très utile
-
- Messages : 7924
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [SDMOTO] fusion SDBOOT + demonstration SD
Super! Merci Daniel
Je viens de survoler rapidement et je tombe sur une incohérence je pense.DP est initialisé dans la zone des PIA. Alors Page0 ou PIA?
Il y a aussi un 'd' en trop dans idle state
Je viens de survoler rapidement et je tombe sur une incohérence je pense.
DP en page 0 du moniteur, ok. Or dans l'exemple qui suitPour lancer la commande, utiliser la procédure EXCMD du contrôleur CS91-280.
- Initialiser le registre DP à $20 pour les ordinateurs MO et $60 pour les ordinateurs TO.
...
- Appeler EXCMD en $E028 (TO) ou $A028 (MO).
Code : Tout sélectionner
*------------------------------------------------------
* Initialisation PIA pour SDMOTO
*------------------------------------------------------
LDA #$E7 valeur d'initialisation DP
TFR A,DP initialisation DP
...
JSR $E028 EXCMD = execution commande
Il y a aussi un 'd' en trop dans idle state
Code : Tout sélectionner
*------------------------------------------------------
* COMMANDES CARTE SD
*------------------------------------------------------
CMD0
FCB $40 go iddle state
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [SDMOTO] fusion SDBOOT + demonstration SD
Bien vu, et merci __sam__. C'est corrigé. Il y a peut-être d'autres erreurs ou imprécisions, mais surtout de grosses lacunes. J'essaierai de les combler en fonction des questions des développeurs.
En particulier, c'est évident pour moi mais peut-être pas clair pour tous : L'adresse à fournir sur 4 octets pour la lecture d'un bloc par la commande CMD17 ou de blocs multiples par la commande CMD18 est différente selon le type de carte :
- Numéro de l'octet pour les SD
- Numéro du bloc pour les SDHC
Bloc est strictement synonyme de secteur, la taille du bloc est fixe (512 octets), les blocs et les octets sont numérotés à partir de zéro.
Dans tous les programmes, il faut obligatoirement tester le type de carte (déterminé par la procédure d'initialisation) pour calculer l'adresse. Par exemple, pour passer au bloc suivant, il faut ajouter 1 pour une carte SDHC et $200 pour une SD.
Je vais ajouter ces informations dans le document...
En particulier, c'est évident pour moi mais peut-être pas clair pour tous : L'adresse à fournir sur 4 octets pour la lecture d'un bloc par la commande CMD17 ou de blocs multiples par la commande CMD18 est différente selon le type de carte :
- Numéro de l'octet pour les SD
- Numéro du bloc pour les SDHC
Bloc est strictement synonyme de secteur, la taille du bloc est fixe (512 octets), les blocs et les octets sont numérotés à partir de zéro.
Dans tous les programmes, il faut obligatoirement tester le type de carte (déterminé par la procédure d'initialisation) pour calculer l'adresse. Par exemple, pour passer au bloc suivant, il faut ajouter 1 pour une carte SDHC et $200 pour une SD.
Je vais ajouter ces informations dans le document...
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7924
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [SDMOTO] fusion SDBOOT + demonstration SD
Est-ce que tu as expliqué quelque part le format des fichiers de démo de musique et de vidéo ? J'ai cru comprendre que SDBOOT en chargeait les 512 premiers octets, puis sautait à une certaine adresse fixe de ce buffer. Dans le buffer nouvellement chargé on trouve le code qui joue le reste des données. Est-ce juste ?
Autre question (dont je me doute de la réponse), sur les 4 octets d'adresse/numéro de bloc c'est du MSB bien entendu ?
Autre question (dont je me doute de la réponse), sur les 4 octets d'adresse/numéro de bloc c'est du MSB bien entendu ?
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [SDMOTO] fusion SDBOOT + demonstration SD
C'est du MSB (octet de poids fort à gauche).
Dans le mémento pour les développeurs je ne parlerai pas les techniques utilisées pour les démos de musique et de vidéo, pour ne pas alourdir le document. Je compte un jour faire un document spécial pour expliquer la technique utilisée pour jouer la musique sans interruption entre chaque secteur, et un autre pour expliquer la technique utilisée pour compresser la vidéo.
Dans les premières démos de musique, le programme SDBOOT chargeait en RAM le premier secteur du fichier SD (512 octets) puis l'exécutait. Ce secteur contenait le programme d'affichage de l'image de présentation (16 secteurs) et de lecture de la musique (secteurs suivants). Tu as bien compris.
A cette époque le contrôleur CS91-280 n'existait pas. Le programme SDBOOT était lancé à partir d'une cassette (ou d'une disquette), il devait être aussi court que possible, c'est pourquoi je mettais la démo proprement dite dans le fichier .sd juste avant les données.
Avec la simulation de disquette sur carte SD la donne a changé : la carte SD est initialisée par le contrôleur, et on dispose de 4 faces de disquettes pour stocker les programmes, il n'y a plus de contrainte de taille. En conséquence le programme SDBOOT disparaît, le programme de démo devient un programme Thomson classique stocké dans l'image de disquette de démarrage, le fichier .sd de la démonstration contient seulement les données : 16 secteurs d'image suivis des secteurs de musique.
Plutôt qu'un long discours, voici la dernière version du programme SDPLAY.BIN et d'un programme de lancement ANNEES80.BAS. L'adresse $03FCC800 "pokée" en $9F8E est celle du fichier .sd contenant l'image de présentation et la musique de la démo "Années 80". Le programme SDPLAY.BIN est identique pour toutes les démos de musique, la seule chose qui change est l'adresse "pokée" par le programme BASIC de lancement.
Dans le mémento pour les développeurs je ne parlerai pas les techniques utilisées pour les démos de musique et de vidéo, pour ne pas alourdir le document. Je compte un jour faire un document spécial pour expliquer la technique utilisée pour jouer la musique sans interruption entre chaque secteur, et un autre pour expliquer la technique utilisée pour compresser la vidéo.
Dans les premières démos de musique, le programme SDBOOT chargeait en RAM le premier secteur du fichier SD (512 octets) puis l'exécutait. Ce secteur contenait le programme d'affichage de l'image de présentation (16 secteurs) et de lecture de la musique (secteurs suivants). Tu as bien compris.
A cette époque le contrôleur CS91-280 n'existait pas. Le programme SDBOOT était lancé à partir d'une cassette (ou d'une disquette), il devait être aussi court que possible, c'est pourquoi je mettais la démo proprement dite dans le fichier .sd juste avant les données.
Avec la simulation de disquette sur carte SD la donne a changé : la carte SD est initialisée par le contrôleur, et on dispose de 4 faces de disquettes pour stocker les programmes, il n'y a plus de contrainte de taille. En conséquence le programme SDBOOT disparaît, le programme de démo devient un programme Thomson classique stocké dans l'image de disquette de démarrage, le fichier .sd de la démonstration contient seulement les données : 16 secteurs d'image suivis des secteurs de musique.
Plutôt qu'un long discours, voici la dernière version du programme SDPLAY.BIN et d'un programme de lancement ANNEES80.BAS. L'adresse $03FCC800 "pokée" en $9F8E est celle du fichier .sd contenant l'image de présentation et la musique de la démo "Années 80". Le programme SDPLAY.BIN est identique pour toutes les démos de musique, la seule chose qui change est l'adresse "pokée" par le programme BASIC de lancement.
Code : Tout sélectionner
/**************************************************\
* S D P L A Y *
* (c) 2013 - Daniel Coulom *
* http://dcmoto.free.fr/ *
* http://forum.system-cfg.com/ *
*--------------------------------------------------*
* Ce code est distribue gratuitement dans l'espoir *
* qu'il sera utile, mais sans aucune garantie et *
* sans engager la responsabilité de l'auteur. *
* Vous pouvez l' utiliser, le modifier et le *
* diffuser librement, en conservant cette licence *
* et les références de l'auteur dans toutes les *
* copies. L'exploitation commerciale est interdite.*
\**************************************************/
* Ce programme utilise le module SDMOTO associe au
* controleur CS91-280 pour jouer de la musique
* Il réalise les fonctions suivantes pour TO ou MO:
* - affichage d'une image monochrome (16 blocs)
* - envoi sur le CNA de musique 5512Hz 6 bits
* L'adresse en parametre de la commande CMD18
* doit être saisie manuellement
*
* Utilisation du 2eme port joystick
* Port A $A7CC (pour les MO) ou $E7CC (pour les TO)
* PA5 en sortie --> SD Clock SCK DB9 pin 2
* PA6 en sortie --> SD Data IN MOSI DB9 pin 3
* PA7 en entree <-- SD Data OUT MISO DB9 pin 4
/**************************************************\
* Version 2014.08.07 *
\**************************************************/
* Historique
* 2014.08.07 correction bug (STA FIN1+1 et pas FIN+1)
* 2014.08.06 masquage des interruptions
* 2014.07.13 adaptation automatique pour MO ou TO
* 2014.02.06 correction bug : initialiser U pour CMD12
* 2014.02.06 correction bug : ajout CC dans PULS final
* 2013.12.30 ajout initialisation PIA pour carte SD
* 2013.10.21 ajout initialisation du CNA en sortie
* 2013.10.19 saisie manuelle de l'adresse pour CMD18
* 2013.10.19 indirection vers EXCMD en $A028
* 2013.10.18 premiere version avec controleur CS91-280
*------------------------------------------------------
* Initialisations et execution CMD18 = Read-Multiple-Block
*------------------------------------------------------
ORG $9E00
INIT
PSHS U,Y,X,DP,B,A,CC sauvegarde des registres du Basic
ORCC #$50
LDX #$1F40 adresse pour test RAM ou ROM
LDB ,X lecture adresse X
COM ,X tente de modifier adresse X
CMPB ,X test modification adresse X
BEQ INIT1 pas de difference -> TO
COM ,X retablissement adresse X
LDA #$A7 valeur initialisation DP pour MO
BRA INIT2 suite des initialisations
INIT1
LDY #$4000 adresse de debut d'ecran
STY DISPLAY+1 initialisation adresse ecran
LDA #$E0 valeur adresse EXCMD (poids fort)
STA READ+1 pour execution CMD18
STA FIN1+1 pour execution CMD12
LDA #$E7 valeur initialisation DP pour TO
INIT2
TFR A,DP initialisation DP
* Initialisation PIA pour SDMOTO
LDA <$CE lecture registre de controle A
ANDA #$FB raz bit 2
STA <$CE selection DDRA
LDB #$60 set bits 5 et 6
STB <$CC bits MOSI et CLOCK en sortie
ORA #$04 set b2
STA <$CE selection PA
* Initialisation CNA en sortie
LDA <$CF lecture registre de controle B
ANDA #$FB raz bit 2
STA <$CF selection DDRB
LDB #$3F set bits 0-5
STB <$CD bits CNA en sortie
ORA #$04 set b2
STA <$CF selection PB
* Lancement de la commande CMD18
LDU #CMD18 adresse commande CMD18
READ
JSR $A028 EXCMD = execution commande
* modifie en $E028 pour TO
*------------------------------------------------------
* Affichage de l'image
*------------------------------------------------------
DISPLAY
LDU #$0000 adresse memoire video
LDY #$0010 nombre de blocs a lire
DISPL1
LBSR RBYTE lecture d'un octet
CMPA #$FE test debut de bloc
BNE DISPL1 attente debut de bloc
LDX #$0200 nombre d'octets a lire
DISPL2
LBSR RBYTE lecture d'un octet
STA ,U+ affichage
LEAX -1,X decrementation compteur
BNE DISPL2 lecture octet suivant
LBSR RBYTE lecture CRC1
LBSR RBYTE lecture CRC2
LEAY -1,Y decrementation compteur
BNE DISPL1 lecture bloc suivant
BRA PLAY
*------------------------------------------------------
* FIN DE FICHIER
*------------------------------------------------------
FIN
LDU #CMD12 adresse commande CMD12
FIN1
JSR $A028 EXCMD = execution commande CMD12
* modifie en $E028 pour TO
PULS B
*------------------------------------------------------
* RETOUR AU BASIC
*------------------------------------------------------
RETOUR
PULS CC,A,B,DP,X,Y,U,PC
*------------------------------------------------------
* Lecture de la musique
*------------------------------------------------------
PLAY
LEAU $E000,U adresse ecran = fin - $2000
LEAX $8,U adresse buffer complementaire
*------------------------------------------------------
* Attente debut de bloc
*------------------------------------------------------
PLAY0
LBSR RBYTE lecture d'un octet
CMPA #$FE test debut de bloc
BNE PLAY0 attente debut de bloc
LDB #$08 compteur octets supplementaires
PSHS B empilage compteur
*------------------------------------------------------
* Lecture d'un bloc
*------------------------------------------------------
PLAY1
BSR PLAY8 joue 8 octets, stocke 1 bit
BMI FIN retour en fin de fichier (3)
LEAX 1,X retablit pointeur octet sup (5)
NOP temporisation (2)
BSR PLAY8 joue 8 octets, stocke 1 bit
BMI FIN retour en fin de fichier (3)
LEAX 1,X retablit pointeur octet sup (5)
NOP temporisation (2)
BSR PLAY8 joue 8 octets, stocke 1 bit
BMI FIN retour en fin de fichier (3)
LEAX 1,X retablit pointeur octet sup (5)
NOP temporisation (2)
BSR PLAY8 joue 8 octets, stocke 1 bit
BMI FIN retour en fin de fichier (3)
LEAX 1,X retablit pointeur octet sup (5)
NOP temporisation (2)
BSR PLAY8 joue 8 octets, stocke 1 bit
BMI FIN retour en fin de fichier (3)
LEAX 1,X retablit pointeur octet sup (5)
NOP temporisation (2)
BSR PLAY8 joue 8 octets, stocke 1 bit
BMI FIN retour en fin de fichier (3)
LEAX 1,X retablit pointeur octet sup (5)
NOP temporisation (2)
BSR PLAY8 joue 8 octets, stocke 1 bit
BMI FIN retour en fin de fichier (3)
LEAX 1,X retablit pointeur octet sup (5)
NOP temporisation (2)
BSR PLAY8 joue 8 octets, stocke 1 bit
* DEC ,S compteur octets supplementaires
FDB $6A60 equivalent pour 7 cycles (7)
BNE PLAY1 boucle suivante (3)
*------------------------------------------------------
* Lecture des octets de CRC
*------------------------------------------------------
* premier octet CRC 158 + 5 + 4 + 5 + 10 = 182
LBSR RBYTE lecture octet CRC (158)
LDB 1,X chargement echantillon sup. (5)
STB <$CD envoi de l'echantillon 1 (4)
LEAX 1,X retablit pointeur octet sup (5)
NOP temporisation (2)
NOP temporisation (2)
NOP temporisation (2)
NOP temporisation (2)
NOP temporisation (2)
* deuxieme octet CRC 158 + 5 + 4 + 5 + 10 = 182
LBSR RBYTE lecture octet CRC (158)
LDB 1,X chargement echantillon sup. (5)
STB <$CD envoi de l'echantillon 1 (4)
LEAX 2,X retablit pointeur octet sup (5)
NOP temporisation (2)
NOP temporisation (2)
NOP temporisation (2)
* 4 cycles de temporisation en moins pour compenser
* le retard pour jouer les 6 echantillons suivants
*------------------------------------------------------
* Lecture des octets inter-blocs
* joue avec retard de 4 cycles par rapport a PLAY8
*------------------------------------------------------
BSR SUPP envoi de l'echantillon 3 (176)
LDB #$08 compteur echantillons sup. (2)
STB ,S stocke le compteur (4)
BSR SUPP envoi de l'echantillon 4 (176)
BSR SUPP6 envoi de l'echantillon 5 (182)
BSR SUPP6 envoi de l'echantillon 6 (182)
BSR SUPP6 envoi de l'echantillon 7 (182)
BSR SUPP6 envoi de l'echantillon 8 (182)
LEAX -1,X retablit pointeur (5)
NOP temporisation (2)
BRA PLAY1 traitement du bloc suivant (3)
* temporisation de 10 cycles apres dernier BSR SUPP
* pour retablir les 4 cycles de decalage du debut
*------------------------------------------------------
* LIRE UN OCTET ET JOUER UN ECHANTILLON SUPPLEMENTAIRE
* joue avec un retard de 4 cycles par rapport a PLAY8
*------------------------------------------------------
SUPP6
* Appel de SUPP precede d'une temporisation 6 cycles
NOP temporisation (2)
NOP temporisation (2)
NOP temporisation (2)
SUPP
* total avec lecture octet : 2+3+156+6+4+5=176
* total sans lecture octet : 2+3+153+3+6+4+5=176
CMPA #$FE test debut de bloc (2)
BEQ SUPP2 pas d'octet à lire (3)
BSR RBYTE lecture d'un octet (156)
SUPP1
LDB ,X+ chargement echantillon (6)
STB <$CD envoi de l'echantillon (4)
RTS (5)
SUPP2
BSR TEMPO (153)
BRA SUPP1 jouer l'echantillon (3)
*------------------------------------------------------
* Joue 8 octets et recupere 1 bit dans le premier
*------------------------------------------------------
PLAY8
* premier octet 7 + 156 + 4 + 2 + 6 + 7 = 182
BSR RBYTE lecture echantillon (156)
STA <$CD envoi de l'echantillon (4)
ASLA b7 dans carry (2)
ROL ,X stockage b7 (6)
CMPX >$0000 temporisation (7)
* octets 2 a 7
BSR PBYTE deuxieme octet (182)
BSR PBYTE troisieme octet (182)
BSR PBYTE quatrieme octet (182)
BSR PBYTE cinquieme octet (182)
BSR PBYTE sixieme octet (182)
BSR PBYTE septieme octet (182)
* huitieme octet 7 + 156 + 4 + 5 = 172
LEAX -1,X modifie pointeur octet sup (5)
NOP temporisation (2)
BSR RBYTE lecture echantillon (156)
STA <$CD envoi de l'echantillon (4)
RTS (5)
*------------------------------------------------------
* Lit et joue 1 octet en 182 cycles
*------------------------------------------------------
PBYTE
* total avec BSR : 7 + 156 + 4 + 10 + 5 = 182
BSR RBYTE lecture echantillon (156)
STA <$CD envoi de l'echantillon (4)
NOP temporisation (2)
NOP temporisation (2)
NOP temporisation (2)
NOP temporisation (2)
NOP temporisation (2)
RTS (5)
*------------------------------------------------------
* Temporisation 153 cycles
*------------------------------------------------------
TEMPO
* total avec BSR : 7 + 2 + 135 + 2 + 2 + 5 = 153
LDB #$1B 27 x 5 = 135 cycles (2)
SUPP3
DECB decremente le compteur (2)
BNE SUPP3 boucle de temporisation (3)
NOP temporisation (2)
NOP temporisation (2)
RTS (5)
*------------------------------------------------------
* LECTURE D'UN OCTET
* Le registre B n'est pas preserve
* Valeur de l'octet dans le registre A en sortie
*------------------------------------------------------
RBYTE
* premier octet
LDB #$7F Valeur pour test bit 7 (2)
CMPB <$CC PA b7 (bit lu) -> carry (4)
STB <$CC clock high, di high (4)
LDB #$5F clear bit 5 (2)
STB <$CC clock low, di high (4)
ROLA C (bit lu) -> b0 reg A (2)
* deuxieme octet
LDB #$7F Valeur pour test bit 7 (2)
CMPB <$CC PA b7 (bit lu) -> carry (4)
STB <$CC clock high, di high (4)
LDB #$5F clear bit 5 (2)
STB <$CC clock low, di high (4)
ROLA C (bit lu) -> b0 reg A (2)
* troisieme octet
LDB #$7F Valeur pour test bit 7 (2)
CMPB <$CC PA b7 (bit lu) -> carry (4)
STB <$CC clock high, di high (4)
LDB #$5F clear bit 5 (2)
STB <$CC clock low, di high (4)
ROLA C (bit lu) -> b0 reg A (2)
* quatrieme octet
LDB #$7F Valeur pour test bit 7 (2)
CMPB <$CC PA b7 (bit lu) -> carry (4)
STB <$CC clock high, di high (4)
LDB #$5F clear bit 5 (2)
STB <$CC clock low, di high (4)
ROLA C (bit lu) -> b0 reg A (2)
* cinquieme octet
LDB #$7F Valeur pour test bit 7 (2)
CMPB <$CC PA b7 (bit lu) -> carry (4)
STB <$CC clock high, di high (4)
LDB #$5F clear bit 5 (2)
STB <$CC clock low, di high (4)
ROLA C (bit lu) -> b0 reg A (2)
* sixieme octet
LDB #$7F Valeur pour test bit 7 (2)
CMPB <$CC PA b7 (bit lu) -> carry (4)
STB <$CC clock high, di high (4)
LDB #$5F clear bit 5 (2)
STB <$CC clock low, di high (4)
ROLA C (bit lu) -> b0 reg A (2)
* septieme octet
LDB #$7F Valeur pour test bit 7 (2)
CMPB <$CC PA b7 (bit lu) -> carry (4)
STB <$CC clock high, di high (4)
LDB #$5F clear bit 5 (2)
STB <$CC clock low, di high (4)
ROLA C (bit lu) -> b0 reg A (2)
* huitieme octet
LDB #$7F Valeur pour test bit 7 (2)
CMPB <$CC PA b7 (bit lu) -> carry (4)
STB <$CC clock high, di high (4)
LDB #$5F clear bit 5 (2)
STB <$CC clock low, di high (4)
ROLA C (bit lu) -> b0 reg A (2)
*
RTS retour (octet dans A) (5)
* longueur totale avec BSR: 7 + 18*8 + 5 = 156
* avec LBSR: 9 + 18*8 + 5 = 158
*------------------------------------------------------
* FONCTIONS D'ACCES A LA CARTE SD
*------------------------------------------------------
CMD18
FCB $52 read multiple block
FDB $0000 adresse bloc (poids fort)
FDB $0000 adresse bloc (poids faible)
FCB $00 checksum non testee
FCB $00 code retour attendu
CMD12
FCB $4C stop transmission
FDB $0000 dummy parameter
FDB $0000 dummy parameter
FCB $00 checksum non testee
FCB $00 code retour attendu
END
Code : Tout sélectionner
10 'ANNEES80
20 CLEAR,&H9DFF
30 CLS:LOCATE0,0,0
40 SCREEN0,7,7
50 LOADM"SDPLAY"
60 POKE&H9F8E,&H03
61 POKE&H9F8F,&HFC
62 POKE&H9F90,&HC8
63 POKE&H9F91,&H00
90 CLS:PRINT" "
99 EXEC:GOTO90
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7924
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [SDMOTO] fusion SDBOOT + demonstration SD
En fait, si je comprends bien cette adresse pourrait même être directement calculée à partir de celle stockée stocké en page 0 et utilisée par CS9-1280.L'adresse $03FCC800 "pokée" en $9F8E est celle du fichier .sd contenant l'image de présentation et la musique de la démo "Années 80".
J'ai fait une maquette ici: http://dl.free.fr/pPtRnj7vl
Ca marche pas trop mal (on entend quand même un "clacclac" régulier au dessus de la musique dans l'emulateur), mais ce qui m'étonne c'est que je dois ajouter $00280200 à l'adresse du fichier en £H608E. Il y a $200 en trop par rapport à ce que je m'attendais. [EDIT] hum ca marche sur emulateur, mais plante sur vrai TO8. Il y a un truc qui doit clocher dans le calcul de l'adresse du début des données, mais je ne vois pas quoi à cette heure tardive
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [SDMOTO] fusion SDBOOT + demonstration SD
L'émulation de la carte SD dans dcmoto est très simplifiée. En fait on n'accède pas à une image de carte SD, mais seulement à un fichier .sd de la carte. Ce fichier est chargé en mémoire. Il y a certainement un problème s'il dépasse la taille mémoire du PC, mais avec un PC moderne ça ne doit pas se produire souvent, et sûrement pas pour un fichier de musique de seulement quelques Mo.
Pour simuler la carte SD, dcmoto ajoute automatiquement deux secteurs avant le fichier .sd. Dans les dernières versions de l'émulateur (après le 8/12/2014), le premier simule le secteur de boot de la carte, le deuxième simule un répertoire et contient une entrée BOOT.SD. Dans les versions précédente le premier n'est pas utilisé, le deuxième contient l'adresse physique du fichier .sd. Dans les deux cas l'adresse physique est toujours $00000400, premier octet du fichier .sd
Après initialisation, il y a donc l'adresse $00000400 en $608E et le type de carte est 0 (carte SD). En ajoutant $00280000 à l'adresse précédente on accède donc bien au premier secteur après l'image de disquettes. Ton calcul est juste.
Par contre tu as récupéré une version "ANNEES80" de première génération, lancée par SDBOOT. Elle contient le programme équivalent à SDPLAY dans le premier secteur. Les données commencent au deuxième secteur, c'est pourquoi il faut ajouter $200. Attention aussi au type de carte, le calcul est bon pour une carte SD mais il faut l'adapter si on utilise une carte SDHC.
De plus j'ai légèrement changé le format de la musique dans la dernière version. L'ancien fichier de données n'est pas compatible avec la nouvelle version de SDPLAY, c'est ce qui explique les parasites entendus aux changements de secteur.
J'ai ajouté les dernières versions de SDPLAY et ANNEES80 à la page http://dcmoto.free.fr/programmes/sdmoto ... index.html
Lien direct pour le téléchargement : http://dcmoto.free.fr/programmes/sdmoto ... 141218.zip
Pour simuler la carte SD, dcmoto ajoute automatiquement deux secteurs avant le fichier .sd. Dans les dernières versions de l'émulateur (après le 8/12/2014), le premier simule le secteur de boot de la carte, le deuxième simule un répertoire et contient une entrée BOOT.SD. Dans les versions précédente le premier n'est pas utilisé, le deuxième contient l'adresse physique du fichier .sd. Dans les deux cas l'adresse physique est toujours $00000400, premier octet du fichier .sd
Après initialisation, il y a donc l'adresse $00000400 en $608E et le type de carte est 0 (carte SD). En ajoutant $00280000 à l'adresse précédente on accède donc bien au premier secteur après l'image de disquettes. Ton calcul est juste.
Par contre tu as récupéré une version "ANNEES80" de première génération, lancée par SDBOOT. Elle contient le programme équivalent à SDPLAY dans le premier secteur. Les données commencent au deuxième secteur, c'est pourquoi il faut ajouter $200. Attention aussi au type de carte, le calcul est bon pour une carte SD mais il faut l'adapter si on utilise une carte SDHC.
De plus j'ai légèrement changé le format de la musique dans la dernière version. L'ancien fichier de données n'est pas compatible avec la nouvelle version de SDPLAY, c'est ce qui explique les parasites entendus aux changements de secteur.
J'ai ajouté les dernières versions de SDPLAY et ANNEES80 à la page http://dcmoto.free.fr/programmes/sdmoto ... index.html
Lien direct pour le téléchargement : http://dcmoto.free.fr/programmes/sdmoto ... 141218.zip
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7924
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [SDMOTO] fusion SDBOOT + demonstration SD
Ah oui, je comprends le décalage alors. C'était la version dispo sur ton site il y a quelque jours.Daniel a écrit :Par contre tu as récupéré une version "ANNEES80" de première génération, lancée par SDBOOT. Elle contient le programme équivalent à SDPLAY dans le premier secteur. Les données commencent au deuxième secteur, c'est pourquoi il faut ajouter $200.
J'imagine que c'est pour ca que ca ne marche pas sur le vrai TO8. En SDHC il faut indiquer un nombre de secteurs, c'est à dire la valeur en [$608E(+0..3)] + $28000, mais le tout divisé par 512. C'est bien ca ?Attention aussi au type de carte, le calcul est bon pour une carte SD mais il faut l'adapter si on utilise une carte SDHC.
J'ai un petit doute.. en SDHC $608E-$6091 ne contient pas un numéro de secteur, mais bien le numéro d'octet du fichier. C'est sans doute les routines dans CS9-1280 qui font la conversion en numéro de secteur en cas de SDHC. Mais la démo utilisant le points d'entrée bas-niveau, cette division par 512 n'est pas faite. Il faut donc la faire en amont dans le lanceur basic. C'est bien ca ?
Ok.. je me disais bien que ces "clap clap" réguliers ne devaient pas être là en vrai.De plus j'ai légèrement changé le format de la musique dans la dernière version. L'ancien fichier de données n'est pas compatible avec la nouvelle version de SDPLAY, c'est ce qui explique les parasites entendus aux changements de secteur.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [SDMOTO] fusion SDBOOT + demonstration SD
Normalement non. Avec les anciennes versions du contrôleur CS91-280, cette zone contient l'adresse physique inscrite par l'utilisateur dans le deuxième secteur de la carte. Cette adresse, déterminée par bootaddress.exe, est exprimée en secteurs pour les cartes SDHC et en octets pour les cartes SD. Avec les versions 2014.12.08 et suivantes, le programme d'initialisation recherche automatiquement l'adresse physique du fichier BOOT.SD et la convertit en secteurs ou en octets selon le type de carte.__sam__ a écrit :en SDHC $608E-$6091 ne contient pas un numéro de secteur, mais bien le numéro d'octet du fichier.
Dans l'émulateur dcmoto, par contre, c'est différent : le type de carte n'est pas testé, car le fichier .sd n'est pas forcément sur une carte. Il peut être sur disque dur, sur DVD, sur clé USB, etc. Donc, dans dcmoto, le type de carte est toujours forcé à zéro (carte SD).
C'est pourquoi il est conseillé, pour tous les calculs d'adresse, de tester le type de carte et de prévoir les deux cas.
Dans les démos en streaming, l'utilisation de la commande CMD18 (lecture de blocs multiples) nécessite de donner l'adresse de départ dans le bon format, mais ensuite il n'y a plus aucun calcul. L'incrémentation de l'adresse est gérée par la carte elle-même et on ne s'en préoccupe pas.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7924
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [SDMOTO] fusion SDBOOT + demonstration SD
Je pense avoir trouvé une typo dans sdplay.doc
Les adresses passées en 60-63 ne correspondent pas avec sdplay.lst. On devrait retrouver &H9F8E en ligne 60 et &H9F91 en 63.
Sinon, j'ai fait une nouvelle version "combo" http://dl.free.fr/q3Yqe4i3F (était http://dl.free.fr/pQXrvhEV9, voir l'édit) qui j'espère marchera avec les SDHC. En tout cas sur emul ca marche impec et sans "clap clap" régulier (hormis celui de la foule en foooooolie entre les morceaux ).
A noter en principe elle devrait marcher sur MO6, mais hélas le test du poke en &h1F40 provoque une erreur avec le basic 128 sur TO (le basic empèche le poke en dessous de &h3FFFF). Pour le basic il faudra trouver une autre astuce pour distinguer les machines.
[EDIT] ARGH la version en http est complètement fausse.. j'ai zippé trop vite avant la mise au point sur machine réelle. Voici une version qui marche sur mon TO8: http://dl.free.fr/q3Yqe4i3F
[EDIT2] Hum.. c'est curieux, j'ai l'impression que le player boucle sur la chanson #1.. elle ne dure pas 15' quand même ? Oui oui je confiorme: vers la fin de la chanson on voit l'image de fond se recharger et la zik boucler.. Cela ne se produit pas sous l'émulateur. C'est du à quoi une sortie prématurée du programme ? Une erreur de lecture, un fichier fragmenté ? (pour plus de sécurité, je l'ai défragmenté avec JkDefrag, mais à part une adresse de début changée, ca boucle pareil)
Code : Tout sélectionner
10 'MODELE POUR SDPLAY
20 CLEAR,&H9DFF
30 CLS:LOCATE0,0,0
40 SCREEN0,7,7
50 LOADM"SDPLAY"
60 POKE&H9F8C,&Hxx
61 POKE&H9F8D,&Hxx
62 POKE&H9F8E,&Hxx
63 POKE&H9F8F,&Hxx
90 CLS:PRINT" "
99 EXEC:GOTO90
Sinon, j'ai fait une nouvelle version "combo" http://dl.free.fr/q3Yqe4i3F (était http://dl.free.fr/pQXrvhEV9, voir l'édit) qui j'espère marchera avec les SDHC. En tout cas sur emul ca marche impec et sans "clap clap" régulier (hormis celui de la foule en foooooolie entre les morceaux ).
A noter en principe elle devrait marcher sur MO6, mais hélas le test du poke en &h1F40 provoque une erreur avec le basic 128 sur TO (le basic empèche le poke en dessous de &h3FFFF). Pour le basic il faudra trouver une autre astuce pour distinguer les machines.
[EDIT] ARGH la version en http est complètement fausse.. j'ai zippé trop vite avant la mise au point sur machine réelle. Voici une version qui marche sur mon TO8: http://dl.free.fr/q3Yqe4i3F
[EDIT2] Hum.. c'est curieux, j'ai l'impression que le player boucle sur la chanson #1.. elle ne dure pas 15' quand même ? Oui oui je confiorme: vers la fin de la chanson on voit l'image de fond se recharger et la zik boucler.. Cela ne se produit pas sous l'émulateur. C'est du à quoi une sortie prématurée du programme ? Une erreur de lecture, un fichier fragmenté ? (pour plus de sécurité, je l'ai défragmenté avec JkDefrag, mais à part une adresse de début changée, ca boucle pareil)
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos