FreeLists / zxspectrum / [zxspectrum] Re: emulazione Spectrum

[Alfonso Martone <a.martone@xxxxxxxxxxx>]

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).