slenkar Wrote:I would like to mirror UDG,
does the mirroring function alter the stored image or create a new one?
I think altering the stored image would be best for most uses
It doesn't do either - it's a function. I think you misunderstand what a function does - it takes a parameter and has a return value.
For example, in Sinclair Basic, CHR$ is a function. It takes a number, and returns a string character. So you do CHR$(65) - sending it 65, and it comes back with "A" as a string. This is why PRINT CHR$(65) prints out "A" on the screen.
The mirror function I listed above is the same thing - it takes one number, and returns another number, such that the bits in the first number are a mirror image of the bits in the second.
Let's use the same number as an example. In Binary, the number 65 is '0100 0001'. So mirrored, that would be '1000 0010' right?
If you do PRINT mirror(65), it prints 130 - which is the decimal equivalent of '1000 0010'
This doesn't change your UDG at all, but it can be the basis of /making/ a udg that's mirrored from another one.
For example, to mirror a udg in place:
Code:
for i=USR "A" to USR "A" +7
poke i, mirror(peek i)
next i
Would probably work. It reads the byte with peek, sends it to mirror, and what comes back from mirror is poked back into the byte again. (Note that with the default graphic of "A" in the UDG A slot, this won't be very obvious, since a left-right mirrored Capital A looks identical before and after). I'm quite certain an assembler version SUB for this could be much better.
In a similar way, vertical reflection means swapping the byte order, so you need somewhere to put them temporarily:
Code:
DIM buffer (7) as uByte
for i = 0 to 7
let buffer (7-i) =peek (USR "A" +i)
next i
for i = 0 to 7
poke (USR "A" +i), buffer(i)
next i
(The code is all off top of my head and untested. Again, an assembler subroutine would be much faster)