continua (next page) La MegaDitta Il Capobanda!!! main index Qui sotto, alcuni testi sparsi di qualche annetto fa, chiacchierando dell'hardware, del più e del meno.


Abbiamo overclockato a 225 MHz (75*3) il K6/200 (66*3) di Massimo. Unico problemino: al boot segnalava uno strano errore riguardante il monitor, ma per il resto tutto sembrava filare liscio. Suggerimenti? La piastra è una Asus TX-97, di fuoco...!

Below, some messages I posted some time ago, about hardware and other little things (like this)...

Nokia 5110 firmware bug - English text only.

I discovered (arrrrrrrrgh!) an ugly Nokia 5110 firmware bug. I still have that great Nokia 5110 (firmware v4.51 NSE-1).

The bug. Try to use the Euro symbol in a message: if you save the message and then modify it again, you see (sigh!) the Euro symbol (that's the last symbol, near the Yen symbol) changed with a blank... :-(

On Altavista search engine I found some pages regarding a cable compatible with the Data Suite, but priced under 49$ (sadly, those pages disappeared from Geocities); anyways, I suspect that the cable is just a RS232 cable...


Informazione disinformata...da un quotidiano particolarmente "esperto di computer", cosa volevate?

Nota bene. A distanza di quattro anni devo premettere che l'uscita dei modem "56k" non ha seriamente cambiato le carte in tavola, visto che quella velocità non è affatto garantita per qualsiasi connessione. Dunque le mie ipotesi e previsioni dell'epoca erano assolutamente esatte.

"ComputerValley" di Repubblica, 5 febbraio 1997, pagina 20.

Articolo: "SuperModem. Una joint venture tra Microsoft, Intel e Compaq produrrà i nuovi apparecchi entro la fine dell'anno".

Leggo, avido di notizie, e che trovo? Niente. Quattro "mezze colonne" per non dire niente, niente di niente. Neppure il titolo era stato così poco esplicativo. Questa è DISinformazione in senso assoluto.

Da buon archeologo vado scavando tra le macerie e trovo che:

  1. la joint-venture in questione venderà "prodotti e servizi" (ma no!!!)
  2. sarà sviluppato un nuovo tipo di modem 30 volte più veloce (1 Mbit?)
  3. i nuovi modem resteranno "allacciati alla rete permanentemente" (??)
  4. e dunque in futuro le famiglie americane (corsivo mio) potranno... blah blah blah.
  5. la joint-venture potrebbe spiazzare la USR col suo modem a 56 kbit/sec.

La sagra delle stupidaggini. Analizziamo punto per punto:

  1. accordi come questo non fanno così notizia, ce ne sono a migliaia ogni mese, e le notizie di ComputerValley sono così fumose che sono sicuramente un paio di righe riciclate da qualche sito (MS? Compaq?)
  2. qualunque sia il tipo di modem che intendano sviluppare (SE intendono davvero svilupparlo e non si tratta come al solito di "vaporware"), allora bisognerà innanzitutto aggiornare le linee telefoniche. Con quelle attuali già si "raschia il fondo del barile" a 33600. Il famigerato standard USR X2 da 56 kb/sec funziona solo se non si viene smistati attraverso un centralino, quindi funziona solo se il chiamante ed il chiamato abitano di fronte (e neanche sempre...).
  3. che ci vogliano nuove linee (con costi spaventosi) è assodato; che l'allaccio sia permanente significa che queste linee dedicate costeranno ancora di più... invece l'articolo cerca di far pensare che acquistando un nuovo modem, improvvisamente uno ha a casa sua un sito Internet attivo 24h/24. Bubbole.
  4. a noi italiani, per motivi storici, pratici e anche tecnici, non può affatto interessare (ma si fanno grandi acrobazie per non farcelo capire) perché abbiamo una tecnologia telefonica, postale, etc, ai limiti di un paese sottosviluppato... per non parlare dei co$ti: una "famiglia americana" non sa neppure cosa sia la TUT, e nel bilancio familiare annuale dedica al telefono solo una piccola spesuccia...
  5. il disperato tentativo della USR di sfondare i 33.6 (almeno in maniera commerciale), dal momento che non è stato imitato da nessuno, dovrebbe far riflettere. In Italia gli X2 li hanno comprati solo i fanatici, per poi usarli a 33600 nel 99% dei casi.

Per concludere: il sottotitolo, una panzana propagandistica colossale:

INTERNET IPERVELOCE SU LINEE «NORMALI»

PANZANA: "linee normali". Anche con qualche artificio clamoroso (come ad esempio centralini che non taglino la banda, ma occorrerebbero poi centraloni e comunque altre linee) ci saranno dei costi assai elevati (e nel caso che ho appena indicato, anche risultati decisamente penosi).

PROPAGANDA: "Internet iperveloce". Evidentemente sanno tutti che Internet è di una lentezza esasperante, e non sempre la colpa è del modem lento. 500k di immondizia sono 500k: che quindi si vada a 33.600 o a 28.800 fa poca differenza (sempreché, per quei 500k di immondizia, non siano intasate le linee). Tutto questo sapendo che quei 500k potevano benissimo essere riscritti occupando solo 50k (compressione, risoluzione, contenuto effettivo, etc). Ma anche in questo caso restano 50k di immondizia. E se anche non fossero immondizia, gran parte dei "navigatori" cerca tanto per cercare, facendo spedire da un capo all'altro del pianeta incredibili quantità di pubblicità ed altra immondizia elettronica.

Ancora un paio d'anni di sforzi, e l'archeoparola "Software" sarà sostituita in tutti i dizionari dal neolinguismo "MicroSoft", mentre l'archeoparola "Computer" sarà sostituita da "Internet".

Supplemento di cronaca, a distanza di diversi anni da quando scrissi quelle poche righe. Più o meno ci sono riusciti: uno oggi non ha da fare troppi arzigogoli per avere internet in casa a velocità più che ragionevoli (ADSL, Fastweb, etc) e a costi non proprio ragionevolissimi; i fatidici modem "56k" sono ormai su ogni computer, anche se a più di "38-40k" è difficile vederli andare; il sito internet fatto in casa propria però non si può metter su comodamente, perché c'è sempre il problema del dynamic-DNS... Ma questa è un'altra storia. La Micro$office continua imperterrita a vendere dei software che sprecano risorse fino all'inverosimile (non si capisce come mai per scrivere tre righe di saluti occorrano decine di kilobytes di tag html) e la "spazzatura informatica" (non solo la cosiddetta "SPAM e-mail") è aumentata fino all'incredibile...

Programmazione in una "Graphical User Interface"

La GUI ufficiale è X-Free ("X" per gli amici :-), un clone gratuito di X/Windows (l'ambiente a finestre dei grossi sistemi Unix). Ma programmare sotto X è di una difficoltà tragica... :-(

Il guaio è che tutti i sistemi a finestre sono nati "strutturati" (scritti in C o in Pascal, come i primi System del Mac) e non previsti per il multitasking (come il GEM, che è stato però abbandonato da sei o sette anni: eppure andava proprio bene sui PC...).

Fra l'altro X è superiore a Windows anche concettualmente: un Xserver gira su un computer, e un buon numero di terminali grafici può usarne le risorse (font, applicazioni, etc). Negli ambienti Unix di rete è proprio il massimo (mentre Win ha bisogno comunque di un PC).

I problemi da affrontare per scrivere un sistema a finestre che sia commercialmente competitivo sono (aaaargh!!):

  1. deve lavorare su diverse schede grafiche, a diversa risoluzione, con diverse "profondità" (numero di colori), etc;
  2. le primitive: non bastano solo punti, linee e font bitmap... una buona libreria grafica è di una complessità alquanto alta;
  3. "clipping" delle finestre (se una finestra è parzialmente coperta ma il programma relativo ci scrive dentro, allora la parte "scoperta" deve comunque essere aggiornata);
  4. un sistema di font non-bitmap (si potrebbe supportare il TrueType perché in giro c'è una marea di fonts TrueType);
  5. utilizzabilità "in rete": la possibilità di installare su una sola macchina tutto il "pacco" (se voglio 10 persone a lavorare con 500 font non devo essere costretto a installare 500 font su 10 macchine!).
  6. al momento non ho presente... :-)

Per Linux ho provato MGR (che fa i punti 1,2,3: 1 e 2 con la svgalib e alcune sue funzioni di supporto, 3 "un po' alla buona" ma ci riesce con delle funzioni sue) e naturalmente X (che fa bene tutti e 5 i punti, ma è spaventosamente complesso da programmare).

Per DOS, prima di Windows esistevano il GEM (Graphics Environment Manager, se non ricordo male), il GEOS (derivato dall'omonimo per C64, e faceva addirittura multithreading e multitasking) e sicuramente qualcun altro che non ricordo (programmi "in grafica" non contano, sto parlando di GUI).

Le altre GUI (OpenLook, NextStep, etc) le conosco solo di nome.


Gente, ho provato il dischetto dimostrativo del QNX.

Nel dischetto c'era:

Il tutto in un solo dischetto da 1.44 Mb da caricare al boot, senza installazione!!!

Poi, DOPO, sono andato anche a leggermi i numerosi file di help a corredo (sempre sullo stesso dischetto), in cui si dice che QNX è un sistema operativo real-time e blah, blah, blah... :-)

Chi vuole il dischetto demo può andarselo a pescare su http://www.qnx.com - però per capire esattamente com'è che un sistema operativo può essere così piccolo (per il dischetto in questione bastano un 386 e 6 Mb di ramdisk) c'è ben altro da spulciare.

Comunque, in parole povere (molto povere):


[...] Linux è così e basta, non è "relativamente difficile". Io ho usato per anni ed anni Unix, per cui quando ho provato Linux per la prima volta, mi sono subito sentito a mio agio.

Dopo che tutti i "tecnici" avevano comprato il PC, bisognava farlo comprare anche a quelli che non ne capivano niente - i quali, con un po' di clic e qualche battutina tipo "ma tu ne capisci di Internet?" si illudono di avere il "Potere dell'Informatica" nelle loro mani...

La cosa clamorosa è che Internet è nata su Unix, e i faticosi adattamenti di protocolli e software fatti su Win cercano disperatamente di lavorare in grafica usando protocolli nati "a caratteri".


Ho scoperto che la piastra 386 che mi avanza, entra perfettamente nello zainetto, lasciando ancora un po' di spazio anche dopo che ci ho infilato il pigiamino, l'alimentatore, l'asciugamani, la tastiera, qualche rivista, la scheda video, un paio di libri, l'ardisco col controller e altri effetti personali.


Ho comprato una superpotente scheda miroPCTV, decodificatore TV e teletext. È una PCI busmaster, vedo la TV a 768×576 a 16 milioni di colori; purtroppo devo fare i salti mortali perché non va troppo d'accordo col chipset SIS496 (*) del mio 486/120 :-( per cui ogni tanto si blocca tutto e devo resettare a hardware.

(*) questa cosa l'ho letta nei sorgenti di Linux, non c'era mica scritto nell'aggiornatissimo manualino fornito a corredo con la scheda... :-(

Nella documentazione si suggerisce un Pentium 100 (e il mio 486/120 corrisponderà sì e no ad un Pentium 60), ed infatti se tento di avviare il programmino W95 che decodifica le pagine Televideo, nel migliore dei casi dice che non trova il segnale (nel restante 99% dei casi si inchioda tutto).

In compenso il chipset BT848 è pienamente supportato da Linux (nella directory video4linux ho trovato diversi suggerimenti); tragicamente la decodifica teletext me la dovrei scrivere io a partire dalla documentazione pdf che trovo su http://www.brooktree.com - riassemblando i circa 1500 kb/sec di raw data che mi passa la scheda (aurrrrrrgh!!!).

Da qualche parte ho letto che su http://home.pages.de/~videotext ci sono dei sorgenti per Linux.


Some notes about BT848 chipset support under Linux.
My Linux box is a 486/120, SiS496 chipset. I got a miroPCTV card, BT848 based, correctly running under W95. In video4linux docs it is reported as "teletext support via VBI decoding in software".

So I compiled video4linux BT848 support in my linux kernel 2.2.5 (RedHat 6 distribution), hoping to get teletext pages here.

Sadly, the vbidecode software does not find/save any teletext page. It uses continuously 15-20% cpu time on my 486/120, but doesn't write any vtx file. Instead, I get some strange ext2fs errors (!!!): I often have to hard reboot and run e2fsck manually...

I think that vbidecode must set the TV channel before starting, so I accessed /dev/video0 (major=81,minor=0) to set up the "TV channel 39" as of this example:

int fd=open("/dev/video0",0);      /* instead of /dev/vbi0 */
int channel=39;                    /* request ch. 39, UHF  */
ioctl(fd, VIDIOCSFREQ, &channel);  /* reports no errors    */


La politica del "no upgrade"...

Io continuo con la mia politica del "non upgrade": c'è gente che vorrebbe usare W98 e Word97, nonostante il fatto che ora stiano bene (uno di questi ha scritto con la massima comodità un'intera tesi di laurea col Word 6.0 sotto Win 3.1 su un Olivetti 386 con 4mb RAM, 60mb hdd e Doublespace; un altro lavora ottimamente col Publisher per Win31 su un 486 con 8mb RAM, a velocità supersoniche; altro che la lentezza spaventosa del P166MMX 16mb RAM 1378mb hdd...)!


"Due sei e novanta più iva": prezzo ETERNAMENTE standard per un notebook!

Verso il 1989 un amico dell'università mi propose un "affarone": un nuovo fiammante portatile 286, "16 MHz" (cioè 12, ma il Landmark speed-test riportava erroneamente 16), "un'ora e mezza di autonomia" (cioè per arrivarci dovevo comprare un secondo battery-pack e portarmelo dietro perché una batteria durava non più di 45 minuti; naturalmente 45 minuti se non lo toccavi: se appena sfioravi la tastiera quei 45 minuti duravano assai meno), "quaranta mega hd" (cioè 20 Mb taroccati con "Stacker", il predecessore di DoubleDisk e simili), totale "due sei e novanta" (più iva).

Oggi un portatile degno di questo nome costa ancora "due sei e novanta più iva" (nel 1990 uno chiedeva un notebook "non oltre i due milioni di lire" e ti rispondevano: "sì, sì, certo: due sei e novanta più iva, come se "2.690.000+iva" fosse "non oltre i due milioni di lire"...): certo, quello oggi è potentissimo, ma ha poca RAM, ha una tastiera che fa schifo e le batterie durano sempre un quarto del minimo indispensabile :-)

Nelle rare eccezioni c'è sempre e comunque una fregatura nascosta... :-)

Piccolo aggiornamento. Linux non spreca risorse (specialmente la CPU), per cui le batterie sotto Linux durano molto di più. Con il mio colossale notebook ho ascoltato duecentocinquantatre (253) minuti consecutivi di files MP3 con XMMS sotto Xfree... Oggi finalmente vendono portatili degni di essere chiamati così, cioè con abbastanza RAM e abbastanza disco, ma solo perché il Winzozz a corredo è paurosamente avido di risorse, per cui ciò che sotto Winzozz ti sembra appena sufficiente per respirare, sotto Linux sarà di una larghezza e comodità notevoli.

Domanda: meglio un lettore 12× CLV o un 24× CAV ?

Questa domanda, in termini leggermente diversi, se la ponevano quelli che compravano i videodischi qualche annetto fa (in Italia non ne ho mai visti).

CLV sta per velocità lineare costante: quando la testina va verso le tracce più interne allora la velocità del disco si riduce. Questo permette di registrare una maggior quantità di dati sul disco perché lo spazio fisico della superficie è sfruttato in modo uniforme.

CAV sta per velocità angolare costante: come gli hard disk, insomma, in cui la velocità di rotazione è sempre la stessa, per cui le tracce più interne sono più "dense". Questo permette un accesso più veloce, ma ci vuole una qualità maggiore del materiale del disco, qualità che nelle tracce più esterne viene poco sfruttata.

"12×" e "24×" sono indicatori di throughput che non tengono conto del tipo di tecnologia. Il primo significa 12*150k al secondo, e il secondo 24*150k. Cioè pare che sia meglio il secondo.

Non conosco esattamente i principi di funzionamento dei CD, ma ho visto in passato parecchi commenti sulla differenza tra CAV e CLV, in cui la maggioranza (me compreso, in fin dei conti), per una periferica che sia di sola lettura preferirebbero il CLV e il suo massimo sfruttamento della superficie fisica del disco.


E ora ti dò pure una notizia bomba.

Pare che talvolta (non sempre) il clock del mouse PS/2 vada in corto col clock della tastiera (i due arnesi però continuano a funzionare; il clock del mouse è più lento e comunque la tastiera non parla se vede la linea "bloccata"). Questa scoperta, sotto cui metto la firma perché sono co-autore e l'ho vista con i miei occhi, è convalidata da un oscilloscopio!


Anche la USB, per le tastiere, sta tardando parecchio ad affermarsi. Addirittura: pare che non sia ancora ben chiaro lo standard, visto che due famosi produttori hanno già tirato fuori due cose diverse...

Il mouse seriale è intramontabile. Ed io ho un mouse il cui connettore è il classico Cannon (ora la Cannon è della ITT) a 25 poli !!!

Tu sei troppo giovane, forse questa non la sai: i primi mouse avevano un doppio connettore, uno seriale ed uno che andava in serie sulla tastiera, da cui andavano a pescare l'alimentazione!!! Robe di quando un mouse pesava parecchio e costava una mezza milionata... (ne ho sentiti di alcuni a 4700 lire più iva, ma pare che non siano quelli più economici in assoluto).


Strange problems with a Windows driver of a Kodak DC210+ digital camera. Some time later, I found that under Linux there is no problem, even at 115200...!

(I sent this email to their support staff but never got a decent answer...)

I installed the Mounter software on my Texas Instruments Extensa 355 (Pentium 150MMX notebook, developed by Acer, still under warranty).

The first day it ran at 57600 baud (I couldn't get it at 115200 baud). The second day I couldn't get it to run anymore, not even at 9600 baud, I don't know why (maybe a system hang while using another application): I got always this "page fault":

Page fault in DC210MNT.DLL at 0137:1001ba63
eax=0, ebx=0, ecx=01b0fc48, edx=100324bc
cs=0137, ds=013f, es=013f, ss=013f, fs=2297, gs=0, eflgs=00010206
eip=1001ba63, esp=01b0fbb4, esi=015008e0, edi=0, ebp=01b0fc54
bytes at cs:eip = 8b 48 04 e8 f5 f1 00 00 8b 46 6c 85 c0 75 53 c7
stack image:
8258347c 00459d78 0045b610 00008bf0 01010034
00005400 8be2219f 17af114c 00000006 0000013f
01b0fc80 004221ec bff74277 0442d4ad 16cf17af
00008c20

I sadly had to reinstall the entire system (backup, format the hard disk, install Windows 95 again, reinstall all applications and restore data: aaarrgh!!!).

I finally installed again the DC210+ Mounter software, but this time (and up to today) I cannot transfer photos at more than 19200 baud (aaaarrrgh!!!!! three or four minutes per photo!!!).

I tried everything to get more serial speed (use battery instead of AC adapter, either on the notebook or on the camera; unload major applications, etc) but I could not get more than 19200 baud.

This seems not a hardware problem, because the first day I got immediately 57600 baud working. And I get also 57600 baud on my old and slow 486 PC.

I see that it's a simple RX/TX/GND RS232 serial connection, so it should not be so time-critical on a Pentium 150 MMX.

If I could get the specifics of the protocol, I may write my own transfer program under DOS or Linux (or even Windows) that does not lock the machine - it is not nice to wait hours (80-100 minutes!) to transfer a full 8Mb compactflash card.

To solve this problem, I asked for the PCMCIA/Compactflash adapter that I found in the Kodak Digital Science Accessory Kits depliant. Sadly, neither major computer shops nor great photo&accessories shops have them, so I had to order it from Kodak Europe at Edinburg and, because of snail mail, I have to wait some weeks to get it here!!!

Well, it's not nice to have such a great camera while being braked by batteries and on-the-field photo transfer (when I am on a mountain, I have no AC power connection and not all the time I have at home).


Quei mariuoloni della XYZ vogliono 600 dollari per un kit di due radio tipo "spread-spectrum" per la trasmissione dati a 9600 baud (fino a 30 miglia a linea di vista)... la cosa è proprio ghiotta (l'apparecchio è una scatola nera con un'antenna e una porta seriale, immagina cosa si può combinare con due sistemi Linux), ma spendere un milione e duecento è davvero improponibile.

Un amico ha trovato delle radio 430-440 MHz a quindicimila lire in uno "scasso" (probabilmente erano per i telefoni in macchina, quelli col prefisso 0333 e che sono stati disattivati da un po' di anni), dunque una soluzione via radio verrebbe a costare in totale meno di duecentomila lire (due radio, due modem radio e due antenne); si andrebbe a 1200 o 2400, ma è già tantissimo...

Piccolo commento extra: la WorldWireless non vende più quei kit, e non sono mai riuscito a trovare un kit uguale allo stesso prezzo. Perfino un loro concorrente mi disse desolato che 600 dollari erano "a real bargain" (un vero affare). Dunque non erano "mariuoloni". Con le radio dei vecchi telefoni per auto non si è fatto più nulla; si potrebbe andare anche a 9600, ma le spese aggiuntive lieviterebbero ben oltre le duecentomila lire previste.

Come funzionava la penna ottica sulla CGA?

Le prime CGA avevano anche un connettore a cinque poli per la penna ottica. Io ho ancora una di queste CGA.

Il principio di funzionamento è questo: se sai quando "parte" il pennello elettronico, quando appoggi la penna ottica sullo schermo, appena il suo sensore "capta" il pennello elettronico del video uno "cronometra" quanto tempo è passato dall'inizio del tracciamento dell'immagine e capisce dov'era la penna.

Dunque va bene su qualsiasi monitor, e può avere una precisione anche abbastanza interessante (prossima al pixel). Anche le "pistole" hanno di massima questo principio di funzionamento; dato che stanno "lontane" dallo schermo, la precisione è parecchio inferiore.

Il touchscreen è un po' più complesso perché richiede sensori "sopra" lo schermo (solo nei quattro lati, in genere), pure può arrivare alla precisione pixel, ma è più costoso.

Purtroppo - non ne ho mai capito il motivo - la penna ottica non è mai decollata. Già verso l'87/88 nessuno ne sapeva nulla, come se si trattasse di un oggetto obsoleto. Infatti solo nelle più antidiluviane versioni di Basic c'erano un paio di funzioni per leggerne la posizione.

Trovai uno schema per autocostruirsela, ma ci voleva una tripla laurea in ingegneria termoelettronucleare per capirlo... per giunta c'era da scriversi anche il software... e allora lasciai perdere.


Turning on with "not new batteries". Is it really a hardware problem? (Kodak DC210+ hardware problem. Again, the support staff didn't answer...)

After the first little use with Kodak PhotoLife batteries (20-25 photos, about a minute use of the TFT display), the machine signaled "battery low" and refused to turn on.

So I used the AC Adapter just to turn it on, and then continue taking photos using the "low" batteries (a lot of great photos, a lot of flashes and TFT display use).

Well: the only problem is to turn on the camera when the batteries are "not new".

Same problem with Duracell batteries, those with the "PowerCheck". When the DC210+ thinks they are "low", the PowerCheck says they have still 75% of charge.

I am waiting for local stores to get NiMH batteries...

Yes: it's a problem of all common batteries, that have a discharge curve too "round". NiCd - and, better, NiMH - batteries solved the problem, because they have maximum voltage level even when they are near to low-power status. When the voltage drops (and the camera complains), it means really that they are discharged. I currently use 2100mAh batteries.

Clamoroso: in corto ma funge...!

Il clock della tastiera è circa tre volte più veloce di quello del mouse (non stiamo parlando di quarzi ma di lunghezza dei segnali, cioè di sincronizzazione!).

(come mai vanno in corto? c'è un'errore nella piastra o cosa?)

No, è proprio così il progetto. Il mouse PS/2 emette semplicemente un interrupt diverso... :-)

Un'altra cosa che mi meraviglia è che nonostante ciò (nonostante la semplicità di progettazione, penso che sia più facile costruire una porta per mouse ps/2 che costruire una seriale), da anni ed anni continuano imperterriti a circolare mouse seriali... :-)

Praticamente la stessa porta PS/2 può essere usata per tastiera, mouse, tastierini e affini, mettendoli addirittura in parallelo. Con una qualche logica che ancora mi sfugge, quando uno "parla", gli altri stanno zitti.

Quando li ho scoperti in "corto" mi sono allarmato, salvo poi capire che nella "Potente" architettura PS/2 c'era questa "genialata" (?).

Altra scoperta recentissima: la Maxim, per il regolatore di tensione MAX878 (un chippetto consigliato per "stabilizzare" l'alimentazione delle porte USB, cioè prende in input da 1 a 18 volt e tira fuori in output sempre 5 volt, cambiando solo l'assorbimento)... ci ha detto "consegna in 94 o 98 settimane".

Incredibile (cioè: assolutamente normale): il materiale "di base" per le porte USB (cioè: utilizzabile *anche* per le porte USB; a noi serviva per altri motivi; nessuno produce un simile mostro di regolazione di tensione!), è consegnabile tra NOVANTOTTO settimane. Non è uno scherzo. Le USB ci sono già sui PC in circolazione, ma non "prenderanno piede" prima di un paio d'anni...!

Se il PC non ha una porta PS/2, devi comprare una scheda PS/2. Ne ho viste alcune sulle 40/50mila lire (più iva, più trasporto, etc) sui soliti cataloghi per corrispondenza, dove ti vendono pure una porta parallela su bus ISA a sole 37.900 lire più iva (un Furto con la eFFe maiuscola!). Ma il mercato va avanti così...


I have two Pentium computers (a notebook and a desktop) on a distance of about 50 km (almost line of sight). Their applications have to run under Linux.

I have to evaluate a cheap solution to get them connected via radio at a decent speed (a throughput of 100 bytes per second is good; faster is better).


Ho visto il Casio HC-4500 a un milione e mezzo... era quello con la cpu RISC a 73,3 MHz, 16Mb RAM, display LCD a colori half-VGA (640×240×256), etc... unico difettaccio: viene venduto con Winzozz CE 2.0 su ROM di serie :-( Chissà se si possono sostituire facilmente le ROM e metterci delle proprie eeprom (o flash) con il sistema operativo preferito (Linux)...

Ho intravisto, passando vicino ad un'edicola, il titolo "i palmari, perché non servono a niente" e c'era la foto del 4500. Credo che intendano che un mostriciattolo del genere, con Winzozz CE, sia inutilizzabile per fare qualsiasi cosa che vada al di là del giochino.

Ma ve l'immaginate F1GP2 (Formula 1 Gran Prix II) su quel bestio? :-)


(tastiera e mouse usano esattamente la stessa porta?)

Sì. Il connettore ha un filo in più, per cui arriva un int 9 in caso di dati da tastiera, o un int 12 in caso di dati da mouse.

Il segnale arriva come per la tastiera, credo - leggere dalla porta 60h (?) quando arriva l'interrupt.

Dunque si può usare la porta anche per trasferire dati. Ma a quel punto devi costruirti un tuo driver per mouse ps/2, che quando arrivano valori stranissimi allora capisce che non si tratta di dati del mouse ma di dati del tuo circuitino.

In ogni caso credo sia più facile farlo per la porta parallela che non per il mouse. Col mouse hai solo due fili (clock e dato), quindi trasmetti ad un bit; con la parallela standard puoi andare almeno a 4 bit contemporaneamente (il quinto, non ricordo quale dei 5 di input, è quello che attiva l'interrupt della parallela).

Sulle porte USB si può collegare qualunque cosa abbia bisogno di scambiare dati in modo seriale: tastiera, mouse, modem, scanner, etc. Forse anche hard disks e affini, ma credo che la velocità massima della USB sia un po' un limite (se ho capito bene, non più di un centinaio di kb al secondo).

Una parallela invece costa praticamente zero, visto che da secoli è integrata, "di serie", su tutte le motherboard e su tutte le schede multi-I/O... di queste ultime, appena uscirono, io ne comprai una a ventimila lire, cioè la metà di quanto proponevano quella parallela citata :-)

Si può autocostruire? Credo di sì. Non me ne intendo di elettronica, ma a parte un po' di chip per "bufferare" i segnali, mi pare sia semplicissima.


Su una rivista di elettronica è apparso uno schema per un convertitore vga/scart con tanto di software.

Il software è "abbordabile"? :-) Se il driver DOS è di non più di 4 o 5k di .COM allora penso che si possa facilmente disassemblare e ricostruire sotto Linux (e, ma non oso sperarci troppo, anche sotto W95).

[...] La VGA ha frequenze più "varie" delle 31.5kHz e 60Hz... le frequenze dipendono dalla risoluzione. Per esempio, alla risoluzione 320×200 hai 70 Hz di refresh anziché 60.

Quelle che hai citato tu - non ho sottomano il manualino - sono per la 640×480... dato che tutti abbiamo almeno un 800×600, andrà a finire che il vga-scart continueremo ad usarlo sotto DOS :-)


Un amico mi cederebbe a un prezzo decente una motherboard K6/200 con 64Mb RAM, ma non so se avrò la pazienza di aspettare fino a settembre quando lui farà l'upgrade. La 486/120 che ho a casa sarebbe più che sufficiente se non avesse strane fisime con le schede PCI; non posso partire la domenica sera pensando che un'ora dopo si può piantare tutto per sei giorni... la 486 è buona solo per qualche partitina a Descent e Doom II...


Ho cercato in giro e ho scoperto che una puzzolentissima scheda teletext viene venduta da certi inglesi che più che inglesi sembrano scozzesi, visto che chiedevano poco meno di mezza milionata.

A quel punto uno compra una delle tante WinTV in giro, allo stesso prezzo, e ci guadagna anche il tv-tuner... ;-)

La scheda teletext della Rai/Datasport veniva ancora indicata a 310mila più iva (cioè 381mila), ma credo sia perché da anni non hanno più cambiato quella pagina del Televideo.

Scopro per puro caso che ne hanno tirato fuori una nuova versione: a 348mila lire iva inclusa vendono una strana scheda con servizio "XXX - il Web via etere"... "web senza costi di trasmissione", etc.

La pacchianata è evidente (con l'antenna televisiva si può soltanto ricevere), ma i grulli ci cascheranno, credendo di avere sotto mano Internet via etere (invece è un canale monodirezionale).

L'idea dei tizi è questa: mandare via etere informazioni più o meno pescate da Internet, che chiunque con una scheda XXX può ricevere e leggersi. Da quanto ho capito si tratta di diversi megabyte di dati al giorno per cui tenendo acceso il PC 24 ore, c'è solo da scegliere cosa leggersi.

Scorrendo le loro pagine però scopro che gran parte del materiale lo pescano dai vari Televideo Rai e affini; non poteva essere che così, visto che quelle sono pagine testo (dunque parecchie cose da leggere in poco spazio), mentre pagine con grafica e audio occuperebbero troppo spazio (non è velocissima la trasmissione dati teletext).

A parte i servizi gratuiti (tali solo perché riversano via etere dati di altre persone) offrono anche servizi a pagamento, non ancora specificati, di dati che credo mandino in giro crittografati.

Ho chiesto ai tizi via email se la loro scheda può essere usata come banale scheda teletext (perché, detto fra noi, finora è la scheda più economica che ho trovato; a meno di trovare una scheda TV-tuner più teletext a meno di trecentomila lire iva e trasporto inclusi).

Quell'arnese ha il software che funziona sotto Winzozz 95, consigliano un P100 con 60Mb di spazio su hard disk.

Sono passati diversi anni dall'avvio delle trasmissioni teletext e può darsi che non valga più la pena preoccuparsene perché nell'arco di pochissimi anni potrebbero essere soppiantate da ben altre cose.


Ci sono diversi telefoni cellulari GSM in circolazione che hanno già a bordo l'interfaccia per il collegamento col PC: manca solo il cavo seriale e il software. Uno di questi è il Nokia 5110.

Il 5110 costa 390mila lire. Il cavetto seriale e il software costano la bellezza di 450mila lire (prezzo non di listino ma "in offerta"), cioè costa più una fetenzìa di cavo seriale con tre dischetti che un intero telefonino.


ho due schede di rete vecchie, non so di che marca siano e non ho alcun software, come faccio a vedere se funzionano?

Avevo il tuo stesso problema, ho usato Linux. Ho compilato il kernel con una gran quantità di drivers per schede di rete (quelli più probabili) e alla fine è uscito che erano banalissime NE2000-compatibili (che del resto hanno invaso il mercato a prezzi stracciati da anni).

Al boot Linux riconosce le schede e ti dice indirizzo fisico (6 bytes), address e IRQ (mentre l'autoriconoscimento di Winzozz fa implacabilmente "fetecchia").

Tutte le NE2000-compatibili che ho in ufficio hanno address 300h, gli IRQ purtroppo variano (da 3 a 12).

Qualsiasi distribuzione di Linux (eccezion fatta per le MiniLinux e simili) comprende i sorgenti del kernel sotto /usr/src/linux (e nella stessa directory c'è anche il file README che ti spiega come riconfigurarlo e ricompilarlo) e il compilatore C - di cui puoi verificare la presenza battendo, da command-line, il comando

gcc -V

I drivers delle schede di rete sono già tutti nei sorgenti del kernel.


Trying to solve software and hardware problems with a bt848-based card...

I have a miroPCTV card, BT848 based (got at less than 99 euro) in a 486/120 SiS496 20Mb RAM Linux box (RedHat 6.0 with Linux 2.2.5-15 kernel: its bttv.h defines BTTV_VERSION_CODE 0x000523).

The antenna cable is about 25mt, but on the PAL TV set I get a strong Teletext signal on at least three channels.

Under Windows 95 I can watch TV on all channels but I cannot get teletext program running because as soon as I try to start another application while mirovideoPCTV is running, the system hangs (miroteletext application requires mirovideoPCTV software running).

Under Linux, I can still watch TV using Xawtv under X (Gnome and KDE; with the great v4lctl utility). But no teletext.

I first tried vbidecode.cc 1.00 by rjkm@thp.uni-koeln-de, the author of bttv.c, but it couldn't get even a row of data. I sent him an e-mail some days ago, but am still waiting for his answer.

His vbidecode.cc is hard to modify (it's not a clean source like his bttv kernel sources); I placed some printf in its code, and it seems that it never has good data to process (it never gets the 0x27 data byte).

Then I tried alevt 1.4.8, but still did not get anything. I found t1.c in the contrib directory: same result. I set up the channel ("v4lctl setchannel 39") even while t1 was running, but nothing changed.

So I placed some "printf(I'm here!)" in hour vbi.c source code and compiled again t1.c to see what happens while reading from /dev/vbi.

I discovered that the vbi_line function starts, then it finds a correct number of periods (from 148 to 156), but returns -1 because of bad frequency (it expected length 39 to 42, "normally 40.9", but it always gets 32 or 33). If I change that line to:

if(i<31 || i>42) return -1; // accept my bad frequencies

the program still doesn't find the data[0]==0x27 as expected.

Nothing changes if I use, instead of norm0 (PAL, 335062 steps), the norm1 (327681 steps, as calculated in vbidecode.cc).

So I tried to see if /dev/vbi returns some data. Yes, it returns about 1500 kb/sec of data bytes; they appear as 4k blocks, with some consistent data in the first forty bytes (things like 35 28 46 42 36 41 27 2b...), then some "sparse" data (not only 00 and 01) up to about 2 kbytes, and the other 2k filled with zeros. Without antenna, I get only 00, 01 and 02 (no other value), so the data of above is surely read from the air...

[...after a while...]

Some problems are solved, main problem is not.

I found the set-tv (v4lctl) utility in the Xawtv package, this is good to tune the TV channel while in text-mode (without seeing TV on screen). Here, on channel 39, I get the strongest teletext signal (at least on the TV set, bought 15 years ago, using a SAA chipset for decoding).

I found the alevt 1.4.8 package, also doing vbi decoding, but it doesn't find any page - not even a row: the same problem I had with vbidecode.cc (it doesn't find the 0x27 starting byte, and the starting 101010101010... sequence does not appear continuously).

I think I get correctly the vbi lines data: 4096 bytes packs with some apparently "consistent" data at the beginning, and "empty" packs (only 00, 01 and 02 sparse values, mainly 00) in the channels where no teletext signal is available (or without antenna).

So I saved on disk some data (dd if=/dev/vbi of=data bs=64k count=200) and tried to analyze that. I placed some jumps in the code, in order to skip the checks for 0x55, 0x27, etc, and had a look to the decoded lines using an hex editor. The decoded stuff is, obviously, nonsense data; there is nothing that appears as - at least - something human written.

The AGC function finds always a max value between 134 and 155 (mainly from 148 to 150) and a min value always 0; the vtscan (scan for 0x54/0x55 sequence at the beginning) always samples bits from the first 38 bytes (because of vtstep=335062, that is "PAL encoding", i.e. norm=0) of the 2kb block (vbi line), but in the (very) rare times that it gets the "1010101010..." sequence, there's never a 0x27 waiting after that (i.e., data[2] is almost always 00 instead of 27 or d5).

The decoded line (45 bytes total) is always scanned in the first 1837 bytes (this also is because of vtstep value): a bit is sampled every 5 or 6 bytes (because of spos calculation with vtstep>>16).

[...after a while...]

Arrrrrgh, it still doesn't work...

I used the step=270517, with big_buf=0 (that is, -oldbttv) and fine_tune parameter set to 0 (I am still using t1.c because of low processing power that it requires to compile and run and print lots of debug info).

It correctly finds "enough periods" and does not return for "bad frequency" (as said before, "hi[5]-hi[1]" is almost always 32).

But it still doesn't find the 0x27 start-byte. I placed some printf() in the for(...i+=STEP) cycle, and found that the check "two ones is enough" always fails: either p[i/FAC] or p[(i+STEP)/FAC] is always 0. That is, one of these two values is not greater than the threshold (I found "thr" ranging from 0x1c to 0x53, the most common values are between 0x27 and 0x43).

I skipped that check and made the cycle repeat for all values (saving and restoring the "i" value when you set the bits in the data buffer): I found always a data[0] value of 0x55, or 0xa5, or 0xaa (only in a few cases I got slightly different values), so the vt_line function is never called :-(

I tried to lower the xtal-freq up to 27.75Mhz (a step of exactly 4 bytes), but with the same results (those lots of 0x55, 0xaa instead of the magic 0x27).

If I set up only the check for frequency (i<31 || i>35) and leave the step=335k, I have the same situation: the "two ones is enough" finds almost always one value (the other is always 0), and instead of the 0x27 (or 0x55/0xaa/... values) I get a quite repetitive pattern (0xda, 0x6d, 0xb6, 0x5b, 0x2d...).

I tried even using a step=270k for frequency evaluation and step=335k soon after, and vice-versa, but without better results.

I feel I'm near the solution, but I don't understand what's wrong (or, what's good) in my fool tries (this linux box runs uninterruptible 24h a day thanks to a lot of "fool tries"); so I try to send you a 32k sample of vbi data broadcast here (dd if=/dev/vbi of=vtxdata.bin bs=32k count=1) so you can have a look at what I am trying to decode.

From the fastest to the slowest refresh rates (BIOS settings), I got always the same results (btw, I cannot capture video data, the cpu is too slow; maybe a DOS utility could be of great help, but since some years all drivers are only for Windoze; I bought a bt848 based card only after I read that was supported by Linux kernel).

[...and, finally...]

The miroPCTV card is not compatible with my PC (SiS496 chipset). I don't understand why heavy works (like seeing TV on a 800×600×16M display) are OK, but light works (like reading vbi data) are not... but on a K6/200 Asus TX97 motherboard it worked very fine (even without a "perfect" TV display).

I'm out of $$$, so I have to wait end of September to get a new motherboard. This doesn't make me happy, because this 486/120 bought on July '95 has already done *all* the greatest and best things (a 486/120 with Linux is something like a supercomputer, while in W95 is like a PC/XT).

[...after a long, long, long time...]

From some weeks I'm up again, with an Abit BE6 motherboard, with a Celeron/400 processor overclocked to 500 MHz, the (in)famous miroPCTV card and alevt 1.4.8 !!!

It runs great. Better than TV set (I have an old TV set with a teletext decoder with 2kb RAM: only one page of memory!), even if the miroPCTV (that now has a separate - and better - antenna) seems not to catch the channels like the "real" TV...

I'm now using Linux 2.2.13 (after some days of 2.0.27); I have to ask "-oldbttv" from command-line, but it runs great. Since I use a 1024×768 X screen, and since I am interested to read teletext pages from the PC (I like the "cache effect": zzzzzzap! here's the page) but I cannot start X at 640×480 just to see those little little little characters!!!



Click here for index page.

send e-mail - continua (next page)