Best way to "rotate" the graphics.spin bitmap

Mag748

Hello,

I am in need of a fast (asm) way to convert the row data in the graphics.spin bitmap to monochrome bytes containing column information. For example, the first column/first row pixel of the bitmap will get mapped to the LSB of the first byte of the new array. The second column/first row pixel of the bitmap will get mapped to the LSB of the second byte in the array, etc. I would do this for the 16 pixels in the first row of the current tile. Then, moving to the second row, map all those pixels to the LSB+1 of each byte in the new array. After I've passed over the tile and the new array is complete, I send it to the display I'm working with.

I've started work on the ASM driver, but before I keep going I want to make sure there isn't an obviously simple solution. Currently my idea is to transfer 1 tile worth of bitmap data to the cog and convert it into a new array in cog ram, then send to out to the display and start over with the next tile.

If anyone has any suggestions, I'd appreciate it.

Thanks,
Marcus

Beau Schwabe

Is this for a ticker tape effect? ... If so, I have something that sort of works that way, but I won't be able to dig it up until tomorrow (May 1st) night ( in flight to Rocklin )

Mag748

No, the specific display I'm working with requires its data to be formatted this way. The GDDRAM is organized in horizontal pages. See the images below.

Horizontal memory access

- OR -

Vertical memory access

byte arangment

Thanks,
Marcus

Beau Schwabe

Ahh, that's a bit more pixel manipulation than just a scrolling ticker tape effect.

lonesock

Here is something similar, but you still have your work cut out for you. This is a driver for ST7565P, and I just added a function that takes data from a graphics.spin memory block and converts it to 1bpp monochrome. The difference is this display uses "fat rows", where 1 byte = 8 vertical pixels, then the next byte = the next 8 pixels to the right of that. Anyway, I hope this helps somewhat. (look for the 'transform_data' PASM routine.)

Jonathan

Mag748

lonesock wrote: »

Here is something similar, but you still have your work cut out for you. This is a driver for ST7565P, and I just added a function that takes data from a graphics.spin memory block and converts it to 1bpp monochrome. The difference is this display uses "fat rows", where 1 byte = 8 vertical pixels, then the next byte = the next 8 pixels to the right of that. Anyway, I hope this helps somewhat. (look for the 'transform_data' PASM routine.)

Jonathan

Dear Jonathan,

I've looked over your submission and I believe that what you have provided is exactly what I am trying to do. The only difference between what you have done and what I was planning on doing was that I was going to read in a whole block of 8 longs from the graphics bitmap into a cog ram array, then work through those 8 longs to get the 16 column bytes to the display ram. I would do this in a loop by acting only on the cog RAM. This way, I'm only reading from the HUB ram to get the graphics bitmap once, and only writing to the HUB ram to place the display bitmap once. Your method reads the graphics bitmap once and reads as well as writes the HUB display bitmap eight times. It might not be necessary to save the few cycles from not having to access HUB Ram, but I though it would be worth it. I am not sure how many times your function would be able to complete in a second. Do you have any idea? I'm looking to get at least 60FPS. Anyway, your loop structure is very organized and I will use this as a starting point for my function.

I greatly appreciate your help.

Thanks,
Marcus

lonesock

Cool.

Including the Spin waiting loop, it takes about 414000 clocks, so if running at 80 MHz that gives you about 190 Hz.

Jonathan