Coordinamento di Francesco Sileno

Piccoli Mozart

Ispirato da un colloquio telematico con un lettore, oggi vedremo prima come far emettere allo speaker del vostro scatolotto delle note, e come voi ben saprete mettendo insieme delle note possiamo fare delle semplici melodie; quindi esamineremo un metodo primitivo per riprodurre suoni campionati.

di Francesco Sileno

NOTE Tutti i sorgenti sono nel file ASM_SRC.ZIP - 12Kb, compresso con PkZip 2.04g, che è presente insieme al pacchetto di BETA o in alternativa nell'archivio on-line. Sembra che Netscape sia particolarmente allergico ai sorgenti assembler (o forse io sono particolamente incapace in HTML) e ogni tanto duplichi righelli in zone casuali. Potrebbe accadere anche in questo articolo. All'inizio era il BEEP... Anzitutto domandatevi: come si fa a far emettere un BEEP allo speaker del PC? Forse qualcuno di voi sa che il carattere ASCII 0x07 (BELL, non a caso), combinato con una particolare funzione BIOS, può aiutarci. Ma cosa fa questa funzione BIOS? Tutto ha origine nel PIT, l'integrato che fa le veci di Mastro Hora nel nostro amato ammasso di circuiti. Il PIT è famoso poichè detiene il controllo dell'IRQ0, collegato all'INT8, il timer di sistema. Ma non fa solo quello: il PIT ha a disposizione un altro paio di contatori, uno dei quali progettato proprio per operare in congiunzione con lo speaker. Eh si, ha dei contatori: ogni frequenza, anche quella del clock, viene generata decrementando il valore di un contatore. E quando quest'ultimo raggiunge lo 0, invia un impulso a qualsiasi cosa abbia attaccata. Poichè il decremento avviene a velocità fissa, variando il valore di partenza, varia la frequenza con cui viene emesso l'impulso in uscita. Vi accludo un estratto dall' HelpPC 2.1 di David Jurgens (lo trovate su internet, è shareware, e vale la pena prenderlo), illustrante l'anatomia e il modo d'uso del PIT. Ma ci serve ancora qualcosa: per accendere e spegnere lo speaker, e per collegarlo al timer 2 del PIT, dobbiamo agire altrove. Precisamente, dobbiamo andare a scomodare il controller della tastiera, in quanto i 2 bit che ci interessano sono stati mappati nella porta 0x60. Dalla Ralf Brown Interrupt List: Bitfields for KB controller port B (system control port) [output]: Bit(s) Description (Table P041) 7 pulse to 1 for IRQ1 reset (PC,XT) 6-4 reserved 3 I/O channel parity check disable 2 RAM parity check disable 1 speaker data enable <-- 0 timer 2 gate to speaker enable <-- SeeAlso: PORT 0061h-W,#P042 Attivando i bit 0 e 1 accendiamo lo speaker, e facciamo in modo che il suo ingresso venga collegato all'uscita del timer 2 del PIT. CURIOSITA': Tenendo fede al principio per cui più le cose sono incasinate più ci si diverte, si è deciso di piazzare quei bit di controllo in avanzo in una porta qualsiasi avente bit disponibili. Il controller della tastiera ne aveva un mucchio, poichè gli hanno appioppato sia il controllo dello speaker, sia il controllo del gate A20. Questo perchè nei vecchi XT queste porte erano utilizzate da un altro integrato (il PPI), e perchè nei nuovi AT non sapevano più dove mettere il controllo per il gate A20, un importantissima opzione che permette anche ai P5 di lavorare in modo reale come un buon, vecchio, glorioso 8086. Bene dunque, lo speaker si può accendere e collegare al timer 2. Ma in che modo esce fuori il suono? Beh, vedete (nell'estratto menzionato in precedenza) che il PIT ha varie modalità di conteggio? Vedete quella denominata MODE 3 - SQUARE WAVE RATE GENERATOR? E' proprio quella che fa al caso nostro... cambiando la frequenza dell'onda, si ottengono diverse tonalità di un segnale ad onda quadra. Un piccolo sintetizzatore, che ha sicuramente molto da invidiare ad una DX7. In che modo la frequenza dell'onda è legata al contatore del PIT? Anzitutto, il PIT viaggia ad una frequenza fissa di 1193181Hz, che è la stessa che otteniamo ponendo un contdown uguale ad 1. Per avere un altra frequenza: 1193181Hz -------------- = valore_contatore Onda_Quadra_Hz Possiamo quindi spaziare da circa 18Hz (quando il contatore vale 0, che in realtà viene interpretato come 0x10000) a circa 1Mhz (quando il contatore vale 1), più che sufficenti per un orecchio umano, e anche per uno disumano. Siamo a posto! Per un primo esempio, nell'archivio incluso nell'articolo, esaminate NOTE.ASM. Qualche precisazione: le frequenze per le note sono approssimate, le ho ricavate da un libro sulla Sound Blaster. Non garantisco che quello che qui chiamo DO sia effettivamente un DO, ma se non altro il rapporto tra un tono e l'altro (semitoni compresi) è valido, a orecchio. l'implementazione delle ottave nella MACRO Play_Note è banale, in quanto l'aumento di un ottava significa il raddoppio della frequenza. la NOTA_NULL, frequenza 0FFFFh = 65535Hz, è inaudibile, e la possiamo usare per le pause. Forse il vostro cane avrà qualcosa da ridire. per fare le pause ho usato l'INT 015h, funzione 086h, che raggiunge la precisione di un microsecondo. Non che ci serva tale precisione, ma fa scena, no? Quello che ci interessa maggiormente è: Program_PIT MACRO Freq mov bx,Freq mov dx,012h mov ax,034DDh div bx [1] push ax mov al,0B6h out PIT_CONTROL,al [2] pop ax out PIT_CHAN_2,al xchg ah,al out PIT_CHAN_2,al [3] ENDM [1] si esegue la divisione 1193181/Freq, per sapere il valore del contatore. Eventualmente si può precalcolare questo valore, se, come nel nostro caso, si usano solo determinate frequenze. C'era un motivo per cui IO non lo avevo precalcolato, ma ora non ricordo... [2] si programma il timer 2, scrittura di una word, mode 3, 16 bit counter. 0B6h = 10110110b [3] si immette il valore del contatore. Prima il byte meno significativo, poi quello più significativo, visto che abbiamo a disposizione una sola porta da 8 bit per un valore a 16 bit. Musica, maestro! Ora possiamo sbizzarirci a comporre quello che vogliamo... prima però cerchiamo di semplificarci il lavoro. Anzitutto, una struttura che ci permetta di rappresentare una nota, intesa come frequenza, ottava e durata. Quindi una serie di durate 'standard', ovvero semicrome, crome, etc. NOTA_QUARTO EQU 200000 NOTA_SEDICESIMO EQU NOTA_QUARTO / 4 NOTA_OTTAVO EQU NOTA_QUARTO / 2 NOTA_META EQU NOTA_QUARTO * 2 NOTA_INTERO EQU NOTA_QUARTO * 4 Nota STRUC N_Valore dw ? N_Ottava db ? N_Durata dd ? Nota ENDS 200000 corrisponde a 0.2 secondi, se cambiate questo automaticamente cambiare tutti le altre durate, alla successiva compilazione. Ora possiamo definire una sequenza di note in questo modo: For_Elisa Nota <NOTA_MI, 3, NOTA_OTTAVO> Nota <NOTA_REd,3, NOTA_OTTAVO> Nota <NOTA_MI, 3, NOTA_OTTAVO> Nota <NOTA_REd,3, NOTA_OTTAVO> Nota <NOTA_MI, 3, NOTA_OTTAVO> ... For_Elisa_notes dw ( $-For_Elisa ) / SIZE Nota L'ultima riga fa uso di un paio di direttive dell'assemblatore: $ indica l'offset nel segmento corrente alla posizione del carattere $, come dire Pippo dw offset Pippo mentre SIZE da la dimensione in byte del dato specificato. $ - For_Elisa si traduce in offset_attuale-offset_inizio, e con la divisione sappiamo quante note ci sono nella sequenza. Per questo esempio, fate riferimento a: ELISA.ASM, SPEAKER.MAC, SPEAKER.PRC. Non mi sembra che ci sia nulla di complicato, se non che ovviamente non è per niente ottimizzato, e che sono ricorso a registri 32bit (EAX) per risparmiarmi un po' di intrallazzi. Si può arrivare anche ad un semplice effetto di polifonia: spezzettando ogni nota in intervalli di piccolissima durata, e suonando alternativamente i pezzettini di ogni voce. Con intervalli veramente microscpici, dovrebbe uscire fuori un effetto simile a quello che si poteva ascoltare sullo Spectrum, come anche sul gioco Elite per PC: VOCE 1 VOCE 2 ... Nota <NOTA_LA ,3 ,NOTA_VELOCE> Nota <NOTA_FA ,1 ,NOTA_VELOCE> Nota <NOTA_LA ,3 ,NOTA_VELOCE> Nota <NOTA_FA ,1 ,NOTA_VELOCE> Nota <NOTA_LA ,3 ,NOTA_VELOCE> Nota <NOTA_FA ,1 ,NOTA_VELOCE> Nota <NOTA_LA ,3 ,NOTA_VELOCE> Nota <NOTA_FA ,1 ,NOTA_VELOCE> Nota <NOTA_LA ,3 ,NOTA_VELOCE> Nota <NOTA_FA ,1 ,NOTA_VELOCE> ... ... poi venne il TADAAA Sfruttando quello che abbiamo appena appreso su altoparlanti e cronometri, possiamo idearci un metodo per fare riprodurre allo speaker dei suoni campionati, pur non avendo un DAC. In realtà il metodo l'ha inventato qualcun'altro tanto tempo fa, io mi limito a riproporvelo. Non faccio come certa gente che passa per sue vecchie idee di altri. Mentre un DAC a 8bit di una scheda sonora può darci 256 livelli di segnale, il nostro speaker può averne solo 2 (acceso/spento), e allora cosa ti ha pensato il geniaccio? Ha pensato di stabilire un rapporto di proporzionalità, per cui maggiore è il valore che ha il singolo campione, maggiore è il tempo che l'altoparlante rimane acceso. Esaminiamo il mode 0 del PIT: dopo aver eseguito il contdown, viene generato un IRQ. In realtà, solo il timer 0 ha collegato un IRQ, gli altri non hanno nessun IRQ, ma sono collegati direttamente ad altri dispositivi. E come abbiamo visto, il timer 2 ha l'uscita collegata allo speaker. Durante il conto l'uscita è bassa, finito il conto, e finchè non si immette un nuovo valore, rimane alta: in corrispondenza avremo che lo speaker si troverà spento durante il conteggio, acceso alla fine e fino al prossimo. Sono piuttsto convinto che questa sequenza di acceso/spento con durata variabile sia riconducibile ad una modulazione di frequenza, e un campionamento altro non è che un caso particolare della modulazione di frequenza (se ricordo bene, sennò tanto funziona lo stesso). Tenendo presente che il valore che immettiamo nel contatore fa da divisore alla frequenza base del PIT, ne consegue che per aumentare il tempo in cui lo speaker rimane acceso, dobbiamo incrementare il valore del divisore. Forse rileggendo con calma gli ultimi due periodi, riuscirete ad intuire quello che volevo dirvi, ricordate che DURANTE il conteggio lo speaker è spento, e fino al prossimo rimane acceso, e che F=1/T. In ogni caso ne viene una tabella di conversione sul modello: Valore Campione Contatore Tempo Accensione Spk. 255 01 Tot_Time - 800ns [1] ... ... ... 192 20 Tot_Time - 16us ... ... ... 128 40 Tot_Time - 33us ... ... ... 064 60 Tot_Time - 50us ... ... ... 000 80[2] Tot_Time - 66us [1]Tot_Time dipende dalla frequenza di riproduzione dei campioni. Per 11025Hz, Tot_Time = 90us, secondo la formula F=1/T. [2]Questo valore, ovvero il massimo che deve assumere il contatore, dovrebe essere determinato su calcoli in base alla frequenza di riproduzione e alla frequenza base del PIT. In pratica però una tabella precalcolata trovata in giro, quella che uso in questi esempi, si comporta sempre meglio di una qualsiasi altra calcolata appositamente. Devo ammettere di non essere riuscito a capire il perchè, visto che sembra tarata per lavorare intorno ai 15Khz, comunque la formula per calcolare l'intera tabella sarebbe (255-valore_campione) * pit_base_freq contatore = --------------------------------------- + 1 play_freq * 256 O io in realtà non ho capito nulla di questo meccanismo, o c'è un piccolo dettaglio che mi sfugge. Se per caso qualcuno capisce cosa, può scrivermi. Va bene, facciamo qualcosa di concreto. Supponiamo di avere file campionati a 11025Hz, 8bit, mono, massimo 64k, in formato raw. Ovvero senza header, semplicemente un campione appresso all'altro. Supponiamo di aver caricato in memoria il nostro file, e di averlo disponibile ad ES:0000 cli Set_Speaker_On mov cx,file_size byte_loop: mov al,es:[si] converti campione secondo tabella out PIT_CHAN_2,al push cx mov cx,150h wait_loop: loop wait_loop pop cx inc si loop byte_loop Set_Speaker_Off sti il limite di 64Kb è per il problema della segmentazione in modalità reale. O meglio, è per il problema della pigriza che non mi vuol far fare troppi intrallazzi. con CLI disabilitiamo gli interrupt, per evitare interferenze. Volendo esagerare, si potrebbe mascherare direttamente il PIC. Usando il solo CLI, leviamo di mezzo il fruscio a 18Khz del clock, se mascheriamo il PIC facciamo in modo che neanche accessi a disco o tasti premuti o qualsiasi altra cosa possa rallentarci il play. la conversione si può fare usando l'istruzione XLAT. Dato l'offset della tabella di conversione, XLAT legge il valore alla posizione specificata in AL e lo sostituisce in AL stesso. Come dire che I = ARRAY[I]. il WAIT_LOOP non è per niente preciso, poichè dipende enormemente dalla CPU. Dovrete cambiare il valore di CX finchè non ne troverete uno adatto che vi farà sentire il file alla giusta velocità. E' questo ciclo che determina la frequenza di riproduzione, per ora. I file da esaminare sono: PLAY.ASM, SPEAKER2.MAC, SPEAKER2.PRC, SOUND.RAW. Ci sono un po' di curiosità in quest' ultimo esempio: Linea di comando il nome del file da riprodurre viene passato tramite linea di comando. Il dos la memorizza nel PSP, una struttura che crea per ogni eseguibile in esecuzione. All'offset 0x80 del PSP vi è la dimensione della linea di comando, memorizzata dall'offset 0x81, e per un massimo di 128 caratteri. Siccome vengono memorizzati anche gli spazi, si deve provvedere ad eliminarli. Ora che ci penso... anche i TAB vengono memorizzati... comunque è tutt'altro che elegante il metodo che ho usato qui, cercerò di rimediare nel prossimo... Allocazione di memoria il dos alloca tutta la memoria compresa nei primi 640Kb al programma avviato. Quindi, se noi vogliamo allocarne per conto nostro, dobbiamo ridurre quella che si è presa l'eseguibile e farci spazio. Qui si magheggia con l'MCB (Memory Control Block), che è un ulteriore struttura che il dos usa per ogni area di memoria allocata, e che ne contiene la dimensione in paragrafi. Magari una delle prossime volte vedremo la questione in dettaglio. I/O su file ho usato le funzioni dos per la manipolazione di file tramite handler. Una qualsiasi guida potrà illuminarvi, roba facile. La prossima volta vedremo come leggere direttamente i file .WAV, ma, cosa più importante, useremo il timer di sistema per avere una frequenza di riproduzione esatta e indipendente dalla macchina.

rimandatamente, Cthulhu