I've read through most of two assembler books: "Mastering Assembler" and "Creative assembler for the BBc Micro".

In the Mastering assembler book, there is a chapter on sprite handling (Chapter 10) which demonstrates plotting a sprite in Mode 2. It explains that Mode 2 is the simplest mode to work with. I almost understand the reasoning - essentially amounting to being able to shuffle data around a byte per time. By moving at a byte per time, one can move a sprite two pixels at a time (to left or right), because in Mode 2, each byte in screen memory represents two pixels (correct??)

Code below is extract from the Mastering Assember book Chapter 10. It goes through plotting a sprite in BASIC (by poking bytes in screen memory) before turning this into assembly later.

My brain has melted in trying to understand how the hex values correlate to coloured pixels in the DATA statements. If each byte is two pixels, and first byte is top left of sprite.. how does 0C come to represent green pixel, green pixel???
I've looked through BBC advanced user guide which somewhat tersely describes logical and physical colours as per video ULA (again a bit of mind bender) which states each logical colour is to be EORed with 7. But applying this to the data statements still doesn't make sense.

Can anyone shed any light on how to poke pixels directly to the screen in mode 2, whilst explaining how to specify the colour I want each pixel to be????

I think understand the screen layout of mode 2 (which some of code below aludes to) .. ie where to plot pixels.. it's how to plot desired colours per pixel in a given byte that's blowing my mind.

Any help on this would be much appreciated.

Thanks.
jbnbeeb

The Beeb uses a weird interleaved bit format to represent pixels within a byte.

In MODE 2, it's like this (warning: dodgy ASCII art):



So bits 1, 3, 5 and 7 are a 4 bit value which represents the left pixel colour; and bits 0, 2, 4 and 6 are a 4 bit value which represents the right pixel colour.

To go back to your example, hex 0C in binary looks like this:

00001100

so bits 7, 5, 3 and 1 contain binary 0010 (left pixel)
and bits 6, 4, 2 and 1 contain binary 0010 (right pixel)

0010 = 2 in decimal = green.

Thanks so much for clearing that up! It was driving me mad trying to work this out! Foolishly, I was starting with the premise that bits 7,6,5,4 = left pixel value and 3,2,1,0 = right pixel value.

With your explanation and ascii art I can now make more sense of Appendix F of Advanced user guide.

Thanks,
jbnbeeb