tag:blogger.com,1999:blog-1094715945364929106.post3971903591548369219..comments2024-01-02T12:34:30.507+01:00Comments on Poor Man's Pinball!: Shades of Sanityrasmadrakhttp://www.blogger.com/profile/15811309356939122577noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-1094715945364929106.post-72540327116688040942012-01-17T23:52:52.797+01:002012-01-17T23:52:52.797+01:00Great Project!
I love pinball dot matrix displays...Great Project!<br /><br />I love pinball dot matrix displays and have worked on many projects controlling them. I usually go down the FPGA route for speed!!! but recently got it working with a LPC2103 micro controller.<br /><br />Keep up the good work!!!!Russell Piriehttp://www.youtube.com/Is200Innitnoreply@blogger.comtag:blogger.com,1999:blog-1094715945364929106.post-53681680161208468572011-08-18T11:10:25.515+02:002011-08-18T11:10:25.515+02:00At the moment I'm using either hardcoded array...At the moment I'm using either hardcoded arrays or my text-to-sprite function that I've written. It's not beautiful, but it works good enough for testing. :)<br /><br />The freeware graphics program GIMP can output c++ headers from graphics files, so I might be using this in the future. Or simply write my own function (on a standalone computer) to create the arrays the way I want them.<br /><br />Since I've begun migrating to also be using a Chipkit Max32 I've probably got more than enough flashdisk to store all animations without an external flashdrive. In theory, at least...<br /><br />It would be really sweet however to read directly from flash to display, let me know if you have any progress with this! :)rasmadrakhttps://www.blogger.com/profile/15811309356939122577noreply@blogger.comtag:blogger.com,1999:blog-1094715945364929106.post-57923910406108706772011-08-18T04:06:11.728+02:002011-08-18T04:06:11.728+02:00It seems you are making great progress. I'll b...It seems you are making great progress. I'll be watching with interest.<br /><br />For the clock I plan to have the images consist of a series of bit-planes. So for a 16 level gray-scale image there would be 4 planes, each of 16384 bits. At this stage I'm not sure if I will shoot for 16 levels, 4 may be enough.<br /><br />The downside of bit-planes is that horizontal scrolling of pixels requires bit shifts instead of the byte copies you can do with chunky pixels but at least you are effectively moving multiple pixels in each plane per shift. <br /><br />If I end up using sprites I also plan to pre-calculate the horizontal shifted positions of the sprites so it doesn't have to be done at runtime. <br /><br />Hopefully the use of planes also means one plane can be manipulated while another is drawn. Time will tell just how much I can get away with.<br /><br />I'm interested as to where you source your images you are using to test the display? The plan for the clock is to use an external SPI Flash ROM or SD card to store animations. it should be possible to use DMA to copy animations directly from the Flash or SD directly to the display.Tristanhttps://www.blogger.com/profile/05731291293164274522noreply@blogger.comtag:blogger.com,1999:blog-1094715945364929106.post-36621592731597446782011-08-16T09:29:29.162+02:002011-08-16T09:29:29.162+02:00It should say: "The actual drawing is now aro...It should say: "The actual drawing is now around 950 us per color with the buffer being built separately.".<br /><br />950 ns, that would be sweet! :Drasmadrakhttps://www.blogger.com/profile/15811309356939122577noreply@blogger.comtag:blogger.com,1999:blog-1094715945364929106.post-4613934540236484362011-08-16T09:12:28.282+02:002011-08-16T09:12:28.282+02:00Cool project btw! :)Cool project btw! :)rasmadrakhttps://www.blogger.com/profile/15811309356939122577noreply@blogger.comtag:blogger.com,1999:blog-1094715945364929106.post-19893671603827837742011-08-16T09:11:42.398+02:002011-08-16T09:11:42.398+02:00Hi there!
Yes, I realized this as well. In the ne...Hi there!<br /><br />Yes, I realized this as well. In the new version I made a separate buffer that gets incrementally built and then drawn "no questions asked". It also uses the double buffer concept where it keeps drawing one frame until the next is finished and then gets swapped. The actual drawing is now around 950 ns per color with the buffer being built separately.<br /><br />But I ran out of RAM. :)<br />So the next step is ordering a beefier MCU (Chipkit Max32) that is almost out-of-the-box compatible with Arduino. This allows me to do multitasking as well, with the display and lights running on a separate MCU.<br /> <br />How would you solve different colors inside one object with your version? I figure you would have to create different layers for each color and object?<br />The main benefit with my version is that it allows me to use a single input buffer with lots of color and/or additional data in the spare bits of the image.rasmadrakhttps://www.blogger.com/profile/15811309356939122577noreply@blogger.comtag:blogger.com,1999:blog-1094715945364929106.post-69373438867586420122011-08-16T03:45:27.355+02:002011-08-16T03:45:27.355+02:00It looks like you are effectively doing the fairly...It looks like you are effectively doing the fairly costly bitmap to planar conversion on the fly. Is there any reason you can't convert you graphics to planar format in advance? This would allow you to copy data directly from your buffer to the SPI peripheral without all the bit shuffling. I'm working on a similar project (https://sites.google.com/site/tristansideas/electronics/pinball-display-clock/) using planar graphics and DMA to copy directly to SPI.Tristanhttps://www.blogger.com/profile/05731291293164274522noreply@blogger.com