All I had to do was change the pin definitions and I was off and rolling.
I tweaked the EnableTime to 15 for my particular PH8 display.
I was thinking just now. if the final output array and gamma table was increased to 10 bits per pixel (8 whole, 2 fraction), then we could reclaim some of the lost color on the low end? But this might only be for a nighttime or indoor mode, as in daylight outside you need to blast the brightness to compete with the sun. Plus more memory chewed up and lower refresh rate.
Where does the refresh rate stand right now?
EDIT: I went ahead and tried it. no way. 10 bpp gamma corrected has too slow of a refresh. scratch that idea. it looks fine as it is.
Also, I think it's really clever the way the pins are precalculated. Is it a true statement that with some minor recoding, half the memory would be required for the output buffer if the defined pins were always at 15 or below? I know that's probably too debilitating to consider.
Rayman: p.s. I hope my return PM to you a few weeks ago didn't get eaten. It shows I replied, but the message wasn't in the saved list.
whicker, Thanks for trying it out! Glad to hear it's working for your.
I didn't actually measure the refresh rate, but that's a good idea.
The gamma adjustment does take away the contrast at low levels... That could be a problem when trying to show a very dark image. But, then we could do like they do on TVs and do "dynamic contrast". Basically, we'd multiply all the pixel values by 4 say and then use "EnableTime" to dial down the brightness by a factor of 4 to compensate.
But, I'm trying to keep things simple right now...
Another option is to use more cogs to get more bits. I think I can easy run 2 or 3 cogs in parallel to increase throughput. But, I'm mostly going to use that approach as a way to increase the number of screens that can be driven.
I did get a PM from you before. Just one though, no reply.
You're right that I could make the output a word array and save space. But, my evil plan is to support several displays in parallel/series combination.
I think I could easily do 3 in parallel with 3 in series for a 96x48 pixel array, keeping 24bpp.
By dropping to say 16bpp, I believe a single Prop could control a very, very large display...
Cool, I wasn't thinking that the row pins could obviously be shared in the Y direction as well as the X direction with your implementation. Just 6 more pins, and maybe a separate ENABLE if module brightness doesn't match.
Yeah. Lots of displays is nice. I've got the bug to buy a few more...
Just a quickie,
As a default you probably want to set default brightness to 256.
because in PUB RGB(r, g, b) you divide by 256.
That way it gives the expected first 28 pixels completely black in Test6.bmp
Thanks for catching that! I just fixed it and uploaded a new one. I really wanted to divide by 255, but made it 256 so that it'll be faster in assembly...
A seperate enable wouldn't work in all cases because I want to support daisy-chaining the displays...
But, I hadn't considered the possibility that the displays might not be equally bright. It's a good point.
I suppose the easiest way is to have a "brightness" factor for each panel.
BTW: There are 3 resistors on the panel that I still haven't figured out what are used for... Perhaps they are individualized brightness adjustments...
Anyway, I have 4 panels, I'll have to check if they all have the same brightness...
Moving forward again with development for these panels...
Want to improve the driver draw speed and also allow for multiple panels.
Just did some current measurements (details here) and the good news is that the driver
is linear with enable time and brightness and number of pixels turned on.
I think that means everything is working right. Also, I can drive multiple
panels with my power supply by just turning down the enable time (brightness).
To help with the wiring challenges of hooking up multiple displays, I've come up
with this shield for Propeller Platform. It should allow up to six chains of panels to be connected.
The current driver should easily allow up to six panels to be driver at once either three chains of two in series or six in parallel.
There are two assembly drivers now.
One constantly refreshes the screen with the precalculated output.
The other one does things like set pixels, draw text and bitmaps.
It can now update the screen with a bitmap at something like 100Hz.
I've got a demo that drives 3 panels from one Prop Platform USB.
It scrolls a 24bpp bitmap up and down on the left side
while scrolling text on the left side.
BTW: I just got some more displays, so I'm going to attempt to drive 6 panels from 1 Prop Platform USB now...
Think I'll go for a 96x32 pixel array although I was contemplating 64x48 to give a TV aspect ratio...
32 pixels tall though will be nice for scrolling the Propeller ROM font...
Adafruit told me about this thread (http://forums.adafruit.com/viewtopic.php?f=47&t=25955&sid=ab69cf917629fcf7fafa826369b705a0&p=133534#p133534) as I am wanting to get back into LED displays again being a long time SX-28/48 designer in SX/B. I have seen many Prop projects but have been out of the microcontroller scene for over a year due to a job loss and now re-establishing myself again as a Test Engineer (been working for 6 months). Anyway, I am very interested in the Adafruit 16x32 RGB or 32x32 RGB LED matrix they sell. I have a little Arduino experience but really no Propeller experience. The work you and others have done on this thread is outstanding. I am deciding to either go with a Arduino MEGA 2650 or Propeller or maybe learn FPGA's (looks really hard!). Having a long standing passion working with other Sure Electronics RG LED displays for 8 or so years and developing a couple of RGB designs with the HT1632C chip, I want to get back into the field again.
Where can I get started like you did to start with one 16x32 and eventually go up to 6 displays or more? I saw in the pictures that your propellor board had some sort of a 6 IDC cable shield on it. Was this custom made by you for this Adafruit 16x32 RGB display or can I purchase it. Basically, what do I need to get started if I do go with the Propellor?
Tim,
Yes, that's a custom board that we came up with for the Prop Platform... Parallax and GadgetGangster sell the Prop Platform. I think Adafruit sells it too.
We did a very short run of those boards, only 3. But, I still have 2 left, if you're interested...
I think I've posted the code to do 6 panels from 1 Prop in 18-bit color or 3 panels in 24-bit color.
We've got some more info on our website...
What is the cost of the adapter board for the Prop platform that you have. You can PM me if you like or just reply back here. I will need to get a power supply too for 3-6 of the 16x32 or 32x32 displays. Sure Electronics had a 5vdc up to about 20 or 25 A but they may have discontinued it as I didn't see it. I'm starting out with nothing so I will need to get everything to start over again. Any help you can provide would be appreciated. I beleive your website listed code for 24 bpp for 3 displays not the 6 displays. Let me know what else I will need for a Propeller Prop outfitting for the RGB display.
Tim, There is an intensity setting in the code you can use to control how much current can be drawn.
I was just using a regular 3A, 5V power supply with the intensity turned way down.
At some point, I want to try using a regular PC power supply to crank it up...
You don't really need my Prop Platform "shield", you can just use jumper wires.
But, if you like I can sell one of my prototype boards for say $15. It does make it a whole lot easier to connect, you just plug in the IDC cables.
If you're interested, just send an email to ray@rayslogic.com .
You might also want a few longer IDC cables. The data cables that come with the panel are very short.
I found some on Ebay for a reasonable price.
I may have not gotten around to posting the 6-panel code. But, I can email it to you...
I think at this point after going through some Altera FPGA online course training with VHDL code structure, I'm going to take a step back (but a step forward from the Arduino) to start learning the Propeller and Rayman's code for the 32x16 RGB display. I'll start with a single display until I understand the code and the Propeller commands better before I get more displays. I still may get an Arduino but I think because of speed, I will focus on the Propeller and once well understood (with Assembly too), move on to FPGA with Verilog or VHDL. Thanks so much to Rayman and other postings as I learn about this new display and Propeller programming.
Well, that's pretty much how I started with Propeller too... I never did move on to FPGA though...
This may not be exactly the best example to start out learning with... I had to use a few tricks as 6-panel mode does push the Prop close to it's limits...
But, I did try to make it at least fairly readable...
Still, if you're brand new to the Prop, I'd recommend looking at some PE Kit examples and blink some LEDs with Spin first...
BTW: It is possible to program in C with the Prop right now using Catalina (and GCC is coming). That might not actually be a bad option for an application like this that uses up a lot of memory. But, it would take a lot of work, I think, to translate it...
When the Hydra first came out, I bought one to learn about the gaming. However, at the time, I was spending alot of my time with the SX chips and learning the new SX/B versions including 2.0. I saw how much harder SPIN was then programming in SX/B (BASIC) with the SX-28 or SX-48 chips so I stuck with the SX chips but later they went into an End of Product line for them so I stayed on with them for a while but went over to the Arduino for LED display projects. I read through the Hydra book a few years back and eventually sold it on Ebay. However, now is a good time to go back to the Propeller as I have advanced my learning from the Arduino C like language. Although I understand a Propeller 2 is being worked on (Any release date?). I will go through all of the example code I can run with the Propellor Platform and re-read as much as I can about the Propellor as far as datasheets, etc. I also did find quite a few regulated 5 vdc high current (10A+) power supplies at reasonable prices on Ebay where I will also pickup some IDC cables with longer lengths too.
I started with Basic Stamps a lot time ago, but got frustrated by all the extra stuff you needed to do anything interesting...
Anyway, if you want to stick to Basic, I think it's possible to use Bean's PropBasic... That's supposed to be as fast as Spin and also allow assembly routines.
Haven't tried it myself though.
That's right. I forgot about PropBasic. It's supposed to have many commands similar to SX/B (which is what I was used to programming) on the SX-28 and SX-48. After I try out your software and spend some time with learning the Propellor, I'm definately going to write some 32x16 RGB software in PropBasic. Thanks for the great idea! I will of course also focus my learning otherwise with SPIN and try assembler later on. I hope to make the big purchase on Friday (payday) but Adafruit doesn't have the 9vdc 1000mA power supply for the Propellor Platform (out of stock). I'd like to get everything in one place. I may have to get that and perhaps the Propeller Platform from Parallax (Is 7.5vdc, 9vdc, or 12vdc best?). Adafruit does have a 5vdc 10A power supply for the RGB display for $25 too.
I just received my 32x16 RGB display yesterday and used it with the Propeller Platform. The display is impressingly bright and I saw no evidence of ghosting as the bitmap picture scrolling and text scrolling was clean and well displayed. The Propeller does this display justice as a faster FPGA would also. Great job to Rayman's Propeller code as found on the Parallax Propeller forum. 1 to 3 displays can be run and really up to 6 can be also. I definitely plan on buying more of these displays.
Glad you got it working! You didn't even ask any software questions... I hope the shield made it easy to hook up.
Actually, I think this is something that could easily be made into a commercial product...
I bet there are a lot of small businesses that would love a low cost - open source, daylight-visible display....
Thank you so much. The sheild is great. Pop it on the Propeller Platform, plug in the IDC cable and apply power. I am still trying to understand your code (well Propeller SPIN code in general) first. Taking it slow. So far, I have been using your Adafruit Demo 1 software (used with 3 displays). I have put in the -1 code for displays 2 and 3 as I only have 1 display for the moment. I also modified it to scroll a BMP up down, left and right. Not much but never using the Propeller SPIN software, its really neat (just a little hard to put together in my head going back and forth between the main, driver and graphics programs.).
I'll have questions I'm sure but I'm trying not to bother you unless, I just can't get it.
I know the Propeller Platform is limited left to right (to 3 displays with your sheild) due to the amount of available pins/IDC sockets on your sheild. Do you think the Propeller Platform could handle it, if a new sheild could be developed for 4 displays (ie 6 outputs from P0-P3, P28-P31)? Is is even ok to use P28-P31?
Or could another set of 3 displays (or more) piggy back off IDC ports 4,5,6 on your sheild (providing 3x3 displays=9)? Can your current software handle it. Looks like all that would change is:
long OutputArray[96*8*8] '96 pixels wide, 8 bits of color, 8 segments
Just trying to see what the largest resolution is possible with the Propeller Platform. How about using a 6.25 MHz crystal for 100 MHz clock speed (or faster) if this would help?
I'm studying your code and the Propeller SPIN language manual (so much to learn!) and it's been a challenge but I'll get it eventually. Knowing when and when not to pass an address is the hardest for me (ie @balance). Your routines for text, BMP graphics, pixel displaying are great! I can manipulate them for the most part.
Let me know about adding more displays if possible with a single Propeller. How about controlling 2 Propellers somehow? I have done that before with the Parallax SX-28 chips with TX/RX commands.
I think the easiest thing to do is cut down on resolution...
This will help with the other problem, the Prop being almost of memory...
If you drop from 24 to 12 bits per pixel, you should be able to do 12 panels as 3 strings of 4 in series...
I was looking at your program Adafruit_Test8. This loads in 7 BMP files but uses slower SPIN to display them with the SetPixel method which is done correctly.
PUB ShowBitmap(pBmp)|p,x,y,i 'Show a bitmap
'This needs to be sped up with assembly code!
'Read bitmap header
p:=ReadBitmapHeader(pBmp)
'Check to make sure bitmap is correct dimensions
if biHeight<>16
return
if biWidth<>32
return
if biBitCount<>24
return
'Set all the pixels
repeat y from 0 to 15
repeat x from 31 to 0
SetPixel(x,y,RGB(byte[p--],byte[p--],byte[p--]) )
Notice the repeat x from 31 to 0 line in code.
However, your latest Adafruit_Demo3_NewYear program uses an Assembly routine:
DAT AsmShowBitmap_ 'Display a 24bpp pixel at given x and y
mov t3,#5
call #GetArgumentsSub
'arg0=address of bitmap bits
'arg1=x0
'arg2=y0
'arg3=Width
'arg4=Height
mov y1,arg2
AsmBmpLoopY
mov x1,arg1
mov t9,arg3
AsmBmpLoopX
rdbyte pixelc,arg0
sub arg0,#1
rdbyte t1,arg0
sub arg0,#1
rdbyte t2,arg0
sub arg0,#1
rol pixelc,#16
rol t1,#8
add pixelc,t1
add pixelc,t2
mov pixelx,x1
mov pixely,y1
call #SetPixelSub
add x1,#1
djnz t9,#AsmBmpLoopX
add y1,#1
djnz arg4,#AsmBmpLoopY
'all done
jmp #loop
This Assembly routine flips the image in reverse (ie Hello World BMP reads as 'dlroW olleH' and what facing the right now faces the left)
I noticed that if you change the original SPIN line repeat x from 31 to 0 to repeat x from 0 to 31 then it follows the same image flipping as your Assembly routine.
Is there any quick fix for the Assembly routine to fix it. I don't know Propeller Assembly yet and thought I would ask you.
I have attached your code (my modified code - so you can see what I mean).
Ok, yeah there may be something wrong in there...
There are actually 3 different ways bitmaps are handled, depending on if they are 24, 8, or 4 bits per pixel.
I kinda concentrated on the 4 bits per pixel routine because I wanted to embed a large text image.
The 8bpp routine is done in spin with setpixel.
It must be the 24bpp routine that's backwards.
I guess you can either fix it or flip your image on the computer...
Comments
Looking really good in fact.
All I had to do was change the pin definitions and I was off and rolling.
I tweaked the EnableTime to 15 for my particular PH8 display.
I was thinking just now. if the final output array and gamma table was increased to 10 bits per pixel (8 whole, 2 fraction), then we could reclaim some of the lost color on the low end? But this might only be for a nighttime or indoor mode, as in daylight outside you need to blast the brightness to compete with the sun. Plus more memory chewed up and lower refresh rate.
Where does the refresh rate stand right now?
EDIT: I went ahead and tried it. no way. 10 bpp gamma corrected has too slow of a refresh. scratch that idea. it looks fine as it is.
Also, I think it's really clever the way the pins are precalculated. Is it a true statement that with some minor recoding, half the memory would be required for the output buffer if the defined pins were always at 15 or below? I know that's probably too debilitating to consider.
Rayman: p.s. I hope my return PM to you a few weeks ago didn't get eaten. It shows I replied, but the message wasn't in the saved list.
I didn't actually measure the refresh rate, but that's a good idea.
The gamma adjustment does take away the contrast at low levels... That could be a problem when trying to show a very dark image. But, then we could do like they do on TVs and do "dynamic contrast". Basically, we'd multiply all the pixel values by 4 say and then use "EnableTime" to dial down the brightness by a factor of 4 to compensate.
But, I'm trying to keep things simple right now...
Another option is to use more cogs to get more bits. I think I can easy run 2 or 3 cogs in parallel to increase throughput. But, I'm mostly going to use that approach as a way to increase the number of screens that can be driven.
I did get a PM from you before. Just one though, no reply.
You're right that I could make the output a word array and save space. But, my evil plan is to support several displays in parallel/series combination.
I think I could easily do 3 in parallel with 3 in series for a 96x48 pixel array, keeping 24bpp.
By dropping to say 16bpp, I believe a single Prop could control a very, very large display...
Yeah. Lots of displays is nice. I've got the bug to buy a few more...
Just a quickie,
As a default you probably want to set default brightness to 256.
because in PUB RGB(r, g, b) you divide by 256.
That way it gives the expected first 28 pixels completely black in Test6.bmp
Thank you for making this driver.
But, I hadn't considered the possibility that the displays might not be equally bright. It's a good point.
I suppose the easiest way is to have a "brightness" factor for each panel.
BTW: There are 3 resistors on the panel that I still haven't figured out what are used for... Perhaps they are individualized brightness adjustments...
Anyway, I have 4 panels, I'll have to check if they all have the same brightness...
Want to improve the driver draw speed and also allow for multiple panels.
Just did some current measurements (details here) and the good news is that the driver
is linear with enable time and brightness and number of pixels turned on.
I think that means everything is working right. Also, I can drive multiple
panels with my power supply by just turning down the enable time (brightness).
To help with the wiring challenges of hooking up multiple displays, I've come up
with this shield for Propeller Platform. It should allow up to six chains of panels to be connected.
The current driver should easily allow up to six panels to be driver at once either three chains of two in series or six in parallel.
There are two assembly drivers now.
One constantly refreshes the screen with the precalculated output.
The other one does things like set pixels, draw text and bitmaps.
It can now update the screen with a bitmap at something like 100Hz.
I've got a demo that drives 3 panels from one Prop Platform USB.
It scrolls a 24bpp bitmap up and down on the left side
while scrolling text on the left side.
It's hard to get a good photo, but here's my try:
Here's a video:
http://www.youtube.com/watch?v=sZywiOOGPkM
http://www.rayslogic.com/propeller/Programming/AdafruitRGB/AdafruitRGB.htm
Also, you can see how I've mounted the panels to rails to keep them secure.
Well done!
BTW: I just got some more displays, so I'm going to attempt to drive 6 panels from 1 Prop Platform USB now...
Think I'll go for a 96x32 pixel array although I was contemplating 64x48 to give a TV aspect ratio...
32 pixels tall though will be nice for scrolling the Propeller ROM font...
The display is now 96x32 pixels:
I'm now using the 96x32 array as a XMAS sign in a window:
http://www.youtube.com/watch?v=r6GopfD5aZE
(I don't know why it's so hard to get a good video or photo of the array...)
The text is really red, don't know why it shows up yellow on camera...
Adafruit told me about this thread (http://forums.adafruit.com/viewtopic.php?f=47&t=25955&sid=ab69cf917629fcf7fafa826369b705a0&p=133534#p133534) as I am wanting to get back into LED displays again being a long time SX-28/48 designer in SX/B. I have seen many Prop projects but have been out of the microcontroller scene for over a year due to a job loss and now re-establishing myself again as a Test Engineer (been working for 6 months). Anyway, I am very interested in the Adafruit 16x32 RGB or 32x32 RGB LED matrix they sell. I have a little Arduino experience but really no Propeller experience. The work you and others have done on this thread is outstanding. I am deciding to either go with a Arduino MEGA 2650 or Propeller or maybe learn FPGA's (looks really hard!). Having a long standing passion working with other Sure Electronics RG LED displays for 8 or so years and developing a couple of RGB designs with the HT1632C chip, I want to get back into the field again.
Where can I get started like you did to start with one 16x32 and eventually go up to 6 displays or more? I saw in the pictures that your propellor board had some sort of a 6 IDC cable shield on it. Was this custom made by you for this Adafruit 16x32 RGB display or can I purchase it. Basically, what do I need to get started if I do go with the Propellor?
Thanks so much for your help!
Tim Gilmore (tdg8934)
Yes, that's a custom board that we came up with for the Prop Platform... Parallax and GadgetGangster sell the Prop Platform. I think Adafruit sells it too.
We did a very short run of those boards, only 3. But, I still have 2 left, if you're interested...
I think I've posted the code to do 6 panels from 1 Prop in 18-bit color or 3 panels in 24-bit color.
We've got some more info on our website...
What is the cost of the adapter board for the Prop platform that you have. You can PM me if you like or just reply back here. I will need to get a power supply too for 3-6 of the 16x32 or 32x32 displays. Sure Electronics had a 5vdc up to about 20 or 25 A but they may have discontinued it as I didn't see it. I'm starting out with nothing so I will need to get everything to start over again. Any help you can provide would be appreciated. I beleive your website listed code for 24 bpp for 3 displays not the 6 displays. Let me know what else I will need for a Propeller Prop outfitting for the RGB display.
Thanks again!
Tim
I was just using a regular 3A, 5V power supply with the intensity turned way down.
At some point, I want to try using a regular PC power supply to crank it up...
You don't really need my Prop Platform "shield", you can just use jumper wires.
But, if you like I can sell one of my prototype boards for say $15. It does make it a whole lot easier to connect, you just plug in the IDC cables.
If you're interested, just send an email to ray@rayslogic.com .
You might also want a few longer IDC cables. The data cables that come with the panel are very short.
I found some on Ebay for a reasonable price.
I may have not gotten around to posting the 6-panel code. But, I can email it to you...
This may not be exactly the best example to start out learning with... I had to use a few tricks as 6-panel mode does push the Prop close to it's limits...
But, I did try to make it at least fairly readable...
Still, if you're brand new to the Prop, I'd recommend looking at some PE Kit examples and blink some LEDs with Spin first...
BTW: It is possible to program in C with the Prop right now using Catalina (and GCC is coming). That might not actually be a bad option for an application like this that uses up a lot of memory. But, it would take a lot of work, I think, to translate it...
Anyway, if you want to stick to Basic, I think it's possible to use Bean's PropBasic... That's supposed to be as fast as Spin and also allow assembly routines.
Haven't tried it myself though.
Actually, I think this is something that could easily be made into a commercial product...
I bet there are a lot of small businesses that would love a low cost - open source, daylight-visible display....
Thank you so much. The sheild is great. Pop it on the Propeller Platform, plug in the IDC cable and apply power. I am still trying to understand your code (well Propeller SPIN code in general) first. Taking it slow. So far, I have been using your Adafruit Demo 1 software (used with 3 displays). I have put in the -1 code for displays 2 and 3 as I only have 1 display for the moment. I also modified it to scroll a BMP up down, left and right. Not much but never using the Propeller SPIN software, its really neat (just a little hard to put together in my head going back and forth between the main, driver and graphics programs.).
I'll have questions I'm sure but I'm trying not to bother you unless, I just can't get it.
Thanks again,
Tim
I know the Propeller Platform is limited left to right (to 3 displays with your sheild) due to the amount of available pins/IDC sockets on your sheild. Do you think the Propeller Platform could handle it, if a new sheild could be developed for 4 displays (ie 6 outputs from P0-P3, P28-P31)? Is is even ok to use P28-P31?
Or could another set of 3 displays (or more) piggy back off IDC ports 4,5,6 on your sheild (providing 3x3 displays=9)? Can your current software handle it. Looks like all that would change is:
long OutputArray[96*8*8] '96 pixels wide, 8 bits of color, 8 segments
Just trying to see what the largest resolution is possible with the Propeller Platform. How about using a 6.25 MHz crystal for 100 MHz clock speed (or faster) if this would help?
I'm studying your code and the Propeller SPIN language manual (so much to learn!) and it's been a challenge but I'll get it eventually. Knowing when and when not to pass an address is the hardest for me (ie @balance). Your routines for text, BMP graphics, pixel displaying are great! I can manipulate them for the most part.
Let me know about adding more displays if possible with a single Propeller. How about controlling 2 Propellers somehow? I have done that before with the Parallax SX-28 chips with TX/RX commands.
Thanks,
Tim
This will help with the other problem, the Prop being almost of memory...
If you drop from 24 to 12 bits per pixel, you should be able to do 12 panels as 3 strings of 4 in series...
Another issue:
I was looking at your program Adafruit_Test8. This loads in 7 BMP files but uses slower SPIN to display them with the SetPixel method which is done correctly.
PUB ShowBitmap(pBmp)|p,x,y,i 'Show a bitmap 'This needs to be sped up with assembly code! 'Read bitmap header p:=ReadBitmapHeader(pBmp) 'Check to make sure bitmap is correct dimensions if biHeight<>16 return if biWidth<>32 return if biBitCount<>24 return 'Set all the pixels repeat y from 0 to 15 repeat x from 31 to 0 SetPixel(x,y,RGB(byte[p--],byte[p--],byte[p--]) )Notice the repeat x from 31 to 0 line in code.
However, your latest Adafruit_Demo3_NewYear program uses an Assembly routine:
DAT AsmShowBitmap_ 'Display a 24bpp pixel at given x and y mov t3,#5 call #GetArgumentsSub 'arg0=address of bitmap bits 'arg1=x0 'arg2=y0 'arg3=Width 'arg4=Height mov y1,arg2 AsmBmpLoopY mov x1,arg1 mov t9,arg3 AsmBmpLoopX rdbyte pixelc,arg0 sub arg0,#1 rdbyte t1,arg0 sub arg0,#1 rdbyte t2,arg0 sub arg0,#1 rol pixelc,#16 rol t1,#8 add pixelc,t1 add pixelc,t2 mov pixelx,x1 mov pixely,y1 call #SetPixelSub add x1,#1 djnz t9,#AsmBmpLoopX add y1,#1 djnz arg4,#AsmBmpLoopY 'all done jmp #loopThis Assembly routine flips the image in reverse (ie Hello World BMP reads as 'dlroW olleH' and what facing the right now faces the left)
I noticed that if you change the original SPIN line repeat x from 31 to 0 to repeat x from 0 to 31 then it follows the same image flipping as your Assembly routine.
Is there any quick fix for the Assembly routine to fix it. I don't know Propeller Assembly yet and thought I would ask you.
I have attached your code (my modified code - so you can see what I mean).
Thanks again,
Tim
There are actually 3 different ways bitmaps are handled, depending on if they are 24, 8, or 4 bits per pixel.
I kinda concentrated on the 4 bits per pixel routine because I wanted to embed a large text image.
The 8bpp routine is done in spin with setpixel.
It must be the 24bpp routine that's backwards.
I guess you can either fix it or flip your image on the computer...