Retrocomputing

[stefanopc]

Philos 10 con Mouse laterale a scomparsa.
Ciao

[speedyant]

Io l'unico portatile vintage che posseggo credo sia un Compaq 486 sx"qualcosa" con Windows 3.1.

[Etemenanki]

Ho diversa roba sparsa qui e la, quando saro' riuscito a terminare il restauro di un mobile ad ante in vetro (di recupero) ed a mettergli delle luci a led per i ripiani, vorrei riempirlo, o almeno metterci un po di quella che io considero "archeologia elettronica" (mentre invece per mia madre sono "tutte schifezze inutili da buttare" )

Vecchie calcolatrici (anche meccaniche), vecchie macchine fotografiche, vecchi componenti elettrici ed elettronici, vecchi strumenti di misura, vecchi computer ... mi piacerebbe esporli tutti, ma purtroppo non sara' possibile (e' solo un'armadio a due ante, mica un'intera stanza come piacerebbe a me )

Ho perfino ritrovato alcune cose che non ricordavo neppure piu di avere, cercando di fare pulizia ... un vecchio oscilloscopio, un po di registratorini a cassette e radioline, un "financial investment analyst" della Texas Instruments (strana calcolatrice), un grosso multimetro in bachelite con doppio strumento, una "Samurai Z2" (strana macchina fotografica a mezzo formato), un sistema di sviluppo per 8080 (regalato da un vecchio amico e mai usato), strane lampadine e tubi a vuoto ... troppa roba, insomma

Cerchero' di fare qualche foto decente, appena riparo la macchina fotografica (il mio vecchio cellulare non fa esattamente fotografie decenti, poveretto )

[mario_maggi]

Ho in qualche scatolone un portatile IBM, se non ricordo male era del 1992, è stato il primo portatile IBM con monitor a colori. Lo usavo in DOS 6, c'era installato Win 3.0 che forse ho aggiornato a 3.1.
Floppy da 3 1/2 , lento q.b. ma faceva il suo lavoro.
Ciao
Mario

[djnz]

Nel senso: se tutto quello che occorreva era l'implementazione di un terminale, era necessario creare un interprete BASIC? Non si poteva piuttosto creare una shell con comandi base, tipo quelle di Unix

Il punto fondamentale secondo me è questo: la memoria (RAM) era poca e costosa. In pochissimi "kappa", in alcuni casi uno solo, dovevano starci le variabili di sistema, la memoria video, il programma utente, i dati del programma, lo stack del processore... mi sembra impensabile dover ogni volta caricare in RAM anche un interprete o compilatore. Il BASIC per sua natura è già un interprete comandi, la cosa più immediata era fargli fare anche la funzione di mini sistema operativo di quelle macchine (parliamo dei primi home computer), tutto in ROM già pronto e funzionante all'accensione.

Oppure, rovesciamo la domanda: nessuno usando il C64 e simili programmava in BASIC? Si torna li: perché un interprete BASIC allora?

E come no, certo che si scriveva in BASIC, ma quello che era possibile ottimizzare in linguaggio macchina lo si faceva, meno spazio occupato e maggiore velocità, anche molto maggiore, visto che già di loro erano processori da pochi MHz.

Sicuramente è corretto ma non è sufficiente a rendere l'idea a chi non ha mai usato quei computer e non ha mai fatto quei lavori.

La parte magazzino è stata descritta, vogliamo aggiungere anche il calcolo di decine di rate di ammortamento di piani di finanziamento? Il cliente dice "ma se anticipo 200 paperdollari quanto devo pagare?" Click (no col mouse ma con la tastiera) ed ecco nuove 50 rate calcolate al volo da scorrere su e giù per pagine.
Oppure, ma se moltiplico due sinusoidi di frequenza X e Y, cosa ottengo? Sono migliaia di punti da calcolare e graficare, mica mi metto a farlo a mano e disegnarli sulla carta millimetrata...
Queste macchine, lasciando da parte il "cervello elettronico" alla Mike Buongiorno, si chiamavano calcolatori elettronici, e servivano a calcolare. Che poi i calcoli oggi permettano (anche) di vedere film e consultare forum, è un'evoluzione tecnica, non lo scopo a cui si pensava inizialmente.

un esempio di quello che si poteva fare una volta con questi PC che "oggi è impossibile realizzare"

La loro semplicità software (il BASIC è praticamente un comando -> un effetto, senza tanta teoria) permetteva da subito di creare programmi interattivi senza doversi fare carico di tutto quello che serve oggi, leggevi la tastiera direttamente, producevi un suono con una sola istruzione ecc. La semplicità hardware e l'accesso al bus del processore permetteva di collegarsi con pochissimi integrati logici per fare il semaforo di Maggi. Il C64 se non ricordo male aveva anche una apposita user port parallela dedicata proprio a questi usi.
Per tanti versi anche i primi PC "IBM compatibili" con l' MS-DOS erano facilmente usabili per scopi hardware: le frequenze in gioco erano ancora basse, e il bus ISA era facilmente interfacciabile, ci avevo fatto un lettore di numeri composti col disco combinatore di un vecchio telefono (GW-BASIC e poche istruzioni assembly), ma anche un rudimentale campionatore audio prima delle soundblaster.
Oggi tutto questo va demandato a circuiti esterni simil Arduino, con vantaggi da qualche punto di vista, e limitazioni in altri. No, un PC moderno non ha più modo di essere collegato direttamente a circuiti hardware personali, e la programmazione richiede tanta tanta teoria in più.

Però vedete che EcoTan programmava in quickBasic su quelle macchine. Quindi la programmazione BASIC c'era e anche per i giochi.

Certo che si, il mio primo programma in assoluto era un gioco in BASIC, il classico missiletto da sparare dal basso contro un nemico che si muoveva in alto. E ne sono seguiti altri, anche in GW-BASIC e Turbobasic (il concorrente Borland del Quick-BASIC). Ma poi il BASIC ha mostrato il limite più grande, la mancanza dell'allocazione dinamica della memoria per gestire grandi strutture di dati variabili, e allora è venuto il turno del Pascal (che considero praticamente alla pari col C ma un po' più semplice e ordinato). E poi di Python, da questo punto di vista ancora più comodo del Pascal.

Insomma il "C++", rispetto al "C" è realmente un passo avanti o si tratta di un mezzo passo in dietro?

Se devi mangiare un grande pentolone di piselli (quelli con la cipolla e il prezzemolo), e hai a disposizione uno stuzzicadenti, un cucchiaino da the, un cucchiaione da minestra, cosa useresti? Ecco, il paragone è più o meno questo, ma per contestualizzarlo in modo pratico bisognerebbe scendere in dettagli tecnici della programmazione che diventano evidenti solo dopo molta esperienza (Python in questo caso è un mestolone).

Mi par di capire che la questione "assembly vs assember"

È un discorso che non finirà mai. La parola "assembler" significa assemblatore, cioè quel programma che legge il codice assembly e produce il corrispondente codice macchina, cioè i byte direttamente eseguibili dal processore. È sempre stato un uso dire programmo in assembler, ma non è mai stato realmente corretto.

[fosforiverdi]

[56] lelerelele--------------

Ciao lelerelele, il modo in cui hai riportato quanto detto da me non mi soddisfa.
Ovviamente il C64 aveva un sistema operativo. Io parlavo di un interprete di comandi, come le varie shell tipo Bash o Zsh.
Questo componente può essere leggerissimo, tanto che esiste una versione minimale anche in GRUB, per fare un esempio.

Dici che non si utilizzavano programmi BASIC ma gli altri utenti non dicono esattamente questo, dicono che era un misto BASIC e Assembly (anzi, loro dicono Assembler).
Sicuramente non programmavi in codice macchina, perché non lo fa nessuno, usavi anche tu il codice Assembly (che loro chiamano Assembler).
Il fatto che tu non usassi mai codice BASIC quindi era una scelta, non una necessità assoluta.
Certamente da quello che ho capito scrivere programmi in BASIC era possibile e comune ma occorreva ricorrere all'Assembly per limitare il consumo di RAM.
Questo non lo dico io, lo dicono gli altri, quindi se non sei d'accordo con loro devi farlo presente a loro.

Ultima cosa: si chiama C64, non C54. Giusto per non confondere chi legge.
Grazie per avermi risposto.


[57] claudiocedrone------------

Va bene Claudiocedrone, userò i tag.
Un inverter trasforma in alternata la corrente continua, got it. Più semplice di quanto pensassi.
Si può dire che è l'opposto di un "raddrizzatore di tensione con ponte a diodi"?

Chi li conosceva (gli inverter) prima che noi (o voi) pensassimo che potessero esistere? Maggi? Ma non mi sembra una cosa complicatissima.

[58] Etemenanki------------

OK Etemenanki, non sei un programmatore. Però uno che fa esperimenti come te un'idea deve pur avercela sui vari paradigmi.
Dal momento che persino io ne ho una, anche se basata principalmente su impressioni, penso che tu possa tranquillamente avere la tua.

Quindi non siete contro Windows, mi fa piacere, perché i fanatici non mi piacciono.
Windows ha sicuramente il merito di aver portato i PC nella case di tutti, per me questo è già un grande valore.

Il fatto che sia sempre più pesante secondo me è parte di un accordo commerciale con chi produce hardware.
Un modo per rendere le macchine obsolete più in fretta di quanto accadrebbe normalmente.
Io sono passato a Linux per questo, perché con Linux puoi usare macchine considerate ormai vecchie quasi alla pari dei PC oggi sul mercato.
Questo perché si può scegliere molte soluzioni fra le interfacce grafiche, ma ho sempre pensato che sia possibile alleggerire anche Windows, solo che non ho mai approfondito.
In realtà il motivo principale per cui uso Linux è che è gratis.

[59] lelerelele------------

Non direi che tutto o quasi tutto il software gira su Windows, come dice lelerele, direi piuttosto che il software disponibile per Windows è maggiore.
Però io sono 2 anni che uso solo Linux e non ho sentito tantissimo questa carenza. Dipende ovviamente da cosa fa uno, non metto in dubbio che in certi casi Windows o macOS siano una scelta obbligata.


[60] mario_maggi------------

Quindi dici che quel computer (Honeywell Microsystem 6/20) era utilissimo per :
- gestire l'amministrazione (troppo generico)
- gestire il magazzino... (inventario: ne abbiamo già parlato)
- "con le rispettive valorizzazioni variabili neol tempo " (questa mi suona come supercazzola - https://it.wikipedia.org/wiki/Supercazzola )
- per lanciare gli ordini a fornitori (OK, questo sembra utile ma è collegato con il discorso inventario)
- * per avere un termine di consegna attendibile (in che modo si ottiene questo risultato?)
- "Il computer teneva conto anche delle ore di lavoro" (poco chiaro, anche l'orologio fa questo in un certo senso)
- "e della disponibilità dei banchi di collaudo " (poco chiaro )

Sicuramente ora vorrai ammazzarmi ma io non sto negando il fatto che queste macchine fossero utili. Dico solo che quello che tu hai visto e sperimentato di persona non è cosi facile da comprendere per chi ti legge senza averne alcuna esperienza.
Ad ogni modo io sono disposto a credere che per voi fossero veramente utili. Ci credo perché tu ne sembri convinto, però non sono riuscito a figurarmi la cosa, anche per via di alcune ammissioni che tu hai fatto in precedenza, ovvero che era "terribilmente lenta" e che gestire l'output "era un casino".
Capisco che trasmettere un'esperienza tramite testo non è affatto facile e probabilmente tu non hai il tempo di scendere nei dettagli.
Spero quindi che capirai la mia difficoltà nel farmi un quadro soddisfacente.
Molti diranno di non avere avuto questa difficoltà, dal mio punto di vista questo non è un motivo di vanto.

Quello che volevo sapere sul SC/MP invece era come avevi collegato le lampadine al computer. Ora parli di transistor ma io credo che per creare un semaforo in realtà un computer non sia affatto necessario. Puoi creare un circuito alimentato che funziona come un semaforo, questa è una cosa. Io volevo capire quale era l'interfaccia fra il PC e le lampadine (o tutto quello che costituiva il semaforo), ma se non te lo ricordi fa nulla, dopo 45 anni è perfettamente comprensibile.

Ciao.

[65] djnz------------

Credo che tu djnz mi hai dato una buona risposta : " Il BASIC per sua natura è già un interprete comandi".
Questo spiega molto ma non tutto.
A parte il fatto che, secondo Wikipedia il sistema operativo del C64 era composto da 3 componenti: " Il KERNAL; Il monitor in linguaggio macchina; L'interprete BASIC ".
Questo significa che il solo interprete BASIC non poteva essere considerato come "IL" sistema operativo, ma solo come una parte.
Dico questo perché tu dici "la cosa più immediata era fargli fare anche la funzione di mini sistema operativo di quelle macchine".

Riguardo a questi tre componenti si legge che :

KERNAL :
"è un insieme di routine preposte alla gestione dell'input/output" (ovvero dello schermo, della tastiera e di tutte le varie periferiche)"

Il monitor in linguaggio macchina:
"era il programma preposto alle funzioni di immissione del testo da parte dell'utente "

L'interprete BASIC :
"era di diretta derivazione del Microsoft BASIC e consentiva all'utente di scrivere i programmi in BASIC, e più in generale di interagire con il sistema operativo, immettendo dei comandi nel modo diretto... In questo modo era possibile interagire con la macchina"


Se ne deduce che sicuramente l'interprete BASIC aveva una funzione simile ad un interprete di comandi ma anche il cosiddetto "monitor in linguaggio macchina" sembra facesse qualcosa di simile.
Probabilmente le due cose interagivano fra loro e dialogavano con il KERNAL tramite qualcosa di simile alle "chiamate di sistema" dei moderni PC.

Quindi djnz, correggimi se sbaglio, quello che vuoi dire è che il contenuto delle ROM veniva processato senza passare dalla RAM e in questo modo si lasciava libera la RAM per i dati da manipolare.
Però i comandi utente dovevano per forza di cose essere letti nella RAM, prima di essere processati. Ad ogni modo i comandi non occupano molto spazio.
Anche un programma BASIC doveva essere letto in RAM, ma anche in questo caso non l'interprete, quindi entro certi limiti la programmazione in BASIC era possibile ma ovviamente la programmazione Assembly era preferibile.

Penso che questa spiegazione possa essere soddisfacente, siete d'accordo?

----

Invece poi sempre tu djnz intervieni per il discorso del Honeywell Microsystem 6/20.
La prima cosa che dici è "vogliamo aggiungere anche il calcolo di decine di rate di ammortamento di piani di finanziamento? ".
Non lo so? Lo vogliamo aggiungere? Vuoi dire le rate per pagare i debiti? Per finanziamenti penso tu intenda "prestiti".
Quindi una banca ti fa un prestito e stabilisce un piano di rimborso, ovvero delle scadenze e delle cifre che corrispondono alle rate.
Teoricamente è la banca a fare i calcoli, tu devi solo ricordarti quando è ora di pagare la rata, come facciamo noi per pagare le bollette del gas, acqua e luce, anche se molti ormai le pagano in automatico.
Ti serve un computer per questo? Forse ad una azienda si, non lo so. probabilmente è una questione di dimensioni. Se hai centinaia di fornitori e centinaia di clienti tenere nota di tutte le scadenze diventa difficile.
Io ho avuto a che fare con aziende ma non aziende di grandi dimensioni. Ovviamente oggi anche l'artigiano usa il computer ma negli anni 80 dovevi avere veramente una grossa azienda per avere bisogno di un computer, forse questo è il nocciolo della questione.


Comunque anche l'esempio del cliente che vuole anticipare un pagamento di 200 paperdollari. Alla fine sono calcoli aritmetici: divisioni, addizioni, sottrazioni, moltiplicazioni..... non è cosi?
L'esempio delle sinusoidi non so se posso accettarlo. Io ho chiesto a mario_maggi esempi reali relativi alla sua attività, non esperimenti universitari. E' fuori tema rispetto alla mia domanda originale.

----

Sempre djnz mi risponde sul "cosa si poteva fare con i vecchi computer che oggi non è possibile", avevo chiesto degli esempi:
Beh, da quello che leggo mi pare che il discorso di fondo sia che con poche istruzioni facevi molte cose. Forse se paragoniamo il linguaggio Assembly di oggi a quello di ieri la cosa quadra ma oggi non è necessario ricorrere all'Assembly. Per rendersi le cose facili si può usare qualche linguaggio di scripting, alcuni molto facili da utilizzare. Persino io una volta ho scritto un programma in Javascript.

Torna fuori il semaforo di Maggi, però lui non ha usato un C64, era un "SC/MP di National " [38]. Comunque accetto la risposta ugualmente, si usava quindi una porta parallela. Di te djnz mi piace che spesso rispondi alle domande per quello che sono, non tutti lo fanno.

Perché la frequenza bassa dei bus era un fattore utile ad interfacciare dispositivi all'hardware? non mi è chiaro.

Cosa era e a cosa serviva il "lettore di numeri composti col disco combinatore di un vecchio telefono"?

E il campionatore era quello che si intende oggi? Uno strumento musicale digitale o qualcosa di più simile ad una scheda audio?

Dici "No, un PC moderno non ha più modo di essere collegato direttamente a circuiti hardware personali" Ok, questa è una risposta ad una mia domanda. Grazie.

Quindi hai usato vari tipi di BASIC, il Pascal, il C e Python. Allora tu sei un vero programmatore, non come Etemenanki. Ma di professione o a livello amatoriale?

Si va bene "piselli e mestoli" ma io volevo un confronto tra programmazione tipo "procedurale" e programmazione "orientata agli oggetti".
Ho capito il discorso dei mestoli, con Python non ti devi preoccupare di creare certe cose, sono già presenti, mentre in C te le devi costruire di volta in volta.
Si parlava di spreco di codice e io ho il sospetto che linguaggi tipo Java siano negativi da questo punto di vista. Essendo C++ orientato agli oggetti a differenza del C ma essendo questi in qualche modo parenti stretti ho scelto loro perché mi pareva l'esempio migliore.
E del linguaggio ADA cosa mi dite? Non sembra molto usato eppure dovrebbe essere uno dei migliori.

Dici le stesse cose che leggo in Wikipedia su Assembly e Assembler. Per conto mio ho già deciso: è più corretto dire Assembly ma non starò a correggere chi userà il termine Assembler ogni volta che lo sento.


DarwinNE ho aperto il tuo gioco e mi sono trovato davanti l'opzione per cambiare il font. Non so come abbia fatta a non vederla le altre volte. Penso che avrei dovuto prestare maggiore attenzione. Con il font normale il gioco va benissimo.

[MarcoD]

Anche se nel tempo trascorso ho acquisito sempre più informazioni e ne acquisisco sempre meno di nuove , ho imparato il nuovo termine KERNAL, credevo fosse un errore di battitura di kernel (in Italiano nucleo ), invece esiste:
Il KERNAL (acronimo per Keyboard Entry Read, Network, And Link) è il nome del kernel del sistema operativo residente nella ROM degli home computer ad 8 bit prodotti da Commodore International. da https://it.wikipedia.org/wiki/KERNAL

thanks fosforiverdi

[DarwinNE]

A parte il fatto che, secondo Wikipedia il sistema operativo del C64 era composto da 3 componenti: " Il KERNAL; Il monitor in linguaggio macchina; L'interprete BASIC ".

Le ROM del C64 non contengono un monitor. Il C128 invece ne aveva uno disponibile a cui si accedeva (appunto) con il comando MONITOR direttamente da Basic. Quello che si chiamava monitor è un programmino che permette di modificare la memoria, vedere il contenuto dei registri, introdurre istruzioni mnemoniche. Il VICE ne contiene uno, per esempio.

Io usavo un monitor sul C64 chiamato ZOOM, ma dovevo caricarlo da disco. Altri usavano utility da cartuccia.
Per il resto, sarebbe troppo lungo commentare punto per punto su quello che fa esattamente il basic sul C64 qui sul forum. Dopo aver letto il manuale utente (che sicuramente avrai già fatto), consiglierei caldamente di leggere la Guida di riferimento del C64:

https://archive.org/details/c64guidadir ... 3/mode/2up

E' uno stile di scrittura un po' desueto su certi punti, ma è un manuale che ho apprezzato, tanti anni fa.

[lelerelele]

[56] lelerelele--------------

Ciao lelerelele, il modo in cui hai riportato quanto detto da me non mi soddisfa.
Ovviamente il C64 aveva un sistema operativo. Io parlavo di un interprete di comandi, come le varie shell tipo Bash o Zsh.
Sicuramente non programmavi in codice macchina, perché non lo fa nessuno, usavi anche tu il codice Assembly (che loro chiamano Assembler).
Ultima cosa: si chiama C64, non C54. Giusto per non confondere chi legge.
Grazie per avermi risposto.

Come ho scritto non conosco il C64, avevo lo spectrum, che sistema avesse su non lo so.

Io programmavo scrivendo sulle locazioni di memoria i codici 255(ret), 155,45,eccc, sono passati una meare di anni, non mi ricordo bene, in definitiva scrivevo i codici che legge il processore, credo che sia codice macchina. No?

evidentemente mi sono sbagliato a scrivere C54.


a proposito, uso software di programmazione microprocessori, programmazione windows (visual studio), cad elettrico PCB, cad meccanico 3D professionali, solidowrks, Catia, 3dsMax...... credo che farli girare su altri sistemi diversi da windows sia difficile, se così non è fammelo sapere che cambio immediatamente sistema!

Se da hobbista scriivo inesattezze spero che siate comprensivi.

saluti.

[djnz]

Sicuramente non programmavi in codice macchina, perché non lo fa nessuno, usavi anche tu il codice Assembly

Circa. A quei tempi si assemblava anche a mano. L'assembly si poteva scrivere su foglioni di carta e a fianco ci si costruiva la codifica in linguaggio macchina aiutandosi con le tabelle di conversione. Poi i byte così ottenuti si caricavano in memoria uno per uno con l'istruzione POKE

Andando ancora più indietro nel tempo, si caricavano direttamente in binario tramite interruttori, e su questi sistemi Gate$ (assieme al collega Allen) ha iniziato la sua fortuna ideando uno dei primi BASIC.

Chi li conosceva (gli inverter) prima che noi (o voi) pensassimo che potessero esistere?

Ho visto il raddrizzatore di una radio (moolto vecchia) formato da un motore in alternata seguito da una dinamo. Immagino che, prima dell'elettronica allo stato solido, facessero anche l'opposto.

secondo me è parte di un accordo commerciale con chi produce hardware

Nella maggior parte dei casi non serve tirare in ballo i complotti, è sufficiente l'enorme risparmio di tempo-programmatore ottenibile dalla non ottimizzazione. Un altro aspetto è che gli algoritmi attuali devono gestire molte più operazioni/situazioni e dati rispetto a una volta. E un altro ancora è che la lunghezza della parola della singola cella di memoria è cresciuta, dai primi 4 bit siamo a 64, quindi un valore che magari prima ci stava in 4 bit, adesso ne "spreca" sedici volte tanti.

"Il computer teneva conto anche delle ore di lavoro" (poco chiaro, anche l'orologio fa questo in un certo senso)

Ogni giorno le attività di tutti i dipendenti vengono caricate per tipologie e durata in un database, così il software può fare tutte le somme per categorie (in modo arbitrariamente complicato) e individuare quanto tempo e denaro se ne va per cosa. Considera di applicare questo processo a centinaia o migliaia di dipendenti per tutti i giorni dell'anno.

secondo Wikipedia il sistema operativo del C64 era composto da 3 componenti: " Il KERNAL; Il monitor in linguaggio macchina; L'interprete BASIC"

Ogni sistema si può scomporre/analizzare in sottosistemi. E questi sottosistemi possono essere più o meno espliciti, chiari, separati, oppure confusi o mescolati tra loro, a seconda di come è stata progettata l'architettura hardware o software. Ma per forza devono esserci sezioni della ROM che si occupano del sistema in generale, del linguaggio, e dell'input/output utente.

quindi entro certi limiti la programmazione in BASIC era possibile ma ovviamente la programmazione Assembly era preferibile

Quasi tutto quello che ho scritto su Spectrum e primi MS-DOS era in BASIC, l'assembly serviva dove il BASIC non arrivava (esempio ottimizzazione di velocità e memoria), e il BASIC serviva dove scrivere in assembly sarebbe stato solo un incubo di fatica e tempo sprecati (esempio calcoli matematici o grafica).

Teoricamente è la banca a fare i calcoli

Esatto, e i calcoli li fa una di quelle macchine appositamente programmate, mica l'impiegato della banca. Ho fatto l'esempio delle rate di un finanziamento perché è un caso reale di cui mi sono dovuto occupare in COBOL e RPG per una azienda EDP dove ho lavorato un anno appena finite le scuole.

Alla fine sono calcoli aritmetici: divisioni, addizioni, sottrazioni, moltiplicazioni..... non è cosi?

Alla fine sono tutte micro operazioni elementari, si, ma milioni, miliardi al secondo...

L'esempio delle sinusoidi non so se posso accettarlo

Non accetti le applicazioni scientifiche? La domanda a cui ho risposto era: "Ma mi chiedo a cosa potessero servire questa macchine cosi limitate. Scrivere testo penso ma non molto altro."

E' fuori tema rispetto alla mia domanda originale.

Hai un tema da svolgere?

oggi non è necessario ricorrere all'Assembly

Su PC certo, per tempo/fatica richiesti e complessità dei sistemi, oltre che per la loro attuale velocità. In assembly Z80 avevo scritto un risolutore di master mind brute force, ma oggi in Pyhton richiederebbe un centesimo della fatica e girerebbe infinitamente più veloce (certo occuperebbe anche oltre cento mega di RAM invece che poche centinaia di byte). Però chi scrive driver per periferiche potrebbe doverlo usare ancora. Oppure chi sviluppa su microcontroller. Ma per la maggior parte dei compiti attuali (su PC) perfino il C è di livello troppo basso, con C++ va già meglio perché è ad oggetti, ma oggi si usano più proficuamente linguaggi a maggior livello di astrazione (Python Java JavaScript PHP ecc) o direttamente script di sistema (bash ecc).

Perché la frequenza bassa dei bus era un fattore utile ad interfacciare dispositivi all'hardware?

Perché i segnali non erano più veloci di 200..250 ns. Si potevano costruire circuiti "artigianali" a fili volanti, lunghi decine di cm, con integrati comunissimi, e tutto funzionava senza problemi, vedi questi sistemi Z80 "scultura":
https://hackaday.com/2019/01/15/twelve- ... ooking-at/
http://www.jackdollhausen.com/shebang/w ... 0/z80p.htm
Addirittura per errore avevo dimenticato il collegamento GND di una EPROM su uno stampato e il sistema funzionava grazie al GND prolungato degli alimentatori sul filo di terra, mi sono accorto dell'errore solo quanto sono passato all'alimentatore unico.

Cosa era e a cosa serviva il "lettore di numeri composti col disco combinatore di un vecchio telefono"?

A niente, solo un esperimento come tanti altri per testare le varie possibilità (sei righe di GW-BASIC e ventidue istruzioni in codice macchina).

Uno strumento musicale digitale o qualcosa di più simile ad una scheda audio?

Un semplice convertitore ADC a 8 bit ad approssimazioni successive, un po' di GW-BASIC e una routinetta assembly, quando ancora su MS-DOS si potevano disabilitare tutti gli interrupt e prendere il controllo totale della macchina.

Dici "No, un PC moderno non ha più modo di essere collegato direttamente a circuiti hardware personali" Ok, questa è una risposta ad una mia domanda. Grazie.

Importante però ricordare la parola "direttamente", cioè collegandosi fisicamente ai circuiti del PC e comandando quanto collegato direttamente con un programma sul PC. Oggi, a meno che la motherboard non disponga di una porta parallela, ci si "collega" in altro modo, attraverso periferiche USB o ethernet. Ma non è più "diretto", si passa sempre attraverso almeno due sistemi che si parlano tramite un protocollo e su cui girano software distinti.

Ho capito il discorso dei mestoli, con Python non ti devi preoccupare di creare certe cose, sono già presenti, mentre in C te le devi costruire di volta in volta.

Questo si applicherebbe anche in assembly, basta usare le librerie fatte da altri e oplà è tutto più semplice. Si, vero, ma la differenza appunto non è questa. Si tratta di un "attrezzo da costruzione" concettualmente diverso messo a disposizione dai linguaggi OOP, che permette di fare (pensare/progettare) le cose in modo più semplice e veloce:
https://forum.ubuntu-it.org/viewtopic.p ... 1#p4450841

Non sembra molto usato eppure dovrebbe essere uno dei migliori

ADA non lo conosco, ma ogni linguaggio è "migliore" in uno specifico ambito di utilizzo in cui le sue peculiarità si adattano bene... e "peggiore" dove le sue peculiarità diventano un intralcio. Credo che il linguaggio universale, nel senso di "comodo" e più produttivo di tutti gli altri, per tutti i possibili ambiti di utilizzo, non esisterà mai.