[zxspectrum] Re: emulazione Spectrum
- From: Alfonso Martone <a.martone@xxxxxxxxxxx>
- To: zxspectrum@xxxxxxxxxxxxx
- Date: Thu, 5 Aug 2004 16:50:37 +0200
Il P900, il cellulare sul quale vorrei far funzionare l'emulatore
Spectrum non e' proprio un giocattolino: processore ARM9 a 32 bit
clockato a 156MHz, display 320x208 a 65536 colori, touchscreen,
possibilita' di scrivere programmi per usare il processore in modo
nativo (dunque C, C++, perfino assembler ARM/Thumb per chi lo conosce).
Il guaio di questo P900 e' quel maledetto sistema operativo Symbian.
In primo luogo, l'input/output lo puoi fare solo seguendo le convenzioni
Symbian (tutta una caciara di active-objects, richieste asincrone,
eventi, priorita', etc). Pensa che un banale "Hello World" costa
qualche decina di righe tra sorgente C++, file i risorse, file di
progetto etc. Il sorgente helloworld.cpp contiene non meno di quattro
classi. Un programa che ti scriva a video l'ultimo tasto che hai
premuto, mentre in C/C++ su DOS/Linux si scrive in una sola riga, qui
richiede parecchie decine di righe di codice. Inutile aggiungere che le
cose tipiche del DOS (sincronizzazioni precise, interrupts gestiti da
te, etc) te le puoi ampiamente scordare...
Il problema dell'output a video si risolve usando una funzione Symbian
(ovviamente non documentata) che restituisce un puntatore alla memoria
video; finche' altri task Symbian non scrivono a video (ossia finche'
non si scarica la batteria o arriva un messaggio o telefonata) si puo'
andare avanti allegramente (e a velocita' supersonica: per colorare un
pixel basta scrivere una word da qualche parte).
Il problema dell'I/O credo di risolverlo con un trucchetto: col thread
principale dedicato ad obbedire alle paranoiche convenzioni Symbian, ed
un secondo thread su cui gira l'emulatore, piu' un blocco di memoria
condivisa per far pescare a quest'ultimo la pressione dei tasti e del
touchscreen.
I guai non sono finiti: le applicazioni Symbian non possono avere
variabili globali (solo dati read-only, ossia "const static"), quindi
anche qui bisogna fare un po' di acrobazie propagando puntatori e cose
simili, tenendo conto di un'altra aberrante limitazione, ossia le
classi istanziate non devono contenere piu' di qualche migliaio di byte
di dati altrimenti "out of memory" (per fortuna con la malloc() si
possono allocare blocchi di centinaia di kbytes... in teoria dovrebbero
esserci almeno 5500-6000 kbyte liberi alla partenza; sul nuovo modello,
il P910, hanno messo piu' RAM e quindi la memoria libera sale a circa
20-21Mb).
Insomma, nonostante tutti questi guai l'emulatore si puo' "portare", a
velocita' ragionevole (perche' in C++ si va a velocita' ragionevole...
col Java, invece, si va piu' lenti perche' si da' comunque un file
binario in pasto ad una specie di interprete; poi non puo' scrivere
direttamente sulla memoria video, etc). Col VisualBasic e' anche peggio
(e l'AppForge, l'engine che fa "il visualbasic per i cellulari", e'
comunque scritto in C++...).
Questo e' proprio il genere di considerazioni da cui cominciare ogni
volta che si vuole "portare" un emulatore Spectrum.
> Domandina: saresti in grado di modificare FBZX o un'altro emulatore
> (preferirei poter usare windows) per simulare le logiche di banking
> della memoria del Chrome ? E' in pratica un'estensione delle logiche
> di paging dei +2/+3, compresa la possibilità di spostare la VRAM in
> fondo. Mi servirebbe per fare un paio di esperimenti.
Dato che ci sono poche differenze tra il +3 ed il Chrome, questo
dovrebbe essere semplicissimo per quasi qualsiasi emulatore, non solo
per fbzx. Io mi sto concentrando su fbzx per comodita' (non e' enorme,
non e' stravecchio, ha solo le feature piu' essenziali, non mi sembra
troppo difficile strappargli via la libreria SDL per metterci la mia
libreria video, etc).
Other related posts:
