Les petites joies du quotidien - Page 22

C'est exact, mais comme tu vois sa fille a tronqué la citation et surtout elle avait un seum bien carabiné de pas toucher de royalties sur les nouveaux albums je pense.

Par définition, un mort se fiche de ce qui arrive. Au final ça ne concerne que les ayants-droits. Et même si je suis loin d'être charmé par ce qui se fait avec Mickey et Winnie l'Ourson, je maintiens qu'un artiste doit savoir accepter que son œuvre ne lui appartient plus totalement, qu'elle fait partie de la culture populaire. C'est même une chance je trouve. Des gens comme Van Gogh et Lovecraft qui ont été particulièrement malheureux de leur vivant seraient sans doute comblés de voir la popularité et l'importance de leur travail aujourd'hui.

Après qu'on soit clair ; si Franquin avait exprimé clairement son opinion, j'aurais trouvé normal de la respecter. Mais à titre personnel, je n'aurais pas été d'accord avec lui, c'est tout.

Ça, c'est fait.

Sympa !
un Lego fait sur mesure ?

Non, juste une babiole sur laquelle je suis tombé par hasard, dans un bazar au Japon. Les briques sont toutes petites (chaque cube fait 5 mm de côté).

C'est pas les Nanoblock comme l'ara que je t'avais envoyé l'autre année?

Effectivement, ça ressemble à s'y méprendre, mais celui-là est une copie (ou une marque blanche) vendue par Daiso :
http://thesydneytarts.blogspot.com/2021/01/nanoblocks-vs-petit-blocks-block.html

Cela dit, je pense pas qu'ils vont se disputer si je les mets à côté de l'ara.

Mais c'est intéressant ça, surtout qu'en effet les nanoblocks coûtent cher (ici je les trouve chez Rougier & Plé et c'est en gros les mêmes prix que dans ton article).

AliExpress a plein de model nanoblock a pas super cher

je step up et ça marche, je suis trop content
(ne prend pas peur Zerosquare, ça fonctionne et ça ne fume pas )

This is spaghetti. #psxdev progress on the USB dev cart for the #Playstation1 #ps1dev still a lot of work to do .. pic.twitter.com/XLeNFjHb4J

— OrionSoft (@onorisoft) March 16, 2024

C'est un ROMulateur basé sur une Action Replay et un RPi Pico (ou quelque chose de similaire) ?

c'est une carte qui ce branche sur le "port action replay" et qui va permettre de communiquer avec la ps1 en USB via une puce FT245, quelques circuits logique 74xx, et une rom at29c512 pour le programme de boot ps1
le but est de remplacer les vieux action replay avec port parallel, et de rendre le dev ps1 plus accessible via l'USB.
je me suis basé sur un design existant trouvé sur le forum psxdev mais jamais terminé, et pour cause, la logique réalisé avec des circuits 74xx etait fausse ... du coup j'ai refait cette partie sur une breadboard et ça fonctionne \o/
(merci l'analyseur logique quand même)
y'a "plus qu'a" coder le protocole de communication et le logiciel coté PC
et refaire une carte propre avec la nouvelle logique

Oh c'est une bonne idée ça, surtout que ces cartouches sont pas très difficile à trouver si je me souviens bien
(d'ailleurs j'en ai une dans un tiroir, pour le jour où... )

C'est du 5 V ou du 3.3 V, le port DB25 qu'il y a dessus ? La PS1 est en 3.3 V, mais la carte ISA d'origine devait être en 5 V, est-ce qu'ils ont fait la conversion dans la carte ou dans la cartouche ?

Zerosquare (./643) :
Oh c'est une bonne idée ça, surtout que ces cartouches sont pas très difficile à trouver si je me souviens bien
(d'ailleurs j'en ai une dans un tiroir, pour le jour où... )

C'est du 5 V ou du 3.3 V, le port DB25 qu'il y a dessus ? La PS1 est en 3.3 V, mais la carte ISA d'origine devait être en 5 V, est-ce qu'ils ont fait la conversion dans la carte ou dans la cartouche ?

l'idée c'est d'avoir une nouvelle carte autonome, parceque les actions replay ne seront pas internel donc je ne voulais pas me greffer dessus (un projet comme ça existe déja d'ailleurs)
sur le port la ps1 y'a du 7.5v et du 3.5v, j'utilise un régulateur pour transformer le 7.5 en 5v, pour les circuits logique, le ft245 et surtout la rom

Ah ok

Mais le signaux du port parallèle de la PS1 sont en 3.3 (ou 3.5) V, non ? Tu utilises des 74x pour convertir entre les deux ?

Zerosquare (./645) :
Mais le signaux du port parallèle de la PS1 sont en 3.3 (ou 3.5) V, non ? Tu utilises des 74x pour convertir entre les deux ?

merci d'avoir posé la question, je viens de voir que c'est du 3.5v
mais ce qui est bizarre c'est que quand un regarde un action replay du commerce, la puce rom utilisé est une "5v only" sst29ee020
le Vcc de la puce est bien a 5v vu qu'ils utilise un régulateur pour convertir le 7.5v en 5v, mais quand je mesure le voltage sur le bus d'adresse et surtout de donnée, j'ai du 3.5v
pourtant il existe des puce identique qui accepte le 3.3v jusqu'a 3.6v, c'est curieux qu'ils ai pas utilisé celle la, ça aurait évité un régulateur de tension
ou alors le 3.5v de la ps1 n'est pas assez puissant pour alimenter le tout ? comment savoir ça ?

Je te conseille pas d'utiliser les accessoires non-officiels comme référence pour l'électronique, ils n'hésitent pas à faire des trucs crades pour diminuer au maximum les coûts de production. Peut-être qu'ils ont récupéré un stock de mémoires 5 V à pas cher.

Pour ce qui est du courant maxi que tu peux consommer sur le 3.5 V du port cartouche, à moins qu'il y ait un fusible dédié (ou de trouver une doc interne de Sony qui donne les spécs), c'est pas évident de savoir. Ceci dit je doute qu'une mémoire moderne + le FT245 et quelques circuits logiques consomment trop. Quitte à faire une cartouche 100% custom, à ta place je ferais un truc "propre" avec tout en 3.5 V.

3.5 et 3.3 ça se marie bien ? J'ai l'impression que c'était pas courant le 3.5 dans l'historique de l'informatique non ?

Zerosquare (./647) :
Pour ce qui est du courant maxi que tu peux consommer sur le 3.5 V du port cartouche, à moins qu'il y ait un fusible dédié (ou de trouver une doc interne de Sony qui donne les spécs), c'est pas évident de savoir. Ceci dit je doute qu'une mémoire moderne + le FT245 et quelques circuits logiques consomment trop. Quitte à faire une cartouche 100% custom, à ta place je ferais un truc "propre" avec tout en 3.5 V.

je vais voir si y'a moyen de fabriquer du 3.5v via le 7.5v, tout alimenter via ce 3.5v régulé, le seul soucis c'est la Flash ROM, j'en ai pas trouvé en DIP 3.5v, uniquement 5v
les seule en 3.6v sont en TSOP ou PLCC, donc je vais devoir acheter un adaptateur pour mon programmateur et un support PLCC sur la carte (par contre la puce est 2x moins cher que celle en DIP)

Brunni (./648) :
3.5 et 3.3 ça se marie bien ? J'ai l'impression que c'était pas courant le 3.5 dans l'historique de l'informatique non ?

oui c'est curieux, toute les puces logique de la ps1 sont en 3.5v et pas 3.3v, peut être qu'en 1993/1994 c'était pas encore le standard

Artemis (./649) :
le seul soucis c'est la Flash ROM, j'en ai pas trouvé en DIP 3.5v, uniquement 5v
les seule en 3.6v sont en TSOP ou PLCC, donc je vais devoir acheter un adaptateur pour mon programmateur et un support PLCC sur la carte (par contre la puce est 2x moins cher que celle en DIP)

Pas moyen d'utiliser la PS1 elle-même pour programmer la mémoire à travers le port d'extension ? En plus, ça permettrait de faire des mises à jour à posteriori depuis un CD, si besoin.

Artemis (./649) :

Brunni (./648) :
3.5 et 3.3 ça se marie bien ? J'ai l'impression que c'était pas courant le 3.5 dans l'historique de l'informatique non ?

oui c'est curieux, toute les puces logique de la ps1 sont en 3.5v et pas 3.3v, peut être qu'en 1993/1994 c'était pas encore le standard

Je me souviens pas avoir vu du 3.5 V ailleurs que sur la PS1. Je me demande aussi pourquoi ils ont fait ça. Peut-être qu'une de leurs puces custom était un peu limite à 3.3 V ?

Zerosquare (./650) :

Artemis (./649) :
le seul soucis c'est la Flash ROM, j'en ai pas trouvé en DIP 3.5v, uniquement 5v
les seule en 3.6v sont en TSOP ou PLCC, donc je vais devoir acheter un adaptateur pour mon programmateur et un support PLCC sur la carte (par contre la puce est 2x moins cher que celle en DIP)

Pas moyen d'utiliser la PS1 elle-même pour programmer la mémoire à travers le port d'extension ? En plus, ça permettrait de faire des mises à jour à posteriori depuis un CD, si besoin.

oui avec mon emulateur de CD c'est possible, mais pour débugger ma ROM c'est pas très pratique de créer un iso a chaque fois et lancer le truc etc...
mais en programmation pour les carte finale ça peut le faire, et du coup je pourrais même utiliser directement un tsop sans support

Artemis (./651) :
mais pour débugger ma ROM c'est pas très pratique de créer un iso a chaque fois et lancer le truc etc...

Un bout de code PS1 qui reçoit des commandes du PC (via le FT245, ou même le port série de la PS1 pour commencer avec un câble Net Yaroze) du style lire/écrire une adresse, et zou ! Tu peux programmer ta mémoire Flash mémoire via le PC, débuguer, etc. sans griller un CD ou refaire une ISO à chaque test

\o/ j’ai enfin trouvé un bug qui m’agaçait depuis des mois \o/
En soi, ce n’était pas grave vu qu’il était dans les tests uniquement, mais n’arrivait que de temps en temps et uniquement quand les tests étaient lancés sur GitHub (sachant que ça dure une demi-heure).

En gros, je faisais :

current_time = now()
write_file()
list_files(after=current_time)

Et manifestement, sur GitHub, l’horloge du système de fichiers est moins précise et le fichier considéré comme créé après current_time…

Ah ouais et comment tu l'as trouvé ?

Ça m'a pris pas mal de temps, surtout que je me suis traîné un autre problème dans les tests unitaires : certains tests tuaient la connexion à la base de données en échouant, flinguant tous les autres dans la foulée avec une belle stacktrace à chaque fois.

Au final, j'étais vraiment dans la situation idéale :
- un bug impossible à reproduire en local,
- impossible d'utiliser un débugguer ou de rajouter trop d'infos,
- un bug qui arrivait de temps en temps (1 fois sur 4, environ),
- l'indication du test qui plantait planquée dans des dizaines de milliers de lignes de stacktrace inutiles,
- les tests prennent plus d'une demi-heure.

Au final, après avoir corrigé le problème qui tuait la base de données, j'ai pu avoir une stracktrace de taille correcte et comprendre quel test plantait. Ensuite, j'ai fait deux versions de ma fonction list_files (une qui prenait en compte l'heure de création et l'autre qui l'ignorait).

flanker (./653) :
Et manifestement, sur GitHub, l’horloge du système de fichiers est moins précise et le fichier considéré comme créé après current_time…

C'est possible, mais même sans ça, ton code avait une race condition quand même : write_file() n'a pas un temps d'exécution nul, et est très probablement exécuté de façon asynchrone à cause du buffering et des caches.

(après, je vais pas prétendre ne m'être jamais fait avoir par ce genre de trucs non plus )

Ah non, je me suis planté : il est considéré comme étant antérieur au moment où je note le temps, d’où le bug.

Plus original, déjà ^^

Ouais je vois.
C'est possible que sur la machine de tests ils aient en fait un autre serveur pour le stockage, où tes tests tournent. Du coup il reporte l'heure du serveur de fichiers et la machine qui exécute ton code est réglée avec un certain délai.

flanker (./653) :
\o/ j’ai enfin trouvé un bug qui m’agaçait depuis des mois \o/
En soi, ce n’était pas grave vu qu’il était dans les tests uniquement, mais n’arrivait que de temps en temps et uniquement quand les tests étaient lancés sur GitHub (sachant que ça dure une demi-heure).

En gros, je faisais :

current_time = now()
write_file()
list_files(after=current_time)

Et manifestement, sur GitHub, l’horloge du système de fichiers est moins précise et le fichier considéré comme créé après current_time…

J'avais eu un problème similaire avec un système de fichier réseau dont les timestamp n'était pas précis à la seconde et qui faisait foirer une synchro. J'ai mis quelques temps avant de la trouver celle-ci !