Adelanto de en lo que estoy trabajando
Re: Adelanto de en lo que estoy trabajando
Wualaaaa! Esto ya son palabras mayores!
Si lo he entendido bien, transferir una pantalla tardaría el equivalente a 3500 estados T?
Sería interesante alguna comparativa teórica entre este modo y su "LDIR" equivalente.
Imagino que para pocos bytes, sería más eficiente ristras de LDI, ¿no?
Indudablemente, el hecho de ser independiente de la CPU es ya una ventaja bestial.
Si lo he entendido bien, transferir una pantalla tardaría el equivalente a 3500 estados T?
Sería interesante alguna comparativa teórica entre este modo y su "LDIR" equivalente.
Imagino que para pocos bytes, sería más eficiente ristras de LDI, ¿no?
Indudablemente, el hecho de ser independiente de la CPU es ya una ventaja bestial.
Re: Adelanto de en lo que estoy trabajando
Muchas gracias !!!!!!mcleod_ideafix escribió:Para parchear la ROM del ESXDOS: se necesita un editor hexadecimal, tal como por ejemplo, HxD
https://mh-nexus.de/en/hxd/
Abrid el firmware de ESXDOS (esxmmc.bin) que quereis parchear con el editor.
Haced una búsqueda hexadecimal de la siguiente secuencia
01 DF 24
(en HxD se pondría así separado, o todo junto, como querais)
En la ventana principal del editor, a continuación de la primera vez que aparece, tienes la secuencia ED 79. Sustituye esa secuencia por 00 00. Se sobreeescriben los valores. Nunca se insertan o borran.
Dale a que busque la siguiente ocurrencia de la secuencia a buscar (normalmente esto se hace pulsando F3)
Después de la segunda vez que la encuentra, hay una secuencia que es ED 78. Esa no la tocamos, pero si miramos un poquito más adelante encontramos otro ED 79. Como en el caso anterior, sustituir por 00 00.
Y listo. Se graban los cambios, se renombra el fichero como ESXDOS.ZX1 y se vuelve a grabar en la Flash desde la BIOS.
Ya lo tengo parcheado. En cuanto pueda, lo pruebo.
- mcleod_ideafix
- Mensajes: 831
- Registrado: 27 Sep 2015, 00:14
- Ubicación: Jerez de la Frontera
- Contactar:
Re: Adelanto de en lo que estoy trabajando
La transferencia usa 4 ciclos de reloj (del reloj de 28 MHz) en llevar un byte desde una posición fuente a una destino. En modo burst, todos los bytes se transfieren uno detrás de otro, seguidos, así que en transferir una pantalla tarda exactamente 6912*4 ciclos de reloj de 28 MHz = 27648 ciclos de reloj. A la velocidad estándar, un ciclo de CPU son 8 ciclos de reloj de 28 MHz, así que medido en ciclos de reloj de CPU, la transferencia tarda 27648/8 = 3456 ciclos de reloj (has hecho bien los cálculos ), o medido en "rasters", unos 15,5 rasters (lineas de pantalla). Un raster son 224 ciclos de CPU a velocidad estándar.Haplo escribió:Wualaaaa! Esto ya son palabras mayores!
Si lo he entendido bien, transferir una pantalla tardaría el equivalente a 3500 estados T?
Pues ahí va (estoy suponiendo que no hay contención en la memoria cuando se hacen transferencias. En el caso real, si hay contención, estos números serán mayores):Haplo escribió:Sería interesante alguna comparativa teórica entre este modo y su "LDIR" equivalente.
- LDIR: 21 ciclos en cada transferencia cuando aún no ha terminado + 16 ciclos en la última = 6911*21+16 = 145157 ciclos de CPU (648 rasters)
- LDIR desenrollada, o sea, una secuencia de 6912 LDI's: 16*6912 = 110592 ciclos de CPU (493,7 rasters)
- Transferencia vía stack: es una secuencia tal que así:
Código: Seleccionar todo
LD SP,fuente
POP AF
POP BC
POP DE
POP HL
POP IX
POP IY
LD SP,destino+12
PUSH IY
PUSH IX
PUSH HL
PUSH DE
PUSH BC
PUSH AF
Los números anteriores pueden dividirse por 2 o por 4 dependiendo de si se pone la CPU a 7MHz o 14MHz. El mejor caso "software" sería la transferencia vía stack, con la CPU a 14 MHz, que tardaría 23328 ciclos de CPU (ciclos de velocidad estándar), o 104 rasters.
Todo esto, por supuesto, obviando el overhead que supone inicializar los registros con los valores pertinentes. Para la DMA, el overhead es mayor que para cualquier otro caso.
Para pocos bytes, usar el stack es lo más eficiente. Usando el código desenrollado que te doy, el overhead es nulo, pero claro, sólo te vale si haces transferencias siempre desde el mismo sitio al mismo sitio, con lo que los valores de los LD SP,nn pueden ser fijos. Para pocos bytes en donde las direcciones fuente y destino pueden variar, creo que es más rápido usar la secuencia de LDI's.Haplo escribió:Imagino que para pocos bytes, sería más eficiente ristras de LDI, ¿no?
La secuencia de inicialización del DMA, para una transferencia burst (ráfaga, a toda velocidad) y la implementación actual, tiene esta pinta:
Código: Seleccionar todo
ld bc,0fc3bh
ld a,DMASRC
out (c),a
inc b
ld hl,SourceAddr
out (c),l
out (c),h
dec b
ld a,DMADST
out (c),a
inc b
ld hl,DestAddr
out (c),l
out (c),h
dec b
ld a,DMALEN
out (c),a
inc b
ld hl,TransferLength
out (c),l
out (c),h
dec b
ld a,DMACTRL
out (c),a
inc b
ld a,00000001b ;transferencia memoria a memoria, burst
out (c),a
;---- la CPU se para y se realiza la transferencia ----
nop, etc... (continúa el programa...)
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA
- desUBIKado
- Mensajes: 1002
- Registrado: 05 Ago 2016, 22:33
Re: Adelanto de en lo que estoy trabajando
Pregunta para el señor McLeod Ideafix
Ahora que en el core EXP25 la CPU puede trabajar con 3.5, 7, 14 y 28 Mhz ¿Es posible añadir la funcionalidad de incrementar o decrementar la velocidad "al vuelo" pulsando unas teclas? ... En caso de ser posible sugiero las teclas F11 y F12.
De esta forma, se podría variar la velocidad de un juego he ir probando cual es la que le viene mejor para ser más jugable.
Y esto supongo que no, pero el preguntar es gratis ¿se podría hacer los incrementos / decrementos de velocidad con más velocidades intermedias? Por ejemplo, 0 (el spectrum parado como con el dispositivo que ideó Primitivo de Francisco para congelar la pantalla y que los de MicroHobby sacasen una foto al juego), 1.75, 3.5, 5.25, 7, ... 28 Mhz.
Ahora que en el core EXP25 la CPU puede trabajar con 3.5, 7, 14 y 28 Mhz ¿Es posible añadir la funcionalidad de incrementar o decrementar la velocidad "al vuelo" pulsando unas teclas? ... En caso de ser posible sugiero las teclas F11 y F12.
De esta forma, se podría variar la velocidad de un juego he ir probando cual es la que le viene mejor para ser más jugable.
Y esto supongo que no, pero el preguntar es gratis ¿se podría hacer los incrementos / decrementos de velocidad con más velocidades intermedias? Por ejemplo, 0 (el spectrum parado como con el dispositivo que ideó Primitivo de Francisco para congelar la pantalla y que los de MicroHobby sacasen una foto al juego), 1.75, 3.5, 5.25, 7, ... 28 Mhz.
Re: Adelanto de en lo que estoy trabajando
Yo casi prefiero AvpG y RePg, que F11 y F12 la usan algunos otros cores.desUBIKado escribió:Pregunta para el señor McLeod Ideafix
Ahora que en el core EXP25 la CPU puede trabajar con 3.5, 7, 14 y 28 Mhz ¿Es posible añadir la funcionalidad de incrementar o decrementar la velocidad "al vuelo" pulsando unas teclas? ... En caso de ser posible sugiero las teclas F11 y F12.
- desUBIKado
- Mensajes: 1002
- Registrado: 05 Ago 2016, 22:33
Re: Adelanto de en lo que estoy trabajando
Ya, pero... de las que usa el spectrum esas están "libres" - siempre habrá distintas funcionalidades a las teclas dependiendo del core/máquina que usemos-. A ver si escribiendo bajito y modosito cuelaUto escribió:Yo casi prefiero AvpG y RePg, que F11 y F12 la usan algunos otros cores.
Re: Adelanto de en lo que estoy trabajando
Mientras no se use el teclado numérico para los que usamos teclados compactos, cualquier otra tecla está bien.
- mcleod_ideafix
- Mensajes: 831
- Registrado: 27 Sep 2015, 00:14
- Ubicación: Jerez de la Frontera
- Contactar:
Re: Adelanto de en lo que estoy trabajando
La funcionalidad es posible añadirla, sí. Estudiaré la mejor forma de hacerlodesUBIKado escribió:¿Es posible añadir la funcionalidad de incrementar o decrementar la velocidad "al vuelo" pulsando unas teclas?
De momento, tal y como manejo el tema de la velocidad de la CPU, no es posible. Quiero hacer no obstante una prueba para controlar la velocidad de una forma diferente y así liberar buferes globales, que son un recurso muy precioso. Si la prueba sale bien, lo que planteas será posible. Incluso la parada total.desUBIKado escribió:Y esto supongo que no, pero el preguntar es gratis ¿se podría hacer los incrementos / decrementos de velocidad con más velocidades intermedias? Por ejemplo, 0 (el spectrum parado como con el dispositivo que ideó Primitivo de Francisco para congelar la pantalla y que los de MicroHobby sacasen una foto al juego), 1.75, 3.5, 5.25, 7, ... 28 Mhz.
http://www.zxuno.com
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA
ZX-Uno · Clon de ordenador ZX Spectrum basado en FPGA
- desUBIKado
- Mensajes: 1002
- Registrado: 05 Ago 2016, 22:33
Re: Adelanto de en lo que estoy trabajando
¡Qué grande! Yo me esperaba un no no pequeño robot, y puede que sea finalmente un sí sí emperatriz