Newsgroup: it.comp.retrocomputing
Titolo: Apollo DN3500 - porte seriali

1) Ottenuto il login via seriale
2) Trovate due utilità di sistema, molto grezze, che inviano e ricevono 
files via porta seriale
SIORF
SIOTF
Ho provato con SIOTF ad inviare un file di testo, che è comparso nella 
finestra di Putty.
Data la mia completa ignoranza di trasferimenti seriali, mentre effettuo 
la solita ricerca in rete, vi chiedo:
- cosa posso utilizzare per automatizzare la ricezione ?
- posso inviare files multipli ? Immagino di no ...
Ho letto di minicom: il menù "receive files" m'offre la scelta fra z/x/
ymodem e kermit ... devo provare, solo che trasferire i files uno alla 
volta, ricreando le directories ... :P
La vedo lunga ... quasi quasi provo a trasmettere il sorgente dello zip/
gzip ...

 gzip ...
 
Mi è venuto in mente che tempo fa utilizzai un tool per Unix/Linux chiamato
'rbak' – omonimo di quello per Apollo – per leggere le immagini di alcuni
nastri che poi credo ti siano stati passati insieme ad altre cose. Vedi:
http://groups.google.com/group/it.comp.retrocomputing/msg/f3d31bb4fa9baa91
 
 
Quindi, nel caso tu voglia trasferire dati FUORI dall'Apollo, mi viene più
facile pensare che tu possa creare un archivio con 'wbak', trasferirlo, e
poi estrarne il contenuto con il clone di 'rbak', piuttosto che trafficare
con zip/gzip. Per il trasferimento inverso però siamo ancora in alto mare.
 
Forse ti conviene cominciare cercando di trasferire i sorgenti di Kermit,
che poi ti agevola molto nel trasferimento di altra roba. In alternativa,
potresti provare con ZMODEM che è più semplice da usare. Vedo che ce n'è
un'implementazione all'indirizzo 
http://www.umich.edu/~archive/apollo/
 in
fondo alla pagina. Provala, magari intanto risolvi per i trasferimenti.
 
Ciao,
G.
 

 fondo alla pagina. Provala, magari intanto risolvi per i trasferimenti.
Vorrei aggiungere che in mancanza di meglio, se tutte le altre strade si
rivelano vicoli ciechi, per trasferire materiale binario potresti pur sempre
codificare i file uno per uno con 'uuencode', trasferirli in modalità ASCII
semplicemente facendoli scorrere sullo schermo e poi decodificarli con il
relativo 'uudecode'. È un processo lungo e laborioso, ma se tutto il resto
dovesse fallire, è una prova da fare. Vedo che sempre alla pagina detta
prima (
http://www.umich.edu/~archive/apollo/
) c'è anche un link a un certo
uuar.tar.gz che potrebbe fare al caso tuo. :-)
Ciao,
G.
P.S. Vedo anche un tar.tar.gz e c'è pure un gzip e tanti altri link...

 
 
Ho compilato rbak/wbak per linux, ma le immagini floppy sono non 
gestibili, dato il formato (teledisk) perché, come detto in un precedente 
post, utilizzano 77 tracce, 8 settori per traccia, 1024 bytes per 
settore ...
Se avessi un nastro funzionante... ma l'unica unità è SCSI, ed ho solo 
interfacce QIC-36.
 
 
Ho cercato di far funzionare i controller OMTi su di una macchina DOS 
(per fare un dd del disco fisso con Aegis 9.7.5), ma sono privi delle ROM 
necessarie :( , sia l'8261 che il 8610-CR (gli unici a supportare il 
Micropolis M4380-FA, Fast Actuator)
 
Ho sempre un'ultima possibilità: smontare il capstan dal Viper SCSI e 
montarlo sull'Archive QIC-36...
 
Ho passato un pomeriggio di jumpers, controllers, cavi e spegni/accendi.
 
Fra parentesi (che non è un monaco ...) molti binari su 
umich.edu
 sono 
compilati per Domain OS SR 10.x, mentre io ho una versione più antica, 
AEGIS/Domain-IX 9.7.5

 AEGIS/Domain-IX 9.7.5
 
Non ci sono anche i sorgenti delle varie cose? E soprattutto, hai un
compilatore? Forse l'avevi già scritto, ma non mi ricordo e non mi va di
andare a spulciare indietro. :)
 
Ciao,
G.
 

 G.
 
E se non ho letto male, vogliono gcc :( , che esiste per la SR10.x
 
Ad ogni modo, ho ancora il problema di far entrare i files nell'Apollo :(
 
Un sorgente me lo posso anche scrivere, con la santa pazienza (l'editor 
full screen non è male), sperando che ci siano tutte le librerie per il 
binding. Non hanno lasciato quasi nulla del sistema operativo ...
 
Certo, se avessi dd scriverei in modo raw sul disco, ma l'hanno 
cancellato ...
 
Ne ho di cose da sperimentare ...
 
Farei molto prima a rimediare un capstan da qualche parte ...
 

 Un sorgente me lo posso anche scrivere, con la santa pazienza (l'editor 
 
La butto lì, anche se non so se quel che sto per scrivere è applicabile a
questo particolare caso: quando in passato mi sono capitati casi del genere,
per esempio con VMS, ho avviato l'editor sul sistema host e poi sul client
ho selezionato e copiato il testo che mi interessava e l'ho incollato dentro
minicom (o chi per esso), col risultato di averlo "digitato" automaticamente
dentro l'editor dall'altra parte; dopodiché mi è bastato salvare e chiudere
per avere il file a destinazione.
 
Per qualche sorgente non potresti fare così anche tu, invece di riscrivere
tutto a mano?
 
Ciao,
G.
 

Il metodo funziona con VMS, l'ho provato anch'io...
Il problema è che l'editor full screen gira in una finestra grafica del 
DM (Desktop Manager), e non è il caso del login via seriale... altrimenti 
è disponibile ... ed ! 
Con un po' di pazienza ne verrò a capo ...

 č disponibile ... ed ! 
 
Uh, ed, che goduria! :D
 
Comunque anche con quello lě dovrebbe essere fattibile il metodo del
copia/incolla, no? Avvii ed, entri in insert mode con 'i' e poi incolli...
 
G.
 

 G.
 
 
Sì, sì ...
C'è rimasto solo ed perché han cancellato /bin, /sbin e tutta la porzione 
Unix/BSD compatibile (tirandosi dietro anche vi...)
C'è ed e red... manca solo edlin del DOS e siamo al completo :)

Riepilogo notturno :)
I sorgenti li ho fatti arrivare, con la coppia
- Linux 
  cat nome_file > /dev/ttyUSB0 (seriale su USB)
- Aegis
  catf /dev/sio1 > nome_file
e da Aegis ho prelevato tre documenti informativi, col procedimento 
inverso.
L'unico problema è stata la manipolazione di CR/LF.
I files ricevuti, in un senso o nell'altro, sono più grandi, ma si 
visualizzano correttamente. Partono in formato Unix ed arrivano in 
formato DOS (CR/LF). Nessun problema per i files di testo.
Ma, ahimé, non c'è il compilatore C :(
C'è un file cc, in /com che, avviato, attende qualcosa ...
La prima volta, ho dato per scontato che fosse il compilatore C.
Oggi, con calma e con più esperienza, ho notato che il sistema lo indica 
come formato uasc ... dunque testo.
È uno script di connessione remota :(
Non mi resta che riscrivere in fortran i programmi in C :D
Il compilatore fortran funziona ...
Come effetto secondario, ho scoperto che forse il TCP/IP è avviato.
Osservando l'errore restituito dallo script di connessione, mi sono 
incuriosito. 
Ho avviato tcpdump sul notebook ed ho riavviato lo script.
Ci sono dei pacchetti con un hw address che non è quello del notebook: 
dato che le due macchine sono collegate con un cavo diretto, senza hub/
switch o quant'altro, i pacchetti derivano dall'Apollo.
Anche se riuscissi a configurare l'indirizzo IP della macchina 
(basterebbe scoprire anche quello attuale, poi sposto il notebook nella 
stessa sottorete) non sembrano però presenti i servers/daemons adatti per 
la connessione, né tantomeno ping e telnet.
Facendo pulizia, dal 4% di spazio libero, siamo arrivati all'87%.
Certo, chi ha limato il sistema, sapeva ciò che faceva. È rimasto il 
minimo indispensabile per avviare la macchina e compilare i programmi in 
fortran :P
Il tentativo, invece, di inviare files binari con cat da Linux verso 
l'Apollo è un disastro.
L'Apollo va in crash immediato. I soliti cinque minuti di salvol :P

 L'Apollo va in crash immediato. I soliti cinque minuti di salvol :P
 
Ecco, questo invece mi meraviglia moltissimo: non mi pare una bella cosa che
un programma user mode (qualunque esso sia) possa tirare giů la macchina. A
prescindere da quale sia l'utente che lo esegue. Non č un sistema operativo
vagamente simil-Unix, multiuser e multitask?
 
Comunque, crash o no, č praticamente impossibile inviare/ricevere file
binari con cat, perché come minimo ti perdi per strada un tot di caratteri
che vengono interpretati come controllo del flusso seriale, non ultimi i
famosi XON e XOFF.
 
Ciao,
G.
 

 fortran :P
non ho capito: cosa intendi per "limare il sistema" ? mettere a punto, o 
rimuovere gli eccessi dai dischi ?
Saluti,
dott, Piergiorgio.

 dott, Piergiorgio.
 
 
 
Togliere parti del sistema operativo :)
 

 G.
 
Ero conscio del problema, ma alle 2 di notte m'andava di sperimentare 
cosa succedesse :)
 
Aegis, a quanto ho letto, era noto per essere buggy ...
Se utilizzo minicom e cambio un paio di volte la velocità di trasmissione 
(9600->1200, 1200-9600) o faccio altre operazioni stupide, ho 
un'altissima probabilità di crash, attivabile da remoto :P
 
Un'altra fonte di crash è utilizzare più volte di seguito ctrl-Q per 
terminare le applicazioni nei pad.
Segno che l'error-handler non è perfetto, oppure ha dei "memory 
leaks" :PPP
 
Ora, non so dirti se il sistema sia così perché malconfigurato, mancano 
delle parti, sia stato "malmenato" o quant'altro ...
 
 
 
 
 
-- 
*** Nucleare ? No, grazie ! ***

 Togliere parti del sistema operativo :)
 
OK capito.... secondo te l' avevano fatto colle dita delle mani o quelle 
dei piedi ? limare il s.o. lasciando il disco abbondantemente pieno o 
era per fare entrare il contenuto o e' per "tanto per fare qualcosa"....
 
Salutami,
dott. Piergiorgio.
 


L'output dei programmi in fortran e di un'altro programma, BLUE, è 
costituito da files di testo e non, anche di alcuni MB.
Il disco è da 380MB: hanno tolto tutte le parti del SO che non fossero 
essenziali per l'avvio e l'esecuzione di BLUE e del compilatore fortran.
Come dire, lascio 
IBMBIO.COM
, 
IBMDOS.COM
, 
COMMAND.COM
, EDLIN ed un paio 
di altri programmi.


 trovarle, le altre cose da trasferire (per esempio il compilatore C).
 
Sto decidendo se scrivere una versione Q&D di uuencode/uudecode solo per 
i miei scopi oppure adattare del codice in C, il che non è un gran 
divertimento ... pensate alla riscrittura di questa roba ... devo 
rispolverare la pazienza :)
 
nextn(cpp)
unsigned char **cpp;
{
    while (**cpp != '\0' && (**cpp < ' ' || **cpp >= ' ' + 65))
        (*cpp)++;
    return (**cpp != '\0' ? (*(*cpp)++ - ' ') & 0x3f : -1);
}
 

 di altri programmi.
OK capito.
Per uuencode, mi sbaglio o gcc ha anche un backend per Apollo ? nel qual 
caso, si potrebbe x-compilare.
Saluti,
dott. Piergiorgio.


Eh, supportano solo dalla SR10.x in poi :(
Tutto nasce dall'assenza di un tape drive ... maledetto capstan :)

 }
Cos�, per diletto, mi sono messo a provare di scrivere un uuencode/uudecode
in Fortran; magari ci riuscir�, ma per ora ho problemi con il lato binario
della cosa: leggere (o scrivere) il file codificato non � un gran problema,
invece non riesco a imbroccare il modo di fare I/O binario puro. Soprattutto
non ci riesco se voglio scrivere del codice portabile: sto sperimentando su
VMS e sono sicuro che se usassi le funzioni RMS mi troverei molto agevolato,
ma poi il codice non sarebbe portabile, men che meno su Aegis... :-)
Tu poi il codice C come penseresti di compilarlo su Aegis?
Stavo anche pensando: chiss� se armeggiando _molto_ con la shell si riesce a
scrivere un qualche script adatto al bisogno. Quanto � rudimentale la shell
di Aegis? Con una tipo bash forse non ci sarebbero dei gran problemi, ma con
quella? A cosa somiglia?
Ciao,
G.

Io sto convertendo il codice da C a Fortran, con tutti i problemi del 
caso :)
 
Ma forse farei prima a riscriverlo direttamente !
 
Il manuale di Aegis, parla sia di /com/sh che di bash, ma bash non c'è 
più ... solo sh, e non ho idea di che bestia sia ... se devo dar retta al 
manuale, dovrebbe conformarsi a BSD 4.2.
 
Considera che mancano tutti i filtri ... sed, awk, grep... per dirla 
tutta "non c'è più una mazza" (sorry !) :P
 
Stasera devo riaccendere l'Apollo (ho passato un pomeriggio di 
ripetizioni ... familiari) e sperimentare il compilatore Fortran.
È dato come F77 compatibile...
 

 invece non riesco a imbroccare il modo di fare I/O binario puro.
Mi rispondo da solo per riportare un po' di sano nazismo informatico che ho
trovato in rete cercando informazioni a proposito di queste cose:
«Before primitive languages like C were invented, and prior to primitive
operating systems like UNIX, nobody used byte stream files. Everybody had
this advanced concept of *records*. A record is a logical group of data that
is composed of fields and often treated as a single gulp of data. Fortran
was designed and specified in these golden ages of computing, before UNIX
and C came along and brought back the primitive notions that it was really
up to the application to specify and maintain any record grouping in it's
own file structure, so that a whole cottage industry of file conversion
programming could be brought into being».
:-)
G.

 Č dato come F77 compatibile...
 
Come te la cavi col Fortran? Io vorrei potermela cavare meglio di quanto non
riesca a fare... :P
 
G.

 G.
 
 
Una volta lo conoscevo benissimo, adesso sono molto arrugginito, ma credo 
che in qualche ora di full immersion tornerei agli "antichi splendori" :)

 che in qualche ora di full immersion tornerei agli "antichi splendori" :)
 
Bravo, al lavoro allora! :) Son proprio curioso di vedere come farai per la
manipolazione dei bit senza usare intrinsic fuori-standard che magari il
compilatore Aegis non conosce. A colpi di moltiplicazioni e divisioni?
 
Potrebbe essere un'interessante "collab" sul NG :)
 
Ciao,
G.
 

 G.
 
Dovrete aver un po' di pazienza, però... ho un calendario pesante :P
/OT_Begin
Domani ripetizioni e poi prove.
Mercoledì e giovedì prove
Venerdì concerto
/OT_End
 
Lavoro a mezzo servizio :)


Il problema dell'I/O raw binary è semplice, mi sono ricordato :)
(Sto togliendo la ruggine dagli ingranaggi ...)

Lavoro a mezzo servizio :)
 
Mi ricordi qualcuno ...
;-)
 
Ciao
 
Giorgio
 
Apple II and Apple III forever !!!

 Apple II and Apple III forever !!!
 
 
Lo conosco ?

Lo conosco ?
 
Solo se leggi qualche giornale!
;-))


 Apple II and Apple III forever !!!
 
 
Collegato ! :D :D :D :D :D