Autore Topic: La storia del Baycom - Parte 4 di 4  (Letto 1776 volte)

0 Utenti e 1 Visitatore stanno visualizzando questo topic.

Offline Gianluca

  • Sr. Member
  • ****
  • Post: 279
  • Karma: 3
La storia del Baycom - Parte 4 di 4
« il: Gio 18 Ago, 23:18 2011 »

BayCom (quarta parte)

Da "Micro & Personal Computer" - Rubrica "PC & Radio"- Giugno/luglio 1997

Il programma BayCom ha dato origine ad una serie di utilità con esso "compatibili", che ci danno
la libertà di impiegare indifferentemente un modem o un TNC con gli stessi programmi.

di Mario Chisari IW0CDT

Il Baycom ha avuto il merito di portare al successo il modem omonimo; trattandosi di un'alternativa
economica ma efficiente ad un ben più costoso e più raffinato apparato di controllo del nodo, il
TNC, è facile capire perché molti abbiano provato ad usare lo stesso hardware con altri programmi
di terminale.

Dapprima sono nati programmi con la stessa struttura del BayCom (un gestore del dispositivo
seriale ed un programma di terminale); più avanti è nata l'idea di emulare direttamente l'intero TNC
da software. Questo stratagemma consente di utilizzare il modem BayCom con qualsiasi
programma di terminale desiderato, poiché esso non noterà alcuna differenza con un TNC vero.

VERSO LA VIRTUALIZZAZIONE

Ecco quindi che diventa possibile comporre la propria stazione Packet combinando in vario modo
l'hardware ed il software; tutto grazie alla scelta tra vari "mattoni" che, composti uno sopra l'altro,
ottengono il risultato della massima flessibilità ed indipendenza dall'hardware. Possiamo così
risparmiare usando il BayCom, per poi spendere un po' di più con un TNC che garantisce la nostra
presenza "in aria" anche a TNC spento.

Ci possono essere diversi motivi per utilizzare un altro terminale che non sia il BayCom: perché
intendete utilizzare la raccolta automatica delle intestazioni dei messaggi ("broadcast") offerta dalla
BBS Packet a cui vi collegate; o perché trovate troppo macchinoso il modo in cui BayCom gestisce
il trasferimento dei file in protocollo YAPP (normalmente usati in Italia); o, semplicemente, siete
già affezionati ad un certo programma di terminale Packet, tanto da non volerlo cambiare con quello
BayCom.

Se siete in una di queste situazioni, potete utilizzare uno dei diversi gestori del modem BayCom.
Essi sono in grado di interporsi tra il programma di terminale e l'hardware, virtualizzandolo, ossia
svincolandolo dalla sua effettiva natura. In questo modo, il programma di terminale potrà
comandare indifferentemente un TNC, un modem BayCom, o una scheda multiseriale come quelle
presentate nella scorsa puntata.

L'unica difficoltà sta nel fatto che il gestore non è ovviamente in grado di emulare direttamente
l'hardware della seriale; molti terminali viceversa pretendono di gestire direttamente l'hardware per
la necessità di aggirare le pesantissime limitazioni del sistema operativo (si tratta di un retaggio del
primo PC IBM mai completamente superato...).

È quindi giocoforza l'utilizzo di terminali che nascano predisposti all'utilizzo di un gestore esterno.
Per nostra fortuna, la maggior parte è ormai così, grazie proprio alla diffusione prorompente del
BayCom: è sufficiente configurarli per scambiare dati usando, anziché l'hardware, un'interruzione
(interrupt) software.

I GESTORI BAYCOM, OVVERO I "TNC VIRTUALI"

Quali gestori è possibile allora utilizzare? La prima scelta cadrebbe sull'L2 del BayCom stesso; esso
però non ha avuto alcun successo come gestore di dispositivo, per mancanza di documentazione o
per le restrizioni di distribuzione a cui è sottoposto.

In genere, come potete vedere in tabella, è molto diffuso il TFPCX (l'acronimo sta per l'altrettanto
criptico "The Firmware PC Extended"); esso, molto simile all'L2, è in pratica un'estensione del
BIOS del PC che fa da gestore per l'interfaccia "modem BayCom".

Lanciando il TFPCX con gli oppurtuni parametri (porta COM da utilizzare, velocità, ecc.), esso si
installa in memoria agganciandosi ad un vettore d'interruzione software. Ora tramite esso tutti i
programmi DOS possono inviare e ricevere dati in formato Packet sull'interfaccia BayCom. Il
TFPCX si occupa di aprire, mantenere e chiudere i canali virtuali, e di gestire ricezione e
trasmissione, nonché la correzione automatica.

Altro programma che svolge la funzione di gestore è il BPQAX25. Esso funziona allo stesso modo
del TFPCX, con la differenza di essere compatibile con BPQ, un gestore che supporta anche le
funzionalità di nodo multiporta (è usato su molti BBS per gestire le varie porte - o frequenze - su
cui gli utenti possono collegarsi, e per rilanciare i pacchetti da una porta all'altra).

Infine l'AX25DRV è un "Packet Driver" ovvero un gestore che fa vedere la seriale a tutti gli effetti
come una scheda di rete. Su esso potete installare - ad esempio - il TCP/IP od un qualsiasi
protocollo di rete che supporti il "packet driver", e realizzare una rete ethernet via radio!

Per quest'ultima utilizzazione è molto diffuso un "terminale" (in realtà è più un sistema operativo)
che gestisce il protocollo TCP/IP sotto DOS: il celebre NOS di KA9Q. In alternativa potete
installare il sistema operativo Linux, un vero e proprio Unix con supporto nativo della rete via
radio, per il quale esistono i relativi gestori per modem BayCom.

I PROGRAMMI DI TERMINALE

Che programmi di terminale si possono usare con questi gestori? Ad esempio il celebre TPK, di cui
abbiamo parlato qualche mese fa; esso però ha bisogno di un piccolo programma residente
"adattatore" (una specie di "zeppa") che si chiama "TNCDED" per interfacciarsi con TFPCX. I due
programmi TFPCX e TNCDED sono forniti in un unico archivio TPK-BCOM.ZIP incluso nelle
nuove versioni di TPK, che quindi ormai supporta ufficialmente il modem BayCom. Lo stesso TPK
tuttavia può usare altri programmi, per "girare" su un nodo BPQ (fare sempre riferimento alla
tabella) che utilizza modem BayCom.

Altri programmi, come gli ottimi TSTHost e Graphic Packet, pilotano senza alcuna difficoltà
direttamente il TFPCX.

Insomma come potete vedere, oggi è possibile utilizzare il modem BayCom con i più noti
programmi di terminale, esattamente come se si trattasse di un TNC, ed addirittura è possibile farlo
in protocollo TCP/IP.

 

free countersfree countersfree counters