di  -  mercoledì 10 marzo 2010

La corsa alle prestazioni e, soprattutto, ai RISC era iniziata con la precedente generazione e proseguiva per dimostrare, se ancora ce ne fosse stato bisogno, che i CISC non erano affatto spacciati, come alcuni specialisti del settore avevano, al contrario, profetizzato.

L’80486 di Intel e il 68040 di Motorola avevano mostrato che eseguire la maggior parte delle istruzioni in un solo ciclo di clock era possibile anche per questi illustri rappresentanti della macrofamiglia, ma il prossimo scoglio si presentava arduo da superare: eseguirne di più in un solo ciclo con un’ISA avente opcode a lunghezza variabile.

Il problema nasce dalla necessità di stabilire dove finisce un’istruzione e, di conseguenza, dove inizia la successiva o, peggio ancora, le successive. I RISC hanno vita estremamente facile perché le loro istruzioni sono a lunghezza fissa (generalmente 32 bit; opcode più lunghi si hanno con le architetture VLIW, che però “impacchettano” più istruzioni), e risulta quindi banale individuare immediatamente l’istruzione corrente e tutte quelle successive.

Coi CISC calcolare l’inizio dell’istruzione successiva è già un bel rompicapo perché, manco a dirlo, bisogna prima conoscere la lunghezza di quella in esame; e così via per quelle a seguire. La difficoltà sta nel fatto che queste informazioni si possono recuperare soltanto a runtime, quando cioè il codice viene eseguito, perché limitandoci a leggere un blocco di dati dalla memoria non si sa se il primo byte è anche il primo di un’istruzione, oppure ci troviamo nel bel mezzo di una di esse (che, quindi, inizia nel blocco precedente e prosegue in quello attuale).

Non si tratta di problemi impossibili da risolvere, poiché allo scopo esistono soluzioni anche molto efficienti che gli ingegneri di Intel e Motorola prima, e AMD in seguito, hanno tirato fuori dal cappello per risolverli. Ma, come capita spesso, ciò è frutto di compromessi che, nello specifico, si traducono in un maggior numero di transistor da impiegare e consumi più elevati.

Con queste doverose premesse è Intel che, al solito, anticipa Motorola presentando l’arcinoto Pentium, CPU superscalare in order dotata di due pipeline (sebbene non simmetriche: soltanto la prima era in grado di eseguire tutte le operazioni). Il 68060, erede del 68040 (e non del 68050, come abbiamo avuto modo di appurare), arriva l’anno successivo, nel 1994, con caratteristiche simili.

Due milioni e mezzo di transistor per questa CPU sono più del doppio rispetto agli 1,17 del suo predecessore, ma ciò non si riflette in almeno un raddoppio delle prestazioni. Motorola, infatti, dichiara più di 110 MIPS e circa 18 MFLOPS a 75Mhz (in realtà ho trovato riferimenti per 12 MFLOPS a 50Mhz). Mentre un ipotetico 68040 a 75Mhz con la sua singola pipeline dovrebbe arrivare rispettivamente a 60 MIPS e 10,5 MFLOPS (anche se su queste misure mi riservo alcune osservazioni, in particolare alla fine dell’articolo).

Già da questi numeri risulta evidente che una superpipeline non può certo garantire un andamento lineare delle prestazioni. Bisogna sempre tener conto che tante volte esistono delle dipendenze fra le istruzioni che ne impediscono l’esecuzione parallela, costringendo il processore alla loro “serializzazione“.

Nonostante tutto e numeri alla mano il 68060 sembra fare un ottimo lavoro, ma ciò è merito anche della possibilità di eseguire un’istruzione di salto per ogni ciclo di clock oltre alle due intere, in modo da minimizzare l’impatto dei cambiamenti nel flusso dell’esecuzione. I salti, in sostanza, sono eseguiti “a costo zero” (zero cicli), ma a condizione che siano “predetti” correttamente. Per meglio comprenderne il funzionamento vediamo intanto il diagramma a blocchi:

Come per il 68040, l’architettura è completamente Harvard, quindi con un’unità (e bus) dedicata per le istruzioni, una per i dati, e un controller per il bus esterno, tutti indipendenti. Le divergenze si cominciano a notare spostando l’attenzione verso il macroblocco a sinistra (quello dell’unità di esecuzione), che risulta a sua volta suddiviso in: un’unità per il fetch delle istruzioni, una con due pipeline per l’esecuzione delle operazioni intere, una per quelle in virgola mobile, e uno stadio finale per la scrittura dei risultati.

Un’altra differenza è rappresentata dalla presenza di ben 10 stadi per la pipeline intera, che risulta decisamente più lunga paragonata alla precedente a 6 stadi. Ciò si è reso necessario per separare nettamente la fase di fetch delle istruzioni (distribuita su 4 stadi) da quella della loro effettiva esecuzione (che adesso fa uso di due pipeline di 4 stadi allo scopo), disaccoppiando e rendendo (parzialmente) indipendenti le due unità.

Il funzionamento dell’unità di fetch è molto semplice. Il primo passo (o stadio che dir si voglia) riguarda ovviamente il calcolo dell’indirizzo virtuale dell’istruzione da eseguire, il cui risultato viene passato alla cache istruzioni. Il successivo si occupa di prelevare l’opcode dalla cache. Il terzo effettua una predecodifica dell’istruzione. Infine il quarto inserisce l’istruzione preelaborata in un’apposita coda delle istruzioni (IB, Instruction Buffer) pronte per essere eseguite.

In questo scenario s’inserisce il meccanismo di controllo (o predizione) dei salti facendo uso di una cache associativa a 4 vie che contiene fino a 256 indirizzi virtuali che rappresentano gli ultimi target processati. Quando l’unità di fetch predecodifica un’istruzione e si accorge che si tratta di un salto, va a controllare in questa cache se l’indirizzo a cui saltare si trova nella suddetta cache, e analizza la sua “storia”.

Se si tratta di un salto “taken” (quindi con elevate probabilità che risulti “preso”), la coda delle istruzioni da eseguire viene svuotata e procede immediatamente a richiedere alla cache le istruzioni a partire dal nuovo indirizzo. Se tutto va bene e il salto risulta effettivamente “preso”, l’unità di esecuzione nemmeno si accorge del cambiamento di flusso, in quanto si troverà a elaborare le istruzioni prelevate dal target.

In questo modo è come se l’istruzione di salto non venisse effettivamente eseguita, in quanto non arriva all’unità di esecuzione. Ovviamente questo meccanismo non funzionerà se non è possibile stabilire che il salto è “taken”, oppure se la predizione si dovesse rivelare non corretta, andando incontro a una più o meno pesante penalizzazione (fino a 7/8 cicli di clock, a seconda del tipo di istruzione).

L’elemento di giunzione fra l’unità di fetch e quella di esecuzione è rappresentato dalla coda delle istruzioni (IB). Si tratta di una coda di tipo FIFO (First-In, First-Out) di 96 byte, da cui viene prelevata una coppia di istruzioni da eseguire in ordine (come già detto, non si tratta di una pipeline out-of-order) nelle rispettive pipeline intere; se, invece, è riconosciuta un’istruzione che coinvolge l’FPU, viene passata a quest’ultima se non ci sono altre istruzioni in esecuzione nella pipeline dedicata, che può processarla in parallelo a quelle intere.

Il numero, 96, mi suona decisamente strano per diversi motivi. Il primo è che risulta un multiplo di una potenza di due. Il secondo è che, da buon programmatore di questa famiglia di microprocessori, so che una singola istruzione può arrivare alla bellezza di 22 byte di lunghezza. 96 non risulta divisibile per 22, per cui l’IB potrebbe contenere fino a 4 istruzioni “e cocci”. Il terzo è che le istruzioni presenti nell’IB sono a lunghezza fissa, ed è anche il motivo per cui l’unità di fetch le predecodifica: per portarle a una forma “canonica” facile da decodificare per l’apposito stadio presente nell’unità di esecuzione (ebbene sì: il 68060 fa uso di una sorta di unità RISC interne estremamente semplici per l’effettiva esecuzione!).

La soluzione a questo dilemma arriva soltanto spulciando lo user manual fino al capitolo dedicato ai tempi d’esecuzione delle istruzioni, in cui viene spiegato in che modo e in quali condizioni l’unità di esecuzione riesce a eseguire fino a due istruzioni nello stesso ciclo di clock.

Senza perdere tempo nella disamina dei diversi e numerosi casi, dipendenze e limiti (che esulano dallo scopo di quest’articolo), viene spiegato che un’istruzione di MOVE che esegue due accessi alla memoria (quindi entrambi gli operandi puntano a una locazione di memoria) viene divisa in due istruzioni più semplici: la prima per leggere il dato, e la seconda ovviamente per scriverlo.

Poiché la MOVE è l’unica istruzione a presentare la possibilità di specificare un qualunque indirizzamento complesso verso la memoria (ogni modalità d’indirizzamento arriva a richiedere fino a 10 byte per la sua codifica) per entrambi gli operandi, il conto è presto fatto (2 byte per l’opcode, più 10 ciascuno per i due operandi), e il motivo della suddivisione condivisibile (essendo l’unico caso, e il più difficile da manipolare).

Tolta la MOVE, una qualunque altra istruzione arriva al più a 14 byte (4 per l’opcode e 10 per la modalità d’indirizzamento). Da tutto ciò mi sono fatto l’idea che i 96 byte possano contenere 6 istruzioni da 16 byte fissi predecodificate, da girare poi alle unità di esecuzione “RISC” (chiamate internamente OEP, Operand Execution Pipeline). E i conti sembrano finalmente tornare.

Rimanendo su conti e numeri, è impressionante notare l’enorme lavoro fatto da Motorola per migliorare i tempi d’esecuzione delle singole istruzioni, che risultano decisamente ridotti anche confrontati col 68040, il quale aveva già stupito coi suoi 20 MIPS a 25Mhz.

Merito di una sezione di Address Generation Unit (AGU) particolarmente efficace, essendo in grado di calcolare gli indirizzi della stragrande maggioranza delle modalità d’indirizzamento richiedendo… zero cicli di clock (ovviamente perché il calcolo viene effettuato nell’apposito stadio di pipeline e, quindi, “mascherato”), com’è possibile vedere dalla seguente tabella:

Giusto per dare un’idea, il suo predecessore era in grado di fare lo stesso soltanto con le 7 modalità più semplici, mentre con le altre le penalizzazioni cominciavano a diventare consistenti, tanto da arrivare a 11 cicli di clock per la modalità indiretta più complicata (l’ultima), per la quale i 3 miseri cicli di clock del 68060 fanno quasi sorridere (specialmente pensando a tutto il lavoro che viene svolto dall’AGU in questo caso).

Anche sul fronte delle singole istruzioni, come accennavo prima, molto è stato fatto. Basti pensare che una moltiplicazione 32×32->32 bit con le modalità d’indirizzamento “a zero cicli” (di calcolo dell’indirizzo, come già detto) richiede a malapena 2 cicli di clock (prima almeno 20), e lo stesso dicasi per l’istruzione CHK per il controllo dei limiti di un array (prima servivano almeno 8 cicli).

Persino le istruzioni che manipolano campi di bit sono diventate appetibili, richiedendo da un minimo di 6 a un massimo di 16 cicli di clock per le più complicate e che fanno anche uso delle famigerate modalità d’indirizzamento indirette verso la memoria.

In generale, fatta eccezione per il calcolo dell’indirizzo (per il quale fa fede la tabella sopra riportata), la stragrande maggioranza delle istruzioni richiede un solo ciclo. Motorola non si è risparmiata neppure per le istruzioni “legacy” (come quelle che operano su dati packed BCD), per quelle che manipolano i flag del registro di stato, gli shift, i singoli bit, ecc.

Per poter sfamare queste due “bocche” affamate è stato necessario raddoppiare le cache per il codice e i dati, che passano entrambe a 8KB a 4 vie, suddivise in 128 insiemi da 4 linee ciascuna di 16 byte. Rispetto al 68040 c’è un cambiamento per la cache dati, dove spariscono i 4 flag “dirty” (uno per ogni longword), rimpiazzati da uno soltanto, il quale indica che l’intera linea di cache va scritta in memoria (poiché modificata):

Si tratta di una soluzione più semplice, ma che purtroppo può risultare penalizzante perché obbliga a scrivere un’intera linea alla volta, anche se è stata cambiata una sola delle 4 longword. Per mitigare quest’effetto indesiderato, il 68060 fa uso di un nuovo meccanismo: il push buffer.

Una linea di cache dati che risulta “dirty” e dev’essere rimpiazzata (perché un’altra più nuova deve prenderne il posto) viene trasferita in un questo push buffer in attesa che il bus controller si liberi e possa, quindi, procedere alla sua scrittura in memoria, rendendo disponibile il posto per un’altra linea “dirty” da sostituire.

A questo utile strumento ne viene affiancato un altro, lo store buffer. Si tratta di una coda FIFO di 4 elementi, per un totale di 16 byte massimi, che si occupa di raccogliere le operazioni di scrittura generate dagli ultimi 2 stadi della pipeline. Non appena il bus controller si libera e non vi sono altre operazioni pendenti, il dato più vecchio viene finalmente spedito alla memoria.

Si tratta di una funzionalità che contribuisce all’aumento prestazioni generali della CPU, perché la pipeline è in grado di generare una scrittura per ciclo di clock, mentre il bus esterno in genere è più lento e nel caso migliore impiega 2 cicli di clock per memorizzare il dato in una qualunque zona di memoria. In questo modo pipeline e memoria risultano completamente disaccoppiate e possono lavorare al meglio nei rispettivi ruoli, eccenzion fatta nei casi in cui lo store buffer risulti pieno e si presenti una nuova scrittura (che comporta lo stallo della pipeline).

Un’altra differenza col 68040 è data dalla possibilità di bloccare il contenuto delle cache, comprese le ATC (Address Traslation Cache) delle rispettive MMU. Ben più interessante è, però, la possibilità di poter eseguire due accessi contemporanei alla sola cache dati. D’altra parte con due pipeline in esecuzione era prevedibile e auspicabile questa scelta.

Nonostante i tanti elementi attivi, Motorola s’è impegnata molto anche nel cercare di contenere i consumi, presentando apposite istruzioni per forzare la CPU a lavorare in una particolare modalità di “sleep“. Inoltre è possibile utilizzare soltanto metà delle cache, delle ATC delle MMU, disabilitare una pipeline e anche l’FPU, il tutto via software.

Proprio nei riguardi dell”FPU è possibile notare altri cambiamenti, in particolare le istruzioni di somma, sottrazione, moltiplicazione e conversione a intero richiedono soltanto 3 cicli di clock, mentre valore assoluto, cambio di segno, confronto e FMOVE soltanto uno. Non si tratta di cambiamenti eccezionali, ma tali da giustificare l’incremento dei MFLOPS di cui parlavo all’inizio dell’articolo.

Le note dolenti le ho riservate alla fine, perché mi riguardano direttamente come programmatore, in quanto certi rospi sono difficili da ingollare. Di fronte a tanto ben di dio, infatti, non posso che storcere il naso di fronte all’eliminazione di qualche istruzione dall’ISA (MOVEP, CHK2, CAS2, CMP2, moltiplicazioni e divisioni a 64 bit, e alcune istruzioni dell’FPU).

In ogni caso vale quanto già espresso nel precedente articolo sul 68040: si tratta di scelte dovute, di sacrifici necessari sull’altare dell’aumento delle prestazioni per le rimanenti istruzioni. La tendenza rimane, quindi, quella di eliminare le istruzioni più complesse, che avrebbero di conseguenza complicato l’unità di esecuzione deputata alla loro elaborazione (quella primaria).

Pur potendo utilizzare la seconda pipeline soltanto per le istruzioni più semplici (e la primaria per tutto il resto), l’idea che mi sono fatto è di un microprocessore eccezionalmente veloce, tenuto conto di tutto il lavoro effettivamente svolto (e con ciò ricordo che i MIPS, di per sé, non vogliono dire nulla, quando in una sola istruzione è possibile effettuare più “operazioni”).

Un autentico mostro, insomma, e tanto di cappello alla casa madre, ma certamente non per aver mandato prematuramente in pensione una favolosa architettura che ancora oggi gli appassionati rimpiangono amaramente.

71 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    streamX
     scrive: 

    Come al solito, complimenti per l’articolo.

    Anche se si tratta di una testata tecnica, cenni sul riscontro di mercato avrebbero giovato al articolo.

    Questo mostriciattolo ebbe successo o vendette pochissimo ?
    La conclusione sul cambio di isa in favore del powerpc fa supporre di no…

    So che non centra strettamente con il 68060, ma la quota di mercato di Motorola nel arco della vita dei processori 68000 è reperibile ?

    PS.
    Puoi darci un anteprima sui tuoi prossimi articoli ?

    Bye

  • # 2
    Cesare Di Mauro (Autore del post)
     scrive: 

    Non ho una schedule precisa. Spesso capita di cambiarla a seguito di “input” esterni. Posso solo dirti che coi Motorola 680×0 non è finita qui, come pure per l’Amiga, perché nelle prossime settimane avrò modo di scrivere parecchi altri articoli su entrambi gli argomenti.

    Sulle vendite del 68060 e di Motoroal in generale non ho dati. Mi sono occupato soltanto del lato tecnico, con la visione che può avere un programmatore che lavora a basso livello coi microprocessori.

    Comunque il cambio dell’ISA era già in programma da tempo, per cui il destino di questa famiglia, e del suo ultimo rappresentante in particolare, era già segnato (purtroppo).

  • # 3
    D
     scrive: 

    Il prossimo articolo cercherà di spiegare le ragioni della morte di questa eccezionale serie di processori (salvo reinterpretazioni tipo coldfire) ?
    A tutti gli effetti, tirando le somme tra i vari modelli, mi pare di capire che la serie 68k ha conosciuto solo miglioramenti nel corso degli anni, forse qualche passo falso, ma una crescita che non sembrava affetta da previsioni infauste.
    I Power Pc d’altro canto erano veramente discutibili soprattutto nelle prime versioni quindi non riesco a spiegarmi perchè mollare questi per quelli.

  • # 4
    Cesare Di Mauro (Autore del post)
     scrive: 

    Non credo che sarà il prossimo articolo. Al momento ho qualcos’altro di cui vorrei parlare, e nel frattempo devo studiarmi un’architettura nuova per una prossima serie di articoli.

    Il problema dei 680×0 sta nella scalabilità, ed è il motivo per cui, a parte gli accordi commerciali con Apple e IBM, Motorola aveva programmato di dedicarsi ai PowerPC.

  • # 5
    streamX
     scrive: 

    Per degli articoli futuri in chiave retrospettiva suggerirei i DEC Alpha…

  • # 6
    Cesare Di Mauro (Autore del post)
     scrive: 

    Sono in programma, ma fra un bel po’ di tempo.

  • # 7
    imayoda
     scrive: 

    Sparc ?? :D

  • # 8
    Cesare Di Mauro (Autore del post)
     scrive: 

    Alpha, SPARC, MIPS, PowerPC, x86: ti assicuro che di roba di cui parlare per quanto riguarda le architetture dei microprocessori ce n’è a valanga.

    L’unica cosa che manca è il tempo per trattare tutto, per cui abbiate pazienza.

    Comunque non ho intenzione di parlare esclusivamente di processori. La rubrica che tengo ha un nome preciso, e ho intenzione di parlare anche d’altro, intervallando così il tema CPU.

    Nella speranza di non farvi annoiare e tenere alta l’attenzione, ovviamente. ;)

  • # 9
    iva
     scrive: 

    Complimenti per l’articolo, pero’ mannaggia a te Cesare, adesso mi hai fatto venire voglia di 68060 per l’Amiga… provero’ a resistere! :)

  • # 10
    Cesare Di Mauro (Autore del post)
     scrive: 

    Puoi trovare diverse schede acceleratrici col 68060 per il tuo 4000.

    Attualmente il più fortunato è Warfox, che ne ha uno sul suo 1200. :D

  • # 11
    D
     scrive: 

    “Il problema dei 680×0 sta nella scalabilità”

    Intesa in quali termini ?
    Erano stati fatti degli esperimenti che avrebbero mostrato una incapacità di aumentare le prestazioni con l’aumentare della frequenza ? (cosa effettivamente grave)
    Incapacità di operare in sistemi MP oltre un numero ridotto di unità ? (sinceramente cosa poco importante vista la non curanza di motorola verso il mondo pro preferendo gli home computer con le versioni low cost e comunque a quei tempi non si parlava proprio di sistemi a più core)
    Colli di bottiglia a causa dell’architettura, ereditati magari proprio dal 68000 e lasciati lì a marcire con il risultato che i programmatori si prendevano libertà che segavano la compatibilità futura dei programmi ? (cosa molto grave)

    Secondo me ci starebbe proprio un approfondimento su questa cosa, perchè allo stato attuale, la scelta della nuova isa sembra dettata più da un capriccio.

  • # 12
    Cesare Di Mauro (Autore del post)
     scrive: 

    E’ in programma, è in programma: lo giuro! :D Non fatemi dire altro. :P

    Anche se in parte qualcosa si capisce, specialmente con gli ultimi articoli. O:-)

  • # 13
    Warfox
     scrive: 

    Fortunato na mazza.. :) ai tempi (10 e piu’ anni fa’) la pagai qualcosa come 1.200.000 delle vecchie lire.. per quello che non la mollo :P
    Pensare che avrei voluto comprare la PPC 604e accoppiata a 060 ma costava un bordello di soldi…

    Se volete comunque posso fare qualche test con lo 060. ASM e Seka sono presenti sull’HDD.

  • # 14
    Cesare Di Mauro (Autore del post)
     scrive: 

    Ti manca il PPC per poterlo confrontare col tuo mostriciattolo. Sarebbe stato bello poter avere dei benchmark a riguardo.

    @D: dimenticavo una cosa. Sì, i programmatori si sono presi parecchie libertà programmando coi 680×0. Colpa anche di Motorola che ha cambiato più volte l’ISA a livello supervisore, e s’è spinta a farlo anche in modalità utente.

  • # 15
    Luciano
     scrive: 

    Complimenti per l’articolo.

    Se puoi metti in calendario anche una recensione dei Transputer, all’epoca stavano una spanna sopra alle altre CPU ed avevano la gestione del multitask in HW (o parallel processing come veniva definito) se non ricordo male erano necessari solo 3 cicli di clock per switchare da un taslk all’altro !

    L.

  • # 16
    iva
     scrive: 

    Eh eh, prima voglio spremere al meglio il 68040… poi ho gia’ speso abbastanza, questo settimana dovrebbe arrivare la Picasso IV e quindi posso finalmente usare un monitor ad una risoluzione decente!

    Sarebbe bello se negli articoli futuri potessi parlare anche un po’ di codice assembly con esempi concreti e le scelte che la differenza nelle varie versioni della famiglia 68k ti ha portato a fare, grazie!

  • # 17
    Cesare Di Mauro (Autore del post)
     scrive: 

    Viste le richieste, posto un po’ roba che mi sono appuntato, rigorosamente in ordine sparso (non è, quindi, una scaletta):

    80386 *
    80486
    Pentium
    Pentium MMX
    Pentium Pro
    Pentium 2
    Pentium 3
    Pentium 4 (Willamette e Northwood)

    K5
    K6-2
    K6-3
    Athlon (K7)
    Athlon64 (K8)

    Cyrix 6×86

    Motorola 56000
    Motorola 88000

    Intel 80860
    Intel 80960

    AMD 29000 *

    InMOS Transputer T212
    InMOS Transputer T424
    InMOS Transputer T800

    HP PA-RISC PA-7000 *

    Sun SPARC *
    Sun MACJ

    Transmeta Crusoe
    Transmeta Efficeon

    PowerPC 601
    PowerPC G3
    PowerPC G4
    PowerPC G5

    MIPS R2000
    MIPS R3000
    MIPS R4000
    MIPS R5000
    MIPS R10000

    IBM 801
    IBM POWER 1
    IBM POWER 2
    IBM POWER 3
    IBM POWER 4
    IBM POWER 5

    Intel/HP IA-64

    DEC Alpha

    Siemens 80C166 *

    Hitachi SH-1 *
    Hitachi SH-2
    Hitachi SH-3
    Hitachi SH-4

    AT&T_Hobbit

    STMicroelectronics LX
    STMicroelectronics ST10
    STMicroelectronics ST100

    Il tutto a condizione di recuperare datasheet, user o reference manual, perché ho bisogno di studiarmi per bene l’architettura.

    Per intenderci: non ho intenzione di scrivere un riassunto con 4 caratteristiche in croce. Se non trovo nulla di interessante, preferisco non scrivere.

    @iva: è mia intenzione realizzare qualche articolo del genere. Visto che ho programmato per parecchi anni coi 680×0, mi sembra il minimo. :D

  • # 18
    D
     scrive: 

    “Colpa anche di Motorola che ha cambiato più volte l’ISA a livello supervisore, e s’è spinta a farlo anche in modalità utente.”

    Beh dati i boost prestazionali tra una versione e l’altra, un piccolo sacrificio era necessario.

    Ti sei dimenticato nella scaletta dei videopoker, dello YM (e relative evoluzioni opl), del progettino a puntate “computer in kit su z80, del SH-5, del chip grafico della scheda video del A3000, dei power vr… ;-)

  • # 19
    jpx
     scrive: 

    Ottimo articolo, ma non avevo dubbi! :)
    Lo 060 è ancora il mio processore “preferito”…infatti pulsa tuttora nell’A1200 qui a fianco… ;)

  • # 20
    D
     scrive: 

    @jpx

    Vorrei farmi anch’io un A1200 o un A4000 con relative schede di espansione varie.
    Potresti farmi un elenco di cosa andrebbe preso tenendo conto anche delle esigenze moderne (connettività, monitor vga ecc. ) ?
    Thx

  • # 21
    Rob
     scrive: 

    complimenti per gli ottimi articoli, nell’analisi del 68040, se non ricordo male, hai dimenticato di citare che trattasi di una CPU a clock interno doppio come i 486 DX2 (disponibili solo molto tempo dopo). I 20 mips a 25mhz sono registrabili solo quando la CPU lavora internamente a ~50mhz. Proprio questo aspetto giustificherebbe il relativo consumo non proprio in linea con gli altri processori a 25mhz dell’epoca e la barriera dei 40mhz di targa per la versione top dove molte parti della CPU stessa operano fino a 80Mhz.

  • # 22
    Warfox
     scrive: 

    @D
    Il top? :)
    Una Blizzard 604e*220Mhz/060@50Mhz.
    Una Mediator PCI
    Una Voodoo3
    Una Delfina
    Una scheda Ide.

    Costo? Abbondantemente superiore a qualunque Pc almeno 10 volte piu’ potente. :)

  • # 23
    D
     scrive: 

    Mi passi qualche link ? C’è una cosa che però mi sfugge: quanti slot d’espansione ha il 1200 ?
    Non c’è un po’ troppa roba da collegare lì ?

  • # 24
    iva
     scrive: 

    @D: qui ci trovi il riferimento alla maggior parte dell’HW mai prodotto per l’amiga
    http://www.amiga-resistance.info/bboahfaq/

    quest’altro e’ uno dei siti piu’ attivi nella community amiga, figurati che quando ho postato un’immagine del mio 4000 chiedendo consigli sulla batteria (fonte di patemi d’animo se non sostituita a dovere in tutti gli Amiga) ho ricevuto 5/6 risposte in un’ora!
    http://eab.abime.net/

    questo e’ il sito piu’ importante (mi pare) riguardo alla compravendita di parti per computer vintage, diciamo che l’amiga la fa da padrona.
    se guardi le offerte puoi renderti conto di quanto vale/costa il pezzo che vuoi:
    http://amibay.com/
    funziona in maniera molto interessante, non ci sono aste, chi vende e’ obbligato a scegliere un prezzo e chi risponde per primo ha diritto a prenotare il pezzo, chi posta dopo si puo’ mettere in lista se la contrattazione non va a buon fine.

    @Cesare: non vedo l’ora!

  • # 25
    Warfox
     scrive: 

    Allora.. la blizzard la trovi su E.bay.. ne ho vista una un paio di giorni fa’ a 350 euro.
    La Mediator PCI si connette tra la blizzard ed il 1200 e aggiunge 5 slot pci (La trovi da Elbox).
    La Voodoo3 e’ una scheda Grafica per la RTG (Retargetable Graphics) la trovi nell’usato.
    La Delfina era una scheda audio con DSP.. e si pianta sulla clockport.
    http://www.vesalia.de/e_delfina.htm
    (Potresti stupirti di dove riescono ad attaccare roba sull’amiga)
    La scheda IDE puoi prendere la Catweasel MK4 da inserire in uno slot PCI.

  • # 26
    D
     scrive: 

    Aspetta come sarebbe “attacco la scheda audio alla clockport”

    Il 1200 non dovrebbe avere solo due slot, uno per la scheda acceleratrice ed uno pcmcia ?

  • # 27
    Cesare Di Mauro (Autore del post)
     scrive: 

    @D:

    Beh dati i boost prestazionali tra una versione e l’altra, un piccolo sacrificio era necessario.

    Esatto e diciamo che mi trovo in buona parte d’accordo con Motorola (l’altra parte, quella del programmatore tradito, la odia :D).

    Però poi non possiamo lamentarci per i danni derivanti dalla mancanza di totale retrocompatibilità.

    Ti sei dimenticato nella scaletta dei videopoker, dello YM (e relative evoluzioni opl), del progettino a puntate “computer in kit su z80, del SH-5, del chip grafico della scheda video del A3000, dei power vr… ;-)

    quello che ho postato è soltanto l’elenco dei microprocessori che vorrei trattare. Poi c’è altra roba, come il videopoker, appunto. ;)

    Sui chip grafici 3D, invece, penso che qualche altro collega abbia le capacità e le competenze necessarie poterne parlare. Certamente non io.

    Aspetta come sarebbe “attacco la scheda audio alla clockport”

    Il 1200 non dovrebbe avere solo due slot, uno per la scheda acceleratrice ed uno pcmcia ?

    Questo è l’elenco delle porte di espansione del 1200:

    Expansion Slots:
    1 x 150pin Trapdoor Slot.
    1 x PCMCIA Slot (Type II)

    Hard Drive Controllers:
    1 x 2.5″ IDE Controller (Unbuffered)

    Drive Bays:
    1 x Custom Floppy Drive Bay
    1 x 2.5″ Hard Drive Cradle

    Expansion Ports:
    1 x 25pin Serial
    1 x 25pin Parallel
    1 x 23pin RGB Video
    1 x 23pin External Floppy
    2 x 9pin Joystick/Mouse
    2 x RCA Audio (Left/Right)
    1 x RF Connector Composite

    @Rob:

    complimenti per gli ottimi articoli, nell’analisi del 68040, se non ricordo male, hai dimenticato di citare che trattasi di una CPU a clock interno doppio come i 486 DX2 (disponibili solo molto tempo dopo). I 20 mips a 25mhz sono registrabili solo quando la CPU lavora internamente a ~50mhz. Proprio questo aspetto giustificherebbe il relativo consumo non proprio in linea con gli altri processori a 25mhz dell’epoca e la barriera dei 40mhz di targa per la versione top dove molte parti della CPU stessa operano fino a 80Mhz.

    Ero a conoscenza di questa notizia e sono stato tentato di scriverla, ma mi ha trattenuto il fatto di non aver trovato riscontri precisi e chiari a supporto di questa tesi.

    Leggendo la FAQ dei processori 68000 ho trovato questo:

    The issue of “clock-doubling” with Apple products and the 68040 is a question often asked on the net. Apple (and others) advertises some of its notebook computers with “33/66 or 25/50″ Mhz speed designations. This has been referred to as “clock doubling”. The ‘040 has two clock inputs – PCLK and BCLK. PCLK runs at twice the frequency of BCLK. BCLK (1/2 PCLK) runs at the frequency of the part and is used to derive all bus signal timing.
    PCLK (2x BCLK) is used for internal logic timing. PCLK is not present on the 3.3 volt parts (MC68040V and 68EC040V). The 68020/030/060 do not have this feature but the 68360 does. Use BCLK as the part’s true speed.

    Che sembra smentire questa tesi. In effetti nello user manual del 68040 si trova scritto più o meno la stessa cosa:

    Processor Clock PCLK4 Clock input used for internal logic timing. The PCLK frequency is exactly 2 ´
    the BCLK frequency.
    4. These signals are not available on the MC68040V and MC68EC040V
    […]
    The M68040 uses two clocks to generate timing: a processor clock (PCLK) and a bus clock (BCLK). The PCLK signal is twice the frequency of the BCLK signal and is internally
    phase-locked to BCLK. PCLK is also distributed throughout the device to generate additional timing for additional edges for internal logic blocks and has no bearing on bus timing. The use of dual clock inputs allows the bus interface to operate at half the speed of the internal logic of the processor, requiring less stringent memory interface requirements.
    Since the rising edge of BCLK is used as the reference point for the phase-locked loop (PLL), all timing specifications are referenced to this edge.

    E’ vero che per il PCLK si parla di utilizzo nella “logica interna”, ma nel manuale l’ho sempre trovato associato ai timing del bus (accoppiato col BCLK).

    Inoltre questo segnale manca nei MC68040V e MC68EC040V, che però non hanno prestazioni dimezzate rispetto alle altre versioni del 68040 che ne fanno uso.

    Per cui personalmente propenderei per non associare questo “clock doubling” del 68040 alla stessa tecnica usata da Intel a partire con gli 80846 DX2.

  • # 28
    Marco
     scrive: 

    @D
    “attacco la scheda audio alla clockport”

    La cosiddetta “clockport” è un connettore si trova vicino a quello del floppy sulla scheda madre. Non c’è nell’elenco di Cesare perché doveva sparire in produzione (e in effetti a volte non ci sono i pin saldati).
    Era prevista inizialmente per un’espansione interna di chip RAM (versione del 1200 con un solo MiB di chip, mai commercializzata) eventualmente con RTC.
    Nel tempo è servita per gli usi più fantasiosi, come controller USB, ethernet, seriali veloci, ecc.

  • # 29
    Marco
     scrive: 

    @Cesare
    “Per cui personalmente propenderei per non associare questo “clock doubling” del 68040 alla stessa tecnica usata da Intel a partire con gli 80846 DX2.”

    Concordo pienamente con te. Da un certo periodo comunque ricordo che Motorola ha cominciato a marchiare le cpu (forse su insistenza di Apple?) con il doppio clock: i 33 MHz sono diventati 33/66 MHz, ecc.
    Solo marketing ovviamente ;)

  • # 30
    Cesare Di Mauro (Autore del post)
     scrive: 

    Marketing, infatti. E’ il solito mito dei Mhz che è duro a morire… -_-

    Grazie per le interessanti informazioni sulla “clockport”, che onestamente non conoscevo.

  • # 31
    Warfox
     scrive: 

    Sulla clockport e’ stato installato di tutto.. :) Poco di manca che ci mettevano schede video (se non fosse per la bandwidth qualcuno secondo me ci avrebbe pensato).

  • # 32
    D
     scrive: 

    \Non c’è nell’elenco di Cesare perché doveva sparire in produzione (e in effetti a volte non ci sono i pin saldati).\

    Ieri sera avevo trovato una foto della scheda del 1200 ed in effetti avevo visto tre connettori: ide, floppy ed un coso bianco sotto gli rca ma niente pin extra. Ne deduco che ci sono diverse revisioni della scheda madre e se prendessi quella sbagliata sarei fregato. Idee in proposito ? La versione Escom della 1200, quella magic pack è ok o segata ?

  • # 33
    Marco
     scrive: 

    Se per caso non ci fossero puoi facilmente saldarli. Le revisioni più comuni hanno solo i 22 pin del più a destra del connettore inferiore (sotto alla chip ram) installati, sufficienti per il funzionamento delle espansioni.

    Non pensavo ne avessero fatte così tante :-D :
    http://amiga.resource.cx/exp/search.pl?intf=clk

  • # 34
    D
     scrive: 

    Quindi vediamo un po':

    Scheda CPU (mi pare di aver capito che esiste la versione con doppia cpu, 060 e ppc) nella trapdoor

    Delfina su questa clockport

    Mediator PCI (che non ho capito dove va messa) mi fornisce 4 PCI quindi lì ci finiscono scheda video (VooDoo 3 è il massimo supportato ?), Rete, USB (anche firewire ?), SATA ^_^ ?

  • # 35
    Warfox
     scrive: 

    La mediator va’ tra la scheda acceleratrice e la trap-door..
    Potresti anche trovare una Blizzard con CyberVision (che e’ la scheda grafica), ma non ricordo se esiste per le blizzard o solo per il 4000. Se metti il Mediator pero’ devi mettere il tutto in un case tower. La rete puoi anche farla usando il PCMCIA. Sata.. humm.. scordatelo.. :)

  • # 36
    jpx
     scrive: 

    @D

    Io ho una visione abbastanza precisa per quel che riguarda queste cose, ed è la seguente: l’Amiga è un computer adatto al retro-computing. Punto. Non ti consiglierò mai di spendere capitali su qualcosa che sarà sempre un passo indietro rispetto a qualunque cosa oramai assunta a standard de facto. Io ti consiglio solo una scheda di espansione di classe 68k tipo le Blizzard (io ho la 1260), 64MB di fastram al max, uno scandoubler se vuoi collegarlo ad un monitor VGA e al posto dell’hard disk una scheda Compact Flash. Retrogaming, programmazione Assembly, demo. Poi per carità: ognuno è libero di inseguire chimere… ;)

  • # 37
    D
     scrive: 

    “La mediator va’ tra la scheda acceleratrice e la trap-door..”

    Cioè la mediator si comporta come una specie di ponte anche per la scheda acceleratrice ? Ma questa non deve attaccarsi alla pci giusto ?

    “l’Amiga è un computer adatto al retro-computing. Punto.”

    Se è per questo non considero moderno neanche il nuovo amiga su sam440 quindi non ti preoccupare che so benissimo quanto posso sperare di osare ed ottenere.

    “Io ti consiglio solo una scheda di espansione di classe 68k tipo le Blizzard (io ho la 1260), 64MB di fastram al max, uno scandoubler se vuoi collegarlo ad un monitor VGA e al posto dell’hard disk una scheda Compact Flash.”

    Beh sicuramente il PPC prende il tempo che trova (so che avevano fatto perfino delle schede acceleratrici basate su G4), la fastram è quella che finirebbe installata sulla 1260 giusto ? Da qualche parte dovrei avere 128MB Edo però non mi ricordo se 2×64 o 4×32. Lo scandoubler raddoppierebbe solo la frequenza d’uscita per il monitor ma mi terrebbe basso con le risoluzioni giusto ?
    Qualunque scheda video volessi aggiungere ci vorrebbe la mediator no ?

  • # 38
    jpx
     scrive: 

    @D

    Io tutto considero il sam440 fuorché appartenente alla famiglia Amiga… ;)
    Considero AROS l’unica cosa sensata quando si cerca l'”Amiga-feeling” su hardware al passo con i tempi (a prezzi onesti), ma lungi da me dar fuoco alle polveri con l’ennesima disputa x86 vs. PPC, OS4 vs. MOS vs. AROS, etc… :)

    Corretto, la Fastram la si installa direttamente sull’acceleratore, ma devi stare attento che si tratti di moduli SIMM con i chip su un singolo lato (nel caso della Blizzard, il modulo RAM una volta installato si trova letteralmente disteso e attaccato allo 060. L’unico modo di poter usare moduli con i chip su entrambi i lati del PCB è di trovare anche il modulo di espansione SCSI per la Blizzard sul quale si trova un altro socket SIMM, inclinato a 45°). Stai attento inoltre alle EDO: so di gente che ha avuto problemi di compatibilità per via dei timing. Cerca se puoi moduli a 70ns, quelli a 60ns fanno un po’ le bizze IIRC.

    C’è un nuovo scandoubler che va installato internamente che costa un po’ caro, ma permette di giocare anche con risoluzioni elevate (in realtà è un ibrido di scandoubler e rudimentalissima scheda video): trattasi dell’Indivision AGA.

    Mediator chiama tower e a quel punto fossi in te opterei per un 4000 con una Cybervision, ma anche qui è questione di gusti… ;)

  • # 39
    D
     scrive: 

    A prop. di case, se non sbaglio esistono anche per 1200, ma poi come si collega la tastiera ? C’è un cavo sostitutivo o si tira una piattina ?

  • # 40
    Warfox
     scrive: 

    Perdona la domanda.. ma ha senso? Cioe’.. tutta sta roba ti costerebbe come un PC ultracarrozzato. Minimo devi contare:
    50/100 euro per l’amiga.
    350 euro per il 060. Il ppc manco si trovano.
    250 euro la mediator.
    50 euro per la Voodoo.
    700 euro almeno..

    A conti fatti o sei veramente fuori come un balcone per l’amiga oppure tutto cio’ non ha senso (imho eh) per divertirsi a fare un po’ di retrocomputing.. anche perche’ poi ti passa.. :)

  • # 41
    jpx
     scrive: 

    @D

    Si, esistono soluzioni tower per 1200 e anche varie interfacce per poter collegare tastiere PC all’Amiga. Ma Warfox ha ragione su tutta la linea. Per farti un esempio, parlavo proprio ieri con un mio vecchio amico, possessore di un 1200 towerizzato con 060, PPC, 128MB FastRAM, Mediator, Voodoo, Dio solo sa cos’altro… mi ha detto che è spento e inutilizzato da mesi, forse anni, e che alla prima occasione lo vende… solo che per meno di 1500 euro non se ne parla. Fai tu! ;)

  • # 42
    D
     scrive: 

    Beh è ovvio che il tutto è fatto solo così per fare. Non è un progetto a breve scadenza e sicuramente ci sono molte altre cose che guadagnano la precedenza.

  • # 43
    D
     scrive: 

    Comunque guardando amiga-hardware.com m’è venuto un dubbio.

    Allora i pc hanno la scheda madre sulla quale si collegano separatamente i vari “moduli” e questi a loro volta permettono al massimo delle espansioni solo strettamente relative alla loro funzione primaria (schede video -> espansione vram e/o scheda figlia per catturare fonti esterne) invece m’è parso di capire che negli amiga, una scheda X può contenere a sua volta ulteriori bus di espansione non strettamente legati allo scopo della scheda stessa, come una specie di usb a cascata, dico bene ?
    Se le cose stanno così come si comporta tutto il sistema nel gestire eventuali priorità d’utilizzo ? Perchè dubito che gli amiga possedessero dei super bus in grado di sostenere allo stesso tempo schede diverse.

    Se guardo questa scheda audio http://www.amiga-hardware.com/showhardware.cgi?HARDID=1295 vedo che si collega ad una scheda video che andrà sul sistema principale ma non credo che quest’ultimo fosse realmente in grado di far andare le cose allo stesso tempo o si ?

  • # 44
    Cesare Di Mauro (Autore del post)
     scrive: 

    Se il bus usato è sempre lo stesso (quello a cui sono collegati CPU, memoria, e schede d’espansione), il funzionamento è simile a quello che hai descritto, poiché viene condiviso da tutte le periferiche connesse.

  • # 45
    D
     scrive: 

    Cosa ne pensi di realizzare un articolo che esponga completamente le differenze tra l’architettura pc ed amiga ?
    Parlare dei 68k: check.
    Parlare del chipset: check.
    Però mi sto rendendo conto che c’è molto altro sotto e che spesso non viene spiegato bene in giro, quasi fosse superfluo, dato per scontato. Sarebbe poi interessante spiegare pure come mai certi chip sembrano integrare funzioni distanti tra di loro, cioè pensi che un chip dedicato allo i/o debba contenere solo quello poi, salta fuori che un tot viene dedicato ad altro, quasi una specie di miscuglio.
    Disordine casuale o voluto ?

  • # 46
    flameman
     scrive: 

    per lavoro ho recuperato con piacere delle schede industriali VME/68k

    sono di fattura tedesca, entrano in un bus VME/64 e montano 2×68060-50Mhz; in eprom c’e’ VxWorks (kernel di windriver)

    dato che il cliente ha pensato di rimpiazzarle con schede ppc405GP, io ho pensato di salvare un paio di schede da “morta in pressa idraulica”, e rimpizzare la eprom con un firmware dei miei, in modo da “segare” il bus VME, ed installarci invece, molto + banalmente, una scheda di rete

    o meglio … in modo da costruire ed agganciare delle funzionalita’ di networking atttorno al chip cs8900 (10Mbit/s, liner memory mapped net device), funzionalita’ da usare per caricare velocemente (a 8Megabyte/sec contro i 1K..2KByte/sec della seriale) applicazioni da testare

    in pratica ho trasformato quella scheda custom in una “I.D.P. board”, la stessa che nel 1997 motorola vendeva agli sviluppatori per 1500 euro attuali: IDP stava per “Integrated Development Platform”, cioe’ una scheda 68060-50Mhz con 8Mb di ram, 2 seriali, una parallela, 2 fpga, 2 eprom in socket (una custom, una con il firmware m68k), … e una vagonata di documentazione specifica di quella scheda, tra cui … documentazione dettagliata sulle macchine a stati contenute nelle fpga, e su quelle necessarie per aggiungere una ipotetica scheda custom sul bus di espansione

    non ho speso un euro, ma diverse nottate nel reverse.enge, il tutto per scrivere un “monitor con capacita’ di download/upload da rete” (qualcosa di simile a DINK32, di cui esistono vaghi sorgenti a cui ispirarsi, se avete presente il prodotto motorola)

    oh, questo x dire: se nel 97 non me lo potevo permettere, ora che su ebay schede ppc te le tirano dietro per pochi euro, io ho una scheda SMP 68060 su cui posso fare esattamente quello che voglio, compreso il “giocare”/”sperimentare” quanto l’ISA 68K sia migliorata con l’ultimo della serie!

    e sfrutto anche ben 4 seriali (grasso che cola davvero) per la console, il debug, e testing vario
    (compresa l’implementazione del protocollo modubus_over_uart/rs232, ho un muster sulla ttyS1, e uno slave sulla ttyS2, troppa grazia davvero)

    ma c’e’ un altro progetto su cui “provare” un 060: beh, il mac lc475!

    non si tratta di una scheda di sviluppo che ti ritaglia diversi gradi di liberta’ nella progettazione, espansione, re.eng

    no, affatto, si tratta di una scheda che difficilmente si potra’ hackare

    tuttavia, siccome ho gia’ curato il porting completo di gentoo/m68k
    ottimizzato per 68040 (e monto un 33Mhz con mmu e fpu)

    ora pare proprio giunto il tempo di sfornare nuovi stage4 ottimizzati per 60

    ha senso farlo? a guardare no, macchina comunque lenta, poca ram (max 64Mb in 1 sola sim72 nel solo socket di espansione +4Mb saldati sulla mobo, somma totale 68Mb, un po’ pochini per le cache di emerge) tanto che in gentoo nemmeno supportano quella arch

    poi, fra i vari guai: un mac lc475 ha firmware scritto per 30 e 40, e pur essendo il 60 pin compattibile con il 40, ha delle rognette se viene considerato un “40 avanzato”

    ergo, prima ancora di ricompilare kernel (di cui, c’e’ da scordarsi i kernel recenti, bisogna stare con kernel scsi2, ergo le possibilita’, volendo, ci sono

    e boh, ad occhio ci vorra’ qualche annetto

  • # 47
    flameman
     scrive: 

    avevo usato un carattere non gradito
    ha perso la seguente:

    ergo, prima ancora di ricompilare kernel (di cui, c’e’ da scordarsi i kernel recenti, bisogna stare con kernel scsi2, ergo le possibilita’, volendo, ci sono

    e boh, ad occhio ci vorra’ qualche annetto

  • # 48
    flameman
     scrive: 

    avevo usato un altro carattere (stavolta il minore) non gradito
    ha perso la seguente:

    ergo, prima ancora di ricompilare kernel (di cui, c’e’ da scordarsi i kernel recenti, bisogna stare con kernel inferiori al 2.6.23), e stage3/4 appostiamente per 60, dovro’ patchare il firmware del mac:

    dissaldare 4 eprom
    leggerle
    riassemblarle in un file immagine
    disassemblarlo (violando un copyright che ormai e’ scaduto da anni)
    trovare i “BAD points”
    correggerli (byte patching)
    saldare delle eeprom su zoccolo
    splittare la firmware fixed image
    programmare le 4 eeprom
    provarle il tutto

    iterando alcuni di questi punti
    fino a che tutto funzioni come deve

    (e credo che dovro’ ritoccare anche il codice del bootloader)

    ho delle rognette anche con il PLL sulla mobo, rognette che andranno risolte al layer hw

    altra grana, secondo me urgente (x via della console seriale, sempre utile): i kernel 2.6 hanno perso del tutto il supporto per la 2 seriali del lc475. Va scritto di sana pianta il kernel_module

    cmq, una macchina gentoo-m68k/68060, fara’ anche fatica a compilarsi quanto gli occorre per sopravvivere all’obsolescenza, ma … un po’ aiutandola con il crosscompiling, un po’ “portando pazienza”, ma secondo me appaga!

    a livello hobbistico, a tempo perso

    conto di montare un display alfanumerico da 2×40 char sul frontale (al posto del floppy): tornerebbe molto utile, come pannello sniffer, o net traffic analyzer … fatta funzionare la seriale, montare un orbit grafico e’ un gioco da ragazzi, come rimpiazzare il rumoroso hd scsi con un adattatore CF_FLASH-pATA->scsi2, ergo le possibilita’, volendo, ci sono

    e boh, ad occhio ci vorra’ qualche annetto

  • # 49
    D
     scrive: 

    Mi ci vorrà ancora molto tempo prima di poter sperare di fare la metà delle cose che hai descritto ma è bello avere una fonte d’ispirazione thx
    Mi chiedo però una cosa: ha senso cercare di far andare linux su questi sistemi ? Non c’è niente di paragonabile sempre unix like e molto più leggero ?

  • # 50
    jpx
     scrive: 

    @flameman

    Da quanto sono i 2 FPGA su quella scheda? Potresti sperimentare con il Verilog del Minimig, ammesso che ci sia abbastanza spazio. Oh, e provare anche a portarci sopra AROS… ;P
    Anche se di uno dei due 060 non te ne faresti niente (a meno di non trovare il modo di implementare il SMP su di un OS Amiga-like e diventare una leggenda all’istante! ;D)

  • # 51
    Cesare Di Mauro (Autore del post)
     scrive: 

    Concordo: su queste macchine personalmente o ci gira AmigaOS oppure AROS. A mio avviso sono gli unici s.o. che possono permettere si fruttarle adeguatamente.

    @D: considerata la varietà di hardware che ha avuto e ha il PC, non so se valga la pena fare un confronto. Perché uno, appunto, non basterebbe. :D

    Sulla questione dei chip di I/O che integrano altre funzioni, è normale: si cercava di risparmiare sui costi della componentista, dei package e sulla complessità della scheda madre.

    Ecco perché, ad esempio, Paula (uno dei 3 chip custom dell’Amiga) integrava anche funzionalità di I/O.

  • # 52
    D
     scrive: 

    Cesare non sto parlando della varietà di hardware (anche se non sarebbe una brutta cosa in effetti cose come “scheda video RTG/non RTG” non sono proprio chiare secondo i canoni moderni”) ma di tutta sta storia di come si collegano le periferiche sopra il sistema.
    Un pc nel momento in cui la scheda madre esaurisce i slot d’espansione è semplicemente finito, un amiga no e non mi sembra una differenza da poco.

  • # 53
    Cesare Di Mauro (Autore del post)
     scrive: 

    Sei sicuro che su PC non si possa aggiungere nient’altro? ;)

  • # 54
    D
     scrive: 

    Il punto è che sul pc aggiungi delle schede e fine, non puoi aggiungere altre schede per altri scopi sulle schede precedentemente installate sulla scheda madre.

    PC: Motherboard -> Scheda, Ram, Dischi, CPU
    Amiga: Motherboard -> Scheda -> Scheda

    Effettivamente guardando come sono fatti dentro gli amiga risulta difficile capire come si potessero espandere mentre invece i pc sono semplici per loro stessa natura.

  • # 55
    Cesare Di Mauro (Autore del post)
     scrive: 

    Sono semplici, ma con delle buone conoscenze si possono realizzare ugualmente degli hack. ;)

  • # 56
    D
     scrive: 

    Lascia perdere gli hack e guarda le cose “regolari”.
    Mi puoi trovare una scheda video che monta uno slot pci/agp/pciexpress aggiuntivo per permetterti di mettere ad esempio una scheda audio ?
    Esistono schede d’accelerazione che puoi infilare nel vecchio socket 370 che ti offre un core quad con ram DDR3 e controller SATA 2 ?
    Al massimo puoi trovare qualche case strambo con la riser card ma nessuna follia come quelle elencate sopra.

  • # 57
    Cesare Di Mauro (Autore del post)
     scrive: 

    Non ho difficoltà ad ammettere che di roba così strana non ne ho sentito parlare. :D

  • # 58
    D
     scrive: 

    La domanda che mi pare ovvia fare è se queste soluzioni erano possibili su amiga grazie a qualche predisposizione particolare o se sono alla portata di qualunque pc

  • # 59
    Cesare Di Mauro (Autore del post)
     scrive: 

    Le mie conoscenze di elettronica sono limitate, per cui onestamente non ti saprei dire.

  • # 60
    D
     scrive: 

    Peccato, i segreti di amiga continueranno a rimanere tali e dovremo continuare ad accontentarci di 68k e chipsettame vario…
    Comunque in alto nella lista hai dimenticato un sistema molto interessante: hp64000

  • # 61
    Cesare Di Mauro (Autore del post)
     scrive: 

    L’ho inserito nella lista, grazie.

    Comunque a me piaceva programmarli gli Amiga, e ti assicuro che si godeva lo stesso anche senza essere a conoscenza di questi trucchetti per espanderlo…

  • # 62
    jpx
     scrive: 

    @D
    \Peccato, i segreti di amiga continueranno a rimanere tali e dovremo continuare ad accontentarci di 68k e chipsettame vario…\

    L’Amiga oramai di segreti ne ha pochissimi, forse nessuno.
    Diciamo che più che l’architettura di per sé è stata la filosofia di utilizzo e di progettazione a spingere alcuni produttori hardware a tali ardite soluzioni. Credo che dopotutto su PC di banda passante ce ne fosse in abbondanza su qualunque bus di sistema (dal PCI in poi almeno), solo che commercialmente non c’era senso nel realizzare schede di espansione su socket CPU (che tra l’altro ce ne fosse stato uno solo…) o schede \a cascata\.
    Su Amiga questo è stato più che altro dettato dalle esigenze di svecchiare una piattaforma rimasta senza casa madre, ma con tanto potenziale allora ancora inespresso. IMHO.
    E comunque: \68k e chipsettame vario\ è dopotutto la definizione di Amiga, ce n’è in abbondanza di roba di cui potersi \accontentare\! ;)

  • # 63
    D
     scrive: 

    Però quelle schede che ho visto non sono nate dopo la morte di commodore ma erano contemporanee.
    Verrebbe proprio da chiedersi se mettendo a confronto kickstart e chipsettame con le controparti pc non saltano fuori dei paletti posti ad esempio da intel stessa, spaventata dalla possibilità di far sopravvivere oltremodo una piattaforma.

  • # 64
    Marco
     scrive: 

    “Incapacità di operare in sistemi MP oltre un numero ridotto di unità ?”

    Al contrario, Motorola ha sempre inserito logica per sistemi SMP glueless fino a 8 CPU, cosa particolarmente raffinata per l’epoca.

    “(sinceramente cosa poco importante vista la non curanza di motorola verso il mondo pro”

    Alla fine degli anni ’80 credo che fosse una delle architetture più diffuse sui “mini” fino a 8 CPU.

    “Colli di bottiglia a causa dell’architettura, ereditati magari proprio dal 68000″

    Consideriamo anche il fatto che un ipotetico “68080” avrebbe dovuto avere un’architettura OOO per reggere il confronto con il Pentium Pro, e quindi subire praticamente una completa riprogettazione. Inoltre a quel tempo Motorola stava spingendo (inutilmente) i clienti verso la serie RISC 88000 (non a caso il PowerPC ne eredita il bus: Apple aveva già prototipi 88K e per passare al PPC601 avrebbe dovuto solamente sostituire la CPU).
    Ultimo, avere praticamente gratis un core RISC che all’epoca sembrava avere le carte in regola per dominare il mondo.

  • # 65
    D
     scrive: 

    Beh 8 CPU mi sembra un numero nel complesso ridotto. Forse sarebbe servito un numero maggiore.

    “Consideriamo anche il fatto che un ipotetico “68080″ avrebbe dovuto avere un’architettura OOO per reggere il confronto con il Pentium Pro, e quindi subire praticamente una completa riprogettazione. ”

    Capisco che motorola si divertiva a cambiare le carte in tavola ad ogni versione ma possibile che solo intel è riuscita a mantenere un sistema compatibile verso il basso senza perdere colpi ?

    “Ultimo, avere praticamente gratis un core RISC che all’epoca sembrava avere le carte in regola per dominare il mondo.”

    Si insomma, come al solito, gli interessi commerciali hanno sovverchiato le realtà tecniche.

  • # 66
    Marco
     scrive: 

    “Beh 8 CPU mi sembra un numero nel complesso ridotto.”

    Stiamo comunque parlando di CPU “entry level”. Considera che questa feature è arrivata fra gli x86 solo con gli Opteron 8yy.

    “come al solito, gli interessi commerciali hanno sovverchiato le realtà tecniche.”

    IMHO dal punto di vista tecnico invece hanno fatto bene a sbarazzarsi di un’ISA così “datata” e complessa, con tutto il bene che ho voluto al 68K.
    Evidentemente il segmento di mercato non era più remunerativo con Apple praticamente unico cliente che vendeva a sufficienza e una CPU non adatta a scalare nell’embedded (per i consumi) e nell’high-end (OOO, 64 bit), cosa dove il PPC/Power eccelle.
    BTW il fatto che anche IBM abbia poi trascurato il mercato desktop per concentrarsi sulle console (e Freescale sull’embedded/automotive) e sull’high-end la dice lunga su quanto sia difficile fare concorrenza all’x86 in quel segmento.

  • # 67
    flameman
     scrive: 

    e’ dura fare SMP con queste CPU 68060

    molto dura
    sulla scheda 2×68060 ho notato, nel codice originale
    che nessuno dei 2 68060 abilita la propria MMU
    dunque devo ancora capire
    come funzioni esattamente la mmu “esterna”
    cioe’ la “scratch MMU” (come c’e’ scritto sulle etichette) realizzata in fpga
    dispositivo che consente ai 2 68060 di mappare indirizzi virtuali in indirizzi fisici in modo condiviso
    (non so come funzioni, ma e’ quanto ho visto con l’analizzaotore logico)

    molto interessante, direi, molto originale
    dovrei complimentarmi con gli ing tedeschi che l’hanno concepita
    tirando xro’ loro le orecchie: xke’ non l’hanno documentata?

    e’ tech di una commessa, dunque e’ segreto industriale? e’ un peccato!

    ma e’ molto interessante anche VxWorks, in generale

    circa gnu/linux su m68k: ha senso con un kernel 2.6 ?
    beh, diciamo che, secondo me, aveva senso con un kernel 2.2, con un 2.4
    xke’ erano leggeri, e occupavano poca memoria
    i 2.6 sono elefanti, grossi, pesanti, e complessi
    (anche x cosa richiedono nel rootfs, specialmente dal 2.6.18 in poi)
    no, ad occhio nessuno vorrebbe un 2.6 sul proprio m68k

    nessuno, ma nemmeno uclinux sui coldfire
    e infatti i professionisti consigliano il 2.4
    (quando non consigliano addirittura un altro kernel)

    io, xro’, come hobbista, ho preferito portare linux.2.6.* sul macLC475
    per una quaestione di “parco applicazioni” e congruenza know/how
    ho poco tempo libero e gia’ gestisco gentoo per diversi arch
    duque e’ ragionevole che giri anche sul mac
    e che ci giri con un profilo “moderno”

    questo anche se in app userland ho previsto “cosucce” come
    * mini http web server
    * network analyzer
    * mac serial terminal

    cioe’ cose stra testate, stra robbuste
    cioe’ tutte applicazioni che si ricompilano e girano tranquillamente
    (ma che si compilerebbero, senza troppi problemi
    anche nei profili necessari per il 2.4)

    diciamo richiederebbe del tempo in +
    e potrebbe essere un guaio se dovessi mai voler compilare
    applicazioni che richiedono SOLO un profilo moderno
    (per esempio cose che richiedono FUSE, oggetto esclusivo dei kernel 2.6)

    ma sul mio MAC, va bene anche il 2.6
    e va bene (rispetto ai tempi di un AROS cross compilato)
    al prezzo di dover aspettare settimane
    per veder compilate NATIVE (cioe’ e’ il mac che le compila)
    installate, configurate applicazioni che
    comunque richiederebbero circa lo stesso tempo
    se fosse scelto un profilo 2.4

    qualche tempo fa trovai un palmare con dentro un mc68ec328
    si tratta di un core 68000 (a 16Mhz) con integrate alcune periferiche
    tra cui
    * spi (a cui e’ attaccato un chip di controllo touchscreen)
    * uart (per il sync dati con il pc)
    * lcd grafico
    * IrPort (classico chip seriale con codifica hw manchester)

    mi ha fatto piacere scoprire il modo di bloccare il firmware originale
    e portare il micro in modalita’ serial bootstrap mode
    in modo da caricare altro codice da seriale

    mi ha fatto piacere mettere in piedi una devchain su unix
    per scrivere qualcosa di intrigante

    tipo
    scollegare il chip IrPort (chi lo usa +?)
    e usare il suo /CS (chip select)
    come /CS per indirizzare un chip di rete su spi

    fare un foro sullo scafo del palmare
    portare fuori l’spi

    in modo da aggiungere un chip di rete alla catena

    * spi
    — chip touchscreen
    — chip (mappato nel dev_addr_range del dell’irda)

    questo xke’ (molto) tempo fa avevo scritto
    una implementazione minimalista udp/ip per mc68hc11 …
    (di cui non ho mai finito un fempo kernel
    xke’ non ho mai avuto voglia di portare freeRTOS o ucos/2)
    con driver per cs8900
    (un net chip ethernet a bus parallelo per micro ad 8bit
    di cirrus logic, da 10Mbit/sec)

    ma ora, se su m68hc11 non avevo troppa voglia
    xke’ avevo max 32Kbyte di (nv)ram
    e dovevo stare stretto nell’implementazione

    direi che e’ invece giunto il tempo
    di portarla quella implementazione su un 68000
    e sperimentare un modulino spi-ethernet
    (questa volta di microchip)

    si, direi che quel palmare e’ l’ottimo dispositivo
    xke’ ha anche 8Mbyte di ram (tamponata)

    e 2Mb di flash (con dentro palmOS 3.5)
    che vorrei invece ignorare

    oggi piove, direi che ci provo
    e domani dissaldo le 4 rom del secondo lc475 =P

  • # 68
    Cesare Di Mauro (Autore del post)
     scrive: 

    Come funzionava AROS sul tuo 68060? Personalmente m’interessa soltanto questo s.o. per CPU o sistemi “leggeri” o datati, perché dovrebbe girare molto bene.

  • # 69
    flameman
     scrive: 

    come gira ArOS sulla scheda industriale 2×68060?
    risposta boh, mai provato e mai lo provero’

    non mi interessa

    non mi interessa un “altro sistema operativo”
    non mi interessa una altra “amiga”
    amiga non l’ho mai avuta
    ho perso il treno
    ai tempi mi hanno dato una Z80/CPM
    chi? che cosa?

    eh, son cose che oggi son da museo
    e bisogna guardare oltre

    c’e’ gia’ QNX per il (soft)real time
    c’e’ gia’ QNX a fare scuola di microKernel
    non sara’ ARoS ad insegnare qualcosa
    c’e’ gia’ linux e i bsd per l’unix like
    non sara’ ARoS a fare parco app
    e gia’ ai tempi di BeBOX mi bastava BeOS
    (o Haiku, altro fork, altro OS, altri nostalgici)
    per il multimedia OS “alternativo” al commerciale QNX

    ma parliamoci chiaro: ArOS non lo vuole nessuno
    eccetto chi ha nostalgia degli amiga
    eccetto chi ora sta portando avanti il 68070
    che senso ha ?

    in termini di amiga OS 200x veloce: non ha senso

    non serve una nuova amiga, non serve un altro OS
    e’ dispersivo in termini di man power
    xke’ la gente normalmente lavora
    e quando ha tempo libero ha diversi progetti
    ma non troppo tempo per portarli avanti
    e chiunque sia del settore
    sa che sviluppare un OS in termini moderni
    non e’ come sviluppare il DOS o il cpm
    o il buon vecchio amigaOS:
    xke’ oggi sviluppare (e mantenere un OS) costa
    e costa TANTISSIMO in termini di risorse umane
    il codice si e’ complicato
    le richieste di quanto deve fare sono aumentate
    e’ tutto immensamente + complicato
    anche l’architettura sottostante

    e in ogni coso le nuove architetture
    non sono x nulla simili al 68k
    sono diverse, e sono molto + complesse
    xke’ continuare a ripescarle x fare cose moderne ?

    non ha senso

    dunque per me … un (2x)68060
    ha senso solo come hobby
    o come studio di VxWorks
    non ha affatto senso portarci ArOS

    come desktop ho gia’ macOSX
    come workstation ho gia’ il mio mac
    come macchina di battaglia ho gia’
    (purtropp) il mio portatile win/linux

    non serve ArOS
    nel cruscotto della mia auto
    come nel cruscotto degli aerei
    come nelle cose avioniche
    ci gira QNX, con librerie specifiche QT

    sul server di virtualizzazione ci gira OpenSolaris
    che ha ZFS e molte feature per la virtualizzazione

    ma chi lo vuole un fs primitivo?

    e allora su ArOS, x quanto “ben fatto” possa essere
    saremo sempre e solo sul sub utilizzo
    cioe’ la nicchia hobbistica
    nessun passo avanti
    nulla di commercialmente utile
    poco e scarso parco applicazioni

    anche sul mio zaurus: non viglio ARoS
    ho limato un kernel linux e vado bene cosi’
    in console testo
    xke’ x quanto ArOS possa essere + leggero
    su Akita non ha senso che ci sia ARoS

    avrebbe senso Haiku, forse

    e dico forse quando penso
    che anche Akita e’ hw vecchio, obsoleto

    chi lo vuole ?

    a me l’han regalato
    l’avessi comprato, avrei scelto pandora
    molto + prestante

    ma su hw moderno di tipo PDA c’e’ gia’ Android
    e c’e’ gia’ ci ci lavora
    nomi come “google”

    da “apple” c’e’ gia’ l’iphone

    dunque siamo seri
    se non gli smanettoni, e i nostalgici
    (cosa che va bene, ma biosogna prenderne atto
    con lungimirante consapevolezza)

    ma chi lo vuole un altro OS
    su hw obsoleto e senza app ?

    io no, non voglio ArOS
    anche se mi piace leggerne il codice
    e sorridere vedendo che
    a qualcuno regala ancora un sorriso
    un brivido

    ma questo e’, e nulla di +
    come i miei hobby

    =)

  • # 70
    Cesare Di Mauro (Autore del post)
     scrive: 

    Siccome avevi parlato di compilazione di AROS, pensavo l’avessi provato. Peccato.

    Personalmente lo trovo un buon progetto, anche se ancora non finalizzato. C’è poca gente che ci lavora.

    Per quanto riguarda lo Zaurus, ho un SL-5500, e aspetto da tempo un s.o. che mi permetta di sfruttarlo come si deve. Speravo in un porting di AROS, ma non gira ancora sugli ARM. E per il momento è finito nel cassetto, in attesa di tempi migliori.

  • # 71
    flameman
     scrive: 

    ho scritto che ho (cross)compilato ArOS
    questo si

    xke’ ero curioso
    e xke’ x la didattica e’ un ottimo riferimento

    e’ ottimo codice
    che trasporta molte idee a cui attingere

    questo si

    ma pensare di portarlo fisicamente su una scheda hacked
    (nel mio caso, non ho una amiga
    ho una scheda industriale, “hackata” per avere un qualcosa 68060
    senza GPU, text serial/lan console)

    e sperare di cavarci qualcosa di usabile
    e’ tutto un altro paio di maniche

    maniche in cui, secondo me, non ha senso entrare

    xke’ c’e’ troppo da investire
    ci sono poche risorse umane per farlo
    e pochi ritorni di utilita’

    x es, x quanto riguarda zaurus
    vero che in linea teorica
    avrebbe senso
    pensare di eliminare un kernel elefante come linux
    in favore di un kernel piuma come ArOS

    ma tu credi che avere un kernel ArOS
    + leggero, indubbiamente, di linux
    ti possa rendere lo zaurus meglio usabile ?

    il kernel non e’ tutto
    contano di + il rootfs e il development environment

    e quale env, e quali app usabili ha
    ArOS rispetto ad una soluzione .. ad es moblin ?

    (si, quel moblin, di intel
    cioe’ gnu-linux + hack di metacity/mutter-moblin
    + un tot di app opensource patchate appositamente
    in un profilo “moblin”, cioe’ pensato per PDA/netbook)

    p.s.
    sul mio C1000, ho sviluppato tutto un profilo stage4
    per usare il PDA al lavoro, connesso o wifi-CF, o lan-usb

    e con kernel linux 2.6.23
    limato all’osso
    ho confezionato un rootfs non-NPTL leggero ed ottimizzato
    (armv5tel-softfloat-linux-gnueabi)

    che comprende
    (oltre ad emerge e portage)

    * una dev chain di sviluppo (ada,python,perl,erlang,gcc-4.1.2/4.3.4,binutils,make,cmake,latex,bison,lex,etc…)
    * una dev chain di cross-sviluppo m68hc11 (core m6800)
    * git,svn,cvs, con un webserver a cui si interfaccia un revision control digester
    * un po’ di tool network sniffer & analyzer
    * un po’ di tool per il serial (uart) sniffer & analyzer
    * un client/server modbus_over_serial (per interfacciare apparati industriali su rs232/422/485)
    * un client/server canbus (idem, bus opencan, fisicamente interfacciato da adattature usb)
    * tool di analisi i2c,spi e loro derivati (fisicamente interfacciati da adattature usb), per programmare eeprom, o interfacciare dispositivi a bus seriale)

    niente grafica, niente X11: non serve!

    x quel minimo di app grafiche x cui ha senso avere della grafica
    cioe’
    * foto
    * pdf

    ho sviluppato appositamente un paio di app
    * image_viewer on directfb
    * pdf reader on directfb

    pdf che, grazie, ad es a media-libs/libsdl
    posso scarabocchiare con “graffiti”
    su 3 layer, in 3 colori
    (gestisco il touchscreen da sdl)

    e’ tutto quello che mi serve avere
    su quel non-“PDA”

    xke’ il “vero PDA” di riferimento e’ l’iphone

    e se ti stai chidendo, ma allora, se non e’ un PDA
    xke’ non un uno smartboot (o netbook)?)

    ti rispondo: xke’ questo non-“PDA”
    che uso modi coltellino svizzero
    sta nel taschino della mia camicia
    come l’iphone
    e, vero, rispetto all’iphone ha meno interfacce
    e meno possibilita’ di sviluppo rapido
    quindi, vero che ha una interfaccia grafica pessima
    inusabile, tutta text
    ma passa quasi inosservato al checkin dell’azienda
    e passa ancora + inosservato quando sono in ufficio
    tanto che lo ripongo in un angolo per accederci via ssh/web
    per usarlo come un miniserver

    con iphone non mi faccio problemi:
    mi serve una app per un qualche scopo real-out-work-life
    scarico una app dal web-app-store

    mentre con il non-“PDA”
    non ho alcun problema a portare/sviluppare applicazioni gnu-linux

    cose che invece, fosse ArOS
    dovrei perdere (MOLTO) tempo ad adattare

    ma a che pro ?
    x avere un kernel + snello
    e una interfaccia grafia snella

    lodevole, si

    ma sono entrambi aspetti che tanto uso ?
    e che se anche usassi non sarebbe usabili?

    xke’ su ArOS le app non ci sono
    e se anche ci fossero, sarebbero quantomeno “rudimentali”

    come hanno gia’ ormai dimostrato DA ANNI
    progetti come iPAD

    la differenza con HP/Compaq
    e’ che moblin ha senso
    xke’ c’e’ intel che investe tempo e risorse

    iPDA di HP/COMPACT invece fu fuffa per smanettoni
    (come openmoko)

    e quindi no, io non commetto questo errore
    che piaccia o meno: il tempo non va sprecato

    e allora le vere e sole cose utili e sensate
    sono gli smartbook/moblin
    o … con un taglio un po’ diverso (trusted_PDA) … android
    (o, l’iphone con SDK)

    e se allora ti stai invece chiedendo
    ok, ma tu ci hai detto che e’ un non-“PDA”
    e se invece fosse un “PDA”?
    xke’ non ci porti applicazioni come
    un GPS router/tracker?

    ti rispondo
    su iphone c’e’ tomtom
    su moblin ci sara’ navit rivisto e corretto secondo intel

    e su ArOS ?
    che sia app gnu-linux o ArOS, su zaurus
    tanto l’hw dello zaurus sotto
    non ha abbastanza potenza elaborativa
    quindi non avrebbe senso un kernel snello come ArOS
    xke’ il problema non e’ il kernel, e’ l’hw!

    ci si puo’ accontentare
    del solo gps map tracking, logging
    ma un vero navigatore deve essere routing!

    portare Navit su zaurus non ha senso pratico
    xke’ costa tante ore di porting
    e, dal parco sviluppatori (e parco code test)
    ci si accorge che costa di meno su hw + potente

    e che quell’ hw e’ meglio supportato
    da gnu-linux
    o, in casi particolari (come automotive)
    da QT-QNX

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.