Carga de Pantallas: Evitar textos ficheros

[Hark0]

Buenas!

Hace una vida, recuerdo que cargaba las imágenes de forma que había un truco o algo para evitar que los típitos textos "Bytes: bla bla" machacaran la pantalla de carga...

¿Alguien tiene un micro tutorial para esto?

Original:


Conversión ZX:



Gracias!

[na_th_an]

Código: Seleccionar todo

10 LOAD ""SCREEN$: POKE VAL "23739", CODE "o"

[Hark0]

Gracias por la info... lo añado a mi cargador...

Luego toca volver a POKEAR pero con el valor original (244) para dejar todo como estaba, ¿ok?


------ Curioseando sobre esa dirección:

Viendo la dirección de memoria que me das, me he puesto a Googlear para ver a qué variable del sistema correspondía ese 23739...

He encontrado esto: http://www.spectrum.8bit.pl/spectrum48/memory.htm (OJO! En polaco de Polonia)

Viene a decir esto (habla de 2 posiciones antes):
23737 - SBRT - llamada de procedimiento de rutina con ROM Spectrum:
LD HL, el valor de
la dirección de llamada de
LD (23738), HL
RET

Y en este otro sitio: http://wiki.vitorfonseca.com/Default.as ... eSupport=1

23739 - Micro Drive Map

¿¿ ??

[na_th_an]

Yo uso ese POKE en todos lados. Funciona. Lo saqué de los cargadores de los juegos desprotegidos de Dinamic hace 20 años... Nunca me he planteado nada más. Nunca he restaurado el valor original tampoco. Y el mundo no ha explotado todavía

[Hark0]

Yo uso ese POKE en todos lados. Funciona. Lo saqué de los cargadores de los juegos desprotegidos de Dinamic hace 20 años... Nunca me he planteado nada más. Nunca he restaurado el valor original tampoco. Y el mundo no ha explotado todavía

JUASSSSSSSSSSSSSS!!!

XD

Es que soy muy cotilla... siempre quiero saber el porqué de todo... okis

[na_th_an]

A ver, a lo mejor a uno que tenga un TK-90 modificado con sintonizador del laser disc de la vecina y unos pedales para aumentar la velocidad del Z80 medio megahertzio y neones azules controlables con el Interface II a lo mejor le da problemas, pero joder, que se aguante

[Hark0]

A ver, a lo mejor a uno que tenga un TK-90 modificado con sintonizador del laser disc de la vecina y unos pedales para aumentar la velocidad del Z80 medio megahertzio y neones azules controlables con el Interface II a lo mejor le da problemas, pero joder, que se aguante

Jajajajaja... el que me ha dejado de aqui -> es el enlace que ponia "23739 - Micro Drive Map"...

[JBGV]

Joer, gracias a ambos, yo siempre andaba modificando la pantalla para que las cabeceras no la chafaran

[na_th_an]

En realidad es

Código: Seleccionar todo

POKE 23739,111

Pero así es como menos bytes ocupa en un cargador:

Código: Seleccionar todo

POKE VAL "23739", CODE "o"

[antoniovillena]

Para los que tengáis curiosidad:
Entre $5cb6 y $5cca se guarda la información de los canales, que por defecto es una copia de estos valores en ROM, pero que se puede modificar:

Código: Seleccionar todo

L15AF:  DEFW    L09F4           ; PRINT-OUT
        DEFW    L10A8           ; KEY-INPUT
        DEFB    $4B             ; 'K'
        DEFW    L09F4           ; PRINT-OUT
        DEFW    L15C4           ; REPORT-J
        DEFB    $53             ; 'S'
        DEFW    L0F81           ; ADD-CHAR
        DEFW    L15C4           ; REPORT-J
        DEFB    $52             ; 'R'
        DEFW    L09F4           ; PRINT-OUT
        DEFW    L15C4           ; REPORT-J
        DEFB    $50             ; 'P'

        DEFB    $80             ; End Marker

En concreto la dirección 23739 es $5cbb que se corresponde al byte bajo de la rutina PRINT-OUT del canal 'S' (screen o pantalla). Al hacer el poke transformamos la dirección de $09f4 a $096f, y como en la dirección $096f hay un ret, básicamente lo que le decimos al spectrum es que cada vez que tenga que escribir un byte en pantalla lo haga mediante una rutina vacía (sólo tiene un ret) en lugar de la rutina PRINT-OUT.

[Hark0]

En realidad es

Código: Seleccionar todo

POKE 23739,111

Pero así es como menos bytes ocupa en un cargador:

Código: Seleccionar todo

POKE VAL "23739", CODE "o"

Siempre apurando.... jejejejeje

[Hark0]

Para los que tengáis curiosidad:
Entre $5cb6 y $5cca se guarda la información de los canales, que por defecto es una copia de estos valores en ROM, pero que se puede modificar:

Código: Seleccionar todo

L15AF:  DEFW    L09F4           ; PRINT-OUT
        DEFW    L10A8           ; KEY-INPUT
        DEFB    $4B             ; 'K'
        DEFW    L09F4           ; PRINT-OUT
        DEFW    L15C4           ; REPORT-J
        DEFB    $53             ; 'S'
        DEFW    L0F81           ; ADD-CHAR
        DEFW    L15C4           ; REPORT-J
        DEFB    $52             ; 'R'
        DEFW    L09F4           ; PRINT-OUT
        DEFW    L15C4           ; REPORT-J
        DEFB    $50             ; 'P'

        DEFB    $80             ; End Marker

En concreto la dirección 23739 es $5cbb que se corresponde al byte bajo de la rutina PRINT-OUT del canal 'S' (screen o pantalla). Al hacer el poke transformamos la dirección de $09f4 a $096f, y como en la dirección $096f hay un ret, básicamente lo que le decimos al spectrum es que cada vez que tenga que escribir un byte en pantalla lo haga mediante una rutina vacía (sólo tiene un ret) en lugar de la rutina PRINT-OUT.

OLÉ!!!



¿Esta información está sacada del tochete Complete ROM Disassembly?
¿Hay algún libro y/o documento más "clarito"?

He encontrado este fichero... me lo he enviado a mi dropbox, porque creo que es interesante...

http://www.ssir.com.ar/VariablesZXSpectrum.pdf



Saludos

[wilco2009]

En realidad es

Código: Seleccionar todo

POKE 23739,111

Pero así es como menos bytes ocupa en un cargador:

Código: Seleccionar todo

POKE VAL "23739", CODE "o"

Esto me deja intrigado ya que desde el desconocimiento no parece muy lóigico y mirando la forma de codificación que tiene el Sinclair Basic he visto que los números los almacena duplicados, primero el valor tal y como se escribe como si fuera un texto("23739" = 5 bytes) más otros 5 bytes para el valor en coma flotante.
Me pregunto qué se había tomado Sir Clive para codificar esto de una manera tan poco eficaz, siendo que podía codificar y decodificar el número cada vez que editamos la línea. Teniendo en cuenta la economía que se usa en la máquina para casi todo, al menos esto llama la atención.

[Hark0]

En realidad es

Código: Seleccionar todo

POKE 23739,111

Pero así es como menos bytes ocupa en un cargador:

Código: Seleccionar todo

POKE VAL "23739", CODE "o"

Esto me deja intrigado ya que desde el desconocimiento no parece muy lóigico y mirando la forma de codificación que tiene el Sinclair Basic he visto que los números los almacena duplicados, primero el valor tal y como se escribe como si fuera un texto("23739" = 5 bytes) más otros 5 bytes para el valor en coma flotante.
Me pregunto qué se había tomado Sir Clive para codificar esto de una manera tan poco eficaz, siendo que podía codificar y decodificar el número cada vez que editamos la línea. Teniendo en cuenta la economía que se usa en la máquina para casi todo, al menos esto llama la atención.

Pues ya somos dos... hay cosas que las entiendo y las veo muy lógicas en lo que se refiere a estructura y organización del ZX... y otras que no entiendo un pimiento...

[antoniovillena]

No la he sacado de ningún libro. Directamente me he puesto a mirar el código (disponible en la página de Geoff Wearmouth http://www.wearmouth.demon.co.uk/) que ya he usado para varios proyectos. Pero sí, ese libro es una buena referencia para entender cómo funciona la ROM.

En cuanto a la eficiencia es relativo. El intérprete basic guarda cada valor numérico en sus dos formas (la decimal en ASCII y la binaria en formato coma flotante de 5 bytes). Si escribes "PRINT 1" ese uno lo transformará el intérprete en 31 0e xx xx xx xx xx, es decir 7 bytes, donde 31 es el 1 en ASCII, 0e es el separador, y xx .. xx es el número codificado en coma flotante. Si prescindiéramos de la representación binaria, la ejecución sería muy lenta, porque cada vez que el intérprete se encuentre con una constante tendría que pasarla de decimal a binario. De esta forma, este paso se hace una sola vez, exactamente cuando tras teclear la orden pulsamos intro. Se podría guardar solo la parte binaria pero entonces no sabemos lo que escribió el usuario exactamente (los valores 1e3 y 1000 dan el mismo resultado).

Por cierto VAL "23739" ocupa 8 bytes, se podría hacer con 7 (y sin perder velocidad) poniendo cualquier número de un dígito seguido de la representación binaria del 23739. El problema sería que al editarlo se pierde el valor, pero como normalmente los cargadores no se editan se podría hacer.