[zxspectrum] Re: Ula+

  • From: Alessandro Dorigatti <adorigatti@xxxxxxxxx>
  • To: zxspectrum@xxxxxxxxxxxxx
  • Date: Mon, 28 Mar 2011 23:07:45 +0200

> Non ho mai studiato "ulatest3" (potrei anche farlo, se mi dite che vi 
> interessa), ma ti posso dire come funziona il mio "floatspy" sotto 
> questo aspetto: per stabilizzare il riferimento temporale di cui dicevo 
> sopra, la routine effettua preliminarmente una serie di accessi in 
> memoria contesa. La contesa della ULA, infatti, risulta utilissima in 
> questo caso proprio perché allinea l'esecuzione di determinate 
> istruzioni a ben precisi boundaries multipli di 8 T-states. Effettuando 
> ripetutamente una serie di questi accessi congegnati in modo opportuno 
> si ottiene l'effetto di "incastrare" forzatamente l'esecuzione di una 
> certa istruzione ad un ben preciso T-state ogni volta.
> 
> Luca
> 

Ciao Luca, e grazie per la risposta. Per ciò che posso dire io, credo
che la tua esperienza sia fondamentale per riuscire a capirci qualcosa.

Riassumo brevemente la situazione con il mio core FPGA: premesso che sto
cercando di implementare il comportamento dell'ULA reale, in pratica ciò
che faccio (e non sarebbe raccomandato nel caso di design da
sintetizzare) è di generare un segnale di clock che DOVREBBE essere in
tutto e per tutto uguale a quello generato dall'ULA reale; questo
segnale poi viene passato al core T80 che emula lo Z80.

Ora, la situazione è chiaramente complessa e nel mio caso non
verificabile andando a visualizzare i segnali generati dall'FPGA; è
anche per me molto complesso effettuare una simulazione con il tool
messi a disposizione dalla Altera fondamentalmente per mia inettitudine.

Aggiungiamo a tutto questo che il core T80 non è nella sua versione
originale fedele al timing dei segnali dello Z80; ho effettuato alcuni
interventi che a mio parere fissano la situazione ma sto attendendo
feedback da uno degli autori del core stesso.

Detto questo mi piacerebbe riuscire a diagnosticare il problema, magari
per gradi, magari utilizzando qualche programma "minimale" che evidenzi
chiaramente un problema preciso che a quel punto si potrebbe fissare.

Questa sera ho testato FloatSpy dopo alcune modifiche effettuate al CPU
clock generator e mi sta dando risultati corretti (effettuando il self
test, questo viene completato con successo).

Rimane tuttavia il fatto che altri software non si comportano in modo
corretto.

Riepilogo un paio di esempi:

Aquaplane: linea di orizzonte propagata sul bordo ad altezza corretta,
ma con flickering a 50Hz sull'estremo sinistro (di ampiezza credo
24pixel); ho notato tra l'altro che il flickering avviene quando viene
emesso un suono (probabilmente questo è un particolare significativo).

BTime: anche qui la linea generata sul bordo (di 24pixel) flickera per
alcuni T-State; nel mio caso particolare i T-State STABILI sono: 14335,
14339, 14343, 14347, 14351, ... e così via a intervalli di 4 T-States.
Anche in questo caso c'è un comportamento interessante che riporto nel
caso in cui possa essere significativo: nel caso di T-States
"INSTABILI", premendo alcune volte un tasto si arriva a una situazione
di stabilità, che tuttavia ricade in nuova instabilità nel caso in cui
si prema nuovamente qualche tasto!

BTime è reperibile (come detto in precedenza) alla URL
http://wizard.ae.krakow.pl/~jb/qaop/tests.html (dove tra l'altro è
presente anche l'ulatest3 di cui si è parlato in precedenza).

Ogni tuo feedback/suggerimento è il benvenuto!

A presto,
Alessandro


Other related posts: