Formato de los bits en memoria de vídeo en modo 1

[joaquinferrero]

En la columna de la izquierda, se representan los cuatro píxeles que 1 byte puede representar en pantalla.

Cada uno de esos píxeles muestra (entre paréntesis) un par de bits, así (MSB LSB), y a la derecha está indicada la posición de esos bits dentro del byte de memoria.

Es en la columna de la derecha que se observa que están intercambiados el orden de los bits, poniendo los menos significativos a la izquierda de los más significativos.

Consultando diversa documentación ( http://www.cpcmania.com/Docs/Programming/Painting_pixels_introduction_to_video_memory.htm ) pero, sobre todo, el propio código de la subrutina, se observa que el orden debe ser al revés: los bit más significativos deben estar a la izquierda de los menos significativos.

Se propone una reedición de esa parte de la documentación.

[lronaldo]

Hi @joaquinferrero

I will write in English just to maintain the default language accesible for all members of the international community in this discussion :). No problem with your message being in spanish for me :).

I think you are confused, as the documentation in cpcmania.com you refer to is erroneous. I also had initial confusion with that documentation until I tested it by myself. If you use current CPCtelera documentation to construct pixels and write them direcly to video memory with an emulator, you get expected colour values. For instance, if you write 0x80 to a byte in video memory, you get the first pixel coloured yellow (color 1, 0b01) which means that the leftmost bit is the LSbit of the pair that forms the first pixel, and not the other way around.

The confusion with the values of the table is easy to make, as the values in the table are shifted exactly 4 bits to the right, as the algorithm iterates 4 time (1 per pixel) and rotates bits left by 1 each time. Therefore, the table at the end becomes 0x00, 0x80, 0x08, 0x88, as expected by the order actually present in the documentation.

Please, do check this statements with the emulator to verify they are correct. I have done a quick test to check for 1 pixel, and the function has been used for a long time with no apparent problems. I understand there is a low probability of this information being erroneous but, as always, no probability is ever 0 :).

Thank you for your review, either the case :)

[joaquinferrero]

Okay, I've checked with the emulator that what the px2byteM1 doc says is correct, as well as the info on cpc-live.com, not cpcmania.com, so the pull-request can be disregarded.

But then, I don't understand how the table at the end works, since it's in this order:

pen2mode1px: .db 0x00, 0x08, 0x80, 0x88

That is, if we pass an "pen 1" down the stack to see a yellow pixel (the color of pen 1 by default), px2byteM1 transforms it to 0x08, when it should be 0x80.

[joaquinferrero]

Ok, I've seen it...

The table is actually shifted one bit to the right because an rlca (shift left) is going to be performed to "push" those bits.

Perhaps it would be good to expand the comments a bit... as the table is arranged, it confuses the order until you realize that they must be displaced.

[lronaldo]

Yes, of course. Expanding comments in a way that can clarify doubts is always a good idea. If you find a good way to fit new comments so to improve explanations, you are more than welcome :).

There's never enough good explanations to convey detailed and important messages :)