Logicielsmoto.com

Nous sommes le 28 Mar 2024, 17:24

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 25 messages ]  Aller à la page Précédente  1, 2
Auteur Message
MessagePosté: 02 Déc 2018, 12:38 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Pour charger sous DCMoto c'est (je crois) pas un fichier BIN qu'il faut, mais plutôt un fichier RAW (brut) qui s'obtient avec l'option "-bd" (binaire données) de C6809 de sorte a avoir le pure code 6809 dans le fichier sans les en-têtes et autres extras du format BIN.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 02 Déc 2018, 15:21 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
salut,

ok je note merci pour l'infos.

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 03 Déc 2018, 09:06 
Hors ligne

Inscription: 27 Juin 2006, 19:44
Messages: 1061
Localisation: France (24)
Tout ça ne me surprend qu'à peine. Il fallu que j'ajoute -Wno-int-in-bool-context pour que la compilation d'un autre programme se passe sans encombre. GCC devient de plus en plus pointilleux.

_________________
Marche a suivre pour s'inscrire sur ce forum
Do not forget to contact one of the administrators to validate your registration.
Le site des démos de Puls
L'émulateur Teo


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 03 Déc 2018, 20:05 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
Et, surtout que j'essaye d'utiliser ça sur mac !
Pour tous les autres outils pc genre

dcfdutil >> encapsuler avec WineBottle en .app pour mac
TPC, SAP2 etc... avec DOSbox

ça marche top nickel !

En passant, merci à ceux qui se sont fait bien chi.. à créer ces outils de conversion grace à qui on peut continuer à dev pour Thomson.

:good:

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 02 Fév 2020, 02:30 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
Fichier binaire Thomson :

Un fichier binaire Thomson commence obligatoirement par les 11 premiers octets pour "typer" le fichier ??
(j'ai vu ça ici : http://dcmoto.free.fr/forum/messages/591147_0.html)
ou
il peut contenir directement les valeurs à mettre en mémoire à partir de $A000 par exemple !

En gros, l'idée c'est de charger une suite de valeurs hexa. en mémoire d'une BANK avec une série de LOADM mais sans rien executer ! (graphismes et sons)
puis de faire un EXEC&H7300. Donc j'aurais par exemple :

LOADM"PROG.BIN" (lui c'est le program qui commence en $7300 donc en non commutable)
BANK4:LOADM"GRAPHIC.BIN" (là je mets les graphismes à partir de $A000 de la BANK4)
BANK5:LOADM"SONS.BIN" (là je mets les sons à partir de $A000 de la BANK 5)

puis pour orchestrer tous ça j'execute PROG.BIN avec un EXEC&H7300.

c'est un raisonnement correcte ?

merci.

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 02 Fév 2020, 13:58 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
Le meilleur moyen de savoir, c'est d'essayer :D
je test ça ...

par exemple, un fichier image sauvé avec GrafX2 en .bin pour "moto" commence comme ça :

00 00 01 e7 c3 65 00 1f 80 40 00 11 11 11 11 11
11 11 11 11 11 11 14 44 44 44 44 44 44 44 .. ..

Le premier pixel c'est le 1er "11" (12eme octet !)

C'est obligé d'avoir les 11 premiers octets ? j'peux pas commencer direct avec le 1er pixel (genre datas bruts)?
Ensuite je gère les datas avec mon programme implanté en non commutable pour aller chercher à ma guise les datas !

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 02 Fév 2020, 19:20 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Si tu fais un "BIN" non il y a un en-tête et une fin à respecter. L'en-tête indique où charger ainsi que la longueur des données. Il ne fait pas 11 octets mais bien moins. En fait ton fichier exemple se décompose en 2 blocs disjoints chargés en mémoire et se lit ainsi:
Code:
00         début de bloc
00 01      longueur du bloc: 1 octet
e7 c3      adresse du bloc: $E7C3 (contrôle RAMA/RAMB entre autres)
65         donnée... ce bloc charge donc $65 en $E7C3

00         début de bloc
1f 80      longueur de bloc: $1f80 .. tiens 8000 octets... Ca doit être un écran
40 00      adresse du bloc: $4000 ... et oui on charge ce qui suit à partir de $4000
11 11 11 11 11 11 11 11 11 11 11 14 44 44 44 44 44 44 44 .. ..

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 02 Fév 2020, 20:20 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
ha super merci,

- On peut donc faire dans 1 seul BIN avec plusieurs operations à la suite si on code correctement "plusieurs déclarations de BIN"
- Genre 2 codes BIN dans 1 fichier BIN.

_________________
Image


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 02 Fév 2020, 20:41 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Oui c'est ce qu'il se passe quand tu ne demande pas une compilation "linéaire" avec c6809. Typiquement à chaque ORG il va générer un nouveau morceau qui sera chargé ailleurs. Du coup si tu mets un ORG $E7E6 (enfin l'adresse à poker pour changer de bank) ne contenant qu'un seul octet correspondant à la banque mémoire suivit par un ORG $A000 etc, tu peux t'arranger pour que le BIN mettes les différents bouts dans différentes banques à partir d'un seul LOADM. C'est plus simple du coté du programme basic, mais ca parait long à l'écran car il n'y a pas de trucs qui bougent à l'écran pendant le chargement. Aussi souvent on se contente du BANK+LOADM+déplacement d'une barre de chargement en basic par exemple.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 02 Fév 2020, 21:21 
Hors ligne

Inscription: 06 Avr 2010, 01:59
Messages: 478
ok je vois,

Dans mon cas c'est pour stocker dans un .BIN les datas de mon image de fond que voici.
Image

Ensuite j'aurais une petite routine dans mon code assembleur qui ira afficher les datas de mon écran stocké en BANK4 à partir de $A000, vers la memoire écran (avec mon swap donc en $0000 puis sur l'autre écran aussi pour pas que ça clignote à chaque swap screen !)

Puis quant je jeux commence le jeux, mes routines stock qqpart en memoire les zones des sprites, pour redessiner juste les endroits des sprites sur ce decor de fond.
L'affichage devrais êtres plus rapide si je ne redessine pas tous !!

ça devrait marcher !

Bon aller c'est partie pour quelques jours pour mettre en place cela :oui: ...

PS : merci aussi à celui qui à ajouté l'export moto dans GrapX2 , c'est bien pratique... :bien:

_________________
Image


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 25 messages ]  Aller à la page Précédente  1, 2

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 36 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com