Fwd: Re: [Aspectrum-devel] Nueva version.

[Kak <jb...@ti...>]

lo siento, pero estoy hasta los webos de esta mailing list que no=
 
mete el nombre de la mailing antes que el nombre del que lo=
 envia! :)

On Thu, 10 Oct 2002 18:39:09 +0200, Kak wrote:
>On Wed, 9 Oct 2002 11:40:19 +0200, Alvaro Alea wrote:
>
>>Otro detalle que habria que valorar es si a Kak le afecta mucho=
 el
>>no usar allegro, con respecto a zxdeb
>
>por eso no te preocupes, es cuestion de tirar palante el=
 proyecto
>aspectrum y yo ya me espavilare en ese aspecto :)
>tampoco me molestaria continuar con una "rama paralela", ya que=
 de
>hecho muchas de estas cosas las hago para aprender, e ir=
 haciendo
>cosas por mi mismo tampoco me matara ;)
>
>>Aun asi a mi me siguen sobrando 3560 estados T despues de la=
 int
>>para que
>>todo salga como debe, si lo hago todo segun el FAQ el horizonte=
 del
>>aquaplane
>>me sale 16 pixels mas abajo.
>
>a ver, en el faq de css dice:
>
>After an interrupt occurs, 64 line times (14336 T states) pass
>before
>the byte 16384 is displayed. At least the last 48 of these are
>actual
>border-lines; the others may be either border or vertical=
 retrace.
>
>Then the 192 screen+border lines are displayed, followed by 56
>border
>lines again.
>
>-
>o sea: se genera la interrupcion (supongamos que se hace en el
>t-state 0) Entonces pasan 64 lineas entre retrace y borde, y
>entonces
>se empieza a pintar a partir del primer pixel de pantalla.
>entonces pasan 192 lineas, y vienen 56 mas de borde otra vez
>
>(56+192+64) * 224 =3D 69988
>-
>
>Now for the timings of each line itself: define a screen line=
 to
>start with 256 screen pixels, then border, then horizontal=
 retrace,
>and then border again. All this takes 224 T states. Every half=
 T
>state a pixel is written to the CRT, so if the ULA is reading=
 bytes
>it does so each 4 T states (and then it reads two: a screen and=
 an
>ATTR byte). The border is 48 pixels wide at each side. A video
>screen
>line is therefore timed as follows: 128 T states of screen, 24=
 T
>states of right border, 48 T states of horizontal retrace and 24=
 T
>states of left border.
>
>o sea, se pintan 256 pixels (de la pantalla). Despues viene el=
 borde
>derecho, despues el horizontal retrace, y despues el borde=
 izquierdo
>de la siguiente linea
>
>entonces, para la emulacion del port 0xff, lo que nos ocupa=
 (creo),
>lo correcto seria hacer tstate actual % TSTATES_PER_LINE, y si=
 es
><128 entonces retornar un valor aleatorio, y si no es <128,=
 retornar
>FF
>
>
>
>
>
>>
>>>yo diria que los calculos (dejando a banda el error ese de=
 los
>>>24/48)
>>>estan bien, y incluso con ese error, el resultado a la hora=
 de
>>>pintar
>>>no deberia diferir, ya que no usamos para nada el 24/48, sino=
 que
>>>usamos el TSTATES_PER_LINE.
>>>entonces el que estaria mal emulado por culpa del 24/48 seria=
 el
>>>port
>>>0xff
>>
>>no me aclaro.
>bueno, la explicacion correcta esta arriba :) diria que ahora=
 es
>correcta y exacta... espero! xD
>
>Bye :)
>Kak
>