[NanoReseau] Projet réalisable ?

[FabriceFABS]

Bonjour Édouard,
Merci pour ta réponse, très intéressante m'éclairant bien à présent sur le sujet tout comme la vidéo de Rodrik, vraiment sympa. Vous avez fait un boulot de dingue...
Je vais prendre attache avec toi pour savoir comment je pourrais aider à mon niveau.

[Fool-DupleX]

Avec plaisir. La première étape à mon sens, vu tout le beau matériel que tu possèdes, c'est de t'aider à rendre tout ça fonctionnel.

[Daniel]

J'ai bien noté le développement en cours d'un driver pour 386SX16, je suis intéressé et si c'est utile je peux le tester.

[gotcha]

Donc la question est toujours la même. S'il y a des gens vraiment motivés à participer soit au reverse, soit à la doc, soit à la réimplémentation, ils sont les bienvenus. N'hésitez pas à me MP.

Sympa ce travail. Je viens d'effectuer le même type de reverse engineering sur un loader pour MPF-1 (via une liaison série), avec aussi la recréation du code assembleur qui donne la même chose au bit près, puis une amélioration du code. Il y a aussi des boucles de temporisation en dur, mais bon, contrairement à un PC, le MPF-1 est une plateforme figée, donc ça ne pose pas de réel problèmes.

Dommage que le monde Thomson ne me motive pas trop en ce moment (j'y suis venu surtout car j'ai récupéré le matériel d'un de mes oncle), car techniquement, tout ceci est extrêmement intéressant

[Fool-DupleX]

@Daniel : c'est noté, Daniel. Je pourrais effectivement te solliciter, merci pour la proposition, c'est apprécié !

@gotcha : le Nanoréseau est une bête extrêmement curieuse en termes de protocole et de services. On n'en a retenu que le chargement des applications éducatives pour des élèves, mais il y a des fonctions fascinantes. Par exemple, dans la version 3.5 inachevée, on peut partager la RAM entre postes pour travailler sur un gros document. Le logiciel "Le journaliste" utilise cette fonctionnalité : on déclare un certain nombre de postes comme serveurs adjoints et leur RAM sert les postes utilisateurs. J'ai perso beaucoup de plaisir à réverser et documenter le NR. J'ai pas mal de choses en stock qui ne sont pas encore sur le site nanoreseau.net.

Edit: ca marche dans les deux sens au fait, si quelqu'un ici a un souhait en lien avec le Nanoréseau, qu'il parle haut et fort (plutôt qu'il ne se taise à jamais, ce qui serait dommage)

Edit 2: il y a un salon de discussion consacré au Nanoréseau sur Discord, sur la chaîne Rodrik Studio. A toutes fins utiles, je suis Fool-DupleX#5466.

[FabriceFABS]

Hello
Je reviens ici pour faire par de l'avancement de ce projet sur un ordi avec un AMD-Duron@1300MHz.
Bon qu'est-ce que je fais avec ce matos NR ? Qui est en panne ou pas, bref l'inconnue totale.

Bon bein pour passer le temps, j'ai qu'un bouchon et il m'en manque un alors par change il me reste une fiche DIN 5 broche male avec laquelle j'affecte les fameuses 3 résistances. Et hop un bouchon additionnel de fait.


Et puis peu après c'est @Fool_DupleX qui accepte de se lancer dans l'aventure avec moi...​
Avant de faire quoi que ce soit, il s'agit à présent de connaître l'état de cette carte. Fonctionne-t'elle ? J'en sais rien.

Le tout premier essai consiste à mettre l'extension NR dans un MO5 clavier méca pour maximiser le succès (les 1ères versions clavier gomme posaient problème si je ne dis pas de bétise) relié au boitier secteur NR avec le nouveau bouchon.
Tout à l'air OK.

On repasse sur le serveur :

Il y a plusieurs étapes au préalable à faire dans le BIOS eu égard aux IRQ 2 et 9 à désactiver absolument.

On arrive à ça :

C'est mieux. Une photo intermédiaire où l'ACPI s'est accaparé l'IRQ9. J'ai disablé l'ACPI, pas besoin sous DOS

Allez c'est parti, on lance l'utilitaire qui va tester la carte NR :

Ça nous a l'air plutôt bien parti la puce NEC est détectée, aurais-je de la chance ​

On continue les tests...


Les délais on opposition ont l'air bien corrects.

Poursuite des test on attends...


Puis on allume le MO5 :


Youpi ça communique de part et d'autre du réseau. J'ai envie de dire sur les couches basses du modèle OSI si je ne m'abuse.
La suite de l'histoire c'est pour bientôt !
Encore merci @Fool_DupleX (Édouard) pour ton temps, ta patience et tes explications ​​​
Vraiment content que tout ça soit positif.

La suite c'est bientôt...

[Daniel]

Bravo !
J'avais déjà sorti un 386SX16 pour tester le driver, je vais pouvoir le remplacer par un Duron, c'est encore mieux

[Fool-DupleX]

Il y a du neuf ... Mais je vais laisser Fabrice raconter ses aventures.

Il a omis de mentionner qu'on développe sous FreeDOS avec Turbo-Assembleur. J'ai choisi Turbo-Assembleur parce que je voulais quelque chose qui tourne sous MS-DOS 3.x, mais on pourrait prendre un assembleur plus récent. Et puis je suis ravi que ça fonctionne sous FreeDOS. Beaucoup plus de flexibilité que MS-DOS par rapport au hardware en général.

[FabriceFABS]

Oui ... !!!
Alors dans la suite de la saga NR, quelques échanges. Le serveur est juste connecté à un MO5 clavier méca.

À cette étape, découverte et utilisation du logiciel IRQSTAT.EXE pour voir si les IRQ sont correctes et pas utilisées pour d'autres périphériques, en l'occurence l'IRQ 2 / 9 doivent absolument être disponibles.


On sait pas trop lire ce truc, mais ça l'air ok.
Petite vidéo :

Maintenant, il faut voir si ça communique bien : Par des beeps sur le serveur à l'allumage / «DOS» du MO5.
Finalement, ce sera en débug par l'affichage de texte montrant là où ça plante.
Après plusieurs modifications de code, il y a eu plusieurs fois le logiciel NR freezé, des erreurs générales, et autres, rien de bien grave... :

general protection fault, j'ai dû trasher la pile sans faire exprès.
Combien de beep avant le crash ?

1 seul...

aaaaaaargh
chui une burne !

Mais non non non ​​​... Voilà on arrive au résultat à l'allumage du MO5 :


Saisie «DOS» :


Les explications d'Édouard :

dans ce protocole nr, toute communication commence par un appel initial
l'appel initial ne fait que 3 octets
Destination - mot de controle - source
La trame complete commence par un flag de debut et se termine par un crc-16 et un flag de fin
La "destination" est reçue, puisque le serveur réagit
Le premier octet (destination) est reçu, c'est que le paquet entier est arrivé et que le CRC-16 est juste. On doit encore avoir un souci de timing.

À suivre ! ​

[Fool-DupleX]

Aujourd'hui, nous avons beaucoup avancé. J'ai corrigé une partie de la routine d'interruption qui reçoit les trames et, divine surprise, un premier échange réseau est arrivé presque jusqu'au bout du processus (je n'en attendais pas autant). Ca pète au niveau du AMA (avis de mise en attente) qui est la dernière trame d'un train :

initnr.png (30.18 Kio) Consulté 3047 fois

Il y a fort à parier que ce souci réglé, le Nanoréseau commencera sérieusement à pétarader sur un Duron 1.3 GHz. Après, il ne restera plus qu'à régler l'avance à l'allumage

[Fool-DupleX]

Rapide update sans intérêt : nous progressons lentement, il y a pas mal de modifs à faire.

Le AMA ne venait pas, en tout cas, parce que la trame PCH était mal formée par le serveur. Ce problème est résolu, mais la trame AMA ne vient toujours pas, alors on cherche ... Je pense que la trame PCH arrive trop vite pour être détectée par le MO5, c'est ma meilleure option.

Au fur et à mesure qu'on progresse, je m'aperçois que c'est pire que des temporisations à coup de NOPs et de LOOPs : les développeurs ont aussi compté les cycles du code utile. Donc il faut parfois rajouter des tempos là où il n'y en avait pas.

Et une tempo sur un Duron avec des NOPs, ça ne fonctionne pas, à cause de l'exécution spéculative, désordonnée et du cache.

Si quelqu'un a une idée pour faire des tempos fiables entre 0 et 1000 microsecondes, je suis preneur. Éliminons déjà ce qui ne fonctionne pas : NOPs, LOOPs, INT 15 fct. 86, timers type INT 08 et 1C (résolutions respectives insuffisantes). J'ai pensé à utiliser l'instruction RDTSC, mais ça compte les cycles et sur un processeur moderne, la fréquence d'horloge est dynamique, donc ça ne marche pas non plus.

Pour le moment, je bricole en faisant des affichages de caractère par le BIOS, un caractère prenant environ 100 us à afficher sur l'Athlon à 1.3 GHz. Au moins ça permet d'avancer.

[Silou78]

Peut-être en utilisant un timer HPET, mais je ne sais pas si ça a déjà été fait ni même si c'est possible sous Dos.

[hlide]

J'ai pensé à utiliser l'instruction RDTSC, mais ça compte les cycles et sur un processeur moderne, la fréquence d'horloge est dynamique, donc ça ne marche pas non plus.

Euh pas tout à fait.

When Intel first introduced the TSC (in original Pentium CPUs) it was clearly documented to count cycles (and not time). However, back then CPUs mostly ran at a fixed frequency, so some people ignored the documented behaviour and used it to measure time instead (most notably, Linux kernel developers). Their code broke in later CPUs that don't run at a fixed frequency (due to power management, etc). Around that time other CPU manufacturers (AMD, Cyrix, Transmeta, etc) were confused and some implemented TSC to measure cycles and some implemented it so it measured time, and some made it configurable (via. an MSR).

[...]

All recent Intel and AMD CPUs have been like this for a while now - TSC counts time and doesn't measure cycles at all. This means if you want to measure cycles you had to use (model specific) performance monitoring counters. Unfortunately the performance monitoring counters are an even worse mess (due to their model specific nature and convoluted configuration).

Grand merdier en effet...

[gilles]

Pas possible en INT 08 ? pourtant on a une horloge de base à 1MHz environ (#define PITFREQ 1193181l dans mon antique code pour le LEP MO5) avec un vecteur utilisateur. On ne descendra pas à 1µ mais pour 20-30 ça doit passer en étant fiable sur tout PC du 8086 aux derniers compatibles MSDOS.

Le caractère BIOS çà risque de ne pas être fiable car, par moments, il va y avoir des clash avec la synchro écran (selon la carte d'affichage).

[Fool-DupleX]

A l'évidence, le caractère BIOS est un bricolage temporaire pour me permettre d'avancer. Je ne compte évidemment pas utiliser ça.

l'INT 08 est en principe remplacée ou simulée par le HPET sur les machines modernes. C'est tout un bouzin à mettre en place (détection via l'ACPI, configuration, paramètrage) mais c'est sans doute jouable. Ceci dit, je ne peux pas utiliser l'INT 08, il faut que j'aille directement poller le HPET, car les tempos j'en ai besoin dans la routine IRQ du NR durant laquelle les interruptions sont bien évidemment masquées.

Cette histoire de PIT m'a soudain rappelé que la carte NR possède son propre PIT cadencé à 447 KHz, soit une résolution d'environ 2 us. Je devrais pouvoir l'exploiter et c'est encore la solution qui me semble la plus fiable et reproductible du 386 au Pentium 4. Je vais essayer ça.

Merci de m'avoir soufflé ces quelques pistes.