Shop OBEX P1 Docs P2 Docs Learn Events
16 and 256 color BMP Video drivers — Parallax Forums

16 and 256 color BMP Video drivers

AribaAriba Posts: 2,682
edited 2013-04-01 17:49 in Propeller 2
Here are two drivers that can show a BMP file direct. No bitmap converter or palette extraction is needed.
Just load the BMP to hubram and start the driver.
The BMP file must be uncompressed and the pixel size must fit to the driver.

The first driver supports 16-color BMPs with 384x128 pixels on PAL video.
The second driver supports 256-color BMPs with 256x100 pixels on NTSC video.

Both repeat every line two times so you get 384x256 and 256x200 pixels on screen.

Making other resolutions is easy, I have chosen this sizes because they fit in 24..25 kByte and work therefore with my DE0-Nano.

The drivers work with the CLUT modes of the video generator. First the palette is loaded from hubram to the stackram (CLUT). Then I just read the bitmap data in longs from hubram an feed every long to the video generator, the color lookup is done by the Prop2 hardware. BMP lines are (normally) stored from bottom to top in the file, so the read pointer needs to be modified a bit between the lines.

You will need P2Load to download the bitmaps. The attached ZIP also contains the *.bin files of the drivers, so you don't need to start PNUT to try it out.
The bitmaps must be loaded to a certain address in hub, so that the palette data is long aligned:
$17CA for the first driver, and $16CA for the second driver.

If you have P2Load in the same directory, then just type: (replace <com> with your COM number)
p2load -p<com> realmario4.bmp,17CA pal_384x128_clut4.bin

p2load -p<com> realmario8.bmp,16CA ntsc_256x100_clut8.bin


have fun

Andy

Edit: The updated ZIP contains now versions with both resolutions for NTSC, PAL and VGA !

Comments

  • Bill HenningBill Henning Posts: 6,445
    edited 2013-03-31 16:01
    Nice!

    I'll try them tomorrow, I have family over today :)
  • Cluso99Cluso99 Posts: 18,066
    edited 2013-03-31 17:18
    Nice Andy. I must get may DE0 addon board running to try this out. But I am still having fun adding options to my debugger.
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-31 17:26
    Hi Ariba.

    Very nice PICTURE. And it fill entire LCD area on my one NOT only small region in midle

    Thanks
  • SapiehaSapieha Posts: 2,964
    edited 2013-03-31 17:56
    Hi.

    Picture from my PAL LCD

    Mario_PAL.jpg
    1024 x 768 - 89K
  • BaggersBaggers Posts: 3,019
    edited 2013-04-01 01:48
    Great work Ariba :)
  • ColeyColey Posts: 1,108
    edited 2013-04-01 04:11
    Ariba,

    The NTSC displayed perfectly but I noticed the PAL doesn't.
    It's almost as though every horizontal pixel is reversed with the next one like the bits are being sent in the wrong order.

    To demonstrate this I did a simple 16 colour bitmap with some text.

    16coltestresult.jpg


    16coltest.bmp
    1024 x 768 - 106K
  • AribaAriba Posts: 2,682
    edited 2013-04-01 05:05
    Thank you guys

    It is mainly Chip's work, if you look at the source, the field loop is really straightforward, and the hardware does most of the decoding.

    @Coley

    It looks like the two 4bit pixels in a byte must then be swapped. This was not visible with the Mario picture. So for the 16-colour mode you can not just feed the video generator with longs from the bitmap. We will need an algorythm that swaps the 2 nibbles in all bytes of the long.
    I will look tonight into this.

    Andy
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-04-01 05:41
    Here is some quick and dirty code that should swap the nibbles for you in 6 cycles/long: (untested)
            ' input in rawpix
    
    	mov	work,rawpix
    	shl	work,#4
    	and	work,himask
    
    	and	rawpix,himask
    	shr	rawpix,#4
    	or	work, rawpix
    
           ' output in work
    
    
           ' required data
    
    himask	long	$F0F0F0F0
    rawpix	long	0
    work	        long	0
    
    Ariba wrote: »
    Thank you guys

    It is mainly Chip's work, if you look at the source, the field loop is really straightforward, and the hardware does most of the decoding.

    @Coley

    It looks like the two 4bit pixels in a byte must then be swapped. This was not visible with the Mario picture. So for the 16-colour mode you can not just feed the video generator with longs from the bitmap. We will need an algorythm that swaps the 2 nibbles in all bytes of the long.
    I will look tonight into this.

    Andy
  • ColeyColey Posts: 1,108
    edited 2013-04-01 13:09
    Thanks Bill, that worked great!

    16coltestresultfixed.jpg


    PAL_384x128_CLUT4.spin
    Here is some quick and dirty code that should swap the nibbles for you in 6 cycles/long: (untested)
            ' input in rawpix
    
        mov    work,rawpix
        shl    work,#4
        and    work,himask
    
        and    rawpix,himask
        shr    rawpix,#4
        or    work, rawpix
    
           ' output in work
    
    
           ' required data
    
    himask    long    $F0F0F0F0
    rawpix    long    0
    work            long    0
    
  • AribaAriba Posts: 2,682
    edited 2013-04-01 13:18
    Yes, with swapping the nibbles the 16 colour mode shows the pixels in the right order.

    I have now made both color modes and resolutions for NTSC and PAL. And also both versions for VGA (signaled as 800x600).
    You find it all attached to the first post. There is also a picture of a wolf in the ZIP, which is much more challenging for low color modes, than the Mario-picture.

    Andy
  • Bill HenningBill Henning Posts: 6,445
    edited 2013-04-01 14:10
    You are most welcome!
    Coley wrote: »
    Thanks Bill, that worked great!

    16coltestresultfixed.jpg


    PAL_384x128_CLUT4.spin
  • Cluso99Cluso99 Posts: 18,066
    edited 2013-04-01 17:49
    These are nice pics guys. Keep up the excellent work!
Sign In or Register to comment.