Autoritratto con mele

Per entrare più in dettaglio sul bug del 2010 che affligge i Newton MessagePad con Newton OS 2.1, fate riferimento ai due articoli che ho scritto in precedenza sull’argomento:

1. Ancora Newton: il bug del 2010
2. Il Newton e il bug del 2010: qualcosa si muove

Come scrivevo nel secondo articolo, uno dei pochi sviluppatori Newton ancora decisamente attivi, Eckhart Köppen, ha preso a cuore l’iniziativa di trovare una soluzione per sistemare questo bug che rischia di compromettere in maniera seria e definitiva la salute dei ’sempreverdi’ Newton a partire dal 1/1/2010.

Dopo aver pubblicato un software diagnostico (Y2010 Diagnostic) un paio di mesi fa, il 24 maggio Köppen ha annunciato nella mailing list NewtonTalk di aver approntato una vera e propria patch di sistema, chiamata Patch 71J059, che dovrebbe risolvere definitivamente il problema in questione. Ecco la doverosa traduzione della pagina relativa alla patch 71J059 del sito di Köppen:

Patch 71J059

Questa è la patch di sistema ver. 71J059 per il MessagePad 2100 con sistema operativo USA. La patch contiene un fix per il problema dell’anno 2010, unitamente ai contenuti della patch 717260 originale.

• Versione: 71J059
• Download via SourceForge

NOTA: QUESTA PATCH VIENE FORNITA SENZA GARANZIA. A CAUSA DELLA NATURA COMPLESSA DELLE PATCH DI SISTEMA, UN’INSTALLAZIONE SCORRETTA O NON ANDATA A BUON FINE PUÒ RENDERE IL NEWTON INUTILIZZABILE, E IL CONSEGUENTE RIPRISTINO RICHIEDE UNA SOSTITUZIONE TEMPORANEA DELLA SCHEDA ROM, CHE PROVOCHERÀ LA PERDITA DI TUTTI I DATI PRESENTI NEL NEWTON!

Compatibilità

La patch è compatibile soltanto con i MessagePad 2100 con sistema in inglese (USA). Non è compatibile con:

• La patch 710031: È necessario rimuovere questa patch prima di installare la 71J059 (vedere più avanti). La funzionalità della patch 710031 potrebbe essere integrata più avanti in una nuova patch.
• Fix2010: Questo fix modifica alcune delle stesse funzioni temporali, e deve essere rimosso anch’esso (vedere più avanti). Fix2010 non sarà più necessario dopo l’installazione della patch 71J059.

File

I file contenuti nella patch sono i seguenti:

• Patch.pkg — La patch vera e propria.
• Y2010 Diagnostic.pkg — Uno strumento per la diagnosi del problema dell’anno 2010.
• 717260 Install Override.pkg — La patch 717260 originale, modificata per potersi installare sopra ogni altra patch, da non usarsi se non in caso di risoluzione di problemi.

Installazione

La patch viene installata come qualunque altro pacchetto per Newton, e si possono usare le Newton Connection Utilities (NCU), Newton Connection for Mac OS X (NCX) o altri software per l’installazione di pacchetti. Dopo l’installazione il Newton richiederà un riavvio. Dopo il riavvio, la patch per il Newton OS sarà aggiornata alla versione 71J059.

I passi da compiere per l’installazione:

1. Creare un backup del Newton
2. Installare il file Y2010 Diagnostic.pkg
3. Se si è già installato un altro software per sistemare il problema dell’anno 2010, come il pacchetto Fix2010, utilizzare il tool diagnostico per eliminare tutti gli allarmi, quindi rimuovere il pacchetto
4. Se il Newton è aggiornato alla patch 710031 (controllare facendo tap sul pulsante [i] e scegliendo ‘Memory Info’) utilizzare il pacchetto 717260 Install Override.pkg per ritornare alla versione 717260
5. Installare il pacchetto Patch.pkg e riavviare il Newton
6. Lanciare il tool Y2010 Diagnostic e controllare se gli orari degli allarmi programmati sono coerenti

Il processo di installazione della patch non modifica né cancella i dati presenti sul Newton (come fa invece un brain wipe), e il Newton è pronto all’uso dopo l’applicazione della patch.

Troubleshooting

SE IL NEWTON NON SI RIAVVIA DOPO L’INSTALLAZIONE DELLA PATCH, SI PREGA DI CONTATTARMI IMMEDIATAMENTE A QUESTO INDIRIZZO: support(@)40hz.org. Il processo di applicazione della patch è estremamente delicato ed è possibile ripristinare lo stato precedente soltanto sostituendo la scheda ROM con una scheda estratta da un MessagePad 2100 con sistema in tedesco, o da un eMate.

Se il Newton mostra uno strano comportamento per quanto riguarda allarmi e altre funzioni legate a data e ora, contattare support(@)40hz.org, oppure tornare alla versione di sistema originale applicando il pacchetto 717260 Install Override.pkg.

Se il Newton entra in un loop di allarme infinito, è possibile eliminare tutti gli allarmi mediante l’applicazione Y2010 Diagnostic. Gli allarmi dovranno poi essere reinseriti manualmente.

Inutile dire che sono strabiliato dalla capacità tecnica di Köppen, che ha praticamente fatto tutto da solo. Svariati membri della lista NewtonTalk e della comunità Newton hanno già installato la patch con successo, e per ora non sembrano esserci problemi di sorta. Qualcuno è persino riuscito a installarla su un MessagePad 2000 con un po’ di iniziativa. Il mio MessagePad 2100 è alla versione 710031, per cui dovrò prima fare un downgrade, ma il procedimento è estremamente semplice. Ora il 2010 fa un po’ meno paura a chi tuttora possiede, usa e ama questo storico PDA che non ne vuol sapere di andare in pensione. Come ho già detto in precedenza, la comunità Newton è davvero straordinaria e piena di risorse e continua a esserlo a più di 11 anni dalla terminazione ufficiale del Newton. E io sono davvero contento di farne parte.

In chiusura al mio post di ieri accennavo al fatto che la realizzazione di un virus per una determinata piattaforma non dipende (o dipende relativamente) dalla diffusione di tale piattaforma (in generale e su Internet). A titolo di curiosità pubblico qui ampi stralci di un articolo di Peter Ferrie (Symantec Security Response) apparso su Virus Bulletin di gennaio 2005, che parla di uno stealth virus ingegnoso e ben scritto, creato nel 1986 e che prendeva di mira… il Commodore 64. Il sito Virus Bulletin è un altro che consiglierei di mettere nei bookmark a chi interessa rimanere costantemente aggiornato in materia di malware.

Per chiarezza: uno stealth virus è un virus in parte residente in memoria, che nasconde i cambiamenti che apporta a livello di sistema operativo, strutture di directory e dimensioni di file, facendo credere al programma che effettua la scansione che tutto stia procedendo normalmente. (Definizione presa da questa pagina).

E ora l’articolo:

Normalmente si dice che il primo stealth virus conosciuto che infettava file fosse Frodo, del 1989. E questo è vero, ma solo per quanto concerne la piattaforma IBM PC. La piattaforma Commodore 64 venne infettata tre anni prima da quel che probabilmente fu il primo vero stealth virus che infettasse file di sistema: C64/BHP.A (da non confonderlo con il boot-sector virus che colpiva gli Atari, anch’esso conosciuto con il nome di BHP).

Tutte le descrizioni di BHP pubblicate a quel tempo erano imprecise; alcune di esse davano persino informazioni errate su come funzionava il processo di infezione. Il presente articolo mostrerà le reali operazioni di quel virus.

Come per tutti i programmi per il Commodore 64, BHP iniziava con del codice scritto in Basic. Il codice era composto da un’unica riga, una chiamata di sistema (SYS) al codice assembler, dove risiedeva il resto del virus. A differenza di molti programmi, il codice del virus costruiva l’indirizzo da chiamare dinamicamente. È possibile che sia stato scritto da un programmatore molto attento, ma questa procedura si rivelò superflua perché l’indirizzo non cambiò nelle versioni successive della macchina.

Una volta che il codice assembler otteneva il controllo, si inseriva nel blocco di memoria solitamente occupato dai dispositivi I/O [input/output] quando la ROM veniva allocata in banchi.

A questo punto è necessario descrivere più dettagliatamente parte dell’architettura del Commodore 64.

Il Commodore 64 utilizzava un processore MOS 6510, una versione più recente del chip MOS 6502 presente su molti computer della concorrenza a quei tempi, fra cui la famiglia degli Apple II e gli Atari 400 e 800. Dato che il bus dati del 6502 (e quindi del 6510) era a 16 bit soltanto, l’intervallo di memoria massimo indirizzabile direttamente era di 64 KB. Per aumentare la memoria disponibile venne implementata un’architettura ‘a banchi’, che permetteva di mappare aree diverse di memoria sotto il controllo dell’utente, semplicemente scrivendo il valore appropriato in una determinata porta mappata.

[...] Dato che le tutte le regioni mappate dovevano rientrare nell’intervallo dei 64 KB, un gruppo di intervalli di memoria forniva la base per tutta la memoria in banchi, così da offrire il quantitativo massimo di memoria sempre disponibile. Ciò riduceva di gran lunga la complessità del programma medio. D’altro canto, tuttavia, erano necessari svariati passaggi affinché un programma in esecuzione all’interno di un banco di memoria potesse accedere ai dati contenuti in un altro banco di memoria. Il primo passaggio era quello di inserire codice in una parte di memoria non allocata in banchi ed eseguirlo. In seguito, quel codice doveva togliere il programma dal banco, inserire nel banco i dati richiesti, accedere a quei dati e salvarli, poi togliere i dati dal banco, rimettere nuovamente il programma nel banco, ripristinare i dati e restituire il controllo al programma.

Un effetto collaterale dell’allocazione in banchi della memoria: si trattava di un ottimo sistema per nascondere un programma, dato che il programma non risultava visibile se la sua memoria non veniva allocata in un banco. Ecco perché BHP piazzava il suo codice nella memoria allocata.

Dopo essersi copiato nella memoria in banchi, il virus ripristinava il programma host alla sua posizione in memoria originaria e ripristinava la dimensione del programma ai valori originali. Questo permetteva al programma host di eseguirsi come se non fosse infettato. Tuttavia in questa fase il virus verificava il checksum del codice Basic del virus e se il checksum non corrispondeva, il virus sovrascriveva la memoria dell’host.

Una nota interessante sulla routine di verifica del checksum è che ignorava i primi tre byte del codice (ossia il numero di riga e il comando SYS): ciò facilitava il lavoro alla persona che avrebbe prodotto la variante successiva del virus. Malgrado la variante successiva differiva solamente per il numero di riga, questo fu sufficiente a battere il programma BHP-Killer, poiché BHP-Killer controllava l’intero codice Basic, compreso il numero di riga.

Il virus controllava se era già in esecuzione leggendo un byte di una specifica posizione in memoria. Se i valori corrispondevano, il virus assumeva che un’altra sua copia era in esecuzione. [...] Se non vi era una copia del virus già in esecuzione, il virus copiava una porzione di codice in un indirizzo basso in un’area di memoria non allocata, agganciando svariati vettori e puntandoli verso il codice copiato.

I vettori agganciati erano ILOAD, ISAVE, MAIN, NMI, CBINV e RESET. L’aggancio di MAIN, NMI, CBINV e RESET rendeva il virus immune dai comandi di interruzione Break, Reset e dalla combinazione Run/Stop-Restore. Tali agganci garantivano al virus di non perdere il controllo durante il riavvio della macchina. Una simile tecnica venne poi impiegata negli agganci Ctrl-Alt-Delete impiegati da virus successivi nella piattaforma IBM PC, e negli agganci Ctrl-Amiga-Amiga nella piattaforma Commodore Amiga.

Una volta effettuati gli agganci, il virus eseguiva il codice dell’host. Il codice principale del virus sarebbe stato invocato a ogni richiesta di caricare o salvare un file.

L’aggancio ILOAD veniva raggiunto quando occorreva effettuare ricerche su un disco. Ciò avveniva ogni volta che si richiedeva l’elenco di una directory, e poteva accadere quando si effettuava una ricerca utilizzando un nome file con caratteri jolly, oppure la prima volta che si accedeva a un file. Altrimenti, l’hardware del lettore salvava in cache fino a 2 KB di dati e li restituiva direttamente.

Il virus chiamava il gestore ILOAD originale, poi controllava se era stato caricato un programma infettato. In caso positivo, il virus ripristinava il programma host alla sua posizione in memoria originaria e ripristinava la dimensione del programma ai valori originali. Altrimenti, anche se non era stato caricato alcun file, il virus invocava la routine di infezione.

L’aggancio ISAVE veniva raggiunto a ogni salvataggio di un file. Il virus chiamava il gestore ISAVE originale per salvare il file, quindi invocava la routine di infezione.

La routine di infezione cominciava controllando che il dispositivo richiesto fosse un lettore di dischetti. In caso positivo, il virus apriva il primo file nella cache. Il primo file in cache sarebbe stato il file salvato se questo codice veniva raggiunto attraverso l’aggancio ISAVE, altrimenti sarebbe stato il primo file nell’elenco della directory. Se il file era un programma Basic, il virus effettuava un veloce controllo di infezione leggendo il primo byte del programma e confrontandolo con il comando SYS. Inizialmente il virus leggeva soltanto un byte poiché i lettori di dischetti erano dispositivi seriali nella piattaforma Commodore 64, e quindi molto lenti. Tuttavia, se il comando SYS era presente, il virus verificava l’infezione leggendo e confrontando fino a 27 byte successivi. Un file veniva considerato infetto se tutti i 27 byte corrispondevano.

Se un file non era infetto, il virus passava a leggere dati dalla cache hardware. Il primo controllo verificava la presenza del classico layout del disco: la directory doveva trovarsi sulla traccia 18, settore 0, e il file da infettare non doveva risiedere in quella traccia.

Se tutti questi controlli erano positivi, il virus controllava l’elenco di tracce alla ricerca di settori liberi. Iniziava con la traccia contenente il file da infettare per poi muoversi all’esterno in direzioni alternate. Questo riduceva gli spostamenti che doveva effettuare il lettore per leggere il file in un secondo momento, e si trattava di un’ottimizzazione molto interessante, dato che alcuni virus multi-sector boot sull’IBM PC inserivano il loro codice a fine disco, e ciò causava spostamenti del lettore facilmente identificabili (da un punto di vista acustico: il lettore iniziava a produrre rumori sospetti).

Se vi erano almeno otto settori liberi sulla medesima traccia, il virus allocava otto settori per sé e aggiornava la bitmap del settore per quella traccia. Il codice per aggiornare la bitmap del settore era bellissimo: allocava i settori e creava l’elenco dei numeri di settore allo stesso tempo. [...]

Il virus scriveva se stesso su disco in questo modo: il primo settore dell’host veniva copiato sull’ultimo settore allocato dal virus, poi quel primo settore veniva sostituito dal primo settore del virus. Dopodiché, il codice rimanente del virus veniva scritto sui settori allocati restanti. Qui era presente la directory stealth, ed era realizzata senza alcuno sforzo da parte dell’autore o degli autori del virus. Era un effetto collaterale del fatto che il virus non aggiornasse il conteggio dei blocchi nel settore della directory. Il conteggio dei blocchi non veniva usato dal DOS [l'autore si riferisce al Disk Operating System del Commodore 64, non al DOS dei PC IBM] per caricare i file — il suo scopo era puramente informativo.

Infatti lo stesso problema si presentava sul DOS della famiglia degli Apple II, e un tale virus sarebbe stato più facile da realizzare per quella piattaforma, dato che la comunicazione con l’hardware è molto più semplice negli Apple II. L’unico effetto evidente nel caso di BHP era che il numero di blocchi liberi su disco era visibilmente inferiore, dato che il valore veniva calcolato utilizzando la bitmap del settore, non l’elenco della directory.

Dopo qualsiasi chiamata a ILOAD o ISAVE, il virus verificava le condizioni di attivazione del payload, che erano le seguenti: a) la macchina doveva trovarsi in modalità ‘diretta’ (prompt dei comandi); b) il campo dei secondi del jiffy clock in tempo reale doveva essere un valore di 2-4 secondi; e c) la riga di scansione attuale del vertical retrace del monitor doveva essere almeno 128. Ciò rendeva l’attivazione un processo piuttosto casuale. Il payload doveva visualizzare un certo testo sul monitor, un carattere alla volta, cambiando in continuazione i colori del bordo.

Il numero seriale visualizzato era il numero di volte che veniva invocato il controllo del payload. A ogni chiamata, veniva incrementato di una unità, e si resettava al valore zero solo dopo 65.536 chiamate.

Adesso è chiaro: BHP era un virus molto avanti rispetto all’epoca.

Il virus BHP era grande soltanto 2.030 byte.

Sorta di appendice al post di ieri, volevo presentare alcuni stralci interessanti di uno studio/presentazione curato nel 1994 da Michael Culbert, allora System Architect di Apple (Informazioni e PDF).

Il documento illustra il percorso di design dell’architettura hardware e software e dimostra come uno dei fondamentali punti di convergenza sia proprio il risparmio energetico. Vengono spiegati i compromessi e le soluzioni adottati per raggiungere un equilibrio prestazionale che offra da una parte un’interfaccia sempre responsiva e pronta all’uso, dall’altra una serie di accorgimenti per ottenere bassi consumi quindi grande autonomia quindi grande affidabilità del dispositivo portatile (specie se consideriamo le forti garanzie di persistenza dei dati archiviati).

L’Abstract e l’Introduzione riassumono con efficacia:

Abstract

Il primo prodotto della linea Newton opera in un ambito estremamente limitato per quanto concerne prestazioni, costo, dissipazione del calore, consumo energetico, scalabilità, dimensioni e peso. Questa presentazione offre una panoramica dell’hardware di sistema del Newton MessagePad e si incentra sulle tecniche e i compromessi utilizzati per superare tali limiti. In particolare verrà trattata la migrazione sinergica di funzioni dall’hardware verso il software e viceversa.

Introduzione

La linea di prodotti Newton ha un obiettivo di primaria importanza: offrire all’utente un’interfaccia uomo-macchina fluida e semplice. Nessun utente del Newton dovrebbe rendersi conto di star utilizzando un computer. Gli utenti dovrebbero poter usare il Newton come fosse un foglio di carta. A mano a mano che la loro familiarità con il Newton aumenta, nuove e potenti applicazioni si renderanno visibili. Per conseguire questo obiettivo occorre considerare svariate scelte di design cruciali, non ultime quelle che riguardano dimensioni, peso, costo e consumo energetico. Il presente studio tratta specificamente il consumo energetico di hardware e software dell’attuale linea di Newton MessagePad.

Occorre notare che, essendo il documento del 1994, i MessagePad a cui Culbert si riferisce sono i primi che vennero prodotti fra il 1993 e il 1994, quindi l’Original MessagePad, il MessagePad 100, il 110 e forse anche il 120. Tutti erano dotati di processore ARM 610 RISC a 20 MHz. I MessagePad 2000 e 2100, introdotti nel 1996 e 1997, e con processore StrongARM SA-110 RISC a 162 MHz erano tutt’altra cosa dal punto di vista prestazionale e di consumo energetico, ma è lecito supporre che le premesse di design e le ottimizzazioni siano dello stesso tipo, seppur a un livello superiore.

Il processore

Nelle primissime fasi del processo di design fu chiaro da subito che occorrevano prestazioni paragonabili a quelle di un processore Intel 486 per poter fornire un’esperienza utente fluida e reattiva, visto l’ambiente software che avevamo iniziato a creare. Vennero valutati più di una dozzina di processori, [...] ma soltanto uno — lo ARM3 di Acorn Computers Limited (Regno Unito) — rispondeva a tutte le esigenze. Lo ARM3, tuttavia, non era un candidato perfetto: il processore non aveva una memory management unit (MMU) integrale e Acorn non aveva le risorse per svilupparne una. Apple si presentò ad Acorn e, in congiunzione con VLSI Technology Incorporated, fondò una nuova azienda chiamata Advanced Risc Machines, Limited (Regno Unito). Lo scopo di questa compagnia era fornire risorse di sviluppo per mantenere l’architettura ARM aggiornata e competitiva in questo nuovo scenario di mercato.

[...]

Il sistema energetico

La scelta del voltaggio per l’alimentazione di un dispositivo di questo genere presenta una serie di compromessi importanti dal punto di vista dei costi, delle prestazioni e del consumo. [...]

La scelta di uno schema a 5V ha avuto un impatto considerevole nella scelta delle batterie da impiegare. Per ottenere un’alimentazione a basso costo avevamo bisogno di un minimo di 4 celle. L’idea originaria di utilizzare pile AA non era più compatibile con il design fisico del prodotto. Dovevamo decidere fra aumentare le dimensioni del prodotto o ridurre ancora una volta l’autonomia delle batterie. L’utilizzo di pile NiCad di dimensioni AAA poteva continuare a soddisfare uno dei nostri obiettivi primari, ossia quello di fornire all’utente medio almeno una settimana d’uso continuato del prodotto; pertanto per il primo Newton vennero scelte batterie AAA.

La progettazione dell’alimentazione era complicata perché i carichi nel sistema variavano da un minimo di circa 10 mA quando il sistema era in stand-by, a un massimo di circa 400 mA nella situazione di maggior carico. Inoltre il carico poteva cambiare in modo praticamente istantaneo da uno stato inattivo di 10 mA a uno stato attivo di circa 180 mA. Il compito era progettare un convertitore a basso costo che potesse rivelarsi efficace in entrambi i casi. Siamo riusciti a ottenere un 85% circa di efficienza nello stato inattivo (10 mA) e più del 90% di efficienza nello stato attivo (180 mA). [...]

Come si può vedere, dietro alla catena di scelte e di compromessi vi è una considerazione di costi e risparmi, ma si cerca di non limitare eccessivamente l’efficienza e le prestazioni del dispositivo. In casi come questo la scelta non è tanto un bivio fra una soluzione A e una soluzione B, ma la creazione di una soluzione C che bilanci A e B (batterie più piccole in modo da rientrare nelle dimensioni pensate per il dispositivo, ma sufficientemente potenti da non offrire prestazioni degradate).

Risparmi energetici e l’interfaccia utente

Il display a cristalli liquidi (LCD), la tavoletta digitalizzatrice, e l’hardware per l’output audio compongono ciò che Apple definisce lo hardware dell’interfaccia utente. Questi elementi vengono scelti con cura e implementati in modo da fornire bassi consumi e facilità d’uso. L’interfaccia utente è il punto in cui si può maggiormente notare l’attenta interrelazione fra hardware e software in questo prodotto.

Quando la tavoletta digitalizzatrice è in uso, il sistema operativo effettua una scansione costante alla ricerca di coordinate sulla tavoletta, con una frequenza di circa 80 punti al secondo. La validità di un punto specifico viene determinata dinamicamente attraverso un metodo proprietario. Tale valutazione automatica evita che siano inviate coordinate errate (causate da più di un punto di contatto sulla superficie dello schermo durante la scrittura) ai livelli più alti del sistema per l’elaborazione. Anche l’area digitalizzata viene controllata costantemente. Se la penna passa in una zona dello schermo che non richiede un controllo preciso delle coordinate, la frequenza di campionamento della tavoletta viene rallentata a circa 10 punti al secondo. Tali aree dello schermo sono dinamiche e vengono definite automaticamente dall’architettura di visualizzazione del Newton. Ciò permette a chi sviluppa le applicazioni di avvantaggiarsi automaticamente di questo metodo di risparmio energia senza nemmeno conoscerne l’esistenza. I risparmi energetici derivati dall’impiego di tali tecniche sono significativi. La circuiteria della tavoletta consuma in media circa 17 mA e il 10% della CPU ARM quando è al massimo dell’attività. [...]

Anche lo stesso display LCD è un elemento importante nell’ottica dei risparmi energetici del MessagePad. In un classico sistema LCD, vi è un controller LCD che utilizza una propria RAM oppure accede alla memoria di sistema principale. Il controller LCD poi guida un orologio ad alta frequenza e un flusso di dati ai driver di righe e colonne sul display LCD. Questo porta a un sistema LCD che può consumare più di 100 mW solo per visualizzare un’immagine statica. Nel MessagePad, i frame buffer LCD sono integrati nei driver di righe e colonne del display LCD. [...] Il risultato finale è un pannello LCD che consuma meno di 5 mW per visualizzare un’immagine statica. [...]

Per finire, un altro elemento di design essenziale per la realizzazione di un dispositivo portatile di questo tipo: l’archiviazione e la conservazione dei dati. Quando ci si trova in movimento bisogna poter spegnere o mettere in stop il dispositivo in ogni momento, oppure considerare imprevisti come l’esaurimento delle batterie e la conseguente interruzione di un lavoro senza temere per l’integrità delle informazioni se il dispositivo si spegne prima che sia possibile salvare i progressi.

Robusta archiviazione dei dati

Anche la robustezza del sistema è un elemento di cruciale importanza in un dispositivo in cui si archiviano dati sensibili. L’utente può, ovviamente, togliere e sostituire le batterie dal sistema in qualunque momento. Il sistema deve essere in grado di ripristinarsi dopo un tale evento senza perdita alcuna di informazioni personali.

È pertanto necessaria la creazione di un database che possa sopportare l’interruzione delle operazioni in qualsiasi momento senza subire danni. Il MessagePad incorpora un completo database transazionale e orientato agli oggetti. Con tale sistema è impossibile perdere dati archiviati nell’object store permanente, a meno che non venga rimossa anche la batteria di backup della memoria.

A chi conosce l’inglese suggerisco la lettura integrale del documento originale, che è scritto in un linguaggio tecnico ma non eccessivamente astruso. È impressionante notare il diagramma di flusso delle scelte di design che hanno contribuito alla formazione di un prodotto, il Newton, che ha avuto sì poca fortuna commerciale, ma che è e rimane una lezione fondamentale di progettazione hardware/software per un dispositivo portatile.

In uno dei suoi post più recenti, Questi erano netbook, Lucio esalta la grande autonomia di due dispositivi portatili da lui usati in passato, un Cambridge Z88 e un Newton MessagePad 2100. Come ho accennato in un mio commento a quel post, a mio avviso il confronto fra quei dispositivi (il primo ha vent’anni, il secondo dieci) e gli attuali netbook non deve essere inteso come un parallelo fra mere specifiche tecniche e prezzi di listino. Se così fosse, è ovvio che i netbook moderni vincerebbero senza problemi.

Ciò che forse vuole dire Lucio — e ciò che sicuramente intendo dire io — è che quei dispositivi ormai vintage e dalle caratteristiche tecniche risibili per gli standard di oggi, hanno moltissimo da insegnare su quali compromessi attuare e su come pensare al design di un dispositivo che nasce per essere portatile e affidabile.

Che cosa rende appetibile un netbook attuale? Il prezzo. È quindi il prezzo a dettare legge nella progettazione e realizzazione di uno di questi sub-computer. Quindi piccole dimensioni, piccole tastiere, piccoli trackpad, piccoli schermi, processori meno veloci e meno avidi di risorse, materiali di costruzione economici, qualità dei componenti media, e batterie che fanno quello che possono. Qualsiasi eccezione farà aumentare il prezzo. I netbook più belli — perché hanno maggiore potenza, o uno schermo più luminoso o a maggiore risoluzione, o materiali migliori, o una tastiera usabile, ecc. — costano di più.

Prezzo e buona qualità sono però due parametri inconciliabili. Se è il prezzo a dettare legge, la serie di compromessi che ne deriva finisce ben presto con lo svantaggiare il prodotto finale. Il prezzo costringe a rinunce praticamente su ogni fronte. Sacrifica questo, sacrifica quello, e il risultato è sì un prodotto da 300 Euro più portatile di un computer portatile standard, ma la raggiunta ultraportatilità va a scapito di una serie di fattori da non trascurare: scomodità di tastiera e trackpad ridotti, scomodità di uno schermo spesso troppo piccolo ovvero con un rapporto densità/dimensioni sfavorevole (schermo da 7-10 pollici + alta risoluzione = icone testo ed elementi di interfaccia minuscoli), usabilità discutibile, un’integrazione fra hardware e software non sempre efficiente, e infine un’autonomia che dovrebbe essere maggiore considerando la varietà di sacrifici apportati ai netbook, e che invece non è.

C’è chi si accontenta di un prodotto così, e non discuto. La parola chiave è però ‘accontentarsi’.

La mia tesi è che gli attuali netbook potrebbero essere prodotti migliori se i costruttori operassero una serie differente di compromessi. Per esempio, nessuno o quasi sembra partire dal software e dall’interfaccia utente. La stragrande maggioranza dei netbook sono concepiti per funzionare come normali computer ma in forma ‘concentrata’ e assai di rado vengono davvero ottimizzati per fare bene una serie ristretta e precisa di compiti. Pensiamo a quando visitiamo un sito Web con MobileSafari su iPhone: confrontiamo la versione standard del sito e quella ottimizzata per lo schermo di iPhone. Quale delle due sarà più efficiente e usabile? Torniamo ai netbook e sostituiamo ’sito Web’ con ’sistema operativo’. Meglio un Windows XP e applicazioni derivate che trattino un netbook con schermo da 9 pollici e processore da 1 GHz come fosse un computer da scrivania normale, o un sistema operativo ‘ridotto’ e ottimizzato per quello schermo, per quella famiglia di processori, per gestire le risorse in maniera più economica e far quindi risparmiare energia al dispositivo e aumentarne l’autonomia?

Invece no: il netbook deve anzitutto costare poco, e cercare di fare tutto, non importa quanto bene. Evidentemente, quando il prezzo è l’unità di misura, anche la ricerca & sviluppo e il marketing sono quelli che sono.

Tornando al Newton e al Cambridge Z88, nessuno dei due era e voleva essere un computer completo. Entrambi erano dispositivi incentrati sulla portabilità e ottimizzati per svolgere con relativa agilità una serie di compiti lontano dal proprio computer principale. Il lavoro fatto in viaggio o in movimento poteva poi essere trasferito, se lo si desiderava, sulla macchina principale. Vi era quindi una componente ‘gregaria’, dipendente, e questo limite apparente era a mio avviso il punto di forza di tali dispositivi, del Newton in primis.

Sul Newton non girava il Mac OS né aveva uno schermo a colori (e nei primi MessagePad non vi era nemmeno la retroilluminazione), ma per svolgere i compiti di assistente personale digitale non era necessario. Per gestire note, documenti, appuntamenti, email e fax, leggere e-Book, ecc., basta uno schermo a scala di grigi — è un compromesso accettabile e funzionale. Che forse potrebbe funzionare anche oggi sui netbook: meglio uno schermo a colori o uno schermo leggibile, ben contrastato, che faciliti la lettura e scrittura di messaggi email, siti Web, e quant’altro? “Eh, ma le foto… i video…”. Beh, uno non si mette a fare del fotoritocco serio su un netbook, e i video si vedono comunque meglio su schermi più grandi (e consumano risorse CPU e batteria).

Con un sistema operativo ottimizzato e orientato al risparmio energetico come punto di partenza, ecco che il processore e la scheda grafica si ritrovano con un carico di lavoro minore e possono compensare sotto il profilo della responsività. Possono essere più efficienti a parità di prestazioni, consumare meno, e contribuire ad avere un netbook che dura più a lungo. (Riuscire a realizzare un netbook che potesse alimentarsi con normali pile alcaline o ricaricabili e durare settimane, non ore, sarebbe il non plus ultra, ma dati i consumi dell’hardware e software moderni, mi pare un traguardo alquanto improbabile). Partendo da questo genere di compromessi è forse possibile arrivare allo stesso obiettivo, quello di avere un computer ultraportatile a un prezzo competitivo, e con i vantaggi dati da un’interfaccia e da un sistema forse meno completi e attraenti, ma più efficaci e usabili. Il netbook nasce come seconda o terza macchina — se si comportasse come tale sarebbe ancora meglio.

Nota: questo pezzo è stato originariamente concepito come un unico articolo che avrebbe integrato la traduzione di parti dello studio del 1994 Low Power Hardware for a High Performance PDA a cura di Michael Culbert, allora System Architect in Apple. Ma sarebbe diventata una lettura lunghissima e complessa. Ho deciso quindi di dividere l’articolo in due parti e di dedicare la seconda parte allo studio citato, che è un ottimo esempio dei compromessi e delle scelte di design architettonico effettuati per rendere il Newton un dispositivo potente, versatile e dai consumi contenuti.

Sistemando i miei archivi, mi sono imbattuto in questa immagine che scaricai da Internet tempo fa. È un annuncio pubblicitario di Compaq della metà degli Anni Ottanta. In piena strategia di marketing comparativo, il prodotto in questione — una nuova serie di personal computer portatili — viene messo a confronto con i prodotti di punta della concorrenza a quel tempo. È interessante notare come il copywriting sia molto in stile Apple. Anche lo slogan sotto il logo Compaq — “Semplicemente, funziona meglio” — potrebbe benissimo essere applicato al Mac (e infatti oggi uno dei tanti slogan usati da Apple per il Mac è It just works, ossia “Semplicemente, funziona”.

Le didascalie — sotto il PC IBM: Difficile da trasportare; sotto il PC portatile: Difficile da leggere; sotto il Macintosh: Difficile da espandere; sotto il Compaq portatile: Difficile da battere.

Il messaggio:

In un confronto di funzionalità, è difficile battere i computer COMPAQ Portable e COMPAQ Plus. Per una ragione molto semplice. Mentre gli altri accettano dei compromessi, COMPAQ produce personal computer portatili che possono svolgere lo stesso lavoro di un computer da scrivania. E molto di più.

Se paragonati all’IBM PC, per esempio, i portatili COMPAQ possono eseguire gli stessi programmi aziendali più diffusi, possono utilizzare le medesime stampanti, hanno una capacità di archiviazione espandibile fino a essere più di 30 volte maggiore. E inoltre hanno una maniglia.

Se paragonati ad altri computer portatili, i prodotti di COMPAQ offrono di più, ancora una volta. Più memoria, più capacità di archiviazione. Una tastiera standard. Drive floppy standard, così da poter utilizzare subito, senza modifiche, qualsiasi programma. Per non parlare di uno schermo luminoso, ad alta risoluzione, che visualizza testo più immagini grafiche contemporaneamente. Non uno schermo con cui giocare al gioco del cucù.

Se paragonati al Mac, i computer COMPAQ vi permettono di aggiungere un secondo drive floppy, o addirittura un disco fisso da 10 megabyte. Dentro, non fuori. Per non parlare del fatto che noi di COMPAQ parliamo la Lingua Madre del Business e il Mac no.

Con un computer COMPAQ robusto e completo di funzioni non dovrete compromettere le capacità, la compatibilità o la leggibilità a vantaggio della portabilità.

COMPAQ – ”Semplicemente, funziona meglio”.

In questo articolo parlavo del cosiddetto ‘bug del 2010′ che rappresenta un serio inconveniente per la piattaforma di dispositivi Newton (fuori produzione da più di un decennio ma mai obsoleti!). Sempre nell’articolo menzionavo il buon Eckhart Köppen, che si sta facendo carico di analizzare il problema e di lavorare a una soluzione.

Köppen sta decisamente facendo passi avanti in tempi piuttosto brevi. In un messaggio apparso nella lista NewtonTalk lo scorso 8 marzo, Köppen annuncia Y2010 Diagnostic, un nuovo software di diagnostica che analizza gli allarmi, appuntamenti, e gli eventi ricorsivi che abbiamo già impostato nei nostri Newton, e che dovrebbe chiarire che cosa può andare storto in futuro se non viene applicata la patch:

L’applicazione permette anche di eliminare tutti gli allarmi attualmente impostati. Questa funzionalità modifica i dati, pertanto fate attenzione e pensateci bene prima di decidere di eliminare tutti gli allarmi dagli eventi che avete già impostato. Se li eliminate per sbaglio, dovrete reinserirli manualmente uno per uno. Siete stati avvertiti.

Se il vostro Newton è afflitto da un allarme in loop infinito, potete provare a lanciare l’applicazione Y2010 Diagnostic e utilizzarla per risolvere la situazione.

Nello stesso messaggio, Köppen fa sapere di essere a buon punto nella creazione della patch che sistemerà il bug del 2010:

Un’ultima cosa a riguardo del fix vero e proprio: a questo punto non terrei installato Fix2010 [l'utility di Avi Drissman]. Ormai mi ritrovo con la maggior parte dei pezzi di basso livello per realizzare una vera patch e li sto utilizzando da un certo tempo; la parte più importante che ancora manca è cosa fare con gli allarmi al momento ancora attivi (naturalmente la cosa più semplice è eliminarli e applicare la patch al Newton). In ogni caso il problema dovrebbe essere ampiamente risolto molto prima del 2010.

Inutile dire che sono orgoglioso di far parte della comunità Newton. È nei tempi difficili che salta fuori il carattere di una comunità.

Come accennavo nella prima parte della mini-serie sulla storia del Newton, il problema più grosso che affligge oggi la comunità di utenti Newton è il cosiddetto ‘bug del 2010′. Questo problema si riteneva pressoché risolto, dato che tempo addietro Avi Drissman (programmatore noto alla comunità Newton soprattutto per l’ottimo Avi’s Backdrop, un’elegante applicazione per la ’scrivania’ del Newton che consuma pochissime risorse) aveva rilasciato un programma chiamato Fix2010 (vedere la pagina del sito di Drissman dedicata al software per il Newton). Il programma, però, è tuttora in alpha, e dopo che alcuni membri di NewtonTalk si sono presi la briga di installarlo e collaudarlo si è constatato che non è risolutivo e, almeno sui MessagePad con l’ultima versione del NewtonOS (2.1), i problemi rimangono.

Eckhart Köppen, uno degli sviluppatori Newton rimasti ancora molto attivi (è autore, fra le altre cose, di un browser, di un lettore di RSS, e di una serie di plug-in per il Newton che ne espandono le possibilità — senza di lui non avremmo il Bluetooth sul Newton), ha deciso di investigare il problema e ne parla in questa pagina del suo sito. Eccone una traduzione:

Il problema dell’anno 2010 nel Newton

Il NewtonOS presenta un bug nella gestione degli anni a partire dal 2010. Il bug si trova nell’interfaccia NewtonScript inerente a determinate funzioni temporali, ed è provocato da un overflow di un valore intero di NewtonScript. Tale bug sembra manifestarsi soltanto in dispositivi con NewtonOS 2.1.

L’orologio del Newton

Nei dispositivi 2.1, il Newton prevede un orologio in tempo reale ad alta risoluzione (RTC – Real Time Clock). L’interfaccia verso il RTC è la classe TURealTimeAlarm in LongTime.h. I valori temporali vengono registrati in oggetti della classe TTime. Il RTC può gestire intervalli di tempo molto lunghi, ma la maggior parte delle funzioni utilizzano numeri interi non firmati a 32 bit come secondi a partire dall’1 gennaio 1904.

Classi e Funzioni

C++

Le funzioni C++ più comuni sono le funzioni RealClock e RealClockSeconds per leggere il RTC, e le funzioni SetRealClock e SetRealClockSeconds per impostare il RTC. La base per tutte queste funzioni è sempre l’1 gennaio 1904, e la risoluzione è in minuti o secondi. L’uso di un numero intero non firmato a 32 bit crea un problema di overflow nell’anno 2040. In generale, si possono considerare tutte le funzioni C++ sicure e senza problemi fino al 2040.

NewtonScript

Le funzioni NewtonScript sono tutte basate sul RTC — non esiste un orologio mantenuto separatamente per il livello del NewtonScript. Tali funzioni si basano sulle funzioni RealClock descritte sopra, e funzionano con risoluzione in minuti o secondi.

La funzione Time funziona con una base temporale incentrata sull’1 gennaio 1904. La funzione TimeInSeconds, e tutte le funzioni che utilizzano i secondi come risoluzione si servono di una base temporale che parte dall’1 gennaio 1993.

Il bug

L’overflow avviene in tutte le funzioni NewtonScript che utilizzano i secondi come risoluzione. A differenza del numero intero non firmato a 32 bit impiegato dalle funzioni C++, gli interi in NewtonScript sono soltanto a 30 bit. Mentre le funzioni C++ possono gestire l’intervallo fra il 1904 e il 2040 senza un overflow, le funzioni NewtonScript devono essere ideate con un intervallo minore a causa della loro limitata precisione.

Le funzioni basate sui secondi vengono implementate prendendo il valore dell’orologio in tempo reale (RTC), sottraendo lo spostamento all’1 gennaio 1993, e convertendo il risultato in un numero intero NewtonScript. Questo intervallo più ristretto e limitato provoca un overflow nel 2010.

I possibili fix

Riformulare una base per le funzioni temporali basate sui minuti

Il problema di un overflow nelle funzioni basate sui secondi è provocato dall’orologio di sistema che raggiunge e supera la data dell’overflow. Assicurandosi che l’orologio di sistema rimanga all’interno dell’intervallo ’sicuro’, è possibile evitare l’overflow. Questo tipo di soluzione è stato implementato da Avi Drissman nel pacchetto Fix2010. Fix2010 impiega il concetto della ‘hexade’ (ossia 16 anni) e regola tutte quelle funzioni che si servono dei minuti come base temporale in modo che rientrino sempre nell’intervallo di tempo ’sicuro’, tenendo conto della differenza di intervallo del gruppo di sedici anni.

Riformulare una base per le funzioni temporali basate sui secondi

Un approccio più a basso livello è quello di cambiare la compensazione impiegata dalle funzioni basate sui secondi in modo che l’intervallo di tempo ’sicuro’ inizi e finisca più tardi.

Considerazioni

Per ognuna delle soluzioni, occorre tenere in considerazione alcune insidie. Le parti del NewtonOS non sistemate potrebbero attivarsi prima che la patch entri in funzione (per esempio al riavvio o dopo un cold boot), e certi dati potrebbero presentare dei valori errati. Per ora rimangono aperte le seguenti problematiche:

• Lo stato dell’orologio dopo la perdita del tempo: l’orologio in tal caso si resetta e torna al 1996, e questo valore può entrare in conflitto con le funzioni a cui è stata applicata la patch.
• Gli allarmi: gli orari in cui è stato impostato un allarme potrebbero essere alterati se l’allarme è stato inserito senza la patch.
• Certe assunzioni precodificate inerenti alle basi temporali: quei programmi che presumono che le funzioni basate sui secondi inizino sempre nel 1993 potrebbero smettere di funzionare.

È interessante inquadrare tutta la questione alla luce delle osservazioni dell’ex ingegnere Newton che ho pubblicato nelle quattro parti sulla storia del Newton. È chiaro che per applicare una simile patch occorre effettuare un reverse-engineering dell’ultima patch di sistema, che è quel che ha fatto Köppen qualche giorno fa, scrivendo in lista NewtonTalk: Pare che creare delle patch proprie sia meno complicato di quel che si pensava. [...] Sono stato in grado di ricreare la patch originale [717260] dai sorgenti e fare qualche esperimento con piccole modifiche. Esistono ancora dei problemi da risolvere, ma in generale è di certo meno magia nera di quanto anticipato. In bocca al lupo, Eckhart. Documenterò eventuali risoluzioni.

Eccoci giunti alla quarta e ultima parte di questo — mi auguro interessante — excursus su alcuni aspetti poco noti della storia del Newton. La premessa che ha portato a questo lavoro in quattro parti è descritta nel primo post. Ho naturalmente qualche osservazione da fare in conclusione, ma dato che sto ancora organizzando le idee, e per non allungare troppo questo post, ho deciso di scrivere un articolo distinto, che spero di poter pubblicare già domani o lunedì.

I MessagePad 120 e 130

Autore: Ex Newton OS Engineer
Data: 05/04/99

I MessagePad 120 con il sistema in lingua tedesca, che sono stati prodotti in minor quantità, hanno in realtà la ROM del MessagePad 130 al loro interno, e la ROM rileva automaticamente le piccole differenze fra le due unità. Gli aggiornamenti di sistema del Newton sono sviluppati in modo da essere specifici per ogni tipo di ROM, e non per ogni tipo di modello (per esempio, i MessagePad 2000 e 2100 hanno la stessa identica ROM), e alcune delle patch nel MP2100 effettuano un rilevamento della dimensione della RAM, poiché è l’unica cosa che differenzia quei due modelli. Un MessagePad 130 è praticamente uguale a un MessagePad 120, le uniche differenze sono un maggior quantitativo di memoria e la retroilluminazione, tuttavia un MP120 non è aggiornabile per trasformarlo in un 130, dato che una piccola revisione alla scheda logica principale del MP120 portò alla creazione del MP130 affinché fosse possibile gestire i chip della memoria aggiuntiva. [...]

Applicare patch al Newton OS

D: Sarebbe possibile effettuare questo tipo di sviluppo con un MessagePad 2100 con le impostazioni di fabbrica e un Mac?

R: Beh, sì, la maggior parte dello sviluppo del MP2000 è stato svolto utilizzando prototipi di MP2000 invece dei cosiddetti “prototipi Bun warmer”. Apple smise di costruire i Bun warmer dopo la produzione del MessagePad 120 perché costavano troppo (3.000 dollari l’uno). Sulla scheda figlia della ROM i prototipi del MP2000 avevano la tecnologia Flash invece della ROM mascherata, e il MP2000 può a tutti gli effetti programmare ‘flashando’ la ROM incorporata attraverso la GeoPort (a 1 Mbit al secondo). Questo è stato fatto servendosi della versione più recente del debugger interno Hammer, oppure con uno strumento chiamato NewtFlasher (se non ricordo male); alcuni sviluppatori ricevettero tali strumenti sotto un accordo di non divulgazione. Flashare la ROM non è un procedimento semplice né infallibile, però, perché parte della ROM deve poter funzionare per essere in grado di interagire con il debugger e caricare l’immagine nuova e programmarla senza danneggiarsi. Durante lo sviluppo era importante collaudare sempre la ROM prima di flasharla in un palmare, perché se la nuova ROM fosse stata davvero corrotta, la successiva avrebbe potuto non essere mai installabile, e ciò comportava lo smontaggio dell’unità e il flashare la scheda figlia della ROM esternamente.

Pertanto lo sviluppo fu effettuato utilizzando un dispositivo palmare per flashare la ROM e un PowerMac con MPW, NTK e un build system che girava sotto MPW. Io ho sviluppato, mantenuto e gestito il Build Server system nel Newton Group; era chiamato Autoserver e tutto il software della ROM fu realizzato con 27 Quadra 950 e alcuni prototipi “Bun warmer” che collaudavano le immagini ROM prima di permettere l’accettazione di modifiche ingegneristiche all’interno della base del progetto sorgente e di distribuire le modifiche ad altri ingegneri del team.

D: Di che cosa avrei bisogno per trasformare il mio codice in una patch del sistema operativo applicabile da altri?

R: Non so come tu abbia portato avanti lo sviluppo, ma immagino tu abbia impiegato i Newton C++ Tools per Macintosh. Oppure hai soltanto un algoritmo sperimentale che gira su un desktop? O hai usato NTK? Ti suggerisco di creare un’applicazione completa e distinta e di lasciar perdere la creazione di una ‘patch’ del Newton OS.

Un Newton System Update o ‘patch di sistema’ è un insieme complesso e mescolato di tabelle MMU, 40-70 ‘fix’ in assembler tutti riuniti in una serie ordinata di pagine RAM da 4 KB. Costruire e collaudare un System Update è un processo complesso e costoso e non è fattibile da un solo ingegnere. Il Newton OS supporta soltanto una patch di sistema, pertanto tutti i fix già prodotti e gli eventuali fix nuovi devono essere combinati e riuniti per creare il System Update successivo. Il Newton OS è molto insolito sotto questo aspetto: è come se il Mac OS supportasse e permettesse solamente una estensione invece di un’intera cartella di estensioni.

Non è possibile fare questo ‘come una patch di sistema’; Apple è l’unica ad avere gli strumenti per costruire un nuovo System Update e tutti gli ingegneri che sanno come eseguire il lavoro non lavorano più in Apple (come me), anche se forse c’è ancora un dipendente che potrebbe realizzare un tale aggiornamento se avesse tempo sufficiente.

Una nuova GC in NewtonScript [GC sta per Garbage Collection] difficilmente si potrebbe completare e collaudare senza i sorgenti ROM. Le prestazioni di moltissimi elementi nel sistema operativo cambiano se la GC è compromessa, e non si ha idea di quanto il sistema possa essere sensibile alle modifiche. ‘Velocizzare’ la GC probabilmente avrebbe effetti secondari negativi imprevedibili e potrebbe compromettere a sua volta tutta una serie di cose. Far sì che la GC venga effettuata nel momento sbagliato potrebbe avere lo stesso tipo di conseguenze nefaste per il Newton OS. Se si è in grado di ingegnerizzare una nuova GC per il Newton OS senza documentazione e senza i sorgenti, il mio consiglio è di farsi assumere come programmatori da qualcuno che pagherà molto bene un lavoro del genere.

E un nuovo OS per il Newton?

Autore: Ex Newton OS Engineer
Data: 07/04/99

Beh, tecnicamente è possibile scrivere un nuovo sistema operativo per l’hardware dei MP2000/MP2100, ma dato che essenzialmente l’intero design hardware non è di pubblico dominio, dubito che questo possa accadere senza una richiesta ad Apple di pubblicare la documentazione.

Inoltre è necessario avere compilatori, linker e assembler ARM, e un sistema di sviluppo in cui farli girare. Ho l’impressione che una versione Linux dei Tools di ARM Ltd sia l’unico approccio pratico.

Il chipset Cirrus Logic è di fatto il MP2000/MP2100. Fu un insieme di chip mal progettato: i cicli di RAM impiegano 7 ‘tick’ del clock del bus! E il processore gira sette volte più veloce rispetto al bus. Solo che, se non ricordo male, quei chip non sono disponibili a livello commerciale.

Decisamente ad hoc

D: Quanta parte dell’hardware dei MessagePad è proprietaria e adattata, senza documentazione al di fuori di Apple?

R: Essenzialmente il 95%. Il chipset Cirrus (4 chip) è praticamente tutto l’hardware tranne la CPU, la ROM, la tecnologia Flash, la RAM, l’I/O audio, i driver della porta seriale e infrarossi, e l’alimentazione.

E naturalmente è il 95% più importante.

Sicuramente qualcuno avrà già smontato un MP2×00 e avrà fotografato le schede logiche principali (da entrambi i lati). È un’operazione semplice da fare ed è il sistema migliore per analizzare l’architettura hardware.

Non basta avere un ‘kernel’ per avere un sistema operativo. Senza driver, un toolbox, un application runtime model, un’interfaccia utente, un ‘Finder’ o una simile applicazione per lanciare i programmi, non si ha in mano niente di utile.

Continua questa piccola parentesi a puntate sulla storia del Newton. Avevo pensato a tre parti, ma il materiale è maggiore di quanto pensassi e c’è molta carne al fuoco, pertanto vi sarà anche una quarta parte che spero di pubblicare domani. Per contestualizzare il testo che sto traducendo e presentando qui, è essenziale leggere la prima parte. Le mie osservazioni e integrazioni all’interno del testo citato sono in corsivo fra parentesi quadre.

Autore: Ex Newton OS Engineer
Data: 05/04/99

Espansioni difficili

6. Sono l’autore dei Newton C++ Tools per Macintosh, e dato che il compilatore ARM C++, l’assembler e il linker che avevamo a disposizione erano tutti strumenti MPW, e che non esiste un ambiente ’standard’ per tool sui sistemi Windows a cui questi tool potevano agganciarsi, non fu mai realizzata una versione Windows dei Newton C++ Tools. Fu discussa, perché alcuni sviluppatori ne fecero richiesta, ma niente più. Mi pare che alcuni dei DDK [Driver Developer Kit o Device Developer Kit] fossero disponibili fino a marzo del 1998 sotto NDA [accordo di non divulgazione], ma si basavano ugualmente su MPW. Probabilmente avremmo potuto intraprendere un porting verso Linux di tutto questo materiale e sarebbe stato un percorso migliore, ma non fu vista come ipotesi fattibile dall’amministrazione o dai tizi del marketing, che cercavano sempre di creare ‘prodotti’ da vendere, non software gratis.

7. Non venne mai creato un modem interno. Sì, esiste un connettore interno che potrebbe essere portato fuori come seconda porta seriale con soltanto il chip driver RS 422 I/O, ma i controlli necessari per la redirezione e la loro verifica per tutti gli usi desiderabili dall’utente non furono mai implementati nel sistema operativo, né sottoposti a debugging. Non è sufficiente avere soltanto l’hardware. Per servire a qualcosa, i prodotti per sistemi informatici devono avere tutti i layer al loro posto; l’hardware è il livello più semplice da ‘vedere’ e comprendere. Il che spiega perché alcuni — che non sono ingegneri di sistema — pensano “ah, ma è facile, basta aggiungere una scheda logica, un chip per il driver e il connettore e funzionerà”. Tempo fa su questo forum qualcuno disse che avrebbe realizzato una scheda per l’adattatore, e ricordo di aver letto molti messaggi riguardanti foto e hack che alcuni nerd erano riusciti a far funzionare, per poi scoprire la mancanza del supporto software.

Per chi non lo sapesse, è stata poi creata una scheda per aggiungere una porta seriale del tutto identica a quella in uso sui Mac beige, ossia RS 422. Nella comunità Newton questa scheda è nota come SER-001. È possibile vedere la scheda installata in un MessagePad 2×00 in questa foto (trovate altre foto interessanti esplorando l’intero set). La controversia a cui si riferisce la didascalia della foto riguarda il progetto e la creazione di questa scheda. Le versioni dei fatti sono sostanzialmente due: a) il prototipo fu creato da ‘PCBMan’ e venne poi copiato e commercializzato da ‘Knowledge Navigator’ (sono ovviamente due nickname); b) ‘PCBMan’ e ‘Knowledge Navigator’ hanno sviluppato indipendentemente la stessa idea e hanno prodotto ognuno la propria versione della scheda; la grande somiglianza fra le due schede sarebbe dovuta a ragioni intrinseche all’hardware del Newton.

Io ho la fortuna di aver ricevuto un Newton MessagePad 2100 con la SER-001 già installata, e funziona egregiamente. Dico ‘fortuna’ per due motivi. Primo: questa scheda non viene prodotta industrialmente e ormai non ce ne sono molte in circolazione; in più non è facile installarla da soli. Secondo: la grande comodità di avere la SER-001 incorporata è l’eliminazione del famigerato ‘dongle’ per effettuare connessioni con il Mac via cavo seriale. Il dongle non è altro che un adattatore che da un lato si inserisce nella porta Interconnect del Newton (se osservate di nuovo la foto del link precedente, la porta Interconnect è quella piatta, quasi simile a una USB, accanto alla porta seriale della SER-001) e dall’altro offre una porta seriale RS 422. Il dongle è indispensabile per collegare il Newton al Mac via seriale, ed essendo un oggetto abbastanza piccolo, è anche facile perderlo. Una scheda SER-001 installata elimina la necessità del dongle e ogni preoccupazione.

Emulare il Newton OS

8. [Probabilmente il nostro Ex Newton OS Engineer risponde a qualcuno che gli aveva chiesto se potesse creare un emulatore del Newton]. Potrei, ma sono un ingegnere software e faccio questo per mestiere, non per hobby. [...] Un emulatore Newton deve emulare non soltanto il processore ARM, ma tutte le funzioni specializzate della MMU [Memory Management Unit] dell’ARM e l’hardware adattato per DMA, IR, schede Flash, schermo, eccetera eccetera. Non è un lavoro facile. La mia stima (e ho un’esperienza trentennale in ingegneria di software e sistemi) è che si tratti di un’impresa di cinque anni-uomo. Tentare una simile avventura senza una documentazione dettagliata dell’hardware di un MessagePad 2000 porterebbe quasi certamente al fallimento.

Mi sembra comunque un’impresa inutile, perché troppe parti del Newton OS erano molto specifiche e legate alle funzioni della CPU e MMU del processore ARM, nonché all’hardware modificato e adattato allo scopo. Apple cercò più di una volta di realizzare un ‘Newton Virtuale’ come progetto secondario all’interno del Newton Group, ma tale progetto non venne mai finanziato né portato avanti davvero. L’ultimo hack fu opera di Greg Christie, che riuscì a far funzionare sotto Mac OS l’Interprete NewtonScript, ma tralasciando tutto l’hardware di basso livello come il supporto per la rete e per l’I/O seriale, per cui il risultato assomigliava più a un NewtonScript/Mac OS che a un Newton OS.

A mio avviso sarebbe stato più interessante implementare un nuovo sistema operativo ‘libero’ per palmari utilizzando il modello di Java/JWT, dato che molti dei vantaggi di NewtonScript/Newton OS sono presenti in Java. Ritengo inoltre che sia relativamente semplice ‘clonare’ il design dell’interfaccia utente del Newton, ovvero creando un ‘Finder’ palmare e un gruppo di librerie di classe per eguagliare gli aspetti migliori del Newton toolbox. Direi che utilizzando Java e un JWT specializzato per piattaforma palmare avrebbe più possibilità di successo e attirerebbe un tipo di collaborazione più in stile GNU, che non il preservare un sistema operativo proprietario abbandonato.

Paul Guyot, in circa quattro anni di lavoro (2004-2007), ha messo a punto Einstein, un emulatore del Newton OS che gira su altre piattaforme, fra cui Mac OS X (PPC e x86), Windows, Linux. Prima il software era scaricabile dal suo sito, ora è stato pubblicato su Google Code, a questo indirizzo. A meno che non sia cambiato qualcosa nel frattempo, per poter utilizzare Einstein occorre possedere un Newton e fare il dump della ROM originale. Il processo è abbastanza lungo se fatto via seriale (io provai tempo fa, ma dopo aver lasciato il Newton collegato via seriale al mio iBook per sei ore decisi di abbandonare, credendo che l’applicazione per effettuare la copia della ROM fosse andata in crash. Fu Guyot stesso a dirmi che in realtà il processo poteva durare parecchie ore).

Einstein non è completo, e determinate funzioni del Newton non sono ancora supportate. Riporto dalla sezione Problemi conosciuti del manuale di Einstein:

• Le porte seriali non sono emulate.
• Le schede PCMCIA non sono emulate.
• Il volume appare regolabile via software ma i cambiamenti vengono ignorati (tranne quando il suono è spento sul Newton).
• L’input audio non è emulato.
• Il tentativo di installare patch di sistema provoca un errore.
• I tasti non vengono tradotti in maniera appropriata a eccezione che sul Mac (la tastiera è inutile).
• La rotazione [dello schermo] non sempre funziona correttamente.
• Su altri PDA con processore ARM, Einstein è mostruosamente lento.

Ho visto Einstein in azione su un PowerBook G4 e, malgrado i problemi elencati, è un’esperienza affascinante e il lavoro di Guyot è stato incredibile. Al momento il progetto Einstein sembra dormiente, ma altri sviluppatori sono coinvolti e speriamo si muova qualcosa in futuro.

Ecco la seconda parte di questo piccolo viaggio dietro le quinte della storia del Newton. Per contestualizzare il testo che sto traducendo e presentando qui, è essenziale leggere la prima parte. Le mie osservazioni e integrazioni sono in corsivo fra parentesi quadre.

Un bug misterioso

2. [In risposta a una domanda su un qualche strano bug del Newton]. Qualche tentativo per risolvere il problema venne fatto, ma i ‘veri’ ingegneri che si occuparono del kernel avevano già lasciato Newton/Apple quando il bug iniziò a manifestarsi, e il personale rimasto (me compreso) non era abbastanza motivato e/o non era in grado di isolarlo. Dagli ultimi lavori compiuti in questa direzione, pare che il bug fosse molto difficile da riprodurre e che il problema fosse nel modulo Flash “demand pager” nel kernel a basso livello. Apparentemente, una combinazione molto complessa di azioni, insieme a un’intensa attività di paging, alla fine provocava un errore di paging che mandava in crisi il sistema operativo.

La causa precisa non fu mai isolata, pertanto non si sa se fosse possibile applicare una patch. La tabella di patch nella ROM contiene la maggior parte delle routine nel codice nativo ROM, ma vi sono parecchie funzioni interne al kernel a cui non è possibile applicare patch a causa della riduzione prestazionale che impatta una funzione solo per essere compresa nella tabella di patch. È molto probabile che il bug non fosse riparabile, ma senza conoscere l’esatta natura del bug non si può affermare nulla di certo.

Un codice prezioso e variegato

3. Oltre a essere il ‘Newton Patch Master’, il mio lavoro primario nel Newton group era occuparmi del Build System e dei Build Tools. La ROM del Newton è in gran parte C++, con parti in Assembler e molto NewtonScript. La ROM veniva costruita soltanto utilizzando un compilatore ARM e un linker modificati (provenienti dall’azienda ARM in Inghilterra), e una serie di strumenti MPW specializzati scritti da Apple, e il tutto girava sotto MPW [Macintosh Programmer's Workshop]. Questo era il solo ambiente di costruzione per i 6 e passa MB della ROM ‘di base’. La ‘ROM extension’ contiene un insieme di pacchetti NewtonScript, altre tabelle, ecc., ed è stata realizzata con NTK [Newton Toolkit] e altri strumenti MPW specializzati.

La ROM contiene inoltre del codice sorgente in licenza da altri produttori software: Paragraph International per il motore di riconoscimento della scrittura corsiva, i dizionari dei termini e del correttore ortografico; ARM Ltd per le librerie Std C. Apple non potrebbe di certo rilasciare il codice sorgente avuto in licenza. In più, la ROM contiene parte del codice Apple più prezioso, una porzione modificata di QuickDraw (dell’epoca del Mac SE) e tutto il Printing support for QuickDraw e per la stampa PostScript. Apple sviluppò anche il ‘Printing Recognition Engine’ [il motore per il riconoscimento della scrittura non corsiva, a lettere separate], è scritto in C/C++ ed è ‘Newton-dipendente’. Fu sviluppato sotto UNIX e i risultati di calcoli automatizzati piuttosto lunghi hanno prodotto la rete neurale che il Newton utilizza per effettuare il riconoscimento [e la conversione] del testo.

Era opinione di Jobs che questo codice fosse troppo prezioso perfino per Newton Inc., figuriamoci al di fuori di Apple. Open Source? Neanche per sogno. E poi il codice base della ROM non è ben distribuito su livelli, molte ampie porzioni sono troppo ‘incestuose’, quindi non è affatto qualcosa sulle cui porzioni un gruppo qualsiasi di ingegneri potrebbe lavorarci in maniera indipendente. Anche con un team riunito in un solo luogo non era infrequente avere problemi causati da interazioni inattese ed errori dovuti alla mancanza di una buona distribuzione del codice su livelli e di un buon isolamento nel sistema operativo e nelle applicazioni incorporate. Nel 1997 fu iniziato un progetto all’interno del Newton group per la realizzazione di un OS ‘modulare’. Lo scopo era riscrivere gran parte della ROM così da renderla mantenibile anche in futuro, ma molto di quel lavoro non fu mai portato a termine.

4. Sì, anche IntelliSync [software di sincronizzazione prodotto da IntelliLink] era in licenza, e a mio parere fu uno degli errori più grandi commessi da Apple, ossia quello di non sviluppare un proprio software per tali compiti. [...]

Dubito che il produttore [si riferisce ancora a IntelliLink, suppongo] intenda rendere disponibili le interfacce e non sono sicuro che NCU sia sufficientemente modulare da accettare nuovi plug-in; non credo lo sia.

Priorità di risorse

[Probabilmente il nostro Ex Newton OS Engineer risponde a domande sul perché, per il Newton MessagePad, furono scelte determinate tecnologie e porte a scapito di altre. Purtroppo nel testo che ho a disposizione mancano le domande precise, vi sono soltanto le risposte dell'ingegnere.]

5. La tecnologia IR (infrarossi) del Newton era anteriore a IrDA e IR non si rivelò essere una funzione molto utile, perché averla costantemente attiva significa un consumo energetico eccessivo. Essenzialmente, per avere un’interfaccia IR funzionante, il software dev’essere sempre in ascolto per ricevere input IR e questo, insieme all’output IR, consuma energia. Inoltre, un IR full duplex è una brutta bestia da implementare, e avere più fonti di input IR allo stesso tempo è problematico, perché distorce l’input. Di conseguenza, la maggior parte delle implementazioni IR sono half dulplex e il processo di scambio dati è lento e costoso quando si ha a che fare con un gran numero di piccoli frammenti di informazioni. [...]

Per quanto riguarda Ethernet, è un livello di trasporto e un protocollo che non ha nulla a che vedere con Windows; il MessagePad 2000/2100 ha il supporto per il TCP/IP, che è il protocollo più comune e si serve di hardware Ethernet per le reti. Il problema legato al ‘Network’ su un PDA e nei Newton MessagePad, è che il Newton non è stato progettato per connettersi a una WAN o a una LAN, e tali reti richiedono un’attenzione costante a livello hardware, che deve mettersi in ascolto per captare tutti i pacchetti che transitano nella rete. Il Newton OS non fu progettato per fare questo, e aggiungere tale funzione in un secondo momento fu un hack. E a mio parere un altro grosso errore commesso da Apple con l’intera linea di prodotti Newton fu il tentativo di rendere i MessagePad dei ‘dispositivi per Internet’. Invece di realizzare un MessagePad 2000 più grande, più ingombrante, più costoso e ‘adatto a Internet’, Newton Inc. avrebbe dovuto costruire un dispositivo più sottile, più piccolo, e meno capace. Ma Palm Computing ebbe una visione migliore del prodotto e realizzò un PDA di maggior successo.