Newsgroup: it.comp.retrocomputing
Titolo: Nuova versione di Hi65

Ho rilasciato la seconda versione del mio emulatore di C65. E'
scaricabile da 
http://devilmaster.altervista.org/hi65.html
 . Ecco le
novità (riassunto per chi non sa l'inglese: ho sistemato dei bug, ho
aggiunto il supporto agli array a una dimensione, la modalità finestra
e più risoluzioni, e anche delle interfacce alternative a cui si
accede digitando GO64, GO128, GO16, GO20 e GOPET).
 
* Fixed a bug in the expression evaluator, so that goniometric
functions also accept variables (only numeric, of course).
* Fixed a bug in the CHAR function, so that it also accepts variables
(only strings - a limitation of the original instruction on the C65).
* Fixed a bug in the function that reads the instruction end address,
so that it is also read correctly whenever its least significant byte
happens to be zero.
* Added the support for more HD resolutions.
* Added the support for windowed mode. Note that running Hi65 from the
launch tool will modify the configuration file to force it to full
screen anyway, because launching it in windowed mode from the launch
tool would cause it to crash. Instead, configuring it to any mode
(windowed or full screen) with hi65cfg.exe and then running hi65.exe
will run it correctly in whatever mode you select.
* Added a flashing cursor whenever Hi65 is accepting keyboard input.
* Added a wraparound check that returns the text cursor to the top of
the screen whenever the bottom of the screen is reached.
* Implemented 1-dimensional arrays for numbers and strings, with a
maximum number of 256 elements (from 0 to 255). This also includes the
ability to use an element of an array as an index in a FOR cycle,
which was not possible in an actual C65.
* Just for fun, added alternative interfaces to the emulator,
resembling screens of other Commodore computers. To try them, use the
following commands: GO64, GO128, GO16, GO20, GOPET. To return to the
classic interface: GO65. Note that the changes are merely aesthetical,
with no difference in functionality or scope of the emulator.
 
E ora ne approfitto per chiedere la soddisfazione di una mia curiosità
personale: qualcuno che sia dotato di Raspberry Pi, potrebbe
ricompilare l'emulatore per usarlo, appunto, su Raspberry Pi? Sono
curioso di sapere in quanto tempo viene completato il programma
gfxdemo1 su quel computer.

 in quanto tempo viene completato il programma gfxdemo1 su quel computer.
 
Ho provato a scompattare l'archivio (hi65-v2.zip) sotto Linux e mi ha 
creato file con nomi tipo "c65\Hi65CFG\hi65.cfg" senza creare la 
struttura delle directory.

struttura delle directory.
 
A quanto pare, hai trovato un bug di Izarc (che è quello che ho usato
per creare l'archivio).
Adesso l'ho ricreato con 7zip (ma sempre in formato .zip), prova a
riscaricarlo.

Vorrei chiederti una cosa: le gfxdemo devono essere animate o creano 
un'immagine fissa ?
 

un'immagine fissa ?
 
Creano un'immagine fissa. In ognuna, il colore di ogni pixel viene
semplicemente deciso in funzione delle sue coordinate (ognuna usa una
formula diversa). Anche se, in effetti, mi ha sfiorato l'idea di
crearne una versione animata modificando la formula in tempo reale.
Ovviamente, avrebbe senso eseguirla solo sull'emulatore, perchč il
vero C65 impiega 20 minuti per tracciare una sola di quelle immagini.


 
 
 
Caspita. Sul Core 2 Duo (tra l'altro con un'installazione strasminchiata 
di seven) che ho usato per il test, l'esecuzione č stata talmente 
istantanea che ho creduto si fosse piantato qualcosa ecco perchč ti ho 
chiesto dell'esistenza dell'animazione.
 
 

 pigi@Sardegna:~/dload/tmp$
 
--------
 
In ogni caso il makefile per linux e' a tua (e di tutti) disposizione.
 
a mio avviso, sull' ultima FAQ, e l' inclusione di GOXXX, io sarei per 
inserire nella TODO la compatibilità cogli altri basic CBM (cosa gradita 
per chi usa il basic nel suo contesto proprio, roba quick'n dirty di 
poche righe...)
 
in termini migliori, ci hai tra le mani le basi per un eccellente, se 
non perfetto interprete CBM basic per Linux e winsozz.
 
Saluti,
dott. Piergiorgio.
 
 


Sarei interessato al makefile... inutile reinventare la ruota :)
Lo si potrebbe inserire da qualche parte per scaricarlo?
Grazie!


se Devil Master me lo richiede glielo invio e vede se incorporarlo nella 
prossima release..
 
Saluti,
dott. Piergiorgio.
 
 

prossima release..
 
Okay, inviamelo. Il mio indirizzo email lo trovi nel readme.
Ma non funziona lanciando make con i parametri indicati nel readme?


Anche.
 
Però visto che si tratta di alpha-testing, avere solo quattro tasti da 
premere + return aiuta ;)
 
Saluti,
dott. Piergiorgio.
 

non perfetto interprete CBM basic per Linux e winsozz.
 
Grazie. Non è ancora perfetto, ma spero di farlo avvicinare ancora di
più alla perfezione.

 più alla perfezione.
 
come detto sopra, una volta completo, sarà ben più utile di quanto 
immaginasti. calma e una cosa alla volta e avrai dato un signor 
contribuito al retrocomputing, e non solo.
 
Saluti, e in bocca al Lupo !
dott. Piergiorgio.
 

 scaricabile da 
http://devilmaster.altervista.org/hi65.html
 .
 
L'ho compilata su Linux, e ha un problema che anche la prima versione aveva:
1) lanciare hi65
2) dentro hi65, scrivere DLOAD"GFXDEMO1.PRG"
3) dentro hi65, scrivere RUN
4) quando la demo ha finito di disegnare lo schermo, premere un tasto
 
Torna la schermata iniziale col READY... solo che non reagisce ad alcun 
tasto, né ESC né qualsiasi altro. Lo stesso con SSAMPLE.PRG. Non succede 
se il .prg viene dato direttamente sulla linea di comando che lancia 
hi65 (cioè, lanciando l'emulatore scrivendo "hi65.exe ssample.prg").

hi65 (cioè, lanciando l'emulatore scrivendo "hi65.exe ssample.prg").
 
Allora è un problema di Allegro che si presenta in modo più estensivo
su Linux che su Windows, e che avevo già incontrato pensando
(sbagliando, a quanto pare) che su tutti i sistemi operativi avesse
gli stessi sintomi. Specificatamente, dipende da questa parte nella
funzione ScreenClose():
 
if (!program_loaded_from_emulator)
  release_screen();
 
che abbassa la priorità a cui viene gestito lo schermo (rallentando la
gestione della grafica e aumentando la priorità degli input da
tastiera) ogni volta che l'emulatore esegue un'istruzione SCREEN
CLOSE, ma solo se il file .prg non è stato caricato dall'interno
dell'emulatore. E' per questo che non succede se lo carichi
direttamente da linea di comando.
L'avevo inserita perchè su Windows, senza inserirla, succedeva la
stessa cosa ogni volta che Hi65 veniva lanciato tramite il Launch
Tool.
 
Vedo adesso che Allegro permette di distinguere quale sistema
operativo è in uso sul computer. Adesso aggiungo quella che penso sia
la soluzione, ma su Windows non noterò differenze. Tu che hai Linux,
dimmi se funziona modificando in questo modo il codice menzionato
sopra:
 
if (!program_loaded_from_emulator || os_type==OSTYPE_LINUX)
  release_screen();


Purtroppo no. Il problema permane. La funzione release_screen() viene 
eseguita, ho verificato con il debugger gdb

eseguita, ho verificato con il debugger gdb
 
Azz.
E se invece vai alla funzione keyboard, dentro a key.cpp e modifichi
la parte finale da cosě
 
acquire_screen();
 if (!mode)
  return 0;
 else
  return((uchar)k);
 
a cosě?
 
if (os_type!=OSTYPE_LINUX)
 acquire_screen();
 if (!mode)
  return 0;
 else
  return((uchar)k);


Cosě la tastiera non funziona proprio, fin dall'inizio...

>Così la tastiera non funziona proprio, fin dall'inizio...
 
Okay, appurato che il problema non sta lì, annulla quella modifica e
fai un'altra prova. Senza caricare alcun programma, apri Hi65 e dai il
comando:
 
GO65
 
Quel comando richiama la funzione startscreen, che ridisegna la
schermata iniziale e acquisisce lo schermo. Se il problema sta
effettivamente lì, dopo aver dato quel comando, la tastiera smetterà
di rispondere. In quel caso, dimmi se succede ancora andando nella
funzione startscreen (in display.cpp) e modificando la linea:
 
acquire_screen();
 
facendola diventare:
 
if (os_type!=OSTYPE_LINUX)
 acquire_screen();


In questo modo succede una cosa strana: dopo il READY, viene accettato 
un carattere da tastiera, al massimo due, ma solo se vengono battuti 
velocemente immediatamente dopo che il READY è apparso. Poi la tastiera 
smette di rispondere.

smette di rispondere.
 
Questo sembra consistente con quello che fanno le funzioni di gestione
della tastiera: rilasciano lo schermo, controllano se c'è stato un
input e lo riacquisiscono. Da ciò che scrivi, i caratteri vengono
accettati quando lo schermo non è ancora stato acquisito, poi viene
acquisito, ma (non so ancora come mai) non più rilasciato, e il
programma smette di accettare input. Sarei tentato di proporre un
rimedio raffazzonato (modificare il programma in modo che su Linux non
acquisisca mai lo schermo), ma così continuerei a non sapere
esattamente cosa causa il problema, quindi non lo farò.
 
Dopo aver annullato quella modifica (cioè aver tolto la condizione che
ti ho fatto aggiungere) fai un altro test diagnostico. Mi hai detto
che il problema non si presenta se specifici da linea di comando il
programma da caricare, quindi prova a lanciare un programma da linea
di comando anziché dall'emulatore in funzione, e dopo che sarà stato
eseguito (mi confermi che in quel caso la tastiera funziona ancora?),
dai il comando GO64 (sì, ho scritto 64, non 65). Se in quel momento lo
schermo è acquisito, i caratteri della schermata pseudo-C64
appariranno in maniera praticamente istantanea, e se invece non lo è,
appariranno con un ritardo visibile tra uno e l'altro (effetto
"vecchia telescrivente"). Dimmi quale dei due casi si verifica (su
Windows compaiono istantaneamente), poi dai GO65 e dimmi se in quel
caso il programma smette di rispondere.

Windows compaiono istantaneamente)
 
P.S.
Scusa, ho sbagliato. NON E' VERO. Su Windows, se lancio Hi65
facendogli eseguire un gfxdemo da linea di comando, poi dò GO64, le
scritte compaiono lentamente. E' solo se a questo punto dò GO65, che
le scritte compaiono istantaneamente.