Newsgroup: it.comp.software.emulatori
Titolo: Dimensione degli ADF...

La domanda sembra stupida, ma in realta' non lo e' (o forse si?):
quanto max puo' essere grande un ADF?
Ho sempre pensato che la dimensione fosse 880KB, dato che e'
l'immagine di un disco Amiga. invece, navigando qua' e la', sono
stato attratto dal sito della Factor5 (chi e' Katiana? ..ops, la Factor5??
:))
e ho scaricato BcKid, rilasciato +o- freeware e, sorpresa, era un unico
ADF (non standard) da 2 MB?!?!?
Allora, chi me la spiega sta' faccenda??
P.S.: Si blocca con il WinUae!
Bow-wow
Killer
--
Killer, EX webmaster di 
http://go.to/KingdomAmiga
 (probabilmente in
chiusura)
sito dedicato al miglior computer di sempre
ICQ: 73998132
"Bisogna essere cretini per prendere una tigre per i coglioni...
ma bisogna essere eroi per continuare a stringere..."

ADF (non standard) da 2 MB?!?!?
Se non ricordo male per i giochi a più dischi puoi unire gli ADF con un
semplice copy/b disco1.adf+disco2.adf gioco.adf... poi per scambiarli su
WinUAE ci dovrebbe essere un modo che non ho presente al momento...
Oppure potrebbero essere ADF a più di 80 tracce o codificati in maniere strane
per matenere la protezione dalle copie... boh?
--
Primo Giovedini Tribute Page
http://digilander.iol.it/primogiovedini/

 per matenere la protezione dalle copie... boh?
Piu' probabile.
Comunque: boh?!
Bow-wow
Killer
--
Killer, EX webmaster di 
http://go.to/KingdomAmiga
 (ormai quasi sicuramente
chiuso)


.

 Oppure e` un'immagine di un Hard Disk.
infatti, credo anch'io.
Saluti,
Fabio Alemagna

 infatti, credo anch'io.
Con estensione ADF? Molto strano...
Comunque, il mistero continua
Bow-wow
Killer


Nulla ti vieta di provare se funziona, l'estensione, in fondo, non vuol
dire niente :)
Del resto anche gli ADF normali possono essere visti come hardfiles.
Ciao,
Fabio Alemagna

Con estensione ADF? Molto strano...
Perche`? Avranno sbagliato una lettera, ma WinUAE dovrebbe montarlo anche
cosi` (non so Fellow).
Ma almeno ci hai provato? :)


 Ma almeno ci hai provato? :)
Si, ma  non vanno! :((
Mi dice "Not a DOS Device in unit DH0:".
Quindi ormai sono quasi sicuro che si tratti si un modo per mantenere la
protezione
anche degli ADF.
Bow-wow
Killer
--
Killer, ICQ: 73998132


 protezione anche degli ADF.
Ma gli emulatori riescono a leggerlo come .adf?
Se ci riescono mi pare una protezione inutile :-)
Certo, non e' possibile riscrivere l'immagine su un floppy reale,
ma il problema riguarda gli utenti di un vero Amiga, e fino a un certo
punto, dato che basta che qualcuno scriva un loader per quell'immagine
e carichi allegramente il gioco da HD :-)
 
-- 
Saluti                                     James \Diskdoctor\ Ossi
      ___
     ////  A M I G A : the REAL pathfinder
___ //// RetroPlay  
http://www.retroplay.com
\\\X///             ICQ 13963485
 \XXX/           *Powered by Linux*

 e carichi allegramente il gioco da HD :-)
Ma a che serve un adf protetto? In ogni caso UAE non sapebbe come
gestirlo...
Che opzioni ha usato per farlo vedere come un hardfile?
La dimesione esatta qual'č? Potrebbero essere piů immagini concatenate
insieme, prova a splittarle.
Ciao,
Fabio Alemagna
PS x MASSI:
Se stai leggendo questo post non pensare a male :) Non ho dimenticato di
inviarti la patch, solo che notavo che con UAE-0.8.12 non funziona, e
non riesco a capire per quale motivo, cosě devo "estrarla" dal sorgente
ultramodificato della versione 0.8.11 :)
Un po' di pazienza :)

 ultramodificato della versione 0.8.11 :)
Se questa patch funge bene perche' non la invii all' UAE Team?


Se ci riescono mi pare una protezione inutile :-)
Non ha senso.
Finche` si arriva alle extra tracks ok, ma se ci sono dati tipo quelli di
un nibbler, e` assolutamente fuori standard e dubito che possa servire a
qualcosa.
Sarebbe come fare un .d64 con le half tracks e i dati di sincronismo. Tanto
vale fare un .G64.
Per Amiga, pero`, in effetti manca qualcosa paragonabile ad un .g64, e
personalmente ne sento la mancanza (ma qui ci scontriamo con le numerose
protezioni dei floppy Amiga, che non erano proprio facili da superare
-anche se non impossibili-).


Un po' di pazienza :)
Quando vuoi, basta che lo fai entro meta` agosto che poi mi scade
l'abbonamento e se non lo rinnovassi quella casella non sara` + valida :)
-- 
 $B%^%C%7!!%+%G%s%F%# (J - Mettete "
iol.it
" dopo la chiocciola.


Se questa patch funge bene perche' non la invii all' UAE Team?
In effetti e` una buona idea. Che ne dici Fabio?
-- 
マッシ　カデンティ - Mettete "
iol.it
" dopo la chiocciola.


 In effetti e` una buona idea. Che ne dici Fabio?
Dico che in effetti la mia patch è 'na strunzata. Non fa niente di
eccezionalmente geniale, solo che va a risolvere, almeno in parte, un
problema così semplice, ma così semplice che non riesco a a capire come
non ci abbiano pensato già loro. 
Comunque ci farò un pensierino...
Saluti,
Fabio Alemagna

 non ci abbiano pensato già loro.
Come ogni uovo di Colombo, e' tale per tutti *dopo* che qualcuno ha spiegato
il perche' e il percome.. 


non ci abbiano pensato giŕ loro. 
Dirci che problema e' ti fa schifo? :p

 Dirci che problema e' ti fa schifo? :p
No, solo che non ero sicuro fosse IT.
Premetto che UAE è scritto una chiavica e che ha prolemi di
progettazione ben più gravi di questo.
Innanzitutto bisogna esporre, per chi non lo conoscesse, il concetto di
"color clock".
Un color clock è l'unità di tempo che impiega il raster a disegnare 2
pixel in bassa risoluzione.
Tutto il chipset dell'amiga è basato su questo color clock. Il color
clock ha una frequenza di circa 3.5Mhz, che è la metà della frequenza
del segnale PAL che è pure la frequenza del 68000 sugli
Amiga500/500+/600/1000/2000.
Per ogni raster line vi sono circa 227 color clocks.
Detto questo, vi basti sapere che tutta l'emulazione di UAE si basa su
questo fatto. Avete presente l'indicatore scorrevole nella GUI di WinUAE
che permette di scegliere la velocità del processore rispetto a quella
del chipset? Bene, in realtà quell'indicatore serve a scegliere quanti
color clocks devono essere emulati per ogni istruzione del processore
che viene emulata.
Il ciclo principale di UAE è qualcosa del genere
for (sempre) {
	emul_68k_instruction();
	emul_chipset(n);
}
dove "n" è il numero di color clocks da emulare.
quando si sceglie l'opzione "velocità di un A500", o qualcosa di simile,
la "n" viene sostituita di volta in volta con *la metà* dei cicli di
clock del processore 68000 che sono stati necessari per eseguire un
istruzione:
for (sempre) {
	n = emul_68k_instruction();
	emul_chipset(n);
}
emul_68k_instruction() restitisce, ovviamente, il numero di cicli già
dimezzato.
Ora potrebbe capitare che su un computer sufficientemente veloce si
riesca a completare un quadro video in meno tempo del necessario, che è
20msec (20 millesimi di secondo, ovvero 50 frame al secondo).
Se questo dovesse succedere si avrebbe un'emulazione del chipset
(grafica e sonoro) poco accurata, in quanto più veloce del dovuto, e si
avrebbe un inutile spreco di tempo macchina.
La soluzione starebbe nel far funzionare solamente l'emulazione del
processore nel frattempo che finiscano i 20msec, in modo da normalizzare
la velocità del chipset e favorire l'emulazione del processore.
La soluzione adottata da UAE, infatti, è questa:
for (sempre) {
	emul_68k_instruction();
	emul_chipset(n);
	while (is_last_line && curr_time < 20msec) {
		emul_68k_instruction();
	}		
}
Potrebbe sembrare un'ottima soluzione... Niente di più sbagliato,
invece.
Mentre ci si trova nel ciclo while l'emulazione del chipset è, come si
può vedere, *bloccata*. Il che vuol dire che anche i cia sono bloccati,
e i cia forniscono i timers, timers che servono all'implementazione del
multitasking! Quindi in tutto il tempo che viene eseguito il ciclo while
*il multitasking è bloccato*.
Questo vuol dire, nella migliore delle ipotesi, che di quel ciclo while
se ne avvantaggia solo un task alla volta. Addirittura se si sta usando
l'emulatore per giocare il gioco potrebbe non avvantaggiarsi per nulla
della potenza in più, in quanto potrebbe stare aspettando che finisca il
vertical blanking, cosa che non avverrà fino a quando non si esce dal
ciclo.
Dunque questa soluzione è pessima.
La soluzione che ho adottato io è, invece, la seguente.
for (sempre) {
	for (x volte) emul_68k_instruction();
	emul_chipset(y);
	while (is_last_line && curr_time < 20msec) {
		emul_68k_instruction();
	}		
}
Quello che ho fatto è stato semplicemente far eseguire anzichè *1*
istruzione del 68k per *n* color clocks, *x* istruzioni del 68k per *y*
color clocks.
La mia, quindi, è un'implementazione più generale rispetto a quella di
UAE.
In questo modo pur venendo eseguite più istruzioni per quadro video non
viene bloccato il multitasking: la differenza è visible ad occhio nudo
su macchine di adeguata potenza.
Semplicemente, prima, la potenza in più del processore veniva buttata al
vento. Ora, invece, anche se non in maniera ottimale, questa potenza
viene sfruttata in qualche modo.
Vi starete chiedendo perchè, allora, ho lasciato il ciclo while. Il
motivo è che questo ciclo viene utilizzato per "ammortizzare" il tempo
rimanente alla fine del quadro video, in modo da mantenere la
temporizzazione dei 20msec.
Infatti ogni istruzione, anche se emulata, ha in generale un tempo di
esecuzione differente rispetto ad un'alra; non è quindi possibile
precalcolare il tempo necessario a portare a termine un quadro video
dati i numeri X e Y.
Per sapere se, una volta applicata la patch, la potenza in più viene
sfruttata, basta vedere se il quadro video viene generato *esattamente*
in 20msec: di meno non può essere, proprio a causa del motivo esposto
prima, potrebbe essere più di 20msec, invece, se il rapporto X/Y è
troppo elevato, ovvero si eseguono troppe istruzioni per quadro video
per quante ne può "sopportare" la potenza del processore ospite.
In questo caso è bene ridurre il rapporto X/Y, in quanto la potenza in
più è solo un'illusione.
In realtà ha importanza non solo il rapporto X/Y, ma anche la grandezza
assoluta dei termini X e Y: più piccoli sono, più l'emulazione è
realistica ma anche più "sprecona" in termini di tempo macchina dovuti
all'esecuzione di troppe chiamate emul_chipset(y). Più grandi sono,
invece, è più l'emulazione è irreale, "blocchetosa", ma è anche più
efficiente.
Il rapport X/Y va, in definitiva, calibrato a seconda della velocità
della propria macchina
Su un PII@350 questa patch permette ad UAE di andare ad una velocità
pressochè doppia rispetto a prima.
Spero di non aver dimenticato nulla e di essere stato chiaro.
Ciao,
Fabio Alemagna

 vale fare un .G64.
mi spieghi la differenza tra i due?
--
------------------------------------------------
                 Andrea "Velvet" Petrucci
------------------------------------------------
E-Mail: 
pu...@novacomp.it
    ICQ: 15954376
------------------------------------------------
     "...perchè la vita è un brivido che vola via
         è tutto un equilibrio sopra la follia..."
------------------------------------------------

mi spieghi la differenza tra i due?
Gia` se n'e` parlato a suo tempo con Andrea Musuruane (colui che mi fece
scoprire l'esistenza dei .g64 :P), comunque detto molto in parole povere un
.g64 e` molto piu` a basso livello di un .d64 (permette di gestire in
maniera accurata l'editing degli errori, le half tracks, le extra tracks,
l'id e i dati di sincronismo).
L'immagine di Silent Service che avevo creato col "metodo Massi" [1] e che
postai tempo fa su IBE (e che in seguito lo stesso Andrea ha uploadato su
Arnold e che potete prelevare da li`) era un .g64, e se lo converti in .d64
non funziona. Ma quasi tutti i titoli che siano protetti in qualche modo un
tantino incazzuso non sono utilizzabili in .d64.
Per restare in termini semplicistici, se usi un nibbler copi un .g64, se
usi un copiatore normale usi un .d64. Il fatto che su Amiga manchi un
formato simile fa si` che per alcuni titoli come la mia versione di Out Run
(per esempio) non possa essere creata un'immagine funzionante.
E` pur vero che girano le versioni gia` sprotette in .adf (o in .d64) ma
per chi come me e` fanatico della "pulizia" (e poi cavolo, e` la mia
versione... almeno io voglio usare quella) non ci sta.
[1] In pratica, un freeze della memoria di un copiatore nibbler prima della
scrittura su disco. In effetti e` stato ricreato sul drive virtuale sotto
emulatore, visto che al momento NON ESISTE un sistema diretto di creazione
dei .g64 attraverso il solo cavo COM1541 e drive 1541 (o simile).


 vale fare un .G64.
mi spieghi la differenza tra i due?
--


 pressochè doppia rispetto a prima.
lo voglio! lo voglio!


 estraneo, giusto?
No, aumentano proprio la velocità dell'emulazione. l'UAE standard butta
a vento gran parte della potenza del processore. Con la mia pathc invece
no. 
L'ho  detto che con la mia patch UAE gira il doppio più veloce
Inoltre i programmi non si ritrovano con nessun timing estraneo.
Saluti,
Fabio Alemagna

progettazione ben più gravi di questo.
[...]
Non ho ben afferrato tutte le parti del tuo discorso, però a quanto ho capito
le modifiche che proponi aumenterebbero la velocità dell'amiga emulato, ma non
la velocità di emulazione, una cosa buona se si usano utility ma che
manderebbe in panne i giochi o i demo, che si ritroverebbero con un timing
estraneo, giusto?
--


 
No, aumenta la potenza di calcolo della macchina, ma rimane il 
sincronismo con i 50 Hz, quindi in teoria dovrebbe andare.
-- 
Night Ranger
----------------------------------------------------
srq...@yvoreb.vg
     Applica ROT13 per rispondere
ICQ# 63076483         
http://nightranger.crontab.org
----------------------------------------------------

 lo voglio! lo voglio!
Quasi finita, aspetta un po'... :)
Ciao,
Fabio Alemagna

Inoltre i programmi non si ritrovano con nessun timing estraneo.
Beh scusa allora una demo di quelle A500 only, se fai eseguire al processore
"virtuale" il doppio o il triplo delle istruzioni che eseguirebbe sulla
macchina vera, non dà problemi?


 Gia` se n'e` parlato a suo tempo con Andrea Musuruane (colui che mi fece
grazie della spiegazione


Spero di non aver dimenticato nulla e di essere stato chiaro.
No, anzi, ce ne fossero di piu' di discorsi del genere!
Chiarissimo.

No, solo che non ero sicuro fosse IT.
Se queste cose fossero OT, allora hanno ragione a dire che siamo proprio
alla frutta :/
Anzi, al contrario. Per quanto mi riguarda fa sempre piacere leggere un
messaggio *tecnico*: anche se non l'ho capito tutto, fa sempre imparare
qualcosa. E a mio parere e` perfettamente In-Topic.
Anzi, se qualcuno che vuole e che puo` ha voglia di usarla per compilare
WinUAE (purtroppo io non ho il Visual C++) e ha voglia di distribuire il
tutto su IBE, ammesso che sia autorizzato e la licenza lo consenta, non
aspetto altro.
-- 
マッシ　カデンティ - Mettete "
iol.it
" dopo la chiocciola.
Fino al 21 giugno si vota per creare il gruppo it.fan.japan.pokemon.
Se non l'hai gia` fatto, clicca qui, rispondi al gruppo mettendo la tua e-mail reale


grazie della spiegazione
Figurati.


No, solo che non ero sicuro fosse IT.
Non so se fosse IT o OT, ma sicuramente era molto interessante.
Grazie,
Lorenzo