Gray experiment utility

Libraries, utilities, bootloaders...

Re: Gray experiment utility

Postby erico » Wed Dec 24, 2014 1:10 am

He posted info to look for when we discussed pixel aspect ratio. Im really not a hardware guy to understand how this all fits together but i have a hunch from my line of work that those speeds are somehow always a float? Interesting stuff I'd wish I was home now to check.

Edit: i sure will take a looj as i get to hq... me loves screen refresh speed ;)
User avatar
erico
 
Posts: 671
Joined: Thu Mar 27, 2014 9:29 pm
Location: Brazil

Re: Gray experiment utility

Postby Drakker » Wed Dec 24, 2014 1:44 am

When I looked around the net for the exact refresh rate last summer I found wild speculations ranging from 30 to 55hz. I also found some official documentation on the display and there was no mention of refresh rate or any sort of timing in there. The answer is probably out there... somewhere.
User avatar
Drakker
 
Posts: 297
Joined: Sun Mar 30, 2014 2:54 am
Location: Québec, Canada

Re: Gray experiment utility

Postby Myndale » Wed Dec 24, 2014 2:58 am

I determined the refresh rate to be ~41 FPS experimentally based on the first Gamebuino device Rodot sent me. At 40 the flicker scrolled one way, at 42 it went the other. 41 wasn't perfect but it was pretty close and I assumed that it was the refresh rate of the internal MUX circuitry. One thing I did notice was that flicker-free greyscale seems to be extremely sensitive to timing. The execution timing of the Gamebuino library's update() function is very inconsistent due to way it works and resulted in a lot more flicker than what I observed in my standalone tests.

For reference, the 5110 uses a PCD6544 controller internally, the data sheet of which is here:

https://www.sparkfun.com/datasheets/LCD ... ia5110.pdf

The only thing that slightly resembles 41 FPS in that document are the recommended MUX rates for the various bias voltages, but nothing matches what I observed experimentally.

So yeah, all a bit of a mystery really.
Myndale
 
Posts: 507
Joined: Sat Mar 01, 2014 1:25 am

Re: Gray experiment utility

Postby rodot » Sun Jan 18, 2015 9:09 pm

I just tryed your gray experiment (sorry I'm late on this topic hehe), the small checker looks pretty good and constant on a large range of FPS (15 and up). I only tried the filled method before, that's why I gave up on gray.
If tried it on 3 Gamebuino from different batches, and found a refresh rate of 40.5Hz, 45.5Hz and 46Hz.
On one of the Gamebuino the gray looks "dirty" (left on on the picture) and on another one there is some slight banding (center on the picture), but it should be OK if gray is only used for sprites, not for large surfaces.
The darkness of the gray really depend on the contrast setting. I will change the settings.hex program for it to display a small checker pattern while adjusting contrast.

2015-01-18 22.05.17.jpg
2015-01-18 22.05.17.jpg (180.06 KiB) Viewed 6910 times
User avatar
rodot
Site Admin
 
Posts: 1290
Joined: Mon Nov 19, 2012 11:54 pm
Location: France

Re: Gray experiment utility

Postby Drakker » Sun Jan 18, 2015 10:16 pm

Just so you know, I discovered since then that the banding is most likely caused by badly synchronized refresh. With the old drawBitmap function it takes more than 100% CPU to draw the whole screen, it is especially visible in Simbuino. So the app in the currently posted version is probably wrong. I would suggest that you either recompile it with the new fast drawBitmap functions or that you make it draw in a smaller area (1/4th of the screen seemed Ok with the old drawBitmap function at 40fps).
User avatar
Drakker
 
Posts: 297
Joined: Sun Mar 30, 2014 2:54 am
Location: Québec, Canada

Re: Gray experiment utility

Postby Drakker » Fri Jan 23, 2015 4:36 pm

I have uploaded a new version of the utility. I compiled it using the beta branch of the library. There is some speed increase in the drawing, but when displaying the status it still gets over 100% usage at 41 fps. To work around this, you can press the B button to hide the status display, which lowers the CPU usage by roughly 30-40% depending on the name of the gray (longer string = more CPU usage).

I also added a light gray color and a dark gray color. Light gray has pixels drawn every 4th frame in a somewhat checkered pattern. The same is true for dark gray, but it draws 3 pixels every frame. I made a composite display with all shades of gray along with white and black.

I coded this on the bus this morning and don't have a Gamebuino with me, so I can't comment yet on how well these shades of gray work (I don't expect them to work very well), but nonetheless, the new version is available.

I said earlier that displaying strings seemed to not use very much CPU at all, well, I was very wrong. It does use a lot of CPU power. I have no idea if it is possible, but could the strings display function be improved with the same treatment the drawBitmap function got?

The status display now shows the CPU usage for odd and even frames. This shows that checkered gray comes at a price. The regular gray uses a lot of CPU power on one frame and none on the other, so this extra CPU every other frame could be put to good use. Of course, when displaying small sprites, you will be drawing some every frame anyway, so that extra CPU usage will not be available and checkered gray is probably better.

I have noticed a weird behaviour with my grid pattern, it uses more CPU on one frame than the other, yet both sprites are 8x8 and they are drawn the exact same way. Is there some sort of optimization going on when there are large areas of 0s or 1s? In the same vein, light gray uses a lot less CPU than dark gray and it has less pixels to display.
User avatar
Drakker
 
Posts: 297
Joined: Sun Mar 30, 2014 2:54 am
Location: Québec, Canada

Re: Gray experiment utility

Postby Myndale » Fri Jan 23, 2015 10:28 pm

The original function calls drawPixel which takes 215 cycles for every black pixel. I debated whether or not to make the drawBitmap speed constant for all pixels when I was optimizing it but ultimately decided that raw speed was probably more important. The version I posted yesterday uses 3 clock cycles if a pixel is white and 8 cycles if it's black, so there's still a difference but it's significantly reduced and the loop mechanics help reduce it further.

Incidentally the way I test the LCD mux rate myself is to alternate between a full-frame of black and a full frame of white and I try drawing it at double the expected rate ie. around 85fps. If the rate is exactly double then in theory that should show one solid color. In reality you get a band moving slow up or down the screen, and as Rodot has reported my 3 Gamebuinos also seem to have differing refresh rates between 41 and 43fps.
Myndale
 
Posts: 507
Joined: Sat Mar 01, 2014 1:25 am

Re: Gray experiment utility

Postby Drakker » Sat Jan 24, 2015 1:44 am

Maybe we should create a list of displays and their quirks based on serial numbers so we could have a rough idea of how many batches there are and maybe optimize for them. Is it possible to get the serial number of a display via software?
User avatar
Drakker
 
Posts: 297
Joined: Sun Mar 30, 2014 2:54 am
Location: Québec, Canada

Re: Gray experiment utility

Postby rodot » Sat Jan 24, 2015 1:54 pm

Hey,
I just added the gray color using the alternating checker pattern to the Gamebuino library. I also improved the settings for better contrast adjustment. Thanks for your experiments Drakker ! :)
Edit : it's on the beta branch of the Gamebuino library
User avatar
rodot
Site Admin
 
Posts: 1290
Joined: Mon Nov 19, 2012 11:54 pm
Location: France

Previous

Return to Software Development

Who is online

Users browsing this forum: No registered users and 27 guests

cron