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 MP2x00 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.