Bonjour + dev sur raspberry pi

Bonjour,

Bien que je passe souvent lire ce forum depuis des années, je viens tout juste de m'inscrire pour de vrai.
J'ai tellement de respect pour le dev 8 bits que je n'osais pas; à coup sur, la peur de déranger mes dieux de l'Olympe
Mais dernièrement le hasard m'a fait rencontrer l'un d'entre vous.
Il est trop sympa et donc je craque : Pouf, me voila inscrit.

Bon j'arrêtes de raconter ma vie pour passer aux choses sérieuses.

Mon premier projet sur Oric sera de me faire un environnement de développement : émulateur / c et asm.
Comme je suis fâché définitivement avec microsoft, Apple, Android et les constructeurs complices, je vais tenter de faire cet environnement sur mon Raspberry Pi 1 avec l'OS Raspbian.

Je commence juste après avoir tapé ce message.
De temps en temps, je posterai sur ce thread pour indiquer comment j'ai fait les trucs qui marchent ou pour demander de l'aide sur les trucs qui ne marchent pas.
Cela sera peut être utile a tous les noobs comme moi, qui n'osent pas se lancer.

Bref, en résumé, votre talent et votre passion me donnent envie de vous suivre dans l'aventure Oric.

A bientôt

Bienvenue dans l'univers ORIC

Hâte de découvrir ton projet

A bientôt

Merci

Bon, j'ai compilé cc65 sans problèmes.
Pour Oricutron, J'ai réussi à le compiler après quelques apt-get et une modification du Makefile (-m32 n'est pas valide sur une architecture ARM)

Bien que je test sur un vieux raspberry pi model B, Oricutron semble tourner parfaitement (3D fungus tourne bien )

J'arrive à lancer les cassettes.
J'ai toutefois un problème pour lire les disks.

Il me mets le message :
sedoric v3.0
@1985 oric international
** WARNING ** DOS is altered !


Une idée ?

La prochaine fois, je m'attaquerai au Makefile en C et si j'ai le temps, je lui collerai un asm au link.

Bonjour 65c02
Bienvenue sur le forum.

** WARNING ** DOS is altered !

On obtient ce message, en général,  lorsqu'on essaie de booter sur une disquette "non master".
Pour gagner de la place pour les jeux, certains discs on été formatés en slave, le système SEDORIC n'est donc pas présent sur le disc et l'oric ne peut booter sur ces disquettes.

Bienvenue !

Bienvenue et bravo pour ton projet, tu n'as pas choisi la voie la plus facile pour te créer un univers !
Je suivrais avec attention ta progression comme cela je pourrais tester ta configuration sur mon pi (meme si j'ai plus de difficultés avec linux)

Merci pour votre accueil, c'est sympa.

J'ai tout installé et fait mon premier "hello the world".
Je vais pouvoir passer aux choses sérieuses.

Le choix du Raspberry Pi n'est pas innocent.
Je me dit que plus tard, je pourrais intégrer le rpi dans un clavier PC noir, avec des touches rouges

On pourrait aussi imaginer faire une image rpi qui lancerait oricutron au démarrage et offrirait un cc65 configuré et des exemples, des docs sur la machine, des démos, des jeux.
Bref, ce serait une sorte d'hommage à la machine.

En attendant, je vais me plonger dans cc65 que je découvre pour l'occasion et étudier le système vidéo de l'oric qui fait tout son charme.

Bienvenue,

Pour faire du C ou de l'ASM sur Oric tu ferais mieux de regarder du côté de l'OSDK qui est plus spécifique à l'Oric. CC65 ne permet pas de faire des disquettes ce qui est un peu limitatif.

OSDK ne compile pas directement sur Linux (et donc sur Raspbian). Perso je l'utilise avec CrossOver (une sorte de Wine) sur MacOS X.

Une autre solution serait de récupérer la bibliothèque ASM d'OSDK et de la porter sur CC65.

C'est vrai que j'ai pas mal hésiter à utiliser OSDK.
Mais mon raspberry est lent de base et lui ajouter un émulateur pour compiler me semble excessif.

Je ne doute pas que OSDK soit super, mais ayant définitivement décidé de ne plus utiliser windows qui évolue sans cesse et de plus en plus mal...
En plus j'ai récemment rencontré des problèmes de compatibilité avec wine sur certains exécutable windows; du coup je me dit qu'il est possible qu'un jour wine ne fonctionne plus correctement et que cela m’empêche de mettre à jour OSDK.
Autant ne plus dépendre de microsoft définitivement.

Je me suis aussi dit que le top serait, plus tard, de faire un package debian et de le mettre sur un repo pour que tout un chacun puisse télécharger le kit de dev oric d'un simple apt-get.

L'idée de porter les libs OSDK sur cc65 ou mieux, soyont fou, tout OSDK sur linux, me semble très intéressante.

Mais avant tout ces jolis projets qui me mettent des étoiles dans les yeux, je vais apprendre à me servir de cc65

Bonjour et bienvenue.

Hialmar a écrit:OSDK ne compile pas directement sur Linux

Je me souviens l'avoir compilé en début d'année pour faire un test pour uLua et je n'ai pas rencontré de difficulté particulière pour y parvenir. Mon seul problème avait été de comprendre comment ça marche et de faire un shell script pour remplacer le fichier .bat utilisé pour la compilation d'un projet.

Je nai pas fait de tests exhaustifs mais si il y a un scénario de test complet, je veux bien le lancer et remonter le résultat.
De mémoire, j'avais vu un .bat de tests mais uniquement pour l'outil pictconv il me semble.

Je suis intéressé par tes scripts. Il faut que je re-essaie mais j'avais eu quelques pbs sur OS X.

Pas de problème, il faut juste que j'en refasse un de propre...

Si j'ai le temps ce week-end je feraisi une mise à jour des sources et une recompilation complète de OSDK sur ma machine.
J'essaierais de faire un test complet en prenant un des projets OSDK présents sur le SVN afin de valider tout ça.

Il ne faut pas oublier que le pi tourne sur un ARM.
J'ai tenté la compilation d'euphoric mais il ne compile pas à cause de ses routines assembleur i386.

Bonjour,

J'ai récupéré les sources de OSDK présent dans la version 1377 du SVN datée du 11/07/2016.
Mon PC utilise un distribution Slackware 14.2 en 64 bits.
La version de gcc de ma distribution est la 5.3.0.

Un make à partir du répertoire public/pc/tools passe correctement mis à part un certain nombre de warnings.

Pour la compilation de pictconv, j'ai utilisé la version de la librairie freeimage fournie par ma distribution (version 3.15.0)

L'outil taptap n'est pas dans la même arborescence mais se trouve dans users/waskol/pc tools/taptap et est écrit en... Delphi.
Je l'ai compilé avec fpc version 3.0.0, il y a juste 2 lignes à modifier pour que ça passe sans problème.

Concernant xa, je ne sais pas en quoi la version fournie par OSDK diffère de la version normale. Celle de l'OSDK est une 2.2.3, celle que j'ai pour ma distribution est une 2.3.7 qui ajoute quelques correctifs et options (dont la génération d'une "crossreference list")
Quoiqu'il en soit, j'ai compilé la version fournie dans le SVN.

Concernant le script make.bat, j'en ai fait une version en shell qu'il faut que je teste encore un peu, mais pour le moment ça fonctionne.
Les seuls problèmes rencontrés avec le script d'origine sont l'utilisation de MAJUSCULES et de minuscules un peu n'importe comment, ce qui ne pose pas de problème sous Windows qui ne sait pas faire la différence


Voilà, suite au prochain épisode.

Merci.  

C'est sympa d'avoir pris le temps de tester tout ça.
De mon coté, comme j'avais fait ma chaine de compile cc65 et j'étais passé sur la prog.

Du coup, on peut imaginer une image raspberry pi spécifique OSDK avec émulateur, jeux, doc, livres en pdf.
Une sorte de petit musée Oric.

Ce week end, je compilerai osdk pour valider que ça marche sur un pi

Je continue mes tests mais j'ai un petit problème et je me demande si le make.bat fonctionne correctement ou si j'ai raté un truc...

Si j'ai bien compris, le fait de déclarer un valeur pour la variable OSDKPACKADDR permet de générer une version compactée d'un programme incluant le programme de décompactage.
Je fais un test avec un petit programme en C tout simple.
Si je compile normalement avec ma version en shell script, j'ai bien un fichier .tap correct.
Si je déclare une valeur pour OSDKPACKADDR, j'ai des erreurs au moment de l'assemblage après le compactage:

Code:


/tmp/Osdk/tmp/pak_linked.s(36):  5009:Label 'sp' not defined
/tmp/Osdk/tmp/pak_linked.s(37):  500d:Label 'tmp1' not defined
/tmp/Osdk/tmp/pak_linked.s(39):  5010:Label 'sp' not defined
/tmp/Osdk/tmp/pak_linked.s(40):  5014:Label 'tmp1' not defined
/tmp/Osdk/tmp/pak_linked.s(45):  5018:Label 'sp' not defined
/tmp/Osdk/tmp/pak_linked.s(46):  501c:Label 'tmp0' not defined
/tmp/Osdk/tmp/pak_linked.s(48):  501f:Label 'sp' not defined
/tmp/Osdk/tmp/pak_linked.s(49):  5023:Label 'tmp0' not defined
/tmp/Osdk/tmp/pak_linked.s(56):  5027:Label 'tmp0' not defined
/tmp/Osdk/tmp/pak_linked.s(68):  5036:Label 'tmp1' not defined
/tmp/Osdk/tmp/pak_linked.s(69):  5038:Label 'tmp0' not defined
/tmp/Osdk/tmp/pak_linked.s(70):  503c:Label 'tmp2' not defined
/tmp/Osdk/tmp/pak_linked.s(72):  5041:Label 'tmp1' not defined
/tmp/Osdk/tmp/pak_linked.s(73):  5043:Label 'tmp0' not defined
/tmp/Osdk/tmp/pak_linked.s(74):  5047:Label 'tmp2' not defined
/tmp/Osdk/tmp/pak_linked.s(79):  504c:Label 'tmp0' not defined
/tmp/Osdk/tmp/pak_linked.s(81):  5052:Label 'tmp0' not defined
/tmp/Osdk/tmp/pak_linked.s(82):  5056:Label 'tmp0' not defined
/tmp/Osdk/tmp/pak_linked.s(84):  505c:Label 'tmp0' not defined
/tmp/Osdk/tmp/pak_linked.s(93):  5064:Label 'reg0' not defined
Break after 20 errors


La partie de make.bat concernée est:

Code:


::
:: Executable compression test
::
IF "%OSDKPACKADDR%"=="" GOTO EndPack

IF "%OSDKBRIEF%"=="" ECHO Compressing
%OSDK%\bin\FilePack -p0 build\final.out  %OSDKT%\final.pak

IF "%OSDKBRIEF%"=="" ECHO   - Converting binary to text format
%OSDK%\bin\bin2txt -s1 -f2  %OSDKT%\final.pak  %OSDKT%\final_pak.s _PackedStart >NUL

IF "%OSDKBRIEF%"=="" ECHO   - Appending depacking code
COPY %OSDKT%\final_fp.s+%OSDKB%\unpack.s+%OSDKT%\final_pak.s %OSDKT%\pak_linked.s >NUL

IF "%OSDKBRIEF%"=="" ECHO   - Assembling
%OSDKB%\xa.exe  %OSDKT%\pak_linked.s -o build\final.out -e %OSDKT%\xaerr.txt -l %OSDKT%\symbols -bt %OSDKPACKADDR%
IF NOT EXIST "build\final.out" GOTO ErFailure

:: The new start address is the packed executable load address
set OSDKADDR=%OSDKPACKADDR%


Si j'ai bien compris, ça donne en langage clair:

1. Compactage du fichier final.out en final.pak + un fichier d'entête final_fp.s (sous Linux, le nom de ce fichier est incorrect, probablement un soucis avec la fonction _splitpath à corriger)
   
2. Conversion du final.pak en fichier texte final_pak.s
   
3. Concaténation de l'entête générée en 1 (final_fp.s) avec la routine de décompactage (unpack.s) et le fichier texte (final_pak.s) dans un fichier pak_linked.s
   
4. Assemblage de pak_linked.s avec xa, et c'est là que ça coince...
   

Je pense qu'il manque une étape d'édition de liens ou de déclaration des variables utilisées par la routine de décompactage.
Est-ce que quelqu'un a déjà utilisé cette possibilité de make.bat et pourrait me dire si ça fonctionne correctement?

[Edit]: Concernant le soucis évoqué dans le point 1 de la liste, je pense en fait que le nom est du fichier d'entête est correct mais que c'est make.bat qui est incorrect.
D'après les sources de filepack, ce fichier doit bien s'appeler final.pak_fp.s et non pas final_fp.s