Newsgroup: it.comp.retrocomputing
Titolo: Apollo DN3500 - Lavori in corso

 
Risolto il problema nastri (almeno così sembra), iniziamo a far sul 
serio :)
 
Non ho HD ESDI presenti nella lista dei modelli supportati.
Ho pensato, però, che la scheda WD7000 potesse essere più flessibile 
della OMTi che ho sull'altra Apollo.
Così, ho provato l'unico ESDI rimasto in magazzino, Maxtor XT-4170E.
 
A quanto pare, l'ha riconosciuto e gradito.
Una mattinata fra caricamento del nastro (per un'opzione sbagliata ho 
dovuto ricaricare tutto da capo...) formattazione e verifica.
Con il lettore nastri rumoroso quanto una stampante a 9 aghi 
bidirezionale :P
 
http://www.supervinx.com/Retrocomputer/Apollo/01017373.JPG
 
http://www.supervinx.com/Retrocomputer/Apollo/01017374.JPG
 
http://www.supervinx.com/Retrocomputer/Apollo/01017375.JPG
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 
http://www.supervinx.com/Retrocomputer/Apollo/01017375.JPG
 
 
Evviva! Fervidi vivissimi rallegramenti! (cit.)
 
G. :)

Un pomeriggio passato a creare nastri...
 
$ mt -f /dev/st0 erase
$ mt -f /dev/st0 offline
$ tapecopy xxxxx /dev/st0
 
con lunghe pause per far raffreddare il capstan (ho posto anche due 
ventoline di raffreddamento, il kit che si poneva sotto gli HD).
A parte una cassetta che s'è rotta durante la scrittura, sembrava andar 
tutto bene, quando ...
L'ottava immagine presenta lo stesso problema della prima.
 
?65535 byte tape record too long for 32768 byte buffer
 
Già ero insicuro sulla buona riuscita dell'installazione, visto che la 
prima immagine nastro che ho utilizzato non è della stessa serie delle 
altre, ma adesso sono proprio fermo...
Non so cosa contenga né se sia essenziale.
 
Ma [censura]... :(
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 ?65535 byte tape record too long for 32768 byte buffer
 
Mi ricordo vagamente qualcosa, ma non come avevamo risolto il problema.
Probabilmente nel nastro originale c'era un blocco danneggiato o qualcosa
del genere, motivo per cui nell'immagine non è stato memorizzato il limite
tra un blocco e l'altro (forse per un bug di tapecopy?).
 
Con tapedd e un po' di pazienza e di prove dovrebbe essere possibile
eliminare dall'immagine il blocco problematico, cioè quello di lunghezza
abnorme, dopodiché bisognerebbe provare a trasferire l'immagine così
ricavata su nastro fisico e vedere se all'Apollo piace ugualmente.
 
Di solito i nastri sono ridondanti, cioè è possibile recuperare i dati anche
se un blocco ogni tot è illeggibile. Se quei dati sono in un formato
decente, probabilmente si riuscirà a recuperare tutto, altrimenti mal che
vada si perderà il contenuto di quel tapefile, ma non di tutto il nastro.
 
Mi sa che dovrai metterti a "giocare" con un editor esadecimale: se non
ricordo male, i dati sono rappresentati da blocchi di 512 byte (o similari,
tipo 2048) nei quali i cui primi due o quattro byte sono un contatore
progressivo del blocco all'interno del tapefile. Poi ogni tot blocchi si
incontra un "separatore" che fa parte del formato TPE, è presente solo nelle
immagini e non viene riportato sul nastro fisico. Scorrendoti l'immagine
dovresti riuscire a capire dov'è la magagna e fare un po' di taglia e cuci.
 
Se trovi il punto hai due possibilità: o tagli via la parte rovinata e speri
che il software dell'Apollo si arrangi in qualche modo, oppure fai una toppa
inserendo N blocchi di zeri esadecimali corredati degli opportuni contatori,
in modo che il nastro risulti logicamente integro...
 
Fra i sorgenti dell'utility rbak per Unix c'era una breve descrizione del
formato di quei tapefile, e cercando in giro si trova in molti posti la
descrizione del formato dell'immagini TPS/TPE. Con quelle informazioni
dovresti riuscire a interpretare i dati e fare il lavoro di sartoria. :)
 
Ciao,
G.
 

So che siete in trepida attesa :) LOL !
Dopo una mattina di nastri (mi ronzano ancora le orecchie), con il salone 
completamente oscurato (causa fotografie senza riflessi vari) ed un paio 
di ricaricamenti, l'installazione del sistema base è terminata senza 
problemi.
Ammetto di esser partito senza leggere manuali (tanto è facile ...) e di 
esser corso ad aprire il file 
008860-A03_Installing_DOMAIN_Software_Mar92.pdf 
quando, dopo fase la iniziale m'ha lasciato con il messaggio
 
Apollo Phase II Enviroment ....
 
ed il prompt
)
 
Dico sistema base, in quanto l'HD da 170MB (153MB formattato) non è 
sufficiente (per circa 25MB) a contenere l'intero sistema nella sua 
configurazione "AVBPL" (Aegis+SysV+BSD4.3+Programmer).
Ho dovuto ripiegare su AL (Aegis Large), lasciando fuori gli ambienti SysV 
e BSD4.3, ma includendo X11.
Servirebbe un bell'HD da 380MB (ESDI) ma dove trovarlo ? Intendo senza 
spendere $€$€$€$€$€$€$€$€$€$€$€$€$€ ?
Ci accontentiamo, dovrebbero essere rimasti circa 20MB liberi...
Devo ancora effettuare il primo boot da disco, ma per adesso basta ...
 
-- 
http://www.supervinx.com/Retrocomputer
 

 da disco, ma per adesso basta ...
 
Il primo boot non e avvenuto.
error: sysboot not found.
 
Sono ripartito da nastro, ed il file sysboot è lì.
Ma non è visto all'avvio ...
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 Ma non č visto all'avvio ...
 
Non č che c'č qualcosa da fare tipo scrivere un bootblock e/o un bootloader
in modo che il firmware possa fare il suo dovere?
 
G.

Ho seguito passo passo le istruzioni del manuale, che coincidono con 
quanto presente nell'Apollo Survival Guide.
Non ci sono opzioni in invol.
Ce n'è solo una, -n, per creare un disco non di boot. In tutti gli altri 
casi, il disco è di boot.
 
Per quello che ho capito, non c'è bootblock.
sysboot è un file, e SAU7 una directory.
Credo che sysboot, caricato all'avvio, sia un qualcosa di minimale che 
consente la lettura della cartella SAUx ed il successivo caricamento del 
kernel.
 
Ho eseguito (di nuovo da nastro) invol, il disco è a posto.
Ho caricato un sistema minimale, sysboot è lì, al suo posto.
Lo Mnemonic Debugger non lo vede.
Temo, invece, che non riconosca il disco.
Se eseguo ex config, non è fra quelli che posso scegliere.
Ho scelto Micropolis 170MB, ma il mio è Maxtor XT-4170. Ci sono delle 
lievi differenze, che potrebbero portare alla non lettura iniziale da 
parte del firmaware (mentre il loader da nastro lo riconosce)
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 ha scritto:

Se ti potesse bastare, magari messo come secondo HD, ho un IBM ESDI da
70MB tipo 0662 di cui però ignoro lo stato di salute non avendo nulla
per farlo funzionare.
 
Prova a dare una occhiata qui:
http://www.traumfabrik.it/Componenti/componenti.htm
 
 
Ciao
 
Giorgio
 
Apple II and Apple III forever !!!

Dalla disperazione, alla depressione, alla rassegnazione :P
 
Imposto Micropolis 170 nella configurazione (ex config)
di nuovo invol,
carico un sistema minimale.
Riavvio, non trova sysboot.
Non posso che pensare al non riconoscimento della geometria del disco da 
parte di qualcuno. Scheda o firmware.
 
Mi sono ricordato che un PS/2 80 in garage aveva un Maxtor 380 come 
secondo disco, inutilizzato. Era difettoso, partiva con difficoltà.
Bene, non parte più.
Sento il click dello sgancio delle testine, ma il motore non s'avvia.
Ho controllato, e sia testine che motore sono "liberi", senza blocchi 
vari.
Dev'esser l'elettronica.
Ma porc[censura].
 
Avevo risolto tutto: i nastri, il lettore, avevo anche terminato 
l'installazione...
!*&&*@&#*((*$()()%())(@)(@*&@%$#@$#&@#$
 
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 !*&&*@&#*((*$()()%())(@)(@*&@%$#@$#&@#$
 
Scusate lo sfogo ...
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

On Wed, 18 Jan 2012 16:33:35 +0000, supervinx wrote:
 
C'e' un motivo se tutta la documentazione relativa a questi sistemi fa' 
riferimento a dei modelli specifici di dischi.
Divertiti con la caccia al disco esdi, vedrai com'e' piacevole.
Anzi se ne trovi caccia un fischio che io sto smontando casa per
recuperare UN disco che SO di avere e che SO essere anche supportato ma 
che NON riesco a ritrovare.
 
-- 
member of the italian hobbyist DECnet network - 
decnet.ipv7.net
 
www.unsupported.info
 - 
img.unixantichrist.net
 

Ultimi tentativi ... negativi ...
Ho provato ad inizializzare il disco con invol della 9.
Il caricamento di domain_os da nastro va in crash
Ho inizializzato il disco con invol della 10 con formato della 9.
Il caricamento dei domain_os (sempre da nastro) si blocca dopo poco.
 
Non ci sono speranze, a meno che fra il disco di DG ed il mio guasto 
(Maxtor 380M) se ne tiri fuori uno sano...
 
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 avere e che SO essere anche supportato ma che NON riesco a ritrovare.
 
MFM ne ho, SCSI a quintali, IDE non ne parliamo.
ESDI pochi, e quei pochi non sono supportati.
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

Se proprio lo devi dar via, lo prendo per i miei PS/2. Il modello 0662 è 
di un PS/2 (8580 o 8560).
Putroppo l'Apollo è veramente schizzinosa ...
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

Mi sono letto buona parte dell'archivio comp.sys.apollo.
L'errore è molto comune, nelle mie stesse condizioni, persino con HD 
supportati. Nessuno, però, ha una soluzione.Si tratta sempre di 
successive reinstallazioni, di retroappassionati.
Evidentemente gli installatori ufficiali conoscevano qualcosa in più 
persino dei manuali.
 
Qualcosa l'ho capita.
Il files sysboot è una specie di boot sector.
Occupa i primi dieci blocchi successivi alla label del disco e del volume 
logico, in modo tale che lo Mnemonic Debugger lo possa leggere senza 
accedere al filesystem. È visualizzato dal comando ld (equivalente di ls, 
dir) ma non è cancellabile, in quando non fa parte "realmente" del 
filesystem.
È creato da invol (infatti l'ho trovato) ma è vuoto, sino al termine 
dell'installazione del sistema operativo.
Invol lo crea per riservare spazio (un po' come il comando DOS format /
B ).
 
Potrei, però, aver sbagliato una sequenza.
È scritto di eseguire
ex calendar
re(set)
invol
calendar
ex domain_os
 
Forse qualche calendar non l'ho eseguito: certo, sarebbe ben curioso se 
una simile dimenticanza portasse al non avvio della macchina.
 
Altra cosa strana.
L'installazione complessiva terminò correttamente e riavviai (dopo lo 
shutdown).
Durante le successive prove, poi, ho riavviato domain_os da nastro.
Ho letto che l'operazione non cancella il contenuto del disco, dovrebbe 
essere additiva. Strano, perché il disco non conteneva più quasi nulla, 
come se l'installazione non avesse scritto nulla.
 
Per oggi basta ...
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

Ormai mi scrivo e mi rispondo ... farò compagnia al tipo del PS/1 ...
Ho ricominciato (con la santa pazienza ...)
Non appena è iniziata l'installazione (ed il DM era caricato), ho aperto 
una console e
1) ho creato due floppy con i programmi accessori contenuti in /sau7
Almeno posso eseguire calendar/invol/salvol/chuvol ... da floppy senza 
dover attendere che centinaia di metri di nastro siano riavvolti :(
2) ho verificato il file sysboot
$ catf /sysboot
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
non valido...
allora l'ho sistemato manualmente con cpboot
 
Considerate che ero nel mezzo dell'installazione, per cui son dovuto 
andare a caccia dei files necessari
(invol, mtvol, cpf, crd, cpboot, dmtvol, sau7) sparsi in varie directories 
che *non sono* dove si troverebbero ad installazione conclusa.
 
Dato che non c'è limite ai guai, cos'è successo ?
Che il terzo nastro (3di3) ma Vol02 per rbak, ha iniziato a mostrare 
problemi
-marginal block detected
e minst s'è fermato lì.
O meglio, è andato avanti leggendo anche gli altri nastri, ma non ha 
terminato l'installazione.
Effettuato lo shutdown e resettato, finalmente ho accesso all'HD e se 
avvio, mi riporta nel sistema minimale utilizzato per l'installazione, e 
posso ripartire da lì.
 
Dunque, quanto riportato nell'Apollo Survival Guide non è esatto.
Partendo da nastro, carica un OS minimale, ma sysboot non è valido.
Se invece fosse già presente un OS valido sull'HD, è possibile riavviare 
da HD con il nuovo OS minimale.
Nel mio caso, qualcosa non doveva esser andato per il verso giusto, la 
prima volta. Eppure minst era terminato senza errori.
 
Adesso ricreo il terzo nastro e riprovo ...