External ROMs +3 (ROMsde un +2A en un +2 gris) ¡Funcionando!

Si por algo se caracteriza el Spectrum es por su gran variedad de periféricos (clásicos y modernos)

Moderador: Sir Cilve Sinclair

Avatar de Usuario
wilco2009
Freddy Hardest
Mensajes: 543
Registrado: Lun Sep 17, 2012 9:40 am
Ubicación: Valencia

External ROMs +3 (ROMsde un +2A en un +2 gris) ¡Funcionando!

Mensaje por wilco2009 » Mar Ago 09, 2016 1:54 pm

Llevo un tiempo en un proyecto para hacer funcionar las ROMs de un +2A/+3e en un +2 gris mediante un interface externo que maneja las llamadas a los puertos $1FFD y $7FFD.

Las utilidades de esto pueden ser varias, pero la mejor que se me ocurre es que de esa manera puedes utilizar un interface de disquetera compatible con un +2A o también un interface IDE compatible con el proyecto +3e.

El hecho es que un +2A es poco más que un +2 gris con 4 páginas de ROM en lugar de 2, por lo que no esperaba grandes problemas en este tema.
A saber, y a grandes rasgos, las diferencias principales entre los dos sistemas son las siguientes, aunque no parece que ninguna de ellas pueda representar un problema para mi objetivo.

- El +2 gris tiene bus flotante como el 48K, a diferencia del +2A.
- Las páginas de memoria contenidas en el +2 gris son las impares (1,3,5 y 7). En el +2 negro son las páginas 4,5,6 y 7 (contando en ambos casos a partir de 0)
- En el +2 negro, la ULA tiene acoplo directo con la CPU en el bus de datos. De ahí que ninguna interfaz de teclado, o interfaz de joystick que mapee posiciones de joystick a pulsaciones de tecla, funcione en el +2 negro.
- En el +2 negro desaparece la función del puerto FFh (indocumentado, pero usado en algunos juegos para detectar cuándo la ULA está pintando la pantalla).
- En el +2A el puerto de expansión tiene algunos pines cambiados, como por ejemplo desaparece ROMCS y aparecen ROM1OE y ROM2OE.

El cambio en el bus ya lo he tenido en cuenta, por lo que no es un problema y el resto de diferencias parecen irrelevantes.
El hecho es que mi interface funciona a la perfección como ROM externa de un +2A, pero cuando lo pincho en un +2 gris me arranca en modo 48K.

Con un analizador lógico, he hecho una traza de la ejecución de las escrituras a los puertos $1FFD y $7FFD para ver en qué momento cambia a la página 3 y se queda definitivamente allí, y el resultado es que hace 24 escrituras a dichos puertos idénticas en ambos ordenadores y luego el +2A continúa haciendo escrituras y el +2 gris se queda en la página 3 (Basic) por lo que ya no vuelve a hacer ninguna escritura más.

¿Alguien conoce la forma de poder trazar esas escrituras de puertos en un emulador para ver si así puedo averiguar dónde está el problema?

Y ya que estamos, si a alguien se le ocurre dónde puede estar el problema y me puede echar un cable, se lo agradecería.

Esta es la secuencia en un +2A (los tiempos están contados a partir de la primera escritura de puerto que se produce)
Time[s] PÁGINA
0 1
0,109147917 1
0,217023917 1
0,325888167 1
0,434311083 1
0,531340167 1
0,628369167 1
0.725398250000000 1
0.822429250000000 1
0.822641250000000 1
0.822853250000000 1
0.823065333333333 1
0.823277333333333 1
0.823506000000000 1
0.823735000000000 1
0.823965083333333 1
0.824886500000000 2
0.824886583333333 3
0.824914416666667 3
0.825973166666667 3
0.825991416666667 1
0.826669583333333 3
0.826685083333333 3
0.834488750000000 3
0.834506750000000 3
0.854481666666667 3
0.854499666666667 3
0.874475083333333 3
0.874493166666667 3
0.879126833333333 3
0.879142333333333 1
0.879318000000000 3
0.879333500000000 3
0.879996083333333 2
0.879996166666667 3
0.880025916666667 1
0.880164916666667 1
0.880165000000000 0
0.880165083333333 1
0.880182166666667 3
0.880692750000000 3
0.880728000000000 1
0.880870416666667 1
0.880885916666667 3
0.881399916666667 3
0.881435166666667 1
0.881577583333333 3
0.881593083333333 3
Y esta otra la de un +2 gris
Time[s] PÁGINA
0.000000000000000 1
0.121065666666667 1
0.121065666666667 1
0.218094750000000 1
0.339160166666667 1
0.436189166666667 1
0.557256000000000 1
0.654285000000000 1
0.775641666666667 1
0.872672666666667 1
0.872885000000000 1
0.873102916666667 1
0.873315000000000 1
0.873530083333333 1
0.873745500000000 1
0.873961250000000 1
0.874429250000000 2
0.875232250000000 3
0.875247750000000 3
0.876281166666667 3
0.876296666666667 1
0.876883666666667 3
0.876899166666667 3
Última edición por wilco2009 el Vie Ago 26, 2016 12:30 am, editado 1 vez en total.

Avatar de Usuario
chernandezba
Sabreman
Mensajes: 408
Registrado: Mié Oct 17, 2007 5:26 pm

Re: Hacer funcionar las ROMs de un +2A en un +2 gris

Mensaje por chernandezba » Mar Ago 09, 2016 5:44 pm

Ya le he contestado a wilco en privado pero lo comento aquí también por si a alguien le resulta útil

El tema es que con ZEsarUX se pueden poner puntos de paro cuando se leen o escriben direcciones de memoria o puertos
Hay unas pseudo variables para activar puntos de paro. Hay 4 para lecturas y escrituras de puertos y otras 4 para memoria.
PRA: port read address: dirección de lectura de puerto
PWA: port write addrress: dirección de escritura de puerto
PRV: port read value. Valor de lectura de puerto
PWV: port write value. Valor de escritura de puerto

Entonces por ejemplo si quieres que salte breakpoint cuando se escriba en el puerto 1FFD debes poner :
PWA=1FFDH

Si quisieras que saltase cuando se lee el valor 32 del puerto FEH pondrias:
PRV=32 AND PRA=FEH

Es bastante intuitivo... Tienes otras 4 variables similares al acceder a memoria en vez de puertos,simplemente cambiando la P por M, o sea:
MRA, etc...
Está documentado en la ayuda de breakpoints

Ten en cuenta que siempre saltara breakpoint según el último valor de la variable, es decir, siempre que el último puerto escrito sea el 1FFDH saltara el breakpoint en el primer ejemplo
Ese breakpoint seguirá saltando hasta que se escriba en un puerto diferente.
He pensado varias veces en poder hacer que un breakpoint salte una vez, y luego no vuelva a saltar hasta que la condición pase a false y luego a true de nuevo, pero no es tarea fácil...
Última edición por chernandezba el Mar Ago 09, 2016 5:50 pm, editado 3 veces en total.
----

ZEsarUX
ZX Second-Emulator And Released for UniX
https://github.com/chernandezba/zesarux

Avatar de Usuario
chernandezba
Sabreman
Mensajes: 408
Registrado: Mié Oct 17, 2007 5:26 pm

Re: Hacer funcionar las ROMs de un +2A en un +2 gris

Mensaje por chernandezba » Mar Ago 09, 2016 5:46 pm

También se puede poner un breakpoint cuando se ejecute una instrucción de código máquina concreta, por ejemplo:
Opcode=Aah
Cuando se ejecute el opcode AAH (que me acabo de inventar ahora)
O bien
Opcode=EDCCH
Para opcode con prefijo ED
Puedes poner condición hasta 4 bytes...
Con esto, si lo que esperas es encontrar un OUT (C),A, le pones la condición de opcode que corresponda (opcode=ED79H si no recuerdo mal) y se te parara justo en dicha instrucción.
----

ZEsarUX
ZX Second-Emulator And Released for UniX
https://github.com/chernandezba/zesarux

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Hacer funcionar las ROMs de un +2A en un +2 gris

Mensaje por zup » Mar Ago 09, 2016 6:27 pm

ZX Spin también tiene ese tipo de breakpoints, cuando llegue a casa busco cómo se hace.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

Avatar de Usuario
wilco2009
Freddy Hardest
Mensajes: 543
Registrado: Lun Sep 17, 2012 9:40 am
Ubicación: Valencia

Re: Hacer funcionar las ROMs de un +2A en un +2 gris

Mensaje por wilco2009 » Mié Ago 10, 2016 1:42 pm

Muchas gracias chernandezba, es justo lo que necesitaba.

He estado haciendo pruebas y he acotado algo más el problema, pero creo que mis conocimientos de ensamblador me la están jugando y algo se me escapa.

A ver si alguien me puede echar un cable.

Tanto en el +2A como en el +2gris esta primera parte la hace correctamente:

Hace 7 llamadas al puerto 7FFD para inicializar las páginas de RAM (esto no utiliza para nada la lógica del interface, ya que la RAM no la gestiono yo, sino el propio ordenador)

Código: Seleccionar todo

; Test memory at startup & initialise

.l010f  ld      b,$08           ; 8 pages to clear

.l0111  ld      a,b
exx
dec     a
ld      bc,$7ffd
out     (c),a           ; page next RAM page to $c000
ld      hl,$c000
ld      de,$c001
ld      bc,$3fff
ld      (hl),$00
ldir                    ; clear it
exx
djnz    l0111           ; back for more pages
Después de eso chequea que se ha escrito correctamente la RAM, para lo cual vuelve a usar el puerto otras 8 veces. (Aquí creo que se podían haber ahorrado un cambio de página porque en el bucle anterior acaba en la página 0) (Sigue sin usarse el hardware del interface por el mismo motivo)

Código: Seleccionar todo

xor     a
ld      hl,$dcba        ; an address in top 16K of ROM
ld      bc,$7ffd        ; memory paging address

.l0130  ld      de,$0108        ; E=8 bits to test, D=bit 0
out     (c),a           ; get next page to segment 3
ex      af,af'          ; save A'=page

.l0136  ld      a,d             ; test to see if bit can be set
ld      (hl),a
ld      a,(hl)
and     d
jp      z,l0367         ; jump if memory not re-read correctly
cpl                     ; test to see if bit can be reset
ld      (hl),a
ld      a,(hl)
and     d
jp      nz,l0367        ; jump if memory not re-read correctly
rlc     d
dec     e
jr      nz,l0136        ; loop back to test other bits
ex      af,af'
inc     a
cp      $08
jr      nz,l0130        ; loop back to test other pages
Después ya no vuelve a hacer uso de los puertos hasta la dirección $189, en donde hace una llamada a la ROM 3 para copiar los UDGs. (Aquí ya sí que se usa el hardware del interface, y aparentemente funciona bien)

Código: Seleccionar todo

ld      (P_RAMT),hl     ; set P RAMT to 64K
ld      de,$3eaf        ; prepare to copy chars A-U from ROM 3
ld      bc,$00a8        ; to UDG area
ex      de,hl
rst     $28             ; execute a LDDR from ROM 3 to copy them
defw    $1661
ex      de,hl
Lo anterior significa una llamada a cada puerto (7ffd y 1ffd) para cambiar a la ROM 3 y otra llamada más de vuelta, cosa que el interface gestiona correctamente

Hasta aquí seguimos bien en ambos ordenadores

En la posición $256 volvemos a llamar a la ROM3 para hacer un CLS.

rst $28
defw $0d6b ; CLS using ROM 3

Para lo que volvemos a hacer una llamada más a cada puerto ($1FFD y 7FFD) usando la RST28.

Hasta aquí seguimos bien, , respondiendo el hardware aparentemente bien, pero a partir de aquí, el +2A hace el CLS y vuelve a la ROM0 y, sin embargo, el +2 gris se queda en la ROM3.

El código es algo enrevesado para un simple CLS, por lo que entiendo que debe hacer algo más.

En la posición $d6b de la ROM3 hay simplemente lo siguiente:

Código: Seleccionar todo

call    $0daf
En $daf encontramos esto:

Código: Seleccionar todo

ld      hl,$0000
ld      (COORDS),hl
res     0,(iy+$30)
call    $0d94
ld      a,$fe
call    $1601
call    $0d4d
ld      b,$18
call    $0e44
ld      hl,(CURCHL)
ld      de,$09f4
ld      (hl),e
inc     hl
ld      (hl),d
ld      (iy+$52),$01
ld      bc,$1821
Todos los calls los ejecuta sin realizar más llamadas a los puertos 1FFD/7FFD hasta que llegamos a la rutina $0e44.

En $0e44 tenemos esto:

Código: Seleccionar todo

.l0e44  push    bc
call    $0e9b
ld      c,$08

.l0e4a  push    bc
push    hl
ld      a,b

.l0e4d  and     $07
rrca
rrca
rrca
ld      c,a
ld      a,b
ld      b,$00
dec     c
ld      d,h
ld      e,l
ld      (hl),$00
inc     de
ldir
ld      de,$0701
add     hl,de
dec     a
and     $f8
ld      b,a
jr      nz,l0e4d            ; (-27)
pop     hl
inc     h
pop     bc
dec     c
jr      nz,l0e4a            ; (-36)
call    $0e88
y ahora viene cuando no entiendo nada, porque en el emulado me salta el breakpoint de la rutina de cambio de página de RAM ($387f) después de pasar varias veces por la instrucción ldir!!!.

Lo he probado en dos emuladores distintos y el resultado es el mismo.

Teóricamente mi problema hardware tiene que producirse entre la entrada a la ROM3 en $d6b y la instrucción ldir de la rutina anterior, ya que esa llamada al puerto 7ffd no llega a producirse nunca en el +2 gris, pero me siento incapaz de trazar el programa ante ese comportamiento del emulador.

¿Tenéis idea a qué puede ser debido ese efecto?

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Hacer funcionar las ROMs de un +2A en un +2 gris

Mensaje por zup » Mié Ago 10, 2016 2:38 pm

¿Es posible que te haya entrado una interrupción? Si mal no recuerdo, el BASIC de los 128k hace paginación durante las interrupciones.

También ayudaría que pongas una lista de los breakpoints que usas, a lo mejor alguno está mal.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

Avatar de Usuario
wilco2009
Freddy Hardest
Mensajes: 543
Registrado: Lun Sep 17, 2012 9:40 am
Ubicación: Valencia

Re: Hacer funcionar las ROMs de un +2A en un +2 gris

Mensaje por wilco2009 » Mié Ago 10, 2016 3:51 pm

Bueno, al final sí era un interrupción. Saltaba a la subrutina $48 en medio del ldir.

El contenido de la subrutina $48 es el siguiente:

Código: Seleccionar todo

.l0048  push    bc
        push    de
        call    l386e           ; scan the keyboard
        pop     de
        pop     bc
        pop     hl
        pop     af
        ei      
        ret     
La cual hace una llamada a $386e

Código: Seleccionar todo

.l386e  push    ix              ; save IX (why?)
        call    l02bf           ; scan keyboard as with 48K ROM
        bit     4,(iy+$01)
        jr      z,l387c         ; check bit 4 of FLAGS
        call    l387f           ; check disk motor if true
.l387c  pop     ix
        ret     
En dicha rutina escanea el teclado y comprueba si el motor del floppy está en marcha ($387f) que es precisamente donde está la escritura de puerto que no llega a realizar el +2 gris.

Código: Seleccionar todo

; Subroutine to check disk motor timeout

.l387f  ld      bc,$7ffd
        ld      a,(BANKM)
        or      $07
        out     (c),a           ; page in page 7
        ld      a,($e600)
        or      a
        jr      z,l38ac         ; move on if motor already off
        ld      a,(FRAMES)
        bit     0,a
        jr      nz,l38ac        ; only decrement timeout every other time
        ld      a,($e600)
        dec     a               ; decrement timeout
        ld      ($e600),a
        jr      nz,l38ac        ; move on if not yet zero
        ld      bc,$1ffd
        ld      a,(BANK678)
        and     $f7
        ld      (BANK678),a
        out     (c),a           ; switch motor off
.l38ac  ld      bc,$7ffd
        ld      a,(BANKM)
        out     (c),a           ; page back page 0
        ret
Y de momento ahí me he quedado. En un punto no determinado desde la posición $d6b (que es donde comienza la rutina de CLS) y la llamada a la rutina $387f (desde la interrupción) el +2 gris hace algo diferente que le hace quedarse en la ROM3.

A ver que más se me ocurre para seguir diagnosticando el problema.

zup
Freddy Hardest
Mensajes: 666
Registrado: Vie Ago 15, 2008 2:43 pm

Re: Hacer funcionar las ROMs de un +2A en un +2 gris

Mensaje por zup » Mié Ago 10, 2016 9:09 pm

Llego tarde, pero por si a alguien le interesa...

La forma de poner ese tipo de breakpoints en ZX Spin es la siguiente:

Abres la ventana del depurador (TAB) y vas a Breakpoints > Set breakpoint. Te aparece la ventana de breakpoints y rellenas los siguientes datos:

- Memory page: Any (para que salte con cualquier página).
- Address: en blanco.
- Location: no deja escribir nada.
- Condition: una de estas cuatro RADDR, WADDR, RPORT, WPORT.

ZX Spin protestará que dejar en blanco Address provocará una pérdida de rendimiento (inapreciable en equipos modernos). Ya lo tienes todo listo. Las condiciones son:

- RADDR, WADDR: Se activan con lecturas/escrituras a memoria. Por ejemplo, podríamos detectar cuándo se empieza a borrar la pantalla con la condición WADDR=16384.
- RPORT, WPORT: Se activan con lecturas/escrituras a puertos. Para detectar la paginación, usarías WPORT=$7FFD.

Observa que puedes poner las condiciones en el sistema numérico que quieras.

Las condiciones pueden ser más complejas, del estilo (RPORT & 255) = 31 (salta al leer el puerto del kempston) o WPORT=32765 and ((A & 7) = 3) que saltaría cuando escribes al puerto de paginación y los últimos 3 bits de A son igual a 3.
I have traveled across the universe and through the years to find Her. Sometimes going all the way is just a start...

Avatar de Usuario
wilco2009
Freddy Hardest
Mensajes: 543
Registrado: Lun Sep 17, 2012 9:40 am
Ubicación: Valencia

Re: Hacer funcionar las ROMs de un +2A en un +2 gris

Mensaje por wilco2009 » Mié Ago 10, 2016 11:46 pm

Gracias por la info. La verdad es que parece bastante potente a la hora de depurar.

Avatar de Usuario
wilco2009
Freddy Hardest
Mensajes: 543
Registrado: Lun Sep 17, 2012 9:40 am
Ubicación: Valencia

Re: Hacer funcionar las ROMs de un +2A en un +2 gris

Mensaje por wilco2009 » Jue Ago 11, 2016 12:57 pm

Develado el significado de la variable $5c3b.

Dicha posición corresponde con la variable del sistema "FLAGS" cuyo cuarto bit (que es el que se comprueba en la instrucción) significa, si está a 0 = modo 48k y si está a 1 = modo +3 BASIC.

Es posible que ese bit se haya puesto a cero en algún momento, o que no se haya puesto a uno cuando debe.

El tema es que los únicos sitios donde se toca ese bit es:

- ROM 0, $1b0: que es donde se inicializan las variables del sistema.

- ROM 1, $1465: Que da servicio al comando "SPECTRUM"

- ROM 1, $1488: Que se llama desde la ROM 0 para poner el sistema en modo 48K (teóricamente solo se llama cuando se selecciona desde el menú).

A ver si averiguo algo más esta tarde.........

Recordemos que el programa aparentemente entra correctamente en la ROM3 subrutina $0daf:

Código: Seleccionar todo

.l0daf  ld      hl,$0000
        ld      (COORDS),hl
        res     0,(iy+$30)
        call    $0d94
        ld      a,$fe
        call    $1601
        call    $0d4d
        ld      b,$18
        call    $0e44
        ld      hl,(CURCHL)
        ld      de,$09f4
        ld      (hl),e
        inc     hl
        ld      (hl),d
        ld      (iy+$52),$01
        ld      bc,$1821
Por lo que el fallo, presumiblemente, tiene que producirse en alguna de las subrutinas hasta la $0e044, que es donde se ejecuta la interrupción que debería mostrar nuevas llamadas a los puerto $1FFD y $7FFD y que recordemos que no se observan en el +2 gris.

Se me ocurre parchear uno a uno los call de la subrutina por un NOP + out ($FE),a para el primero y el segundo que quedarían con borde negro y los otros sustituyendo el NOP por un DEC A, para ver hasta donde llega.

Avatar de Usuario
chernandezba
Sabreman
Mensajes: 408
Registrado: Mié Oct 17, 2007 5:26 pm

Re: Hacer funcionar las ROMs de un +2A en un +2 gris

Mensaje por chernandezba » Vie Ago 12, 2016 10:00 am

Si te sirve de algo y tienes práctica compilando programas en C, te sugiero modificar el código de mi emulador y meter printf en lugares estratégicos... El 50% de los problemas que he tenido con el emulador los he solventado con dichos printf, son una maravilla... ;)
----

ZEsarUX
ZX Second-Emulator And Released for UniX
https://github.com/chernandezba/zesarux

Avatar de Usuario
wilco2009
Freddy Hardest
Mensajes: 543
Registrado: Lun Sep 17, 2012 9:40 am
Ubicación: Valencia

Re: Hacer funcionar las ROMs de un +2A en un +2 gris

Mensaje por wilco2009 » Vie Ago 12, 2016 5:30 pm

Gracias por la sugerencia, pero más o menos ya tengo delimitado el problema. ¡¡¡Lo que pasa es que no puedo entender porqué ocurre!!!. :shock: :shock: :shock: :shock: :shock: :shock:

Como ya dije, he detectado que el bit 4 de la variable del sistema FLAGS ($5c3b), que indica si estamos en modo +3BASIC o en modo 48K, se pone a 0 (modo 48K) sin razón aparente, por lo que el sistema termina arrancando en modo 48K.

Para poder detectar cuándo se pone a cero ese bit, me he liado a insertar el siguiente código cada vez en un punto del programa para ir detectando el valor de ese bit en cada uno de esos puntos:

Código: Seleccionar todo

	xor a
	inc a
	bit 4, (iy+$01)
	jr nz, +1	
	etq0: 
	inc a		
	out ($fe), a	
etq1: 
	jr etq1
En el registro iy se copia al principio del código la posición $5c3a y no se toca el registro en el resto del código de la ROM.

Pues bien, el valor de ese bit es el esperado hasta que estamos a punto de llamar a la rutina de CLS en la ROM3 desde la ROM0, en la posición $265.

Código: Seleccionar todo

rst     $28
defw    $0d6b           ; CLS using ROM 3
En esa posición, el bit todavía está a 1, pero ¡sorpresa! :shock: , si lo volvemos a comprobar en la posición $0d6b de la ROM3, ¡¡resulta que está a 0!!.
Nadie toca la RAM ni el valor de iy entre esos dos puntos.

Avatar de Usuario
wilco2009
Freddy Hardest
Mensajes: 543
Registrado: Lun Sep 17, 2012 9:40 am
Ubicación: Valencia

Re: Hacer funcionar las ROMs de un +2A en un +2 gris

Mensaje por wilco2009 » Vie Ago 12, 2016 9:04 pm

Creo que ya se por donde van los tiros.....

El puñetero +2 gris decodifica el puerto $1FFD de alguna manera ya que si no fuera así no debería inmutarse ante una llamada a ese puerto.

He hecho una prueba. He quitado el interface y he hecho un out 8189,4 ($1FFD) y !el ordenador se resetea! :o

Quizás a la hora de decodificar el puerto $7FFD realizan una decodificación incompleta y se confunde los dos puertos internamente. ???????

Avatar de Usuario
chernandezba
Sabreman
Mensajes: 408
Registrado: Mié Oct 17, 2007 5:26 pm

Re: Hacer funcionar las ROMs de un +2A en un +2 gris

Mensaje por chernandezba » Mar Ago 16, 2016 5:36 pm

chernandezba escribió: Ten en cuenta que siempre saltara breakpoint según el último valor de la variable, es decir, siempre que el último puerto escrito sea el 1FFDH saltara el breakpoint en el primer ejemplo
Ese breakpoint seguirá saltando hasta que se escriba en un puerto diferente.
He pensado varias veces en poder hacer que un breakpoint salte una vez, y luego no vuelva a saltar hasta que la condición pase a false y luego a true de nuevo, pero no es tarea fácil...
Siguiendo un post mío anterior... He modificado el código de mi emulador para que ahora los puntos de paro sólo saltan cuando la condición pasa a ser falsa->verdadera. Y no vuelven a saltar hasta que la condición pasa de verdadera->falsa y luego a verdadera de nuevo. Esto por ejemplo evita que siempre se esté deteniendo el emulador cuando la condición sigue siendo verdadera (por ejemplo cuando ponemos la condición A=0 se detenía siempre que A=0 y no seguía la ejecución hasta que A valía cualquier cosa), y sólo volverá a detenerse cuando la condición pase de falsa a verdadera.
Este comportamiento es el que está por defecto ahora, pero se puede cambiar al comportamiento anterior desde el menú debug cpu.

Saludos
----

ZEsarUX
ZX Second-Emulator And Released for UniX
https://github.com/chernandezba/zesarux

Avatar de Usuario
wilco2009
Freddy Hardest
Mensajes: 543
Registrado: Lun Sep 17, 2012 9:40 am
Ubicación: Valencia

Re: Hacer funcionar las ROMs de un +2A en un +2 gris

Mensaje por wilco2009 » Mar Ago 16, 2016 9:13 pm

¡Eso está muy bien!

Seguro que me viene de maravilla para futuros cacharreos. :D

Muchas gracias. ;)

Responder

¿Quién está conectado?

Usuarios navegando por este Foro: Bing [Bot] y 4 invitados