Va de Retro (Satanás) -- Versión 3.3 SSL

Os leo lo que comentáis y parece que habláis como el que va a comprar una barra de pan, como si nada, se cambia la placa, se ajusta aquí y allá y ya esta, a funcionar.
Profano de mi, cuanto me gustaría haber estudiado electrónica.

Ya he grabado la ROM y me he puesto a repasar la implementación.
De momento le he añadido el (d)efecto ULA Snow que no estaba implementado en la versión de 48K (para esto si hay que hacer un puente para conectar la señal /RFSH a la CPLD).

Kyp escribió: ↑12 Dic 2020, 13:13 Ya he grabado la ROM y me he puesto a repasar la implementación.
De momento le he añadido el (d)efecto ULA Snow que no estaba implementado en la versión de 48K (para esto si hay que hacer un puente para conectar la señal /RFSH a la CPLD).

¿Y para que queremos el ULA snow?, yo sinceramente ese tipo de defectos, los quitaria, ya que molestan mas que otra cosa, vale que si quieres una implememtacion "exacta" hay que replicarlo todo como el original, pero es que eso justamente, es un defecto que no se corrigio en su dia y se ha ido arrastrando.

flopping escribió: ↑12 Dic 2020, 13:19

Kyp escribió: ↑12 Dic 2020, 13:13 Ya he grabado la ROM y me he puesto a repasar la implementación.
De momento le he añadido el (d)efecto ULA Snow que no estaba implementado en la versión de 48K (para esto si hay que hacer un puente para conectar la señal /RFSH a la CPLD).

¿Y para que queremos el ULA snow?, yo sinceramente ese tipo de defectos, los quitaria, ya que molestan mas que otra cosa, vale que si quieres una implememtacion "exacta" hay que replicarlo todo como el original, pero es que eso justamente, es un defecto que no se corrigio en su dia y se ha ido arrastrando.

Bueno, aunque lo llamen defecto, realmente en algún juego precisamente se usa como "efecto", por ejemplo en Vectron.

flopping escribió: ↑12 Dic 2020, 13:19

Kyp escribió: ↑12 Dic 2020, 13:13 Ya he grabado la ROM y me he puesto a repasar la implementación.
De momento le he añadido el (d)efecto ULA Snow que no estaba implementado en la versión de 48K (para esto si hay que hacer un puente para conectar la señal /RFSH a la CPLD).

¿Y para que queremos el ULA snow?, yo sinceramente ese tipo de defectos, los quitaria, ya que molestan mas que otra cosa, vale que si quieres una implememtacion "exacta" hay que replicarlo todo como el original, pero es que eso justamente, es un defecto que no se corrigio en su dia y se ha ido arrastrando.

La pega que yo tengo con ese defecto, y por eso lo implementé en JSpeccy y luego lo quité, es que no estoy muy seguro que esté correctamente determinado cuando, cómo y dónde sucede. Sí, si sacas "basurilla" aleatoria das el pego, pero es muy difícil replicar exactamente el efecto y mucho menos comprobar si lo estás haciendo bien. Yo lo pondría, es un defecto "muy Spectrum", pero dado que solo lo aprovecha Vectron y algún test, me da rabia implementar una característica con tantas incertidumbres.

My two cents...

El ULA Snow no tiene nada de aleatorio, está perfectamente definido como pasa. Básicamente es esto:
wire[12:0] a = { va[12:7], !rfsh && ca[15:14] == 2'b01 ? ca[6:0] : va[6:0] };

Que traducido es:

va = video address, la dirección de memoria que quiere leer la ULA.
ca = cpu address, la dirección de memoria que quiere leer la CPU.
a = lo que realmente lee la ULA.

El valor de a depende de si la señal /rfsh está activa (vale 0) y de si los dos bits más altos de la dirección que quiere leer la CPU (ca[15:14]) son 01. Si no se cumple la condición la ULA lee la dirección que quiere leer. Si se cumple la condición la dirección efectiva que lee la ULA es, la mitad inferior (bits [6:0]) son los de la ULA y la mitad superior (bits [12:7] son los de la CPU).

¿Por qué es solo la mitad? Pues porque como el bus de memoria está multiplexado (se asigna en dos tiempos), debido a la temporización con que ocurren las señales internamente, la CPU solo pisa una de las partes.

¿Por qué ocurre? Porque el mecanismo de contienda no tiene en cuenta la señal /rfsh así que cuando la CPU quiere refrescar la memoria compartida con la ULA, esta no bloquea el acceso como hace en el resto de casos y la CPU interfiere con la dirección que intenta asignar la ULA.

Complicado entonces de emular por software, principalmente porque el refresco se produce durante los T3-T4 de M1, y en un emulador no se hace un cálculo tan fino de tiempos, al menos en los emuladores que yo he visto.

Lo que no veo claro es la dirección de la CPU. Si es una lectura sin /RFSH la cosa no admite discusión, es la dirección del opcode que está tratando. Pero si /RFSH está activa la dirección que se ve en el bus debería ser el contenido del conjunto 'IR', ya que es lo que pone en ese caso la CPU. O eso creo, no puedo hacer pruebas exhaustivas al respecto porque no tengo analizadores ni osciloscopios. De hecho, el problema se produce precisamente cuando se pone el registro I entre 0x40 y 0x7F y no en otro caso.

Como no veo el resto del código VHDL no sé si en el T80 se respeta lo de sacar ese contenido al bus en ese momento (y en otros que no debería, dicho sea de paso). A veces, la Z80 deja en el bus contenidos de IR o de otros registros en pasos intermedios para luego volver a usarlos o no, hay un poco de todo. Es más, en algunas instrucciones como DJNZ parece que la señal /RFSH se extiende hasta un T5 de M1 o un T1 de M2, incluso más allá, como INC DE.

No se que decirte, no conozco las interioridades del Z80 tan bien como tú. Además, en la FPGA hay dos buses de datos, el de entrada es independiente del de salida, no está compartido como en un ordenador real.

Falta mucho para finalizar este proyecto.....?

Ya tengo un +2 (sin ULA+ de momento) con DivMMC en fase de pruebas