Newsgroup: it.comp.retrocomputing
Titolo: Nastri QIC

 ld
ctape error ... sense error... etc...
 
Allora ho collegato il lettore QIC-60 alla macchina Linux e:
 
$ mt -f /dev/st0 erase
$ tapecopy xxxxx /dev/st0
 
Sembra scrivere senza problemi, solo che il nastro aumenta 
progressivamente la velocità e termina prima che la scrittura sia 
completata (e sono solo poco più di 30MB).
La prima parte sembrerebbe, però, scritta correttamente.
 
Adesso, l'Apollo scorre tutto il nastro, senza "sense error", ma qualcosa 
non gli piace ancora, mi dice boot error, unrecognized. Forse perché la 
scrittura sul nastro è incompleta.
Domanda: perché il nastro non basta ?
Forse perché una cassetta DC6150 contiene 150MB compressi, ma non 60 MB 
puliti ? (Ho detto una [censura] ?)
 
Vado a riesumare una QIC-120 dal garage, mi sembra di averla ...
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 Vado a riesumare una QIC-120 dal garage, mi sembra di averla ...
 
QIC-120 e QIC-150 hanno la stessa densità (credo 120), ma in uno dei due
tipi c'è più nastro fisico che nell'altro. Idem vale per 320 e 525 (densità
525) e 1000 e 1200 (densità 1000, mi pare)...
 
Insomma, può darsi che tu stia usando un nastro della densità sbagliata e/o
dentro un lettore che non riesce a leggere o scrivere quella densità. Io
purtroppo ora sono molto di fretta e non posso fare indagini, ma tu potresti
dare un'occhiata a 
www.qic.org
, lì da qualche parte c'è la tabella con tutti
i tipi di nastro e le densità fisiche relative. Così almeno scopriamo se
stai usando il nastro giusto nel lettore giusto.
 
Ciao,
G.
 

 
Il lettore QIC-60 (un Viper SCSI di provenienza Apollo) è senza coperchio 
superiore: montato esternamente nella macchina SCSI con Linux ed una 
Adaptec PCI è proprio sotto il mio naso, e vedo chiaramente il 
funzionamento.
Mentre mt riconosce la fine del nastro, tapecopy si blocca in quel punto.
ps -ef rivela che il processo è non interrompibile, non c'è kill -s 9 che 
regga, il bus SCSI è in tilt. È necessario spegnere e riaccendere la 
macchina, perché detto bus riprenda a funzionare.
Però, se vado a rileggere con tapedump quanto scritto, sembra che non ci 
siano problemi, solo che manca buona parte dell'immagine nastro.
 
Ho letto un po' di materiale, ed son rimasto col dubbio se:
1) un'unità QIC-24 possa scrivere correttamente un nastro DC6150. 
Sembrerebbe di sì, ma l'articolo si riferiva a lettori IBM, non Tanderberg 
o Viper
2) un'unità QIC-24 legga un nastro DC6150 scritto su di un'unità QIC-150. 
E questo credo proprio di no. Dovrei scrivere una DC600 su un'unita 
QIC-150 e provare.
 
Mi chiedevo, a questo punto, cosa accadrebbe sostituendo l'unità QIC-24 
SCSI sull'Apollo con una QIC-150. Dovrebb'esser trasparente e risolvermi 
i problemi di compatibilità ...
 
Riesumato tapedd... farò una prova ...
 
http://www.supervinx.com/Retrocomputer
 

Devo usare questa sintassi ? 
tapedd itve=source.tap otvr=/dev/st0 fskip=1 fcnt=1 verbose 
oppure devo omettere fskip a fscount ?
 
 
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 omettere fskip a fscount ?
 
Aggiornamento: una buona notizia ed una cattiva...
 
Buona: la scheda SCSI WD7000 accetta il lettore di nastri esterno anche 
per il boot, purché abbia ID 0. Così, pensavo, risolvo i problemi di 
compatibilità.
Ho scritto, perciò, il primo nastro sul lettore IBM, con tapecopy, senza 
errori e poi l'ho collegato alla DN3500.
 
Cattiva: Sembra che vada molto meglio, solo che arrivato a fine nastro 
restituisce un errore e riavvolge tutto. Eppure ho controllato con hexedit 
e nell'immagine del primo disco è presente la directory /sau7, relativa 
alla DN3500.
 
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

Ho provato a scrivere l'immagine con tapedd.
Stesso comportamento di tapecopy.
Nastro velocissimo che termina in anticipo sulla fine dei dati.
Scrive, praticamente, alla velocità con cui riavvolge.
 
Almeno tapedd esce, tapecopy blocca il processo.
Tapedd segnala la scrittura di 7MB ! Su una DC6150 !
L'immagine è di oltre 39MB, e la directory sau7 si trova intorno i 9MB.
C'è qualcosa che non quadra circa la densità... almeno per come viene 
riconosciuta.
Ho controllato con dd e /dev/nst0: i files (spezzettati) che ottengo, 
contengono i dati presenti nell'immagine, dunque la scrittura avviene 
correttamente, in senso molto lato ;)
Scrive 7MB dove ne sarebbero contenuti 150MB ...
 
 
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 Scrive 7MB dove ne sarebbero contenuti 150MB ...
 
Se hai usato la sintassi tapedd che hai scritto in un altro messaggio, per
forza che succedono cose strane: gli hai detto di scrivere su un nastro
fisico quel che dovrebbe scrivere in un'immagine virtuale raw (otvr) e
oltretutto non tutto il contenuto del tape di boot, ma solo un pezzo.
 
Ripeto ciò che ti ho scritto in un altro messaggio:
 
Ora non ricordo più la provenienza delle tue immagini (Vampire?) comunque tu
devi prendere TUTTA l'immagine (che penso sia di un nastro completo formato
da più tape file, ma questo a te non interessa) e copiarla TUTTA su nastro
fisico, senza saltare pezzi (fskip) e senza copiarne solo una parte (fcnt).
 
Mi sa che c'è qualcosa che non mi/ti/ci è chiaro, parliamone! :)
 
G.

 oppure devo omettere fskip a fscount ?
 
Certo che devi ometterli: fskip e fcnt se tu volessi copiare solo parte
dell'immagine, ma tu vuoi copiarla tutta, no? E soprattutto non devi saltare
il primo tapefile, che č quello che contiene il boot loader.
 
Ora non ricordo piů la provenienza delle tue immagini (Vampire?) comunque tu
devi prendere TUTTA l'immagine (che penso sia di un nastro completo formato
da piů tape file, ma questo a te non interessa) e copiarla TUTTA su nastro
fisico, senza saltare pezzi (fskip) e senza copiarne solo una parte (fcnt).
 
Mi sa che c'č qualcosa che non mi/ti/ci č chiaro, parliamone! :)
 
G.

 i problemi di compatibilità ...
 
Esatto. Comunque mi pare che il formato QIC-120 su cassetta DC6150 possa
essere la lingua franca che potrebbe aiutarti. :)
 
Ciao,
G.
 

 Ora non ricordo più la provenienza delle tue immagini (Vampire?)
 
Non cominciamo con queste basse insinuazioni, le immagini provengono dal 
freaknet e sono dump fatti con tapecopy dei loro nastri.
Io non ho colpe.
 
-- 
member of the italian hobbyist DECnet network - 
decnet.ipv7.net
 
www.unsupported.info
 - 
img.unixantichrist.net
 

 Io non ho colpe.
 
Chiedo umilissimamente perdono, sono colpevole colpevole colpevole.
 
Vado a preparare i ceci secchi.
 
g. (in minuscolo per punizione)
 
 
 
 
 
 
 
 
 
 
 
 
 
:PPP

Risposta unica, hai ragione, ho omesso dei pezzi.
1) QIC-24, pensavo ai 60MB quando ho scritto
2) Ho usato la sintassi giusta con tapedd, m'ero letto l'help
 
tapedd itve=xxxx otq=/dev/st0, ma il nastro non basta (DC6150 in QIC-24), 
forse per incompatibilità di tracce.
Quel poco che scrive, però, lo scrive bene...
 
Ovviamente, tapedd e tapecopy hanno lo stesso risultato su lettore QIC-150 
e nastro DC6150. Perfetto.
Il problema era nastro DC6150 in QIC-24.
Alla luce di quanto visto, niente supporto, dunque per le QIC-150 nel 
lettore QIC-24.
 
Ho trovato due DC600, ma il nastro s'è spezzato al primo movimento.
Ho, però, una decina di QIC120 usate.
 
Il lettore QIC-150 esterno IBM (sì, Tanderberg 3600) è visto dall'Apollo 
ma non legge correttamente. Sulla macchina Linux sì.
 
Devo provare, perciò, a scrivere non su di una DC6150 ma su di una 
cassetta QIC-120, chissà gli piaccia. 
Potrebbe esser che il controller SCSI abbia problemi con la periferica e/
o con il formato.
 
Farovvi sapere a notte inoltrata :)

 Quel poco che scrive, però, lo scrive bene...
 
Dovresti/potresti provare a forzare la scrittura in modalità QIC-120 con il
comando mt setdensity, magari funziona...
 
Secondo lo standard QIC-95-101, il density code per il QIC-120 è 0Fh, quindi
il comando dovrebbe essere qualcosa tipo mt -f /dev/st0 setdensity 0x0f
 
Mi pare anche di capire che in certi casi mt status riporti fra le varie
cose pure le densità supportate dal drive e/o dal nastro.
 
Lo standard lo trovi in fondo a 
http://www.qic.org/html/qicstan.html
 
 
Ciao,
G.
 

 ld
(zzzzzzzzzzzzzzzzz.........)
è comparsa la directory SAU7 e tutte le utilità !!!!!
-------------------------
Ho scoperto una cosa, che non sapevo.
Il nastro è scritto metà in andata e metà al ritorno.
/SAU7 si trova "al ritorno".
Quando scrivevo un QIC-150 sull'unità QIC-24, il nastro si bloccava alla 
fine, e non scriveva durante il riavvolgimento.

 ex domain_os
 
crash_status 00080010 PC 3C4500AB pid 0001
S 3C4278C4  2700  BC
3C4278C4: 4E4F
 
:(
 
Almeno il nastro l'abbiamo risolto...

 Almeno il nastro l'abbiamo risolto...
 
http://www.umich.edu/~archive/apollo/all_stcode.txt
 
 
Pensavo peggio... non c'è l'HD, ecco il motivo del crash...
 
Siamo sulla buona strada... mancano 8 cassette QIC-120 e qualche HD 
ESDI... "hai detto un prospero" direbbero dalle parti del Colosseo...
 
-- 
http://www.supervinx.com/Retrocomputer
 

 /SAU7 si trova "al ritorno".
 
Sì, i nastri QIC hanno diverse tracce parallele che vengono scritte a
zig-zag (scrittura bustrofedica) e ogni volta che il nastro inverte la
direzione la testina si sposta leggermente in modo da leggere un altra
traccia o gruppo di tracce. :)
 
I primissimi QIC avevano solo quattro tracce, due in un senso e due in
quell'altro; nei QIC successivi le tracce sono state aumentate ma (quasi)
sempre mantenendo le quattro possibili (macro-)posizioni fisiche della
testina, la quale però rispetto all'originale è composta da più gruppi di
lettura e scrittura, così ottenendo più tracce parallele. Nello standard
QIC-5010 (l'ultimo, quello delle cassette da 13 GB non compressi) ci sono
alcuni schemi esemplificativi abbastanza carini. In ogni caso comunque le
tracce pari vengono scritte in una direzione e quelle dispari nell'altra in
modo da minimizzare le interferenze fra tracce adiacenti. :)
 
G.

 
Sapessi il mal di testa che è venuto a me, per tener traccia di tutte le 
possibili combinazioni, hardware e software, compresi gli scambi di 
"cinghie" di trasmissione ...
 
- Due Viper 21160 SCSI, QIC-24 (?) 60MB, interfaccia SCSI-50 pin
- Due Archive interfaccia QIC-24 (quella edge). Uno con cuscinetto 
sciolto, l'altro l'ho sistemato ma non ancora provato
- Lettore QIC-150 esterno IBM (Tanderberg 3600)

 sciolto, l'altro l'ho sistemato ma non ancora provato
 
L'interfaccia di questi potrebbe essere una di tante: QIC-02, QIC-36, ESDI,
Floppy AT e forse altre. Una pių orrenda e antidiluviana dell'altra. :)
 
N.B. QIC-24 definisce solo lo standard di lettura/scrittura. :)
 
G.


 
L'interfaccia è QIC-36, mi sono ricordato ...
 
Antidiluviana ? LOL !
 
Ti sembra che l'Apollo DN3500 abbia l'aspetto di una macchina "moderna" ?
Persino un "vecchio" VAX sembra avveniristico :P
 
La lettura di una semplice utility comporta due passate intere del nastro.
Oltre 10 minuti.
Considera:
1) ld (15 minuti)
2) ex calendar (10 minuti)
3) ex invol (10 minuti + tempo di esecuzione vero e proprio, 
formattazione e preparazione del disco ESDI)
4) ex domain_os (10 minuti + tempo di installazione di 1 + 8 nastri)
 
Mi sto preparando psicologicamente :'(
 
 
-- 
http://www.supervinx.com/Retrocomputer
 

 Mi sto preparando psicologicamente :'(
 
Be', se ti può consolare, l'installazione di OS/400 (comprensivo anche di
PTF e prodotti aggiuntivi come ad esempio i compilatori) su un 9402-400 ci
mette circa otto ore e dieci, su un 9401-P03 tredici e trenta.
 
I tempi li presi tempo fa: l'installazione del 9402-400 fu fatta da CD-ROM
(Se non erro un Panasonic 2X rimarchiato IBM), quella del 9401-P03 invece da
QIC-1000 (però i nastri mi pare che fossero tutti QIC-150, ma forse c'era
anche qualche QIC-525, dovrei riguardarci).
 
In particolare, l'IPL automatico speciale di installazione delle PTF sul
9401-P03 durò dalle due e venti di notte alle otto e un quarto della mattina
successiva (io intanto me n'ero andato a letto: prima carica il contenuto di
tutti i nastri, poi procede con un'unica applicazione).
 
E comunque anche gli standalone backup di VMS, specialmente se avviati da
nastro TK50 o TU58 (per non dire dei floppy da 8"), ci mettevano oltre tre
quarti d'ora solo per caricare l'utility per fare il restore del resto. :)
 
G.

 fine, e non scriveva durante il riavvolgimento.
 
Per scrivere circa 60MB, ho perso il conto di quante volte ha mandato il 
nastro "avanti e dietro" :P
 
 
 
-- 
http://www.supervinx.com/Retrocomputer