Come si invogliano nuovi dev a mettere mani in AROS?

[cdimauro]

• 

Devo andare a vedermi Capitan Harlock con la famiglia, quindi un appunto solo su questo:

(soprattutto quello implementato ad uso e consumo linux/BSD, sopratutto la super cazzata di aver usato una macchina virtuale x86 per inizializzare le schede video, questa cosa e' una cazzata galattica che non funziona quasi mai su nessuna macchina non x86, quindi non ha 2 volte motivo di esistere)

Purtroppo questo "hack" è necessario, perché non c'è altro modo per inizializzare una scheda grafica VESA e da usare poi col framebuffer.

Ed è una cosa sulla quale mi sto cimentando di recente. Vediamo se ne uscirà fuori qualcosa di utile per AROS.

[Allanon]

• 

@cdimauro
Piccola parentesi OT: io Capitan Harlock l'ho visto un paio di giorni fa, se vuoi in un thread apposito ne parliamo
Buona visione!

[cdimauro]

• 

Per me va bene.

[Z80Fan]

• 

Proviamolo.

Se riesci a procurarti i sorgenti del driver NVIDIA, ci darei volentieri un'occhiata!
(il mio "proviamo" era più da leggere come "tentiamo in modo pratico", una mezza allegoria per dire che, senza due implementazioni che sfruttano i due sistemi e che possiamo misurare, solo in via teorica è difficile concludere)

Il fatto che sia ottimizzata su Linux non implica che sia migliore di altri metodi.

Era per dire che, nonostante sia una chiamata a un sottosistema generico come il filesystem, l'esecuzione per questo caso particolare è comunque molto veloce.

La stessa identica cosa si può fare anche con una libreria.

Perché non si potrebbe fare altrettanto con una libreria?

Ovvio che si può fare; il dibattito non è cosa si può/non si può fare, ma quanto veloce è, e la mia tesi è che non c'è una così grande differenza in questo caso.

Non ho parlato di libreria di sistema, ma di libreria. Dunque perfettamente gestibile in user-space, al costo di:
- una LOAD LibraryBase (solo la prima volta nel caso di chiamate consecutive alla libreria) nel registro usato per memorizzarla;
- una CALL a un certo offset dal registro per eseguire il codice.
Questo in un s.o. Amiga/like, perché c'è la necessità di passare / usare la LibraryBase.

In altri s.o. è possibile, invece, "risolvere" al caricamento della libreria gli indirizzi delle funzioni che sono necessarie all'applicazione, per cui chiamare un'API significa soltanto:
- una CALL PuntatoreAllaAPI (questo su x86/x64; su processori RISC in genere serve una LOAD e una CALL).

Dunque richiamare l'API di una libreria è un'operazione estremamente veloce, di gran lunga più veloce rispetto al meccanismo di:
- codifica dell'operazione da eseguire in un buffer (e quindi ti serve anche memoria allo scopo);
- invocazione della syscall fwrite (dunque passaggio da user a kernel mode: context switch!);
- in base al file handle, il kernel deve capire a quale device deve spedire i parametri della fwrite;
- chiamata al fwrite del device;
- nel caso del device nvidia0, questo deve analizzare il buffer e capire cosa ha scritto l'applicazione. Dunque parsing di uno stream dati -> recupero del codice/opcode del comando invocato & relativi parametri;
- a questo punto viene "invocato" il comando (codice comune all'API della libreria: stesse cose da fare);
- il device restituisce il controllo al kernel;
- il kernel restituisce il controllo all'applicazione (passaggio da kernel a user mode: un altro context switch).

Per quanto possa essere ottimizzato in Linux, tutto ciò rimane decisamente più pesante e complicato da gestire. Una chiamata a libreria è immensamente più semplice.

Non hai capito; mi sa che stiamo parlando di cose un po' diverse, perciò mi spiego meglio:
prima di tutto, io sto parlando di questo particolare caso del driver e GPU NVIDIA, e non altre librerie di alto livello (come potrebbe essere la libc ad esempio, o altre librerie di disegno più "interattive" come SDL).

Secondo, un'applicazione OpenGL che usa il driver NVIDIA su Linux funziona circa così:
1) Il driver NVIDIA è composto da due parti: una che lavora kernel-mode (e che  è responsabile della creazione del device /dev/nvidia0), e una parte user-mode (che parla con l'applicazione per esporre tutte le funzioni dell'API).
La parte user non lavora in un suo processo, e quindi sospetto che sia tutto dentro la libreria libGL.so (che, come si capisce dal nome, espone OpenGL), o al massimo ad un'altra libreria che viene caricata da libGL stessa.

2) Le GPU moderne non lavorano con la tecnica di una volta imposta_registri - esegui - imposta_registri - esegui etc, perchè sarebbe una lentezza esorbitante; quello che succede è che lato CPU viene creata una lista di comandi, sotto forma di un bufferone di strutture, che viene inviato in blocco alla GPU tramite DMA; la GPU al suo interno possiede un processore di controllo che interpreta i dati e fa il dispatch dei vari comandi ai vari core di esecuzione parallela.

3) Detto questo, lato CPU abbiamo "solo" il compito di tradurre le chiamate che l'applicazione fa a OpenGL nell'apposito bufferone di comandi; da quanto posso osservare dall'esterno, credo che questa operazione venga fatta solo dal sistema user-mode, quindi da libGL.so diciamo.
Quindi, attraverso /dev/nvidia0 (che ora che ci penso probabilmente è aperto in mmap, quindi non ci sono neanche copie dovute a read() e write()) ci passano solo dati che sono già organizzati per essere inviati alla GPU (e al suo controller interno); quello che la parte kernel-mode deve solo fare è fare un po' di serializzazione in base al PID (nel caso ci siano più applicazioni che usano libGL), e gestire le operazioni di DMA.

Detto questo, un sistema del genere non risente dello "strano" modo di mappare i dispositivi su file tipico degli Unix.
Se dovessimo implementare un sistema del genere tramite una "libreria", si potrebbe fare in due modi diversi (che sono i due punti che avevo elencato sopra):

• 1) Si tiene la stessa organizzazione di adesso (user fa tutto, kernel gestisce il dma e concorrenza): in questo caso l'unica differenza sarebbe che la parte user e la parte kernel, invece di parlarsi e condividere i bufferoni tramite l'mmap e il /dev/nvidia0, si parlando tramite memoria condivisa (che alla fine è il mmap), e alcune funzioni dedicate alla comunicazione (buffer pronto/ricevi buffer/copia dati etc). Questo credo che sia come viene fatto in Windows ad esempio, che ha il vantaggio di permettersi un driver model molto più "tipico", però (come i benchmark mostrano), questo sistema non è né migliore né peggiore del sistema unix, in quanto il grossissimo del lavoro è fatto in user-mode per la creazione delle liste di comandi, e il piccolo segnale che user deve mandare al kernel per inviare i comandi alla GPU è una percentuale molto piccola del tempo totale da risultare trascurabile.
• 2) Si mette tutto dentro il kernel che espone direttamente le funzioni OpenGL a mo' di syscall: in questo caso, lato applicazione non si avrebbe più la corposa libGL.so che fa un po' tutto,  ma si avrebbe solo uno stub che a turno usa i metodi del sistema operativo per mandare le chiamate al driver, che così internamente può fare tutte le cose che gli interessano. Questo metodo è evidentemente più lento del sistema precedente, perchè ogni chiamata deve passare per i sistemi di dispatch dell'OS, deve entrare in kernel mode e deve essere ricevuta dal driver; oltretutto, l'applicazione deve essere messa in attesa della fine della chiamata a funzione. Quest'ultimo punto può essere mitigato (e anche molto, in base all'api), se si usa un sistema di message-passing che ammette RPC asincrona: in questo modo, l'applicazione può inviare a raffica molte chiamate a funzione e solo in un secondo momento leggere i valori di ritorno.

Fine. Ricapitolando: in questo particolare caso, il sistema e le condizioni sono tali da non prendere un colpo dal particolare sistema di comunicazione via file descriptor.

Non è una dimostrazione formale, ma mio avviso risulta piuttosto chiaro che l'approccio a libreria sia intrinsecamente più efficiente di quello tramite utilizzo di un file "speciale".

Questo è ovvio ("ovvio" non per sminuire quello che hai detto, ma che si spera sia evidente a chiunque nel settore), se parliamo di una libreria generica; praticamente si avrebbe la pesantezza di un sistema di message passing unito alla pesantezza delle operazioni del filesystem.
In questi casi particolari, invece, dove la destinazione di queste informazioni è già un dispositivo hardware che lavora più o meno a stream di byte, la differenza è molto meno sentita, se non annullata.
Riprendiamo l'esempio di legacy: ovviamente quel sistemino lì è molto pesante, perchè l'applicazione, il driver e la CPU devono far lavoro di codifica/decodifica dei dati solo e unicamente per conformarsi al contorto sistema di trasferimento dati tra applicazione e libreria.
Ma se il file fosse mappato a una zona di memoria che è una finestra per un dispositivo hardware che fa le stesse operazioni, allora non si avrebbe nessuna operazione aggiuntiva, perchè già i dati vanno codificati nel formato che l'hardware vuole, e non c'è nessuna decodifica da fare lato cpu.

su hw SGI questo e' il giro del fumo, ampiamente dimostrato essere il modo + efficace e pulito possibile (sopratutto quanto si tratta di super computer), anche perche' si tratta di sistemi NUMAflex, dove la o le CPU e GFX si parlano solo tramite interrupt, e DMA. La applicazione di turno parcheggia  i comandi ed i dati grafici nella pipe della/delle GFX interessate, ci aggiunge anche i puntatori della zona di memoria video condivisa e quando scatta il crossbar event il DMA fa il resto, ovvero si puppa in un sol colpo la lista di cose da fare, i dati da processare, e si mette a processarli rilasciando poi, eventualmente, un interrupt

e' stata per anni la soluzione vincente dalle piccole Workstation ai supercomputer Visualize

la separazione dei compiti e' netta:

• il kernel si occupa SOLO di infilare il bufferone nello slot giusto del crossbar per farlo arrivare sano alla GFX giusta, non da altre parti, e di raccogliere flag ed interrupt
• la parte in userspace si occupa SOLO di confezionare quel buffer di comandi nel modo giusto, senza cose bislacche, e di passare pure i puntatori giusti, e sopratutto aggiornati, per la memoria video condivisa

a me personalmente va bene e piace che sia cosi' anche per ridurre la complessità del codice, o mi occupo del kernel e ragiono per buffer, o mi occupo dello user space e ragiono per comandi e servizi per le primitive grafiche

Stessa cosa che fa l'hardware moderno; se leggi la presentazione di NVIDIA che avevo anche linkato prima, vedrai che è proprio come dici.

Purtroppo questo "hack" è necessario, perché non c'è altro modo per inizializzare una scheda grafica VESA e da usare poi col framebuffer.

Ed è una cosa sulla quale mi sto cimentando di recente. Vediamo se ne uscirà fuori qualcosa di utile per AROS.

Avevo lo stesso problema quando lavoravo sul mio kernel hobby: GRUB mi andava comodo perchè mi metteva già in modalità protetta, ma questo significa che non potevo fare le chiamate al BIOS per le funzioni VBE. A suo tempo avevo visto quel trick che faceva X11, e avevo anche una mezza idea di tirargli fuori quella parte di sorgente da usare ai miei scopi, poi però mi son accontentato di far impostare la modalità grafica a un GRUB modificato, e disegnare a mano nel framebuffer.
Avevo anche letto di gente che usava la modalità protetta per creare un "processo" che girava in modalità reale, e lo si usava per far girare il codice del BIOS. È sicuramente un'idea furba e molto interessante, ma credo anche sia abbastanza tricky da far funzionare.

Renderai pubblici i tuoi test? Mi interesserebbe vedere come ne vieni fuori...

[cdimauro]

• 

Non hai capito; mi sa che stiamo parlando di cose un po' diverse, perciò mi spiego meglio:
prima di tutto, io sto parlando di questo particolare caso del driver e GPU NVIDIA, e non altre librerie di alto livello (come potrebbe essere la libc ad esempio, o altre librerie di disegno più "interattive" come SDL).

Secondo, un'applicazione OpenGL che usa il driver NVIDIA su Linux funziona circa così:
1) Il driver NVIDIA è composto da due parti: una che lavora kernel-mode (e che  è responsabile della creazione del device /dev/nvidia0), e una parte user-mode (che parla con l'applicazione per esporre tutte le funzioni dell'API).
La parte user non lavora in un suo processo, e quindi sospetto che sia tutto dentro la libreria libGL.so (che, come si capisce dal nome, espone OpenGL), o al massimo ad un'altra libreria che viene caricata da libGL stessa.

2) Le GPU moderne non lavorano con la tecnica di una volta imposta_registri - esegui - imposta_registri - esegui etc, perchè sarebbe una lentezza esorbitante; quello che succede è che lato CPU viene creata una lista di comandi, sotto forma di un bufferone di strutture, che viene inviato in blocco alla GPU tramite DMA; la GPU al suo interno possiede un processore di controllo che interpreta i dati e fa il dispatch dei vari comandi ai vari core di esecuzione parallela.

3) Detto questo, lato CPU abbiamo "solo" il compito di tradurre le chiamate che l'applicazione fa a OpenGL nell'apposito bufferone di comandi; da quanto posso osservare dall'esterno, credo che questa operazione venga fatta solo dal sistema user-mode, quindi da libGL.so diciamo.
Quindi, attraverso /dev/nvidia0 (che ora che ci penso probabilmente è aperto in mmap, quindi non ci sono neanche copie dovute a read() e write()) ci passano solo dati che sono già organizzati per essere inviati alla GPU (e al suo controller interno); quello che la parte kernel-mode deve solo fare è fare un po' di serializzazione in base al PID (nel caso ci siano più applicazioni che usano libGL), e gestire le operazioni di DMA.

Detto questo, un sistema del genere non risente dello "strano" modo di mappare i dispositivi su file tipico degli Unix.
Se dovessimo implementare un sistema del genere tramite una "libreria", si potrebbe fare in due modi diversi (che sono i due punti che avevo elencato sopra):

• 1) Si tiene la stessa organizzazione di adesso (user fa tutto, kernel gestisce il dma e concorrenza): in questo caso l'unica differenza sarebbe che la parte user e la parte kernel, invece di parlarsi e condividere i bufferoni tramite l'mmap e il /dev/nvidia0, si parlando tramite memoria condivisa (che alla fine è il mmap), e alcune funzioni dedicate alla comunicazione (buffer pronto/ricevi buffer/copia dati etc). Questo credo che sia come viene fatto in Windows ad esempio, che ha il vantaggio di permettersi un driver model molto più "tipico", però (come i benchmark mostrano), questo sistema non è né migliore né peggiore del sistema unix, in quanto il grossissimo del lavoro è fatto in user-mode per la creazione delle liste di comandi, e il piccolo segnale che user deve mandare al kernel per inviare i comandi alla GPU è una percentuale molto piccola del tempo totale da risultare trascurabile.
• 2) Si mette tutto dentro il kernel che espone direttamente le funzioni OpenGL a mo' di syscall: in questo caso, lato applicazione non si avrebbe più la corposa libGL.so che fa un po' tutto,  ma si avrebbe solo uno stub che a turno usa i metodi del sistema operativo per mandare le chiamate al driver, che così internamente può fare tutte le cose che gli interessano. Questo metodo è evidentemente più lento del sistema precedente, perchè ogni chiamata deve passare per i sistemi di dispatch dell'OS, deve entrare in kernel mode e deve essere ricevuta dal driver; oltretutto, l'applicazione deve essere messa in attesa della fine della chiamata a funzione. Quest'ultimo punto può essere mitigato (e anche molto, in base all'api), se si usa un sistema di message-passing che ammette RPC asincrona: in questo modo, l'applicazione può inviare a raffica molte chiamate a funzione e solo in un secondo momento leggere i valori di ritorno.

Fine. Ricapitolando: in questo particolare caso, il sistema e le condizioni sono tali da non prendere un colpo dal particolare sistema di comunicazione via file descriptor.

Non è una dimostrazione formale, ma mio avviso risulta piuttosto chiaro che l'approccio a libreria sia intrinsecamente più efficiente di quello tramite utilizzo di un file "speciale".

Questo è ovvio ("ovvio" non per sminuire quello che hai detto, ma che si spera sia evidente a chiunque nel settore), se parliamo di una libreria generica; praticamente si avrebbe la pesantezza di un sistema di message passing unito alla pesantezza delle operazioni del filesystem.
In questi casi particolari, invece, dove la destinazione di queste informazioni è già un dispositivo hardware che lavora più o meno a stream di byte, la differenza è molto meno sentita, se non annullata.
Riprendiamo l'esempio di legacy: ovviamente quel sistemino lì è molto pesante, perchè l'applicazione, il driver e la CPU devono far lavoro di codifica/decodifica dei dati solo e unicamente per conformarsi al contorto sistema di trasferimento dati tra applicazione e libreria.
Ma se il file fosse mappato a una zona di memoria che è una finestra per un dispositivo hardware che fa le stesse operazioni, allora non si avrebbe nessuna operazione aggiuntiva, perchè già i dati vanno codificati nel formato che l'hardware vuole, e non c'è nessuna decodifica da fare lato cpu.

OK, è tutto chiaro adesso. Avevo capito che /dev/nvidia0 veniva usato per spedire i comandi grafici, che andavano codificati e poi decodificati.

Per quanto hai scritto, non ci sono differenze prestazionali fra l'approccio a file e a librerie in questo caso.

Purtroppo questo "hack" è necessario, perché non c'è altro modo per inizializzare una scheda grafica VESA e da usare poi col framebuffer.

Ed è una cosa sulla quale mi sto cimentando di recente. Vediamo se ne uscirà fuori qualcosa di utile per AROS.

Avevo lo stesso problema quando lavoravo sul mio kernel hobby: GRUB mi andava comodo perchè mi metteva già in modalità protetta, ma questo significa che non potevo fare le chiamate al BIOS per le funzioni VBE. A suo tempo avevo visto quel trick che faceva X11, e avevo anche una mezza idea di tirargli fuori quella parte di sorgente da usare ai miei scopi, poi però mi son accontentato di far impostare la modalità grafica a un GRUB modificato, e disegnare a mano nel framebuffer.
Avevo anche letto di gente che usava la modalità protetta per creare un "processo" che girava in modalità reale, e lo si usava per far girare il codice del BIOS. È sicuramente un'idea furba e molto interessante, ma credo anche sia abbastanza tricky da far funzionare.

Renderai pubblici i tuoi test? Mi interesserebbe vedere come ne vieni fuori...

Ehm... non penso proprio. La mia idea è di sviluppare una libreria che esponga delle API che vengono richiamate dal driver che implementa il supporto al VESA (per settare un determinato modo video da BIOS, ed elencare le modalità video disponibili). Compilerò e rilascerò la libreria (o un file oggetto, se qualcosa dovesse servire da linkare nel kernel), ma non i sorgenti. Quelli del driver, invece, saranno giocoforza pubblici causa licenza virale.

Mi spiace, ma non ho intenzione di condividere il mio lavoro con tutti. C'è parecchio da sgobbare, e non voglio svendere la mia professionalità, soprattutto pensando che qualcuno possa sfruttarlo senza che né io né AROS abbia qualcosa in cambio.

Comunque al momento parliamo di ipotesi. Prima che possa capire se funziona o meno, passerà parecchio tempo sperimentando.

[Z80Fan]

• 

Ehm... non penso proprio. La mia idea è di sviluppare una libreria che esponga delle API che vengono richiamate dal driver che implementa il supporto al VESA (per settare un determinato modo video da BIOS, ed elencare le modalità video disponibili). Compilerò e rilascerò la libreria (o un file oggetto, se qualcosa dovesse servire da linkare nel kernel), ma non i sorgenti. Quelli del driver, invece, saranno giocoforza pubblici causa licenza virale.

Mi spiace, ma non ho intenzione di condividere il mio lavoro con tutti. C'è parecchio da sgobbare, e non voglio svendere la mia professionalità, soprattutto pensando che qualcuno possa sfruttarlo senza che né io né AROS abbia qualcosa in cambio.

Comunque al momento parliamo di ipotesi. Prima che possa capire se funziona o meno, passerà parecchio tempo sperimentando.

Conosco bene come la pensi, per questo ho chiesto. Comunque a me non interessano i sorgenti, ma solo informazioni varie tipo se ti scrivi un emulatore oppure usi il trick del segmento in modalità reale, oppure se hai incontrato comportamenti strani non documentati di cui stare attenti.
Ovviamente se non vuoi neanche discutere di queste cose, non ci sono problemi: lavoro tuo, decisione tua.

pensate che bello il fatto che sulle workstation SGI ed HP non c'e' bisogno di fare quei giri per la "scheda video", hai gia' tutto esposto dal firmware

Vabbè, lì ti parte la musichina "ti piace vincere facile? bonsci bonsci bon bon bon"!

[cdimauro]

• 

pensate che bello il fatto che sulle workstation SGI ed HP non c'e' bisogno di fare quei giri per la "scheda video", hai gia' tutto esposto dal firmware

Lo credo bene: hai solo quella, o comunque pochi modelli, di cui hai pieno controllo.

Pensa, invece, cosa serve per poter cambiare modalità video per TUTTE le schede grafiche esistenti (che supportano VESA e Linear framebuffer, ovviamente: diversamente è tecnologia dell'anteguerra di cui non ha nemmeno senso discutere). O hai i driver del produttore (come capita con Windows, e qualche volta con Linux), oppure piangi in aramaico antico.

Ehm... non penso proprio. La mia idea è di sviluppare una libreria che esponga delle API che vengono richiamate dal driver che implementa il supporto al VESA (per settare un determinato modo video da BIOS, ed elencare le modalità video disponibili). Compilerò e rilascerò la libreria (o un file oggetto, se qualcosa dovesse servire da linkare nel kernel), ma non i sorgenti. Quelli del driver, invece, saranno giocoforza pubblici causa licenza virale.

Mi spiace, ma non ho intenzione di condividere il mio lavoro con tutti. C'è parecchio da sgobbare, e non voglio svendere la mia professionalità, soprattutto pensando che qualcuno possa sfruttarlo senza che né io né AROS abbia qualcosa in cambio.

Comunque al momento parliamo di ipotesi. Prima che possa capire se funziona o meno, passerà parecchio tempo sperimentando.

Conosco bene come la pensi, per questo ho chiesto. Comunque a me non interessano i sorgenti, ma solo informazioni varie tipo se ti scrivi un emulatore oppure usi il trick del segmento in modalità reale, oppure se hai incontrato comportamenti strani non documentati di cui stare attenti.
Ovviamente se non vuoi neanche discutere di queste cose, non ci sono problemi: lavoro tuo, decisione tua.

No, mi limito a non pubblicare i sorgenti. Della soluzione ne posso anche parlare.

Ho scartato la soluzione di creare un segmento/descrittore per eseguire codice in modalità reale o dentro una macchina virtuale 8086, per due motivi: primo perché non funziona su x64, e secondo perché non mi dà pieno controllo per quello che voglio fare.

Per cui vale la prima che hai detto: mi scrivo un emulatore 8086 "nudo e crudo" (niente 80186 o altre migliorie). Il minimo indispensabile per far girare il codice del BIOS della scheda video installata, in modo da recuperare facilmente l'elenco delle modalità video, e di settare quella desiderata.

Al momento penso di svilupparlo in Python, per una questione di velocità di modellazione. Tanto per queste cose non mi serve assolutamente la velocità d'esecuzione, ma vedere se l'emulatore si comporta bene e fa il suo lavoro correttamente.

Una volta verificato funzionamento, converto paro paro il codice in C nudo e crudo, e "sufficientemente portatile". Quest'ultimo significa che al momento il codice sarà esclusivamente little-endian, ma farò uso di macro per accedere a word/16-bit, in modo da rendere molto semplice l'eventuale porting su altre architetture.

Soltanto per Windows, penso di incapsulare il tutto dentro una DLL, in modo da poter riciclare il codice di unit-testing che scriverò in Python. Specialmente per queste cose, lo unit-testing è fondamentale. Anche perché mi consente di sperimentare nuove implementazioni senza l'incubo di aver introdotto qualche bug.

Al momento è tutto, ma di carne al fuoco e pensieri ce n'è già abbastanza. Ho in mente anche altre soluzioni per migliorare la velocità d'esecuzione (che comunque, per quel che deve fare il progetto, non è assolutamente importante), ma è decisamente prematuro parlarne.

[Z80Fan]

• 

Ho scartato la soluzione di creare un segmento/descrittore per eseguire codice in modalità reale o dentro una macchina virtuale 8086, per due motivi: primo perché non funziona su x64, e secondo perché non mi dà pieno controllo per quello che voglio fare.

Ah già, questa cosa me la ero dimenticata; probabilmente per lo stesso motivo pensavo di riusare il codice dell'emulatore di X, ma son passati alcuni anni e non mi ricordo proprio cosa avevo pensato a quel tempo...

Per cui vale la prima che hai detto: mi scrivo un emulatore 8086 "nudo e crudo" (niente 80186 o altre migliorie). Il minimo indispensabile per far girare il codice del BIOS della scheda video installata, in modo da recuperare facilmente l'elenco delle modalità video, e di settare quella desiderata.

E prendere il codice da qualche altra parte? Ad esempio da DOSBox, o da Bochs? Ti velocizzerebbe tantissimo lo sviluppo.
(Ovviamente devi fare una veloce indagine e capire se il codice è abbastanza modulare da essere spostato dal progetto originale a questa nuova occupazione, e solo in caso negativo metterti a scrivere il tuo emulatore)

[cdimauro]

• 

Il problema è la licenza: il primo è GPL, e il secondo LGPL. Io voglio poterci fare quello che voglio col mio codice, senza essere costretto a rilasciarlo...

Poi non ti nascondo che smanettare con queste cose mi gasa molto: adoro lavorare con roba a così basso livello.

[cdimauro]

• 

Perdonami, Carlo, ma quando hai le mani libere puoi fare quello che vuoi e inventarti il sistema più bello e fico del mondo.

Il PC si porta dietro la progettazione del primo modello targato IBM, che è stato via via espanso/esteso aggiungendo nuove funzionalità, ma preservando la famigerata retrocompatibilità.

Col senno di poi è facile dire cosa sarebbe stato meglio fare...

[cdimauro]

• 

no, il punto e' un altro: io non ci spenderei 2 minuti su quella roba, ovvero farei come ti ha suggerito tra le righe Z80fan, ovvero la prima ciabatta gia' fatta, e pedalare

E' roba GPL, per cui incompatibile con le mie esigenze.

perche' per come la vedo io, se devo investirci tempo, deve essere na roba che non mi da fastidio viscerale

Ma io mi sto divertendo.

che poi, c'e' pure da vedere se a presentare solo i binari non ti facciano storie sul fatto che vogliono anche il sorgente senno che roba opensource e' ?

provato sulla mia pelle: e al posto degli elogi (per ripagarsi almeno della fatica) arrivano i calci in culo (tipico, tra parentesi dei talebani dell'openqualsiasi, non so quanti ce ne siano anche in AROS, in linux &C sono tutti fissati) , per cui .. 2 motivi per dire anche no, o meglio, pigliatevi la ciabatta, e zitti 

Nel mondo AROS non sono tutti talebani dell'open source, fortunatamente. Icaros, che è la "distro" più diffusa e apprezzata, integra parecchia roba di cui gli autori forniscono soltanto i binari.

[TheKaneB]

• 

su AROS e sul mondo Amiga in generale l'Open Source è arrivato abbastanza tardi, per cui gli utenti e sviluppatori non ne hanno un attaccamento particolare. Nascere lontano dalle università ha i suoi pregi

[TheKaneB]

• 

@dsar
no, secondo me bisogna valutare i costi di progetto, nel senso che ai tempi del bios dei PC che ci portiamo ancora oggi dietro c'erano gia' soluzioni nettamente migliori, se vado a guardare gli stessi tizi di IBM su un S/36 sembrano dimostrare che quando si scuciono assegni con diversi zeri le faccende fanno la differenza tra la cioccolata e la cacca, stesso colore, sono sempre computer 

eh si, ma i sistemi s/360 costavano nell'ordine delle centinaia di migliaia di dollari, mentre il PC era sotto i 5 mila. Non puoi confrontarli, ma mai nella vita

[Z80Fan]

• 

soluzione3, come le motorola EVS, pero' costava una standard forzato delle classi dei devices, motorola di fatto ha imposto la cosa con la linea industriale VME, e tutti si sono adeguati senno calci in culo rotanti, i PC IBM invece … hanno aperto le porte ai cloni e cosi', con la storia che cani e porci potevano metterci mano, ognuno ha fatto quello che voleva, e quindi senza BIOS extension non se ne veniva fuori

Il problema (tecnico) è che l'8086 (8088 in realtà) che aveva il PC IBM poteva indirizzare al massimo 1 MB di memoria, a differenza dei 4 GB del 68000, quindi è difficile se non impossibile riservare degli spazi così grandi di indirizzamento senza poi bloccare l'espansione di RAM (che a un certo punto incontra gli slot dei dispositivi e quindi non può più aumentare).

[Z80Fan]

• 

quello sicuramente nel 8086, poi' pero' con i 32bit … siamo rimasti legati

Ovvio, per colpa della famigerata retrocompatibilità. Hardware a 32 bit è arrivato molto prima del software che ne faceva pieno uso (il 386 è della metà degli '80, ma non è prima di Windows 95 e NT che si è finalmente avuto un vero supporto a 32 bit su hardware consumer e pro-consumer), quindi l'hardware doveva rimanere 100% compatibile con tutto il software precedente.

cioe' tu dimmi, oggi, con addirittura 64 bit, siamo ancora alla bios extension
mica ho voglia io di andare a ravanare OGGI in quelle faccende

Ma infatti le VBE (Vesa Bios Extensions) non le usa nessuno (commercialmente), vanno tutti di driver VGA di default (tutte le GPU partono in modalità VGA-compatibile e si attivano solo quando ricevono i segnali magici dai diver) o di driver del produttore.

Il fatto che le VBE siano state fatte male è ovvio, anche perchè l'ultima versione è del 1998, anno in cui tranquillamente la maggioranza di PC erano a 32 bit (e di sicuro quelli che avrebbero incluso le VBE sarebbero stati più nuovi ancora), quindi non ha senso che avessero incluso un sistema da usare solo in modalità reale*.

* In realtà *c'è* una modalità per usare le VBE in modalità protetta, ma già sono usate talmente poco che i produttori le implementano in modo molto sommario, quindi a meno di non avere proprio un dispositivo fatto bene penso siano praticamente inutili.

sul serio, e' tutto lavoro inutile, una perdita di tempo che non ha senso a cominciare dal design

meglio stare su hw SLOTed, no ?
a meno che sia per lavoro, dove … mi posso pure tappare il naso
ma per hobby decisamente no

Se vuoi stare su PC, questo ti tocca. E comunque, i progetti "per hobby" non stanno a rompersi il cazzo e si impostano un framebuffer lineare durante il bootloader (fatto a mano oppure lo fa fare a GRUB), e poi vanno di puntatore in memoria; alla fine, "per hobby" interessa che appaia qualcosa sullo schermo, se poi non hai l'accelerazione hardware pazienza.
http://wiki.osdev.org/Drawing_In_Protected_Mode