[riscosfr] Re: A la recherche d'information pour un projet.y
- From: Etienne SOBOLE <e.sobole@xxxxxxxxxxxxx>
- To: riscosfr@xxxxxxxxxxxxx
- Date: Sun, 7 Jan 2018 21:56:32 +0100
Salut Rick.Merci pour tes Informations, et surtout leur précision :)Je vais
tenter de réaliser mon Projet Avec le RiscOS.Par contre je vais quand même pas
mettre tout mes oeufs dans le même panier. Donc exit le Basic, vive le
C/C++.Sait on jamais si je dois changer d'OS en cours de chemin.Pour les Bench,
j'attends que ma rPi3 et la SDCard "RISC OS ePic" arrive, et je les ferai moi
même :)Mais si on peut transférer au moins 2 foix 1920*1080 pixel 32 bits en
60Hz alors ça devrait aller !Ça fait tout de même une bonne bande
passante...Pour le PiLCD, j'ai trouvé pas mal de trucs, ça devrait le faire.Il
ne restera que le problème du Wifi (le dongle faut voir),un peu
d’électronique et hop :)Bon j'ai hâte que tout ça arrive maintenant.A très
bientôt.Etienne SOBOLE06.51.51.05.54
Salut,
L'inverse me semble difficile, quoique. Si tu génères uniquement de
l'ASM depuis ton compilateur C, il doit y avoir moyen de l'insérer
dans un buffer sous le Basic, puis de faire un call dessus.
Je pense que c'est possible, mais il faudrait expérimenter cela.
C'est quasi-possible. Si ton code C est uniquement un fonction autonome (qui
n'appelle aucun autre fonction), on peut pass cet code au linker pour crée un
fichier "bin" (binaire, sans preamble comme AIF). Charger cet fiche dans un peu
de memoire, et utilise CALL et USR comme d'hab.
Sans sous-fonctions et sans CLib, il n'y a pas de besoin de verifie le stack, ni
mettre en place les registres pour workspace, statics, etc etc.
Il y un chose - peut etre SpriteExtend? - qui utilise un petit fonction écrit
en C parce que c'est plus clair qu'assemblage.
Sur le long terme, le Wifi devrait toutefois être supporté.
Un jour...
Curieusement les dongles 3G (voire 4G ?) sont gérés par RISC OS.
C'est un question de comment parler avec le chose. Par example, le premiere
Vonets utilise un protocol bizarre qui marche presque uniquement avec XP. Le
plus recente Vonet (et plus capable) marche avec un capable navigateur.
Peut-etre Otter? Je n'essaie pas. NetSurf sont insuffaisante.
https://www.heyrick.co.uk/blog/index.php?diary=20161208
Il y une couche d'abstraction matérielle dans RISC OS 5 qui permet de
programmer bas niveau sans se soucier de la plate-forme matérielle
utilisée.
Sauf pour les petits choses comme quel VFP et ordre de couleurs RGB or BGR, le
plupart de RISC OS est pareil n'importe quoi machine on utilise.
Questions relatives au couple RiscOS / RaspBerry PI1 - Peut on
afficher sur les 2 écrans (le PiFTF et la sortie HDMI) des contenus
différents ?
Je dirais que non,
Oui/non. Le Pi n'est pas capable de 2 écrans differentes; mais si vous avez le
code source de le pilote PiTFT, peut etre il visualiser un chose completement
different de l'ecran principale?
Par exemple, mon pilote OLED utilise un sprite 128x64 pour le données que je
souhaite, et le papier electronique sur le machine GPS (j'oublie qui crée ca),
c'est pas le meme qu'un écran.
Mais - attention - comme ca tu peut mettre ton dessin sur un sprite (VDU, Plot,
des fonts) mais jamais le Desktop, fenetres, etc).
Côté modules LCD/OLED type SPI (de mémoire), Rick a proposé du code
permettant de les piloter depuis RISC OS.
La mienne c'est que pour les petits (autour d'1 pouce) OLEDs de taille 128x64 et
branchée sur le port IIC.
C'est un autre qu'écrit PiSPI, pas moi! :-)
2 - Si je branche un écran FullHD sur le HDMI mais que la bande
passante ne suit pas, peut-on passer dans une résolution inférieure ?
Genre 960 / 540 ou autre d'ailleurs ?
Le Pi n'est pas un processeur TI! Il est vraiment bonne avec les capabilities
vidéo. Mes Pis (vers adapteur VGA) n'a aucun probleme avec un écran 1280x1024
(c'est plus que je peut dire pour le Beagle xM).
Le Pi Zero, avec meme adapteur VGA, donne un claire image HD sur un écran
1440x900 avec OSMC.
Et, comme David dite:
On fait ce que l'on veut ici. Mais cela devrait suivre. 2560x1440@60
Hz avec mon Pi 3 :)
C'est QHD! Eh, meme que mon téléphone... c'est un peu fou, un resolution comme
ca dans un écran de 5 pouces!
3 - Le RiscOS impose t-il une limite sur la taille de la carte SD ?
256 Go. Mais j'aurai tendance à dire qu'il vaut mieux se limiter à 128
Go.
Je préfére de limiter vers 8Go ou 16Go. Pourquoi? Le systeme des fiches sur
RISC OS est un peu fragile, et sans DiscKnight il n'y aucun moyens de recouvrir
dans un probleme. Ecoute bien - AUCUN MOYENS sans achete DiscKnight.
Avec un taille SD plus petit, c'est pas trop compliqué de mettre le carte sur
mon PC et fait imager completement sur un disque dur USB. Je fait ca
periodiquement.
Plus - les softs RISC OS sont pas gros. Je ne trouve pas que ~8Go d'etre un
grande restriction...
J'utilise des cartes Samsung Evo+ et Pro.
Je ne sais pas pour le marque, sauf pour dire que le difference entre un carte
lente et un carte vite est incroyable. Souviens quand vous acheter ton premiere
disque dur et ne utilise plus des floppies? C'est un peu comme ca. :-)
A se demander pourquoi certains veulent encore passer par un disque
USB 2.0 externe, car c'est kif kif côté vitesse et cela n'encombre pas
la bande passante des ports USB.
Le gros probleme avec le Pi (et plusiers autres cartes ARM) est que on peut voir
un joli quatre ports USB sur le cote de la carte. Mais, entre/sortie le chip est
UN SEUL port USB. Il passe vers un hub avec 2 voies (Pi1) ou 4 voies (Pi2, Pi3,
Beagle...) et AUSSI le ruisseau Ethernet. Pour copier un movie sur disque depuis
un NAS, il marche plus lente qu'un PC parce que le USB est utilisé pour
l'ethernet et puis pour le disque. Ensemble.
En réalité, c'est pas un gros probleme avec RISC OS. On ne pas d'habitudes de
transferrer les gros volumes des données.
5 - Et d'un manière générale est ce que qu'il existe des bench donnant
une idée de la performance (graphique principalement) du couple ?
Pas terrible. Nous n'a pas d'acceleration vidéo. Je fait un teste en 2012:
The Tōkyō Sky Tree video (AVC1, 400×300) plays reasonably smoothly on the
Beagle but is quite jerky on the Pi (as can be seen in the top video). This is
because the RISC OS version of MPlayer is using software decode with no
assistance from hardware. The snippet of Kara no Kyōkai that I tested (XviD,
720×480) was very jerky on the xM so I didn't bother trying it on the Pi.
Avec OSMC, HD aucun souci. FullHD aussi, mais mon écran n'est pas capable. :-)
Amicalement,
Rick.
Other related posts:
