il primo sistema operativo multitasking (cosa parzialmente vera)
Cosa intendi esattamente per “cosa parzialmente vera”?
Ovviamente i complessi e costosissimi frameworks Unix, grossi come stanze, che solo università ed enti di ricerca o grosse aziende avevano, quelli erano già in multitasking, è chiaro … pertanto Amiga 1000 / Lorraine non è stato il primo computer multitasking.
È forse stato il primo home-computer per le masse con multitasking?
Se no, quale è stato il primo? (scusate il parziale OT …).
A parte il fatto che “multitasking” vuol dire poco o nulla, bisognerebbe vedere come è realizzato il multitasking, la politica di scheduling, cosa si intende per “priorità” di un task ecc …
Fra parentesi, è una cosa che ancora non ho ben capito:
si vede nella MountList nei sistemi 1.3 … in ogni entry-point della MountList, abbiamo un device, il suo header (spesso questo risiede in L: ), vediamo la grandezza dell’eventuale buffer, la grandezza dello stack, poi globvec = -1, che non so cosa voglia dire, e poi il valore della priorità.
Ecco, chissà cosa si intende esattamente per “priorità” nel mondo Amiga classici.
Io ad esempio lavoro come firmwarista in un’azienda, e abbiamo sviluppato un nostro OS proprietario per le nostre schede, traendo spunto da FreeRTOS. Nel mondo degli RTOS per applicazioni industriali embedded, spesso la “priorità” non è altro che il numero N di slot temporali (1 slot = tempo che ci mette il contatore del tick di sistema ad andare dal valore massimo impostato a zero facendo count-down, quindi a scatenare il tick-sys-interrupt che scadenza la base dei tempi dello scheduler) durante i quali lo schedulatore NON può fare prelazione della CPU, ovvero durante ad esempio N=4 slots temporali (4 x 1ms, ad esempio), la CPU rimane nelle mani del processo (=nessun cambio di contesto è possibile, per nessuna ragione) che la detiene attualmente, l’OS non può sottrargliela, a meno che non sia il processo stesso, magari perché ha finito il lavoro prima del previsto, a dire, tramite un’API apposita, all’OS: “OS, ho già finito, ce l’ho fatta in 2 slots anziché 4, riprenditi pure la CPU”. Questa tecnica si chiama in gergo “cooperative”.
non per aver messo a disposizione di tutti alcune caratteristiche che poi sono diventate standard
Come ad esempio il plug’n’play, o “hot-plug”, come dir si voglia (Autoconfig, in gergo amigoso).
Mi pare addirittura a partite dall’OS 1.2, ma a causa di un bug, divenne realmente funzionante a partire dall’OS 1.3, comunque stiamo parlando (correggetemi se sbaglio) di 1987/1988.
Microsoft ha fornito il suo primo plug’n’play realmente funzionante con Windows95!!
E forse un altro motivo di primato o comunque semi-primato amigoso è il fatto che la CPU (68000, nel nostro caso) viene messa in cooperazione con chips custom per motivi di coadiuvazione grafica e sonora.
Fino a poco tempo fa pensavo che Amiga fosse il primo home computer dove la CPU venisse aiutata da chips custom come Paula oppure Denise, ma leggendo qualche riga di Atari ST520 e fac-simili, si evince (parlo da ignorante disinformato) che forse anche lì si aveva una forma di cooperazione audio-visiva in parallelo al lavoro della CPU … correggetemi/eruditemi se sbaglio.
Non ho mai avuto l'Hardware reference manual
Lo trovai tempo fa su Ebay, un venditore dall’America, ad un prezzo esorbitante, qualcosa come 150 euro per 2 o 3 libri, se non erro … Ovviamente non me lo potei permettere … davvero un lusso!
Qui mi viene un'altra domanda: AmigaOS 4.x usa ancora RoundRobin come politica di scheduling?
Non lo so … ad ogni modo il “RoundRobin”, ovvero il “furto di ciclo”, lo dice la parola stessa, vuol dire “rubare il ciclo”, ovvero togliere la CPU al task che correntemente detiene la CPU stessa per darla ad un altro task (… correggetemi se sbaglio … io sono elettronico, non informatico): bisogna vedere sotto quali condizioni e in che modo viene sottratto il ciclo al task N e secondo quali logiche viene data la CPU al task N+1 … credo che sia questo a fare la differenza fra le varie forme di “RoundRobin”.
la paginazione dei processi sia stata introdotta sempre con gli AmigaNG (4.x)
Si, so per certo che in OS4.x abbiamo la MMU, quindi il concetto di memoria virtuale: ogni processo pensa di essere da solo, di iniziare dall’address 0, come se fosse davvero l’unico processo, come nei firmware “bare metal” che si scrivono per le piccole CPU (piccoli PIC, piccoli Atmel, ecc…) senza OS sopra, inoltre ogni processo pensa di avere per se più memoria RAM di quella effettivamente messa a disposizione dal sistema, questo grazie al fatto che una parte di RAM “creduta” da ogni programma non è RAM in effetti, bensì una porzione di disco, una porzione di swap-area, e inoltre di conseguenza abbiamo l’impaginazione (le pagine dei processi non spesso utilizzate, e/o non frequentemente utilizzate, vanno sul disco, in swap-area).
Chiaramente, il valore del contatore deve essere impostato in base al clock di sistema...
Certo, e chiaramente anche in base a quanto vuoi fissare il tuo system quantum tick.
Per lavoro, noi nel nostro OS proprietario lo abbiamo fissato a 100us.
Gli A2000 e 4000 (ma credo anche i 3000) hanno un alimentatore tipo alimentatore PC
che abbassa la tensione di rete, la filtra e la rende disponibile sulla MB tramite connettore.
Alimentatore tipo PC … quindi stiamo parlando di un ponte a 4 diodi (ponte di Leo Graetz) che realizza un raddrizzatore a doppia semionda (=viene fatta passare quasi trasparentemente la semi-onda positiva della “sinusoide” di rete, a meno della caduta di tensione sui 2 diodi in conduzione, e poi viene “invertito il segno” della semi-onda negativa di rete, sempre al netto delle cadute di tensione in serie sugli altri 2 diodi in conduzione ), con in serie una squadra RC come filtro passa basso per reiettare le armoniche multiple di f0=50Hz.
Quindi alla MB arriva la tensione Vdc, quindi raddrizzata e filtrata dalle armoniche superiori Nxf0.
Gli alimentatori di PC, da notebook insomma, quelli che escono con la 19Vdc, sono tutti così.
Nei connettori quadrati Amiga, quelli a 5 poli, abbiamo solo Vdc continue (GND, 12V, -12V, 5V).
E' possibile che venga sollevato un interrupt software (TRAP)?
Può essere, non lo so.
Nei microcontrollori di oggi, l’IRQ “TRAP”, ovvero una “trappola” per il program counter PC della CPU, viene scatenato quando si fa il debugging, ed il PC passa attraverso un break-point da noi posizionato presso una nostra riga di codice, codice che appunto stiamo debuggando. Il PC si ferma presso quel break-point proprio in ragione dell’ingresso del PC stesso in un vettore di interrupt TRAP, da cui non esce, fino a quando non glielo consentiamo noi tramite IDE/toolchain di compiling/linking/debugging (così da far tornare il nostro FW “under-debugging” in condizione di free-running).