Loader inicial para otla?

[D_Skywalk]

Hola de nuevo, aquí ando peleando con el CPC. En esta ocasión solo por placer estoy trasteando las ultra cargas del OTLA...

Funcionan de maravilla, pero me gustaría añadirles las pantallas iniciales de los juegos, con su paleta y su mode... pero no lo consigo

Este es el pequeño inicializador el cual es un pequeño fronconstein del código que anda por este foro (thx Artaburu) y por el wiki

Código: Seleccionar todo

ORG #4000

; Llamadas al firmware

;.scr_set_mode_firm equ &bc0e
; Entradas A tiene el valor del modo (0,1,2)
; Se corrompen AF,BC,DE,HL
.scr_set_ink equ &bc32
; Entradas A tiene el número de PEN, B tiene el primer color, C el segundo
; Se corrompen AF,BC,DE,HL

;.inicio
call inicializar_colores
halt
ld A,0
call scr_set_mode_nop ; pantalla en modo 0
;call &013a
ret

.scr_set_mode_nop
ld BC,&7F00 ;Gate array port
ld D,&8C ;Mode and rom selection (and Gate Array function)
add D
out (C),A
halt
call &b9b0 ; refresco
halt
ret


.inicializar_colores ;rutina de SYX
ld A,0
ld hl,tabla_colores
.bucle_inicializar_colores
ld b,(hl)
ld c,b
push af
push hl
call scr_set_ink ; Corrompe los registros AF,BC,DE,HL
pop hl
pop af
inc hl
inc a
cp 16
jr nz,bucle_inicializar_colores
LD B,0
LD C,0
CALL &BC38
ret

tabla_colores
db 0,13,26,12,24,9,18,10
db 20,1,2,11,4,15,3,6

Estoy intentando no usar el scr_set_mode_firm, ya que me limpia la pantalla y es lo que intento evitar, usar mi propia función de cambio de modo, para evitar que se cargue el loader que se encuentra en la posición &FF00

He visto que trasteando con los halts, en alguna ocasión en Winape ha funcionado, pero no siempre me funciona, asi que creo que es más bien un bug del programa cuando compila

Un Saludo y yo se que alguna manera fácil de hacer esto habrá

[syx]

Estoy intentando no usar el scr_set_mode_firm, ya que me limpia la pantalla y es lo que intento evitar, usar mi propia función de cambio de modo, para evitar que se cargue el loader que se encuentra en la posición &FF00

Dentro del firmware siempre hay llamadas de más bajo nivel como son las del Machine Pack, en ellas puedes encontrar MC_SET_MODE ($BD1C) que al igual que SCR_SET_MODE recibe el modo de pantalla en el Acumulador, pero esta no te borra la pantalla.

He visto que trasteando con los halts, en alguna ocasión en Winape ha funcionado, pero no siempre me funciona, asi que creo que es más bien un bug del programa cuando compila

Esto te sucede porque has modificado el modo justo a continuación de que lo haya hecho el firmware, es por lo que se queda tu selección, pero como has comprobado es más normal que el firmware tome prioridad sobre tus cambios.

Otra cosa a tener en cuenta es que no debes mezclar llamadas al firmware con accesos directos al hardware, pues estás llamando a problemas de esos de los de volverse majareta Lo digo porque en scr_set_mode_nop estás usando el hardware para hacer el cambio de modo, pero claro si no notificas al firmware de que has hecho ese cambio (cambiando las variables del sistema), el seguirá pensando que está en el modo en que se encontraba antes.

La regla de oro es ó usas el firmware para todo (ó al menos hasta antes de tomar el control de la máquina, por ejemplo, para cargar ficheros ó inicializaciones variadas que con el firmware se reducen a unos cuantos LDs y CALLs) ó usas el hardware para todo.

[D_Skywalk]

Llevo toda la mañana dandole vueltas y nada...

Estoy pensando que hay algún cambio de paletas en el loader del otla

Código: Seleccionar todo



Hdir equ $ff

ORG Hdir*$100



ld hl , $800e
ld de , $ff0e
ld bc , 250 - 14
ldir
jp start_loading


inicio


table
defb $40,$40 ;defb &fc,&fc
defb $40,$40 ;defb &fc,&fc
defb $40,$40,$40,$40,$40 ;defb &fc,&fc,&fc,&fc,&fc
defb $41,$41,$41,$41,$41 ;defb &fd,&fd,&fd,&fd,&fd
defb $42,$42,$42,$42,$42 ;defb &fe,&fe,&fe,&fe,&fe,&fe
defb $43,$43,$43,$43,$43 ;defb &ff,&ff,&ff,&ff,&ff,&ff
defb $43,$43,$43,$43,$43 ;defb &ff,&ff


men
defb $0a
defb "Loading error"
defb 0


velozloader
pilot

ld d, (hl)
dec hl
ld e, (hl)
push de
push hl

ex de,hl

di

exx
push bc
ld bc,$7f10
out (c),c ;border
ld c , $44
exx

pii_0

ld bc, &f510 ; ear

pii
exx
out (c), b ; a ;
exx

xor a

pi_LOW inc a
in f,(c)
jp m, pi_LOW

exx
out (c),c
exx

pi_HIGH inc a
in f,(c)
jp p , pi_HIGH


cp $39
rl c ; d
cp $29
jr nc, pii

inc c ; d
jr nz , pii_0

syn_LOW in f,(c)
jp m, syn_LOW

cp $19
ld a, $f2 ;e ; $fa

jr c, no_inv

xor 8

syn_hi in f,(c)
jp p , syn_hi

no_inv
ld (p1),a
xor 8
ld (m1),a



xor a
ld c,a
jr enter


full and H
ld (de),a
inc de
xor c
ld c,a
ld a, $fe; ; 1+2+2+1+1+2 = 9

enter
more

HIGH inc l
in f , (c)
p1 jp p , HIGH


exx
inc c
res 3,c
exx

ld h, Hdir ;

ld h, (hl)

ld l, table - (Hdir * $100) -2

; 11


LOW inc l
in f,(c)
m1 jp m, LOW

rlca
rla

jr nc, full ;p nC, full

exx
out (c),c
exx

and H
jp m, more ; 1+4+1 +1+3 = 10

exx
pop bc
exx

pop hl
pop de
ld (hl),e
inc hl
ld (hl),d

ld a, c
or a

di ;ei
ret z

ld hl, men
wr_men
call $bb5a

ld a,(hl)
or a
inc hl

jr nz, wr_men

ei
ret


start_loading

ld bc, inicio ; pila

ld bc,$f610
out (c),c ;OUT &F600,&10 motor

call entra_multiblock


ld bc,$f6ef
out (c),c ;OUT &F600,&10 motor off

ld hl,(bu+1)
ei
jp (hl)
dexec
ret



header defw $c020-1 ;$bfff
bu defb 01 ; ret ;ret/ld de,/jp/call
defw dexec

entra_multiblock

ld hl, header -1
call velozloader

ld hl,(header)
call velozloader
jr bu


Yo solo veo un cambio de border al inicio y no de paletas:

Código: Seleccionar todo

ld bc,$7f10

Para volver al loader estoy probando con: "jp velozloader" y "jp start_loading"

Otra cosa a tener en cuenta es que no debes mezclar llamadas al firmware con accesos directos al hardware, pues estás llamando a problemas de esos de los de volverse majareta Lo digo porque en scr_set_mode_nop estás usando el hardware para hacer el cambio de modo, pero claro si no notificas al firmware de que has hecho ese cambio (cambiando las variables del sistema), el seguirá pensando que está en el modo en que se encontraba antes.

Ok, lo hago todo por hard... ¿pero cuales son los que tengo que tocar IX, IY?
No veo nada de eso en vuestros ejemplos

Un Saludo y muchas gracias syx por tu paciencia

[D_Skywalk]

Ya creo que está es el cargador previo que mete en &8000

Código: Seleccionar todo


org $8000


ld hl,tablaCRTC
xor a
buCRCT
ld b,&bc
out (c),a ; direcciona registro (0, 1, ..., 17)

ld b,&bd
ld c,(hl)
inc hl
out (c),c ; escribe registro

inc a
cp 18
jr nz , buCRCT


ld bc,$7fff
ld hl,tablaGA
xor a

buGA out (c),a
ld d,(hl)
inc hl
out (c),d

inc a
cp 16 ; 16 (tintas)
jr nz , buGA


ld d,(hl)
inc hl
out (c),d ; + multiregistroGA

ld d,(hl)
; inc hl
out (c),d ;+ tinta actual

pop hl
ld sp,$fffd
jp (hl)




tablaCRTC defb 0,0,0,0
defb 0,0,0,0
defb 0,0,0,0
defb 0,0,0,0
defb 0,0
;CRTC: data register (0, 1, ..., 17)


tablaGA defb 0,0,0,0
defb 0,0,0,0
defb 0,0,0,0
defb 0,0,0,0

defb 0,0

;ink value register (0, 1, ..., 15, 16)+Gate Array: multi configuration register

Estoy pensando en machacar su tablaGA con mis datos y luego meter el mode 0 en su tablaCRTC, a ver que pasa

UPDATE: Nada, falsa alarma hay una rutina en &8000 pero lo único que hace es colocar el cargador en &FF00, está rutina no está en el cargador...

un Saludo!

[syx]

Pero exactamente ¿qué es lo que te ocurre con la paleta?

Si lo que ocurre es que haces el cambio de paleta y se produce como un flash y aparece la paleta por defecto del sistema, eso quiere decir que no has "matado" el firmware, por lo que esté sigue poniendo todos los frames la paleta, reescribiendo la que tú hubieses puesto.

Otra cosa a tener en cuenta es que no debes mezclar llamadas al firmware con accesos directos al hardware, pues estás llamando a problemas de esos de los de volverse majareta Lo digo porque en scr_set_mode_nop estás usando el hardware para hacer el cambio de modo, pero claro si no notificas al firmware de que has hecho ese cambio (cambiando las variables del sistema), el seguirá pensando que está en el modo en que se encontraba antes.

Ok, lo hago todo por hard... ¿pero cuales son los que tengo que tocar IX, IY?
No veo nada de eso en vuestros ejemplos

Las variables del sistema no se almacenan en registros, sino en posiciones de memoria, todo esto viene bien detallado en la Guía del Firmware, entre otros libros.

Y algo que también debes tener en cuenta, es que bastantes programas de cpc usan el firmware, por lo que para estos casos no puedes "matarlo", ni corromper las variables y la tabla de saltos del firmware.

[D_Skywalk]

Lo que ocurre es que cambia a MODE 0, pero ...

Código: Seleccionar todo

call WAIT_VBL
ld a,0
call &bd1c ; pantalla en modo 0
call WAIT_VBL
call inicializar_colores_firm

ld hl,&ffe9 ; dejar al loader recuperar el control
ld sp,&ffff
jp (hl)

Código: Seleccionar todo

.inicializar_colores_firm ;rutina de SYX
ld A,0
ld hl,tabla_colores
.bucle_inicializar_colores
ld b,(hl)
ld c,b
push af
push hl
call scr_set_ink ; Corrompe los registros AF,BC,DE,HL
pop hl
pop af
inc hl
inc a
cp 16
jr nz,bucle_inicializar_colores
LD B,0
LD C,0
CALL &BC38
ret

El problema es que la paleta no cambia, hay alguna manera de coger el control, cambiar la paleta y volver al modo firm? o si se puede hacer todo con el firm, mejor...

La idea es simplemente cargar la pantalla de presentación del juego con sus colores (OH MY G...! no puede ser tan complicado), si puedes echarle un ojo te dejo el sna justo en el momento que carga la rutina y el cdt para que veas la carga.

en #ff00 esta el loader y en #8000 está mi intento de inicialización de pantalla

Un Saludo, espero que puedas echarme un cable mis conocimientos de z80 no dan para más

[Artaburu]

No me he leído toda la historia pero prueba a poner un bucle que no haga nada más que tiempo para dar tiempo (valga el rebuzno) a que se cambien las tintas:

Código: Seleccionar todo

ld b,10
.bcltonto
halt
djnz bcltonto

A mí me pasaba eso cuando hacía los cambios de tinta por hardware, igual por firmware te está pasando lo mismo

[syx]

No veo en ningún lado del snap el cambio de modo, pero bueno la solución rápida es:

Código: Seleccionar todo

.inicializar_colores_firm ;rutina de SYX
ld A,0
ld hl,tabla_colores
.bucle_inicializar_colores
ld b,(hl)
ld c,b
push af
push hl
call scr_set_ink ; Corrompe los registros AF,BC,DE,HL
pop hl
pop af
inc hl
inc a
cp 16
jr nz,bucle_inicializar_colores
LD B,0
LD C,0
CALL &BC38

; *** Este trozo es nuevo ***
LD A,0
CALL &BB0E ; mc_set_mode
; Esperamos al refresco para que el firmware realice los cambios de modo y tintas
CALL WAIT_VBL
HALT
; Esperamos al refresco una segunda vez para que el firmware modifique las tintas parpadeantes
CALL WAIT_VBL
HALT
; *** Fin del trozo nuevo ***
ret

Era lo que había comentado antes de que no "matas" al firmware, por lo que justo después de que cambies las paletas y el modo, el firmware hace el cambio a las que él tiene en sus variables internas.... bueno en realidad, es algo más complejo, lo que sucede es que al firmware no le da tiempo a actualizar sus variables internas a los valores que le has escrito antes de que entre en funcionamiento la rutina de carga del otla, ya que está lo primero que hace es desconectar las interrupciones, la cosa es que una vez que la rutina de carga termine y vuelva a activar las interrupciones, tus cambios de modo y paleta se harán efectivos, pero para entonces ya será demasiado tarde

Todo se reduce a eso que comentaba de que mezclar el hardware y el firmware sin saber muy bien lo que se está haciendo solo lleva a problemas de volverte loco

[D_Skywalk]

Sólo he tenido que hacer este cambio para que funcionara:

Código: Seleccionar todo

;CALL &BB0E ; mc_set_mode?
call &bd1c; mc_scr_set_modo

Ahora a recuperar correctamente el puntero a la carga, y el cargador está listo

Un Saludo y muchas gracias a los dos por acudir en mi ayuda :***

[D_Skywalk]

Espero que no moleste que ponga un doble post, he preparado un pack completo con todo lo necesario para montarte tu ultra loader con las pantallas originales. Seguramente lo termine usando yo sólo pero ya que llevo unas semanas con esto del otla, pues que valga de algo el esfuerzo ;D

He intentado documentarlo todo lo mejor posible, además tenéis el tutorial para torpes que puse en mi blog
http://david.dantoine.org/articulo/577/ (XD)

Un Saludo y muchas gracias a los dos por venir en mi ayuda

[syx]

Todo aporte es siempre positivo para la comunidad

Y es por ello que no se puede dejar de aplaudir y agradecer tu esfuerzo, seguro que más de uno lo encuentra útil

[Artaburu]

Ya te digo.
Trocoloco seguro que se encuentra encantado por tu aporte porque hace poco estuvo preguntando por cómo hacer cosas de estas con el otla

[trocoloco]

pues sí que llevais razón syx y artaburu. Viene como anillo al dedo vamos hacer probaturas pq llevaba un tiempo bastante perdido. Haber si salen cositas con esta ayuda. Gracias D_Skywalk

[D_Skywalk]

pues sí que llevais razón syx y artaburu. Viene como anillo al dedo vamos hacer probaturas pq llevaba un tiempo bastante perdido. Haber si salen cositas con esta ayuda. Gracias D_Skywalk

trocoloco, si tienes cualquier problema por aquí ando día si, día también

Ahora ando perfeccionando el inventillo y aunque requiere modificar el código original y lamentablemente el autor parece off. Estoy posicionando el cargador en &BE00 (ya que en &BF00 parece que algo modificaba su código durante la ejecución) la pregunta es muy rebuscada pero...

¿existe algún modo de una vez terminada la carga que el cargador se elimine a sí mismo?

El problema es que si posiciono el cargador en una zona de memoria que no sea la pantalla al terminar la carga, otla continúa ahí y quizás a algún juego eso le pueda llegar molestar (espera tener ahí NOP y encuentra code...)

No se si será ya marear mucho la perdiz o quizás sea complicar aun más todo por que necesitamos colocar ese "borrador" a su vez en otro lugar de la memoria. Pero se me había ocurrido colocarlo en la propia zona de memoria de vídeo justo al final de la carga y que la propia pantalla lo machacara

Un Saludo y si digo tonterías tratadme con cariño

[syx]

Ahora ando perfeccionando el inventillo y aunque requiere modificar el código original y lamentablemente el autor parece off. Estoy posicionando el cargador en &BE00 (ya que en &BF00 parece que algo modificaba su código durante la ejecución) la pregunta es muy rebuscada pero...

Si no modificas el puntero de pila, este por defecto se situa en $C000 y recordemos que la pila crece hacía abajo, así que es el uso de la pila lo que corrompe el cargador.

También hay que tener cuidado de no corromper la tabla de saltos del firmware y sus variables para el caso de programas que hagan uso de él.

¿existe algún modo de una vez terminada la carga que el cargador se elimine a sí mismo?

El problema es que si posiciono el cargador en una zona de memoria que no sea la pantalla al terminar la carga, otla continúa ahí y quizás a algún juego eso le pueda llegar molestar (espera tener ahí NOP y encuentra code...)

En un principio un programa bien hecho no debería de depender de que en ciertas posiciones de memoria que no ocupa espere encontrar unos valores determinados (excepto la tabla de saltos del firmware entre otras zonas), aunque existe alguna protección basada en ese concepto, pero esos casos son los de menos.

Así que el lograr la "autodestrucción" del cargador no debería inquietarte demasiado, lo normal es encontrar un hueco donde poder situar tu cargador y que no sea sobrescrito por el programa, aunque siempre se pueden sobrescribir las partes que ya han sido ejecutadas en el caso de que el programa trate de usar toda la ram disponible (casi siempre por motivos de protección).