DEV Quel environnement ? - Page 2

Ca vaudrait le coup de creuser ça

J'ai passé ma fin de soirée (jusqu'à 1h) à essayer de lancer via DOSBOx : l'accès aux fichiers se fait bien, c'est assez convivial comme système mais j'obtiens pour les exe "This program cannot be run in DOS mode"... Hum... peut-être un paramètre à bidouiller dans la config de l'émulateur.

J'essaye GCC sur mon Falcon ce week-end, avec tentative de compil de cc65 et ra65. Le reste des programmes existe en version ST, il me semble...

"On va y arriver, ya pas de raison" "le kung-fu dit : ma tête est plus solide que la brique, ça devrait le faire"

pour handy, il me semble qu'il a été recompilé il y a peu sous windev ou équivalent...

Bon, état des lieux :

- j'ai installé un cross-compiler GCC qui produit du code 68000 sous MacOSX (merci à Monsieur Donzé).

- j'ai trouvé un environnement en source (page de 42Bastian -> cc65src.zip). Malheureusement, je crois qu'il est un peu vieux (17/10/1999). Qu'y a-t-il eu comme update depuis ? (Note ultérieure : oups, j'avais pas vu le newcc65src.zip dessous, fo dire que j'avais downloadé le premier à partir d'une autre page)

Donc :

- me suis amusé à recompiler le cc65 pour donner un exécutable 68000, sous Xcode et m68k-atari-mint-gcc. Ensuite, sur Atari (NoSTalgia en fait), ce cc65.ttp m'a transformé un mydemo.c tout simple en mydemo.m65 (avec des bugs d'affichage TOS, mais ça pourra être corrigé).

- me moins amusé en passant par le bash et les "make install" et modification des "makefile" avec production de exe PPC ou de ttp 68K. J'ai la batterie de cc65 ra65 link65 libr65... mais pas le sprpck (ça, je pourrai le faire maison en bon GFA). Le problème est la compilation des lib (c.olb, lynx.olb, le runtime étant correctement produit), je suppose que c'est un problème de chemin, mais set CC65INCLUDE et CC65LIB, ça marche pas trop. Question : puis-je piquer les c.olb et lynx.olb ainsi que les includes des versions plus récentes ?

Voilou , vais me coucher, je crois avoir bien mérité mon week-end

le source de sprpck doit être dans ton répertoire BLL/sprpck
Pour ta dernière question, ça ne devrait pas poser de mrpoblèmes à mon sens, vu c'est du code 6502.

Pour le sprpck dans le répertoire BLL, ce n'est pas exactement ce que vous avez en version PC : c'est ici un convertisseur SPS (fichier texte) vers SPR (packé ou non). ça devrait être possible de bricoler un interne à l'IDE, similaire à un éditeur d'icones (comme dans Interface).

oki pour le code .olb... merci. je devrais avoir qq chose qui marche ce week-end, je le sens bien

Tu es sur ? j'ai juste vérifié le n° de version : c'est la 1.98 (donc la dernière)
Je vérifierais ça.

Dans le répertoire BLL Atari, oui, c'est bien du SPS

Ayéééééééé

J'ai réussi à avoir des TTP qui produisent du code et un fichier .o final. Merci à FagEmul pour le verdict final. Je devrait retoucher les sources pour régler quelques blèmes (pas de retour ligne pour les printf, et les jokers ne sont pas pris en compte dans le libr65 (il considère *.obj comme un fichier).
Pour l'instant, lancé via le cmd.tos de MagiC, je devrais faire des *.BAT. Un IDE sur Atari, c'est donc possibleu.

C'est super

Rassures toi, le *.obj est considéré comme un fichier sous DOS aussi dans mon libr65.
Pour ma part, je fais toujours une librairie avec tous mes objets sprites, c'est plus simple (j'ai un script makelibr.bat ou j'ajoutes chaque nouveau sprite que tempi m'envoies).

J'ai vérifié, j'ai bien le source d'un sprpck qui gère les images
Maintenant, savoir ou j'ai récupéré ça... mais si ça t'intéresse, je peux te l'envoyer

PS : j'ai pas demandé par optimisme, ton .o est bien correct ?

"Merci à FagEmul pour le verdict final". C'est lui qui l'a testé, vu que mon Handy/MacOSX plante avec les .o
Et c'était bien ma version du .o, paske j'ai merdé avec le libr65 (problème avec le *.obj, donc j'ai fait à la main un par un) : yavait pas tous les sprites.

Si tu peux mailer ou déposer le zip avec un lien sur ce forum, merci d'avance

et voila :
http://fadest.free.fr/DevLynx/sprpck.zip

Tu sais que tu peux faire un lnx avec ton .o ?

merci

Fadest
: Tu sais que tu peux faire un lnx avec ton .o ?

oui oui, mais là, je suis naze de chez naze : fatigue mentale. si je m'arrête pas, c'est crise de nerf/nerd assurée. Je continuerai ça dimanche, avec si c'est convenable, la release publique des ttp et tout ce qui va avec.

Et bien les développeurs Lynx vous pouvez vous féliciter, vous avez gagné une belle recrue

\o/

La Lynx reprend du poil de la bête depuis qqs semaines

Ouais... enfin si là on demande la spécifité des cartouches homemade présentées à la JC y'aura pas foule à savoir qu'il s'agit de la couleur...

Etat des lieux :

- j'arrive à avoir un script batch sous MagiC (via la ligne de commande MCMD.TOS), me compilant et linkant tout à la volée
- j'ai un bon make_lnx.ttp qui me produit un fichier correct (tests avec le rapid_racer.lyx -> lnx de FafEmul) avec bidouillage dans le source car il me swappait quelques infos dans l'entête, du coup Handy ne voulait rien savoir.

- problème : le lynxer.ttp (newlynx.ttp, lynxer2.ttp ou lynxer4.ttp), seul programme d'origine atari (sic) semble ne pas marcher, je n'ai que ce qui correspond à l'insert.o, puis vient des rasters (verts ou violet+bleus, très joli, mais c'est pas ce qui est prévu )... c'est la dernière étape qui coince, en plus du problème du sprite unique dans le sprdemo1.o.
quelqu'un aurait le lynxer.c dont Karri parle dans un de ses posts sur le forum cc65 ?

-

Rajah : non, je n'ai pas trouvé de lynxer.c dans mes répertoires pour l'instant.
Lynxer2.ttp ne marche pas ?
Tu as essayé d'aligner tous les fichiers (ou de ne pas les aligner) :
insert.o
#ALIGN
toto.o

je ne pense pas que ça change grand chose, mais bon

#ALIGN entre insert.o et le programme.o ? pas vu ça comme ça, mais je vais essayer...

En fait, ça permet de dire que le fichier suivant commence au début d'un bloc et non à la suite du précédent
C'est surtout pratique quand tu mets des fichiers pour les recharger (vu qu'il faut charger par bloc)
Je ferais des essais à l'occasion avec steem + lynxer2.ttp

ben ça marche pas... (avec newlynx). même effet.

je demanderai à Karri le source de lynxer.c, vu qu'il doit l'avoir, car le lynxer2.ttp est pas convivial : il demande envoi vers cartouche ou disque...

bon, c'est sur http://rajah.atari.org/files/http://rajah.atari.org/files/ -> lynxdev_st.zip 450 Ko

Fourni en l'état (lire ci-dessus, car ça ne marche pas encore tout à fait, bien qu'on ait les fichiers finaux).

Le script compile.bat dans sprdemo1 marche avec mcmd.tos sous MagiC, il faut le réécrire pour Mint si vous vous faire sous Mint. Prière de tester ça sur une partition où vous n'avez pas de données précieuses (on sait jamais, je devrais être aussi prudent étant donné qu'il y a tout DGEM.DEV à côté).

Il est super-cool et rapide, le Karri : j'ai obtenu le source de lynxer.c
Et des renseignements pour sa flashcard... vais me l'offrir si le mandat postal est possible.
Tests ce soir ou demain (c'est plutôt muscu ce soir)

Il est actuellement question de dev sous mac sur la mailing liste internationnale

Et ils disent quoi ?

J'ai pas lu en détail mais il disent que en gros personne n'a vraiment creusé mais que ça devrait quand même marcher...

Bah coopy va lire en détail et nous faire un résumé.
Mais en gros, il n'y a pas de raisons que ça ne passe pas sous OS/X vu que ça passe sous Debian

@vince : on s'inscrit où, pour cette mailaingue liste internachionnale ?

Sinon pour la version MacOSX, c'est à la porté du premier kuk venu. Simple comme bonjour : un "make install" comme sur Nunux.
Ce qui rebute par contre, c'est qu'un clavier Mac n'est pas trop fait pour coder... il faut toujours ruser pour les touches | [ ] { }. Alors avec un clavier iBook qui n'a pas de pavé numérique... (yen a en USB, mais bon...)